In combination, the EU’s Second Payment Services Directive (PSD2) – and the European Banking Authority’s (EBA’s) related Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA) and Secure Open Standards of Communication (CSC) –profoundly impact banks' IT systems and business models.

They open up banks’ systems to third-party payments services providers (TPPs) for account information, payment initiation and confirmation of funds via access interfaces such as application programming interfaces (APIs). The RTS also describes requirements regarding SCA.

While banks must comply with the RTS by 14 September 2019, many questions remain unanswered. Bodies such as the ERPB API Evaluation Working Group, Open Banking Europe from PRETA, Berlin Group, European Commission and European Central Bank have clarified some issues, but areas of uncertainty remain. The EBA is also seeking to build consistent supervisory practices across the EU, and on 13 June 2018 it published an opinion paper on the RTS implementation. I’ll now look at the most important clarifications, along with their consequences and the questions still to be addressed.

Customer consent

The opinion paper says contracts between TPPs and customers can be bilateral, with ASPSPs not checking the consent provided by the customer to the TPP, and consent being implicit through SCA performed by the ASPSP. There are ongoing controversy discussions in the market that ASPSPs could include a TPP registration process in their developer portals which is contradicting to PSD2 and RTS. A clear statement need to be made that additional registrations at ASPSP side are not compliant.

Data scope and four-times-per-day limit

PISP: PISPs should be allowed to check availability of funds before initiating a payment. The service of confirming availability of funds is initially granted for PIISPs, and is especially important where an ASPSP’s systems use batch rather than real-time processing. In these cases, the ASPSP should enable the TPP to check the payment status (pull) or send a notification (push).

AISP: AISPs should have access to the maximum data fields available to the PSU regardless of channel. This means the ASPSP must provide the same level of information to the AISP as is provided to e.g. the mobile channel or a “computer online connection”, which may have more fields than does the desktop browser version. It remains unclear what this means for e.g. specialized B2B interfaces such as EBICS that can carry even more data fields (e.g. camt.052); is it required that the API provide these huge amounts of additional fields? And while AISPs can request customer account information up to four times a day if the customer is not actively requesting an update, AISPs and ASPSPs could contractually agree to exceed this number. This also raises the question of how a bank evaluate check if a request was initiated by the customer or TPP.

Guidance on what payment account types should be in scope is also missing.

Strong customer authentication

SCA of the payer must be performed on all payment transactions, including credit transfers and card payments. The opinion paper describes three elements – knowledge, possession and inherence – but lacks guidance on which SCA methods are compliant with the RTS. The biggest question concerns the existing biometrics mechanisms provided by smartphone manufacturers. How does this fit with dynamic linking, issuance of security credentials and validation of biometric data in the bank environment?

The opinion paper also states that a card’s CVV number obviously cannot be the second authentication factor for "knowledge" since it is plainly visible. Today, card schemes mostly run second-factor methods such as 3D Secure via the issuer bank's decoupled app or via SMS TAN. Again, guidance is needed on what SCA methods are RTS-compliant in this case as well.

TPPs can rely on the SCA methods provided by the ASPSPs which have the final word on authentication. The ASPSP can agree to delegate SCA to the TPP, but remains liable in case of fraud and losses. What happens, however, if there is no delegated SCA solution in place? In the worst case, TPPs such as wallet providers might have to perform SCA and the ASPSP on top of it as well. A wallet can be considered as a completely new payment instrument even if they rely on underlying other payment instruments such as cards. Clarity is required here as well.

EBA clarifies that a device such as a smartphone can be considered as “possession”, there needs to be a reliable means to confirm possession through the generation or receipt of a dynamic validation element on the device. There are technologies in place today to ensure this but some more recommendations will need to be provided.

Exemptions from SCA

EBA states that only the payer's PSP – not the payee’s – can determine SCA exemptions. For card transactions, multiple exemptions can be applied by the acquiring side, ranging from contactless to recurring to low-value payments. The 90-day exemption for AISPs to access account information needs to be applied separately for each AISP. However, it remains unclear if the exemptions for PISPs on low-value credit transfers (30 EUR and 100 EUR accumulated, up to five transactions) and contactless payments (50 EUR, 150 EUR accumulated, up to five transactions) must be counted together or separately per channel. A credit card can be used as physical card or virtually in a wallet at the POS. The question is: does the counter apply per card account or per representation (physical and multiple virtual representations in different digital channels)? As already stated above, the wallet itself can be considered as a new payment instrument and hence counters apply separately – but a confirmation of this is missing here.

Acquirers and banks are not allowed to use transaction risk analysis (TRA) to increase the exemption thresholds for trusted merchants or specific channels. Hence, TRA is not a reliable mechanism for merchants to exempt from SCA for higher amounts and allow merchants to offer frictionless payments. Banks won't be able to monetize this option to offer better fraud rates for partnering trusted merchants.

Assuming an ASPSP decided not to set up a dedicated interface but rather, to only have an “adapted PSU Interface” allowing screen scraping, would SCA exemptions be applicable for that interface as well? The opinion paper leaves this question unaddressed.

How to handle SCA approaches

Article 32 of the RTS, regarding obstacles in the context of the redirection SCA approach, also raises a key question. While the redirection approach is generally not considered an obstacle as per the EBA opinion paper, the way an ASPSP implements it may become a barrier if a technically more convenient approach is available. However, the paper provides no recommendation on the preferred approach. The market voice on this is that the redirect approach is preferred for smaller fintechs (cheap option for fintechs to quickly to adopt) and the embedded one for bigger players (more expensive for TPP but would own the customer interface).

What's next?

While the EBA opinion paper provides some high-level guidance on RTS implementation, more detailed and technical answers are needed – time is running. As a result, the NCAs’ interpretations of its national guidelines are likely to vary, making it difficult for TPPs to build services applicable for the entire EU single market. Market participants have been asked to formulate open questions and submit these to EBA under the EBA's Q&A process. They should take the opportunity to do so.