Re: SEPA Credit Transfer + W3C PaymentRequest

On 2019-08-19 16:12, KETELS Kris wrote:
> Hi Anders,

Hi Kris,

> 
> Thank you!
> 
> A small note maybe on your wording re. ISO 20022 that it was not designed for the frontend; actually it was designed to be used in any financial environment. It is indeed predominantly used in the backend because that (used to ;) be dominated by banks.

The story here is that security does not seem to be an *integral part* of ISO 20022 while it is the *very core* of schemes like FAPI (Financial API) and Saturn.
If I have got this wrong, please provide a pointer to the appropriate public[*] ISO document.  BTW, I surely don't claim to be an ISO 20022 guru :-)

Anyway, FAPI and Saturn use very specific (non bank-ish) information flows which made their respective security solutions equally specific.


> Now that the pre-settlement space been commoditised and has opened up to other types of players, it would be a good strategy to use 20022 in that space as well (where applicable) at least for the information flows, to reduce friction.

I'm not sure what you are referring to here, any pointers would be much appreciated.

AFAIK, most Open Banking APIs targeting non-direct payments using credit transfer, do this by building what UK's OBIE call "overlays" which deal with all but the final credit transfer operation.  The rationale for that is that it can be applied to any system and be readily extended when needed.  Saturn builds on this concept as well, including support for refunds.

In Saturn a design goal was to liberate the "Wallet" from payment system details associated with the backend.  I feel that this has been accomplished.  However, after the Wallet has delivered its result, the Merchant must still request to be payed including adding whatever is needed for the actual payment system (like PAIN.001). See the yellow box in step #4:
https://cyberphone.github.io/doc/saturn/saturn-authorization.pdf
So yes, there is ISO 20022 support in Saturn but not in the "Wallet"!

William Vanobberghen writes:
 > As you certainly know, ISO 20022 is used today in Instant payments (SCTInst) where response time is key and could perfectly be used tomorrow at a point-of-sale through an ISO 20022-style “RequestForPayment” API or through a card-initiated payment authorisation

It is hard for me to have an opinion about that since such a system has yet to be documented.  Saturn is BTW based on using the same protocol in every merchant-initiated payment scenario, be at the PoS, Gas Station or the Web.

Kind regards
Anders

*] I have a bit of an issue with pay-for standards and I'm actually not alone.  Maybe https://www.iso.org/standard/59848.html is a great standard, maybe it is not.  Very few will ever know...

> 
> Kind regards
> 
> *From:*Rouslan Solomakhin [mailto:rouslan@google.com]
> *Sent:* Sunday, August 18, 2019 2:40 PM
> *To:* Anders Rundgren
> *Cc:* Web Payments Working Group
> *Subject:* Re: SEPA Credit Transfer + W3C PamentRequest
> 
> Mail originates from outside SWIFT !
> Be vigilant before you click on a link, open attachments or reply !
> -------------------------------------------------------------------------
> 
> Thank you for the kind words, Anders.I'm happy that you were able to get you Android payment app working with Chrome. For the curious, here's some documentation on it: Android payment apps developer guide <https://developers.google.com/web/fundamentals/payments/payment-apps-developer-guide/android-payment-apps>. Anders gave us excellent feedback on the docs that we are planning to incorporate into the docs.
> 
> On Sat, Aug 17, 2019 at 10:37 AM Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
> 
>     Hi Payment Aficionados,
> 
>     F.Y.I. I'm putting the finishing touches on a Payment Authorization solution for account-2-account based transactions like SEPA Credit Transfer.  It builds on a native Android application invoked by Google's Android implementation of W3C's PaymentRequest. Aided by excellent help from Rouslan it wasn't too difficult to get PaymentRequest going.
> 
>     This implementation uses massive amounts of cryptography to enable an end-2-end secured and scalable trust model which I believe is new for the banking industry:
>     https://cyberphone.github.io/doc/saturn/enhanced-four-corner-model.pdf
>     Yes, authenticating Merchants is (in this scenario NB) a prerequisite.  AML considerations also speak for this.
> 
>     The client also needed some pretty advanced security features to cope with the rather demanding push payment model:
>     https://cyberphone.github.io/doc/saturn/saturn-payment-credentials.pdf
> 
>     Signed and encrypted JSON data is based on
>     https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-06
>     which I hope to get published as an "Informational" RFC.
> 
>     It was a pleasure replacing the awkward (and security broken) URL handler scheme with PaymentRequest!  Suddenly the App became an integral part of the browser experience.
> 
>     If anybody wonder where ISO 20022 is in this scheme the answer is simple: ISO 20022 was designed for the "backend" while this system targets the "frontend".  Of course the information need to perform the backend operations must be available, but that is not the same thing as running the entire system on ISO 20022.  The security constructs as well as the message in step #4 has no counterpart in any backend protocol.
> 
>     Thanx,
>     Anders Rundgren
>

Received on Monday, 19 August 2019 16:04:04 UTC