PSD2

Status: These notes were prepared by Cyril Vignet for discussion at the 25 January 2016 teleconference of the Web Payments Interest Group. See also Notes on PSD2 and Blockchain from Paddy Ramanathan. Theses notes have been updated (major upadate) by Cyril Vignet with help of Frederic Meignein for discussion at F2F IG meeting at San Fransisco, february 2016

PSD2 reference

PSD2 (Payment services Directive number 2)

Legacy relationship between client and Bank

Usually, a bank is providing the management of accounts. Retail activities are based on a direct relationship between the client and his bank:

• Human relationship in the branch
• Web interaction with home banking

The 3 main interactions due to use of bank services are listed on the chart below. In this chart, we replace the term bank by Account Servicing Payment Service Provider to use the vocabulary of the PSD2.

2016-CYV-PSD2-003.png

New opportunities brought by PSD2

The PSD2 (Payment services Directive number 2) is the new regulatory framework following PSD1 (2007, effective 2009). Among a lot of important matters, the PSD2 creates 2 new types of regulated actors related to payment:

• PISP, Payment Initiation Service Providers, which can initiate Credit Transfers on behalf of the client.
• AISP, Account Information Service Providers, which provide aggregation services on account data

PISP

2016-CYV-PSD2-004.png

Using UML terminology in the chart, Alice is an “actor” i.e. a human being, PISP, AISP and ASPSP are “participants” i.e. information systems.

Obviously those interactions bring some issues:

• What is the nature of the Authentication between the client and the PISP
• How the previous Authentication between client and ASPSP should evolve with the presence of the PISP?
• What is the nature of the Authentication between the ASPSP and the PISP?
• How to interconnect those 3 authentication process in order to have a secure “3 actors” system

Furthermore the PSD2 asks:

• for a strong authentication (2 means on 3) of the client, with possible exceptions to be determined
• for a strong authentication with dynamic link to amount and beneficiary in case of a payment
• for prior reimbursement by the bank if the client claims the transaction to be unauthorised, then the bank asks the PISP
• no obligation from a PISP towards an ASPSP

AISP

2016-CYV-PSD2-005.png

Obviously those interactions bring same type of issues:

• What is the nature of the Authentication between the client and the?
• How the previous Authentication between client and ASPSP evolves with the presence of the AISP?
• What is the nature of the Authentication between the ASPSP and the AISP?
• How to interconnect those 3 authentication process in order to have a secure “3 actors” system

Furthermore the PSD2 asks:

• for a strong authentication (2 means on 3) of the client with possible exceptions. Even if the PSD2 do not detailed the first time and recurrent connection, for a user perspective it is admitted that:
  • the authentication for the first time (when the client asks the AIPS to aggregate) should be strong
  • then, the recurrent connection of the AISP to ASPPSP do not involved the client for systematic strong authentication
• without any contractual obligation from a AISP towards an ASPSP.

Business opportunities

To summarize, we could say that the PSD2 asks for an open Account-API to any regulated business:

• with all the existing/state of the art security for client
• with the minimum barriers for those new business. Indeed, existing contractual relationship for a PISP (or AISP) to any ASPSP (banks) in Europe is impossible.

In our view, we could expect 3 business opportunities:

• Full view and management of accounts for Alice
  • A combined AISP/PISP company provides an aggregated view of all the accounts of Alice
  • Furthermore, this company could provide cash management facility to easily transfer money from an account to another
  • Done with a smooth user experience and mobile App, it will help client to simplify his banking activities management
• New Payment Process for Web Merchant
  • A PISP provides a new service for the merchant that enables any client of this web merchant to pay easily with credit transfer
  • As the credit transfer is usually free at the home banking, we could imagine the payment cheaper than card system
  • Furthermore, we could also imagine high payment amount because the limit is depending of the balance of the account and not on authorisation limit
  • On the other side, there are no payment facility as we could have credit card debited end of the month or by instalments
• New Payment service for client at web merchant
  • A PISP provide a service Alice to pay to any merchant with credit transfer
  • It is slightly the same as above but the PISP is client-oriented and not merchant oriented, as we could see in card wallet inititives
  • Note: in the card systems, the client choose one of cards he possesses depending on marketing opportunities, rebates or additional couponing, miles,…
