he European Banking Authority (EBA) has published the long-awaited draft of the Regulatory Technical Standards (RTS) covering Secure Customer Authentication (SCA) and secure communication. Apologies in advance for the Three Letter Acronyms (TLAs) which litter the PSD2 landscape!
There’s a lot to digest, but the key points are highlighted here, along with some thoughts around the impact on the market.
1) Banks to define their own interfaces
It’s up to banks – referred to in the legislation as Account Servicing Payment Service Providers (ASPSPs) – to define their own interfaces. Article 19.4 says “Account servicing payment service providers shall make sure that the technical specification of their communication interface is documented, the documentation made available for free and publicly on their website.”
This drives a stake through the heart of the idea of a defined, interoperable standard for these interfaces. The EBA mentionS that IT considered the arguments for a “governing entity” to define and police a standard, but decided that “the future RTS must not prescribe the use of a specific industry standard of internet communication”.
To provide true interoperability, a detailed, centrally imposed standard would be needed. This would be inflexible and difficult to police. Although Account Information Service Providers (AISPs) and Payment Initiation Service Providers (PISPs) have managed to survive and thrive in the current “Wild West” of ad-hoc interfaces and screen-scraping, a set of principles will at least be a step forward, and much less onerous than a rigorous standard.
2) APIs, not screen scraping
The paper effectively mandates the use of “proper” APIs. It says that “each ASPSP shall offer at least one communication interface…which shall be documented and freely available on the ASPSP’s website”. This interface “shall use ISO 20022 elements, components or approved message definitions.” This definition excludes the use of existing Internet Banking interfaces, which generally don’t use ISO 20022 data elements, would be extremely difficult to document.
While it is possible to implement interfaces using “screen scraping” of Internet Banking websites, it is certainly not good practice. There are plenty of technologies specifically designed to support dedicated machine-to-machine APIs which can offer a more secure and robust interface, including the required controls on which entities can perform which operations on which accounts.
3) Payment security up to the banks
The paper clarifies that it’s up to the banks to define the security procedures to be applied when a third party initiates a payment. The EBAs say that normally “the authentication procedure will remain fully in the sphere of competence of the ASPSP” and that the Payment Initiation Service (PIS) would only authenticate the customer (Payment Service User or PSU) in case of a prior contractual agreement between the PIS and the ASPSP, and that agreement would be outside the scope of PSD2.
This means that the model that PISPs like Paypal and Amazon currently use for card payments, cannot be used for PSD2 payments unless separate contractual agreements are established with each ASPSP used by European customers. If such agreements would be “outside the scope of PSD2”, does that mean they would be outlawed because discrimination between PIS is not allowed? If so, the plans of some organisations to transparently replace current card payment methods with PSD2 push payments may be confounded.
4) Generating authentication codes
All those points are detailed on the Web site http://www.paymenteye.com/…
5) Dynamic Linking of authentication codes
6) Exemptions from Secure Customer Authentication
7) Sensitive payment data
8) Use of eIDAS Authorities
9) Card Not Present requires Secure Customer Authentication
I also add the Cap Gemini Info-graphic
For more information you can dive into the Regulation itself: Regulatory Technical Standards on strong customer authentication and secure communication under PSD2