RE: SEPA Credit Transfer + W3C PamentRequest

Hi Kris, Anders and All,

We do confirm on our side as well that ISO 20022 is used today with much success in card payments working in an interactive mode (authorisation and all other types of card payment message exchanges starting from a merchant to a bank acquirer – ISO 20022 CAPE series of messages  - up to an issuer – ATICA ones).

Furthermore, as Kris may confirm, it could perfectly well be used in an API environment following the principles that have been worked out by Kris and other participants to achieve a global ecosystem of data exchanges in the financial world around a unique ISO 20022 methodology (both messages and APIs).

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. ISO 20022 has also become the preferred methodology for clearing and settlement services (e.g. TIPS, STET in France).

Best regards,

William

De : KETELS Kris <Kris.KETELS@swift.com>
Envoyé : lundi 19 août 2019 16:12
À : Anders Rundgren <anders.rundgren.net@gmail.com>
Cc : Web Payments Working Group <public-payments-wg@w3.org>; Rouslan Solomakhin <rouslan@google.com>
Objet : RE: SEPA Credit Transfer + W3C PamentRequest

Hi Anders,

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.
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.

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

--------------------------------------------------------------------------------------------------------------------------------------------
Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est  susceptible d'altération. Le Groupement des Cartes Bancaires "CB" décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié.


This message and any attachments are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Groupement des Cartes bancaires "CB" shall not be liable for the message if altered, changed or falsified.