• Any other businesses that creative people will invent

Implementation issues

There are a lot of issues related to opening those Account APIs. At a conceptual level those issues are all related to:

moving from a bilateral paradigm (client <-> ASPSP) to a 3 corner model (client, AISP, ASPSP) or a four corner model (client, merchant, PISP, ASPSP) with the same level of security

• Authentication issues for AISP or PISP to ASPSP
• Authentication issues for ASPSP with their client, especially if flows are not supposed to be direct between ASPSP and its client (man in the middle breach)
• Traceability of authentication related to transaction
• Integrity of a transaction, which is composed of several messages between different actors
• User experience that should be smooth and fluid
  • When paying using PISP
  • When enrolling at an AISP
  • When managing access authorisation already given
• SEPA credit transfer is not designed to do that easily:
  • The IBAN of the beneficiary (i.e. the merchant) is done at the risk of the client today. In the future this risk should be mitigating because the IBAN is no more provided by the client.
  • Once the credit transfer initiated, the ASPSP do not provide signed acknowledgement that could be transmitted to the merchant and PISP. But those participants are waiting for this information before launching delivery process (and DSP2 asks clearly to provide this information).
  • Furthermore, real time process of the credit transfer initiation at the SAPSP is not always available but should be for DSP2 compliance

Note: the previous charts designing to explain PDS2 new actors have a note stating that are not flows but only interactions. This is an important matter because security issues arise depending of the workflows between actors.

At this stage, the EBA (European Banking Authority) is currently defining some technical standards. (IJ: I'm not sure this is accurate from my understanding of the current status of EBA work; we'll learn more on 22 Feb.)

An interesting model is to consider is the 3DS model, that deal with a 4 actors paradigm. Furthermore, a proposal had been made at the WPIG to deal with all those implementation issues, not only for Credit Transfer, but for all types of payments. https://www.w3.org/Payments/IG/wiki/Main_Page/ProposalsQ42015/SCAI

Use cases

Paying at web merchant (with PISP Merchant oriented)

• The user is finishing his shopping at a webmerchant and accepts the cart
• This merchant offers to pay with “PISP Brand”.
• The user will select the his favourite ASPSP
• A credit transfer initiation will be sent to the ASPSP
• The user will confirm the credit transfer with a strong authentication (related with the merchant and the amount according with the DSP2)
• The PISP will receive a confirmation that the credit transfer is on progress
  • Initiation
  • Banking acceptation
• The PISP will provide credit transfer status to the merchant
• The merchant will process to deliver the goods or services

Paying at a web merchant (with PISP client oriented)

• The user is finishing his shopping at a webmerchant and accepts the cart
• This merchant offers to pay with “Credit Transfer”.
• The user will select the his favourite PISP which will propose the ultimate user experience to choose
  • Clear view of all accounts with real time balance
  • Commercial opportunities to pay with an ASPPSP …
• A credit transfer initiation will be sent to the ASPSP chosen
• The user will confirm with a strong authentication (related with the merchant and the amount) the credit transfer
• The PISP will receive a confirmation that the credit transfer is on progress
  • Initiation
  • Banking acceptation
  • Interbank settlement
• The PISP will provide credit transfer status to the merchant
• The merchant will process to deliver the goods or services

Registering of an AISP

• The user is on the website of an AISP
• The user will select all the IBAN of his accounts in different banks
• The user should authenticate to all banks in order to declare the AISP
• The AISP get the data and confirm the registration

Using daily the AISP

• The AISP retrieve daily the data form the user without bothering the user (no strong authentication)
• The user connects to the AISP using an reliable authentication
• The user could admire the ultimate aggregation service of all his accounts

PSD2 and the W3C (WebPayment Interest Group or authentication TF)

We believe that there should be a strong interest of the W3C to work on the PSD2 issues as mentioned above:

• PSD2 will have a major impact on banking web usage in Europe
• The view of an ASPSPS API will overrun the European boarders to other countries
• The new security and transaction paradigm (with 4 actors) is enhancing the existing bilateral concept and could be leverage in other W3C activities
• The PISP webpayment is part of the WPIG charter (use of Credit Transfer as payment method)
• The PISP and AISP uses cases should be consistent with other webpayment use case to provide a good user experience