New EBA Guidance On Obstacles And Interfaces: Open Payments Under PSD2

Source: Payments Cards & Mobile

The second Payment Services Directive (PSD2) created the need for a regulatory technical standard (RTS) to govern communications among service providers who offer online payment accounts (ASPSPs) and third party service providers (TPPs) that offer account information services (AIS) or payment initiation services (PIS).  From time to time the European Banking Authority (EBA) issues guidance on the interpretation of the RTS in practice. The latest guidance explains certain "obstacles" that ASPSPs must avoid creating for customers who wish to use the services of TPPs. I've summarised the guidance here to make sure I understand it generally, but please let me know if you need advice in any a specific scenario.

ASPSPs must allow TPPs to connect to their systems through either a "dedicated interface" or the same interface that its customers use for authentication and communication. The challenge is that the dedicated interface must not create "obstacles" to the TPP's provision of payment initiation and account information services. The EBA is particularly concerned about scenarios where the customer has to be redirected from the TPP's system to the ASPSP's system in order to be authenticated. TPPs have argued that such redirection is an obstacle to the customer experience in accessing their payment accounts, where that is the only method of authenticating the customer. 

The RTS itself notes some obstacles, but the EBA guidance now provides other examples in terms of:

• the types of authentication procedures that ASPSPs’ interfaces are required to support;
• whether mandatory redirection at the point-of-sale is an obstacle;
• whether multiple Strong Customer Authentications (SCA) can be required;
• whether the 90-days re-authentication requirement can be relaxed;
• the extent to which manual account input/selection is an obstacle;
• whether additional checks on customer consent can be required; and
• what additional registrations might be permissible.

Authentication procedures that ASPSPs’ interfaces must support

If the interfaces provided by ASPSPs do not support all the authentication procedures made available by the ASPSP to its customers, this would be a breach of the RTS and an "obstacle". So, if customers use biometrics or a mobile authentication app to access their account directly with the ASPSP,  then they must also be able to do so when using their payment account via a TPP.  That interface should not create unnecessary friction or add unnecessary steps in the customer journey compared to the direct customer interface. 

Payments at point-of-sale

It has been argued that mandatory redirection to the ASPSP's system when the customer uses a payment initiation service (PIS) offered by a payment initiation service provider (PISP) to initiate a payment at the point-of-sale is an obstacle because redirection only works in a web-browser or mobile apps-based environment. For payment initiation services to work at point-of-sale, PISPs argue that ASPSPs should be required to enable 'decoupled' or 'embedded' authentication flows, even if they don't offer that to their customers when paying directly.

The EBA says that while PSD2 does not oblige ASPSPs to enable PIS-initiated payments using authentication procedures that the ASPSP does not yet offer to its customers directly, if an ASPSP were to offer to its customers the ability to perform instant payments at the point of sale directly, then the ASPSP should also allow its customers to initiate instant payments using a PISPs’ services at the point of sale, within the same amount limits.

Requiring multiple strong customer authentications (SCA)

The authentication of the customer with the ASPSP as part of the TPP user experience using a redirection or decoupled approach would be an "obstacle" if it creates unnecessary friction or add unnecessary steps, compared to the authentication procedure offered by the ASPSP to its customers when accessing their payment accounts or initiating a payment directly.

Similarly, when a customer is using a PISP to initiate a payment, it would be an obstance if one SCA were required to access the account data, and a separate SCA for initiating the payment, unless required by the ASPSP as part of "duly justified security arguments" in a particular case (e.g. suspicion of fraud for a particular transaction) and the ASPSP could substantiate that upon request by the local regulator.

The fact that the ASPSP may require a separate SCA for ‘log-in’ (or to access payment account data more generally) when the customer directly initiates a payment with the ASPSP, is not a sufficient ground to justify applying two SCAs in the PIS scenario.

However, in some PIS journeys customers do not specify which payment account is to be debited in the payment initiation request, and only do that when transferred to the ASPSP’s domain/system. In such cases, it would not be considerd an obstacle for the ASPSP to require one SCA to access the list of payment accounts in its system, and a second SCA to authenticate the payment.

