EBA publishes PSD2 guidance on strong customer authentication and secure communication

On 23 February 2017, the European Banking Authority (EBA) published its final report containing the draft regulatory technical standards (RTS) on strong customer authentication (SCA) and common and secure open standards of communication (CSC) for the revised Payment Services Directive (PSD2). The RTS will come into effect in November 2018 at the earliest.

What's changed from the earlier consultations?

Earlier drafts of the RTS provoked concern in the industry, which led to an unprecedented number of responses to the EBA's consultation. Out of approximately 300 issues raised by stakeholders, the EBA focuses on three key recurring issues:

1. the scope of the draft RTS and that they had to be technology-neutral;
2. the exemptions from the need to use SCA; and
3. the access to payment accounts by third party providers and the requirements around the information communicated.

In summary, the EBA has changed the RTS in the following ways:

1. Technology neutrality: The EBA has removed references to particular international standards, technology and other characteristics to ensure technology neutrality and allow for future innovations.
2. Scope: The EBA confirms the scope of the requirement to apply SCA is that set out in PSD2 (see below) and includes e-money transfers. However, SCA will not apply to electronic payments initiated by the payee only.
3. Exemptions from SCA: The EBA has introduced two new exemptions and amended others, including:

(i) a new exemption based on transaction-risk analysis (TRA), which will apply to remote transactions below a monetary threshold ranging from €100 to €500 depending on the payment service provider's reference fraud rate (calculated as the value of unauthorised or fraudulent remote transactions divided by the total value of all remote transactions for the same type of payment instrument, whether authenticated using SCA or relying on an exemption);

(ii) a new exemption for unattended terminals for the purpose of paying transport or parking fares; and

(iii) an increase to the low value transaction threshold from €10 to €30.

However, the EBA refused to exempt corporate payments, despite numerous comments from respondents.

1. Communication between payment service providers: The EBA has maintained the obligation for account servicing payment service providers to offer at least one interface for account information service providers and payment initiation service providers to access payment account information. ASPSPs that decide to use a dedicated interface must now ensure they provide the same level of availability and performance as the interface offered to, and used by, their own customers, as well as to provide the same level of contingency measures in case of unplanned unavailability.
2. Screen scraping forbidden: The EBA has, however, ruled out the existing practice "screen scraping", which will no longer be allowed after the transitional  period.

What's next?

The RTS and PSD2 act as the frame around which payment service providers now need to build or adapt their payments infrastructure and legal documents. It does not provide all the answers. Amongst other things, payment firms need to consider, legally and commercially, how best to address allocation of liability (and workable mechanics to recover any loss), revised terms with customers and new terms with third party providers, and how to ensure compliance with the incoming General Data Protection Regulation.

With PSD2 taking effect in January 2018, the Competition and Markets Authority's work already starting on Open Banking in the UK (see our article of 2 February here) and the Financial Conduct Authority due to publish its consultation on implementing PSD2 in the UK imminently, all payment services firms should now be focusing on PSD2 implementation.

The remainder of this briefing summarises the key requirements of the RTS.

Strong customer authentication

When is strong customer authentication required?

The RTS on SCA are based heavily on the EBA's existing guidelines, which apply to internet payments. The PSD2 requirements on SCA are broader, however. Under PSD2, a payment service provider must apply SCA where the payer:

1. accesses its payment account online;
2. initiates an electronic payment transaction; or
3. carries out any action through a remote channel which may imply a risk of payment fraud or other abuses.

The EBA confirms that SCA, therefore, applies to electronic payments initiated by the payer, or by the payer through the payee (such as credit transfers - including e-money transfers - or card payments), but does not apply to electronic payments initiated by the payee only.

What is strong customer authentication?

SCA must be based on two or more of the following elements which result in an authorisation code:

1. knowledge (i.e. something only the user knows, such as a password, code or PIN);
2. possession (i.e. something only the user possesses, such as a token, smartcard or mobile phone); or
3. inherence (i.e. something the user is, such as a biometric characteristic like a fingerprint or retina scan).

Payment service providers must mitigate the risk that these security elements are compromised. They must also adopt security measures to ensure each of these elements are mutually exclusive so breach of one does not compromise the other. It must not be possible to forge an authentication code or generate a new code based on knowledge of an earlier code.

In addition, payment service providers must make the payer aware of the amount of the payment and the identity of the payee. The authentication code shall be specific to the amount and the payee that the payer agreed to, known as dynamic linking. Any change in the payment amount must make the authorisation code invalid. Payment service providers must also ensure the information on the payee and payment amount are kept secure and protected from fraud.

When does SCA not need to be applied?

Payment service providers can rely on a number of exemptions from the need to apply SCA. These exemptions are as follows:

1.  Access to account information

Payment service providers do not need to apply SCA where a customer is only able to view their account balance or their transaction history for the last 90 days online (i.e. online banking access and logging on to an app to view balances and transaction history). Payment service providers must, however, ensure sensitive payment data is not disclosed during this process. This exemption is not available for first time access or, in relation to accessing payment history, where SCA has not been applied for 90 days.

2.  Contactless payments

Contactless payments up to €50 each are exempt, provided the cumulative amount, or number, of contactless payments since the last time SCA was used does not exceed €150 or five consecutive occasions.

3.  Transport and parking fares

Payment service providers do not need to apply SCA for electronic payments at unattended payment terminals for the purposes of paying for transport or parking fares.

4.  Regular payees and recurring transactions

