The ERPB Highlights the Holes in PSD2

A year ago, the European Retail Payments Board (ERPB) flagged that “In practice, PSD2 and the EBA RTS will not cover all aspects that are relevant for the development of an integrated market of Payment Initiation Services (PIS) in the EU”. In November 2016, they set up a Working Group on Payment Initiation Services “to identify conditions for the development of an integrated, innovative and competitive market for payment initiation services in the EU”, to which Icon Solutions contributed via CAPS. The working group has now published its report, which highlights several important gaps that need to be filled. Unfortunately, regarding interfaces, disagreements in the working group prevented consensus being reached.

Identification of TPPs
The RTS says that Third Party Providers (TPPs) must identify themselves towards Account Servicing Payment Service Providers (ASPSPs – “banks”, roughly speaking) using eIDAS digital certificates. The data carried in the certificate is limited, and there is no rule linking the withdrawal of a TPP’s authorisation with the revocation of their eIDAS certificate. The working group therefore proposes the creation of an online machine-readable pan-European directory of TPPs (and ASPSPs) that can be updated in real time.

Use of certificates
The RTS mandates the use of eIDAS digital certificates for identification of PSPs, and specifies information to be carried in the certificate such as the role of the PSP. The encoding of this additional information must be standardised to ensure interoperability, and CAPS is driving an initiative with ETSI, the organization responsible for European digital certificate standards, to agree the required definitions.

The meaning of “payment initiation”
When an ASPSP responds to a TPP to confirm that the payment has been initiated, that could have different meanings depending on the ASPSP and the payment system used. At one extreme it could mean that the payment order has been accepted, but the availability of funds has not been checked, and funds have not been blocked. At the other extreme, if an instant payment (e.g. SCT Inst) is executed, it could mean that the payment has been cleared and the funds are already available in the beneficiary account. If Payment Initiation Services are to be useful for e-commerce, the merchant needs a guarantee that the payment has been, or will be, executed. The working group did not reach an agreement how a consistent guarantee can be offered.

Information needed for payment initiation
PSD2 draws a distinction between Payment Initiation and Account Information, but the Working Group pointed out an overlap. When a payment is initiated, customers with multiple accounts must choose the account from which they want the payment to be made. For the TPP to present the list of accounts to the customer, the ASPSP must provide the information, which arguably falls into the sphere of Account Information rather than Payment Initiation. As well as account numbers, some TPPs wanted additional information such as balances, overdraft limits, pending transactions, etc. Again, the working group was unable to agree whether this should be provided.

Relying on the ASPSP for authentication
PSD2 specifies that a TPP can rely on the ASPSP to authenticate the customer using Strong Customer Authentication (SCA). Three models have been identified:
• Embedded: the TPP captures the personal security credentials (e.g. username/password/2nd factor) of the customer and transmits them to the ASPSP
• Redirection: the PSU is redirected to the ASPSP’s website for the sole purpose of authenticating the customer
• Decoupled: SCA takes place via a dedicated device and/or app
The Embedded approach is used by the “screen scraping” TPPs today, and the working group was unable to agree whether that should be supported under PSD2.

API standards
Given the differences of opinion already noted, it is no surprise that there is no agreement on the technical standards to be applied to APIs offering the Payment Initiation (and Account Information) services. National and cross-border standardisation initiatives exist – the Berlin Group, STET in France, CAPS, and UK Open Banking – but there is no harmonised pan-European approach, hence no interoperability. The report glosses over the deep disagreements and entrenched positions highlighted by the recent screen-scraping debate, leading the ERPB to comment that “the working group did not deliver on all parts of its mandate.”

Fraud information
The RTS specifies several data items that must be checked to prevent fraud, and several more that must be examined if a PSP wants to apply the Transaction Risk Analysis exemption from SCA. This implies that those data items must be passed from the TPP to the ASPSP, so must be specified in the API definition. This requirement seems to have been overlooked in some of the standardisation initiatives.

Liability framework
Article 73 of PSD2 says that in case of an unauthorised payment, the account servicing payment service provider shall refund immediately; and if the payment initiation service provider is liable for the unauthorised payment transaction, it shall immediately compensate the account servicing payment service provider. No mechanism or framework is defined for determining liability or resolving disputes. This must be defined to enable an effective market for the professional indemnity insurance that TPPs are mandated to hold.

Next steps
The Report highlights several gaps that need to be filled to make PSD2 effective and interoperable across Europe. The question is, how will those gaps be filled? The ERPB invites the working group “to present its final report taking account of the finalisation of the EBA Regulatory Technical Standards on authentication and communication and to respond fully to the different dimensions of its mandate for the next meeting.” That can only be effective if the current “fintechs vs banks” mentality is overcome. Failure to do so will result in a fragmented market that benefits no-one.