Two SCAs may also be necessary for a combined use of an account information service and a payment initiation service (unless an exemption applies): one to access the payment account data and another to initiate the payment.

90-day re-authentication for Account Information Services (AIS)

The RTS provides an exemption from the requirement to apply SCA for each access to the ASPSPs system where the AIS accesses only a limited set of data (account balance and/or 90 days of payment transactions) and its customers must re-authenticate at least every 90 days. This is to balance ease of use with increased security. The EBA "advises" local regulators to encourage all ASPSPs to use this exemption. 

ASPSPs may also choose to delegate or outsource SCA to TPPs to conduct SCA on the ASPSP’s behalf,  but are not obliged to do so (outsourcing guidelines would apply).

Account input or selection

Interfaces that require customers to manually input their IBAN into the ASPSP’s system in order to be able to use a TPP’s services are an "obstacle".

To avoid this, either: 

• the TPP can seek its customer's consent to retrieve the list of all her accounts with the ASPSP via the ASPSP's interface and display it to the customer in the TPP's system, so she can select the account and the TPP can then request access or initiate a payment using the account details; or

• if the ASPSP has implemented a redirection or decoupled approach and the TPP does not extract and then transmit the account details to the ASPSP with its customers' request,  the customer could select the relevant account(s) on the ASPSPs’ domain during the ASPSP's authentication procedure, in a way that is no more complicated than selecting the account(s) directly with the ASPSP (e.g. via a drop-down list of accounts, or prepopulated account details if only one).

In an "embedded" scenario, however, where the customer's credentials are exchanged between the TPP and the ASPSP and the customer does not interact with the ASPSP to authenticate, a PISP may need to obtain the details of the account from the customer in advance (if it does not also have an AIS license and/or consent from the customer to access the list of accounts). That's because a PISP is not entitled to access the list of all the customer’s payment accounts, as this information goes beyond the scope of data that PISPs have the right to access. So not providing the list of all payment accounts to a PISP is not an "obstacle".

However, even where the customer only selects the account on the ASPSP’s domain, the ASPSP should provide to the PISP the number of the account that was selected and from which the payment was initiated, if this information is also made available to the customer when the payment is initiated directly. Once the account number is provided to the PISP, the ASPSP should not request the customer to re-select that account when using the PISP again, because that would be an "obstacle".

Additional checks on consent

It is the regulatory obligation and the responsibility of each TPP to ensure that it has obtained the customer's explicit consent to the use of its service. The ASPSP must not make its own check for whether the customer gave that consent to the TPP, and it would be an "obstacle" for the ASPSP to require the customer to give that prior consent. 

Similarly, the ASPSPs contract with its customers “should not contain any provisions that would make it more difficult, in any way, to use the payment services of other payment service providers...”. This extends to access by individual authorised users on corporate accounts.

Additional registrations

Requiring a TPP to go through additional registration processes with the ASPSP to access the ASPSP’s interface would be an obstacle, unless (a) technically required to enable a secure communication (e.g. pre-registration to use the ASPSP’s mobile banking app or a dedicated/decoupled app), (b) processed in a timely manner, and (c) does not create unnecessary friction in the customer journey. 