Payments a payer makes to existing payees and recurring payments of the same amount and payee (i.e. standing orders) are also excluded from the need to apply SCA. This exemption does not apply to the first payment or when the payer creates, confirms or amends the existing list of payees.

5.  Payments to self

SCA does not need to be applied to payments made between a person’s different accounts with the same payment services provider.

6.  Low value transactions

Payments below €30 do not need to be subject to SCA, provided the cumulative amount, or the number, of previous remote electronic payments made by the payer since the last application of SCA does not exceed €100 or five consecutive payments.

7.  Transaction risk analysis

Payment service providers are exempt from the need to apply SCA to payments which they identify as low risk based on their real-time risk analysis and transaction monitoring requirements (see below). This TRA exemption will only apply if the payment amount does not exceed a value between €100 and €500, depending on the payment service provider’s reference fraud rate. This fraud rate is calculated as the total value of unauthorised or fraudulent remote transactions divided by the total value of all remote transactions for the same type of payment instrument, whether authenticated using SCA or relying on an exemption. Therefore, the lower the fraud rates, the higher the monetary threshold and, consequently, the higher the number of "use cases".

Monitoring and reporting requirements

To rely on any of the exemptions above, payment service providers must have transaction monitoring mechanisms in place to enable them to detect unauthorised transactions. Such monitoring systems should include real time risk monitoring taking into account a customer’s payment history, spending patterns, location and any abnormal behaviour etc. Payment service providers must record and monitor all of their fraud rates as well as the performance of the TRA method used.

A payment service provider’s security procedures must be documented and periodically tested, evaluated and audited by internal or external independent and qualified auditors on at least an annual basis. The report must be made available to regulators on request.

Standards of communication

General requirements: Identification and traceability

The RTS include a general requirement for payment service providers to ensure secure identification when communicating between the payer's device and the payee's acceptance devices for electronic payments. Payment service providers also have to mitigate the risk that communications are misdirected to unauthorised parties.

Payment service providers must also ensure each stage of a payment transaction or other interaction is traceable. This will require any communication session to establish a unique identifier, security mechanisms to record the transaction in detail and timestamps.

Communications with ASPSPs

ASPSPs must have at least one interface which allows AISPs, PISPs and card issuers to identify themselves to the ASPSP and allows AISPs and PISPs to communicate securely with the ASPSP to carry out their own services. The method of communication must be through a dedicated interface or through the same method the ASPSP's customers use (i.e. online banking). Where an ASPSP puts in place a dedicated interface, the interface must offer the same level of availability and performance, as well as same level of contingency measures, as the interface made available to customers directly accessing their accounts online.

The EBA confirms that the existing practice of "screen scraping" will no longer be permitted after the transitional period comes to an end. The EBA considers this practice does not comply with PSD2 requirements because it does not enable the third party provider to identify itself to the ASPSP, it does not ensure secure communications or rely on the authentication procedure and it does not comply with the restrictions on third party providers accessing data.

The RTS effectively push ASPSPs into adopting open API standards, as already required in the UK through the Competition and Markets Authority's Open Banking Project (for which, see our article of 2 February here). In particular, the RTS require ASPSPs to create an interface that is made available, free of charge, to authorised payment services firms, as well as a testing facility with support for connection and functional testing.

Security and frequency of communications between ASPSP and third party providers

ASPSPs, PISPs, AISPs and card issuers shall apply secure encryption when exchanging data via the internet.

PISPs, AISPs and card issuers will also have to:

1. keep the sessions as short as possible and actively terminate each session as soon as the requested action has completed;
2. reference details of the customer(s), the corresponding communication session, the unique identifier for the payment transaction (for payment initiation) and the unique identifier for the request for confirmation on availability of funds; and
3. ensure that where they communicate personalised security credentials and authentication codes, these are not readable by any staff at any time (where there is loss of confidentiality, the customer and the issuer of the personalised security credentials should be informed without undue delay).

Further, AISPs shall only be able to access account information held by ASPSPs for the purpose of performing their services:

1. whenever the customer actively requests such information; and
2. no more than four times in a 24 hour period where the customer has not actively requested such information (unless a higher frequency is agreed).

Exchange of data between payment service providers

ASPSPs must provide AISPs and PISPs with the same information they make available directly to their customers. ASPSPs must also provide payment service providers, upon request, with a "simple 'yes' or 'no' confirmation" of whether the payer's account has the necessary funds for a particular transaction.

Further, ASPSPs have to notify other payment service providers in the event of an unexpected event or error occurring during the identification, authentication or exchange of data. For ASPSPs that offer a dedicated interface, the interface has to allow payment service providers to notify other payment service providers too.
AISPs must have systems in place to prevent access to information other than from designated accounts and associated payment transactions.

PISPs shall provide ASPSPs with the same information requested from the customer when initiating the payment transaction directly.

What do the RTS not cover?

While the above summarises what is included in the RTS, there are still some thorny issues that neither the RTS nor PSD2 specifically address. These include: the allocation of liability between payment service providers (which is covered in PSD2 to a degree legally, but which raises interesting commercial decisions and potential for new financial and reputational risks for ASPSPs in the payment ecosystems), the need for revised contractual terms with customers and third party providers accessing ASPSPs' data, the impact of and compliance with the incoming General Data Protection Regulation and how those ASPSPs who are also subject to the CMA's Retail Banking Order for open banking can implement these requirements in a way which is most efficient and consistent between the two regulations. These RTS and the PSD2 are the frame around which payment services firms now need to build their payments infrastructure and legal documents.