.svg)
The rulings confirm that account servicing payment providers (ASPSPs) can impose conditions on enhanced payment information and clarify the rules on corporate proxy matrices and API key use in strong customer authentication (SCA).
The European Banking Authority (EBA) has published three new Q&As highlighting how to interpret the revised Payment Services Directive (PSD2).
The new Q&As address questions on payment initiation service provider (PISP) access to payment status information, corporate proxy matrices and the potential use of API keys as a knowledge element in SCA.
PISP access to payment execution information
In one response, the EBA confirmed that ASPSPs need to provide PISPs with information on the initiation and execution of a payment order immediately after receiving it.
The submitter, who remained anonymous, warned that “some ASPSPs, unlike the broader industry standard, impose additional requirements, such as mandating the use of a ‘user token’ to access payment execution information.
“This practice conflicts with broader industry standards, where ASPSPs provide the necessary information without imposing similar constraints,” the submitter said.
“Requiring ‘user tokens’ undermines the uniformity intended by PSD2, leads to inconsistency among ASPSPs, and hinders PISPs' ability to comply with their obligations under PSD2 and the RTS.”
However, the regulator has seemingly taken the banking industry’s side, clarifying that the obligation does not extend to later updates, although ASPSPs may provide these voluntarily.
If an ASPSP chooses to provide additional execution status information beyond the legal requirements, it may impose technical and security conditions, such as requiring a user token, as long as these do not obstruct access to the mandatory information.
This is largely positive for ASPSPs, and gives them flexibility in how they provide information to PISPs.
The Q&A should help ASPSPs to mitigate operational and fraud risks while staying compliant. It allows them to differentiate their services by positioning enhanced payment tracking as a value-added offering. One of the pain points with PSD2 is that open banking requirements are frequently offered entirely free of charge.
For ASPSPs that already require user tokens, the ruling effectively legitimises this practice. The Paris-based watchdog confirmed that, provided the minimum information required under PSD2 is made available, a token requirement does not constitute an obstacle.
The outcome is less favourable for PISPs such as Yapily and Brite Payments, as these firms risk losing out on consistency across the market.
The EBA did not require ASPSPs to harmonise their approach, leaving PISPs facing fragmentation across Europe. The challenge is that whereas some banks may provide payment status data freely, others will impose extra conditions, creating uneven access.
Corporate proxy matrices and TPP access
In another question, this time submitted by a bank, the EBA addressed whether ASPSPs can support detailed proxy matrices set by corporate clients that restrict which employees can access accounts via third-party providers (TPPs).
Again, the EBA has taken a decision that is favourable to ASPSPs.
It stated that PSD2 entitles payment service users to use TPPs, but ASPSPs must not discriminate against orders or data requests transmitted through TPPs compared with those made directly.
At the same time, corporate account holders retain the discretion to define internal governance rules, including differentiated access rights for employees using TPPs.
The EBA said that ASPSPs enforcing such access controls in line with a corporate client’s instructions would not be creating an obstacle under the regulatory technical standards (RTS).
However, ASPSPs are not able to impose additional unilateral checks on authorised users when they access accounts through TPPs.
API keys as a knowledge element in SCA
The EBA also considered, in response to a question submitted by a national competent authority, whether an API key can qualify as a knowledge element in SCA.
The regulator noted that PSD2 defines SCA as using at least two independent elements from the categories of knowledge, possession and inherence.
An API key may be recognised as a knowledge element if it meets all RTS requirements, including ensuring that it remains known only to the user, cannot be retrieved by the system and is sufficiently independent from other authentication factors.
However, the EBA warned that in the case presented by the submitter, the implementation appeared to rely on only one valid SCA factor – possession via a one-time password – since a user ID is not considered a valid knowledge element.
As such, compliance would depend on the specific design of the API key solution.