Optional or freely agreed registrations between ASPSP and TPP are permitted (they just can't be imposed by the ASPSP).

It would also be an "obstacle" to require registration steps or processes with the ASPSP in order for the TPP to have access to the ASPSP’s production API, other than the identification of the TPP via an eIDAS certificate.

New To Payments? Try PSD2 Customer Authentication and Communication Standards!

If you are among the new entrants to the regulated payments space you should know that, in a bit to captivate and inspire a generation, the European Banking Authority has published the final 'regulatory technical standards' for payment user authentication and the secure communication of payments data. The standards should take effect in the second half of 2019, but the authorities are keen for regulated payment service providers (PSPs) to adopt them as soon as possible. They are written in legalese, but I've summarised them below in a bid to get them straight in my own head.  Grab a coffee before proceeding!

Strong customer authentication 

PSPs must know they are dealing with their own customer by applying strong customer authentication. This is subject to certain permitted exemptions outlined below. PSPs must also protect the confidentiality and the integrity of each customer's personalised security credentials. Their security measures must be documented, periodically tested, evaluated and audited by auditors with expertise in IT security and payments and operationally independent within or from the PSP.

 

Broadly, authentication must be based on two or more elements of 'knowledge' (password/PIN), 'possession' (card/device) and 'inherence' (fingerprint/iris scan). 

These elements must be subject to measures designed to prevent disclosure (in the case of knowledge) , replication (in the case of possession) and resistance against unauthorized use of device or software (in the case of inherence). 

The breach of one element must not compromise the reliability of the others. Certain measures must also mitigate the risk that a multi-purpose access device has itself been compromised. 

Credentials and Code

Authentication credentials must be masked when displayed and not fully readable as they are being entered; not stored in plaintext; and must be protected from unauthorized disclosure. 

PSPs must document how they encrypt credentials or render them unreadable. 

The creation, processing and routing of credentials must be done in secure environments that accord with industry standards. 

Specific requirements govern the process of associating the user with credentials; delivery; authentication of devices and software; and the renewal, destruction, deactivation and revocation of credentials.

Authentication must result in the generation of an authentication code that is only accepted once by the PSP when the payer uses it to: access the payer’s payment account online, initiate an electronic payment transaction or to carry out any action through 'a remote channel which may imply a risk of payment fraud or other abuse'. 

No information on any of the authentication elements can be derived from the disclosure of the authentication code; nor can it be possible to generate a new authentication code based on the knowledge of any previous code. The code must not be able to be forged. 

Where the authentication has failed to generate an authentication code, it must not be possible to identify which of the authentication elements was incorrect. 

No more than 5 failed authentication attempts can take place consecutively before the authentication tool is blocked, either temporarily (based on certain factors) or permanently (after a warning). The user has 5 minutes of inactivity after being authenticated before access must time-out. 

Dynamic linking!

The payer must be made aware of both the amount of the proposed payment transaction and of the proposed payee. The authentication code must also be ‘dynamically linked’ (specific to) the amount and the payee. Any change to the amount or the payee must result in the invalidation of the authentication code  that was generated. 

PSPs must ensure the confidentiality, authenticity and integrity of the amount of the transaction and the payee throughout all of the phases of the authentication; as well as the information displayed to the payer including the generation, transmission and use of the authentication code.

Transaction monitoring

PSPs must monitor interaction with their customers to detect unauthorised or fraudulent payment transactions, taking into account elements which are typical of the user when normally using the credentials and, at a minimum, the following risk-based factors: 

• lists of compromised or stolen authentication elements; 
• the amount of each payment transaction; 
• known fraud scenarios in the provision of payment services; 
• signs of malware infection in any sessions of the authentication procedure; and
• where the access device or software is provided by the PSP, a log of the use of the device or software and the abnormal use of the device or software. 

Exemptions from strong customer authentication

The permitted exemptions (subject to transaction monitoring, and quarterly assessments to be shared with the FCA on request) are: 

• checking the balance or the last 90 days of transactions without entering sensitive payment data; 
• a contactless payment of up to €50, a series of up to €150 or 5 consecutive contactless payments; 
• payment at an unattended parking or transport ticket terminal;
• the payee is included in a list of trusted payees (unless adding to or changing the list); 
• recurring payments (after authenticating for the first);
• transfers between the users’ own accounts with the same PSP; 
• a remote electronic payment of up to €30, consecutive payments of up to €100 or 5 consecutive remove electronic payments; 
• commercial payment processes or protocols where the FCA is satisfied they guarantee at least the same level of security as under PSD2; 
• low risk remote electronic payment transactions (based on certain risk factors) where: 

o the fraud rate is below the relevant reference rate; 

o the amount is below a specific threshold; and 

o the PSP’s real time risk analysis hasn’t identified certain specified problems. 

Secure communcations

A PSP's communication sessions must be protected against the capture of authentication data transmitted during authentication, and against manipulation by unauthorised parties based on certain communication standards. These include secure identification of payer’s and payee’s devices; traceability of both the transactions and the interaction with the user and other participants in transactions; and a secure access interface between payer and online payment accounts. 

The access interface must allow for access by the user’s chosen account information service providers (AISPs) and payment initiation service providers (PISPs), although access by AISPs and PISPs can be facilitated via a dedicated interface that meets certain requirements. 

Wakey-wakey!

The End.

Will Regulatory Technical Standards Slow The Pace Of Payments Innovation?

Under the new Payment Services Directive (PSD2), the European Banking Authority (EBA) is tasked with producing 'regulatory technical standards' to be followed by those with certain obligations, including how payment service providers (PSPs) must authenticate customers and communicate with each other. But it seems this process and the standards themselves are acting as a brake on innovation and related investment.

The EBA consulted on its proposed regulatory technical standards for authentication and communication between August and October, with a revised set due in the coming months.

PSD2 requires PSPs to apply "strong customer authentication" where "the payer... accesses its payment account online, initiates an electronic payment transaction or carries out any action through a remote channel which may imply a risk of payment fraud or other abuses."

But two big issues raised by PSD2 are (1) how each type of payment is initiated; and (2) who actually initiates it.

The EBA believes card payments are initiated by the cardholder as payer, but fudges the issue somewhat by requiring the card acquirers (i.e. the PSP of the merchants) to require their merchants to support strong authentication for all payment transactions. The added complication is where a payment transaction is initiated by the payee, but the payer's consent is given "through a remote channel which may imply a risk of payment fraud or other abuses".

There is a view, however, that card payments are among those that are in fact initiated by the payee (the merchant), who is not in fact the 'payee' of the cardholder at all but is paid by the card acquirer to which the merchant submits its transactions. The cardholder just pays the card issuer. This is all bound up in fundamental problems with the definitions of "payment transaction", "payer" and "payee" in both the PSD and PSD2; and the fact that card acquiring works through a series of back-to-back contracts that do not involve any direct contract between the buyer and the seller at all concerning payment processing. Indeed, a challenge for the UK's implementation plans is that there is a Court of Appeal decision which supports this view. 

In these respects, PSD2 appears to set up a 'legal fiction', which (despite taking a somewhat purposive approach in the 'fudge' explained above) the EBA appears to insist on in language at the end of its consultation paper: "all the requirements under consultation apply irrespective of the underlying obligations and organisational arrangements between" the various types of PSP, payers and payees. In other words, we have a weird situation where the law and related standards are to be applied regardless of how payment systems and processes really work.

Not only can this lead to situations where, for example, some banks insist that the PSD does not cover card acquiring, but it can also cause over-compliance to avoid doubt and other restraints on innovation.

While distinctions concerning how payments are inititiated and by whom might seem to matter less in the context of security measures to be adopted by PSPs - since everyone is interested in reducing financial crime - it is absolutely critical in the context of software and services that contribute in any way to payments being "initiated" and whether the suppliers or users of such software and services must be authorised as "payment initiation service providers" or perhaps even as the issuers of payment instruments. 

It will be very interesting to see how the Treasury proposes to address these problems in transposing PSD2 itself, although it's more likely the FCA will be left to explain how to comply, assuming the Treasury declines to take a purposive approach to EU law and simply copies the language of PSD2 into UK law (a process known as 'gold-plating').

There are numerous other glitches in the technical standards that have been identified by respondents, too numerous to mention here, but which it is hoped will be reconsidered in the next version - not that such standards should ever be considered as 'final' or set for all time. Indeed, an overarching problem seems to be that in the EBA's attempts to drag our legacy payments infrastructure into the 21st century, insufficient attention has been given to existing and potential alternative security technology - even in cases where incumbents are seeking to leapfrog the limitations of legacy systems.

Meanwhile, a year has slipped by since PSD2 was approved and the standards themselves are only due to take effect in October 2018 'at the very earliest', by which time they are likely to be thoroughly out of step with commercially available technology. 

While old systems may need to be accommodated to some degree, surely the pace of payments innovation should not be tied to the slowest animals in the herd?