The Challenge of PSU Identity in PSD2

TL; DR - the drafting of the regulations concerning customer/PSU identity introduce risk and a lack of guidance to the ecosystem. This could be dealt with by functional API specifications, but this option introduces further risk. Adoption of Core OpenID Connect’s ‘user info’ or id_token resource present better options for future proofing, and enhance customer control and security, with additional options for identity federation.

For the majority of business models, Third Party Providers (TPPs) must identify the Customer (PSU) who authenticates (following redirect) on the Bank/ASPSP platform. Article 98 (d) of PSD2 mandated the EBA to develop regulatory technical standards on “the requirements for common and secure open standards of communication for the purpose of identification, authentication, notification, and information, as well as for the implementation of security measures, between account servicing payment service providers, payment initiation service providers, account information service providers, payers, payees and other payment service providers”.

In Paragraph 27 of their opinion on the implementation of the RTS on SCA and CSC, it states: “Additionally, the EBA clarifies that the scope of data to be shared with AISPs and PISPs by the ASPSP under PSD2 and the RTS on SCA and CSC does not include the PSU’s identity (e.g. account holder name, address, date of birth, social security number) given that those are not data that are necessary or requested to initiate a payment or access account information under PSD2.” This opinion is confirmed at paragraph 17.33 of the FCA Consultative Paper (CP) 18-25.

If identity information is not within the scope of data to be shared with AISPs and PISPs under PSD2 and the RTS on SCA and CSC, it is technically impossible for the TPP to know who has undergone the authentication journey at the ASPSP. 

What are the possible solutions?

The Open Banking Implementation Entity (OBIE), in their API design, have detailed two optional data fields (see here and here)  which serve information about account holders. If implemented, these would largely resolve the practical issue of a TPP being able to link the user of their service to an account held by the ASPSP. This information would only be shared (as all other account information) with the consent of the PSU. ASPSPs would not be liable for the accuracy of this information beyond its connection to a particular account as, for a range of business cases, TPPs are obliged to perform their own KYC checks – the rationale for the service is to allow the TPP to link the identity they interact with to a specific account. 

From a technical point of view, the above solution introduces risk (due to the flow of personally identifiable information), and only partially addresses a broader problem, that of the decoupling of identities. TPPs would still be taking a risk based decision on connecting the account to their user and would see varying responses for accounts with more than one account holder. Given the intention is to serve information about the user who has authenticated (and their ownership of account resources), creating an additional standard for this when Core OpenID Connect (already part of the Security Profile for Open Banking) provides for this information in its ‘user info’ resources seems overkill, particularly when this standard is not specific to the banking domain.

The difficulty of the regulations is compounded at para 17.130 of the FCA CP18-25, it states “In our view and in line with the EBA Opinion 33, where an interface allows for redirection, an AISP or PISP is not prevented from relying on the ASPSP issued credentials. This is because the AISP or PISP is able to ‘use’ the customer credentials and rely upon the ASPSP authentication procedures. Furthermore, the AISP or PISP is not required to issue its own credentials or authentication procedures.” Both the EBA and FCA have misinterpreted the technical functioning of the redirect model in these opinions. The possibility of a TPP relying on the ASPSP issued credentials and authentication procedures only works if identity information about the PSU is provided, such as an id_token. No ASPSPs are providing this, which makes reliance in the manner described impossible.

Unless the API platform were to return identity information intended for this purpose (as in the guise of the OIDC design), any TPP is forced to issue credentials to a user, to facilitate use and to enable them to be uniquely identified; or to rely on another Identity Provider e.g. social login with Google. In the most light-touch model, this could be through registration of email address and password. As authentication with the ASPSP is decoupled from the interaction with the TPP, and no identity information is available about the authenticated user, it is technically impossible (in the OAuth2 redirect model) for the TPP to rely on the credentials used at the PSU-ASPSP interface to identify the customer. These credentials are never seen by the TPP, and an access token is used to access the ASPSP resource endpoints.

CP18-25 foresees a solution at para 20.24 – “It is open to the ASPSP to allow a PISP, an AISP or another party to apply strong customer authentication on the ASPSP’s behalf as part of a bilateral contract or arrangement. We would expect the parties to ensure that the contract addresses the allocation of liability between the parties.” Technically, this would mean an ASPSP federating a digital identity and authentication service to a TPP, so that the PSU could login to the TPP service using ASPSP credentials and the ASPSP authentication method. This is distinct from the redirect model as, since Strong Customer Authentication will have been applied at the start of the session, there is no requirement for redirect in the middle of the customer journey. Additionally, there is no decoupling of identity, as the PSU uses only one at the point of inception

This could be facilitated by the adoption of a Core OpenID Connect framework for PSU identity. This standard is non-domain specific, gives options for granular control over what information is shared, is widely understood and supported by existing vendors and implementers alike, and, if implemented correctly, could greatly enhance customer and TPP experiences. This level of partnership should be seen as the zenith of integration between TPP and ASPSP services. OpenID Connect also provides for an id_token, which could enable the ASPSP to provide identity / identifier (and other private claims) in a signed JWT to the TPP following the authentication journey at the ASPSP. This would avoid the need for userinfo endpoint or other resource API being called by a TPP. This mode of identity provision promotes the interests of all, as risk is reduced, security and interoperability are enhanced, and the experience for all is improved.

The current drafting of the guidelines in the CP is problematic, as it leaves federation of identity to the discretion of the ASPSP, and subject to a contract. This consequence of this is that ASPSPs have discretion to offer a solution to TPPs of their choosing, which has the potential to damage the goal of interoperability through standardisation, and cause unnecessary fragmentation at a time of increasing regulatory support for convergence on technical standards. 

What will happen if no changes are made

ASPSPs in the UK have indicated that they will not provide account holder information through the dedicated interfaces they have built to display account information. There is the potential for the creation of a market for the unregulated screen-scraping of ASPSPs account holder identity information that exists outside of PSD2 regulations. This is not only antithetical to the objectives of the regulatory framework, but introduces significant risk to the market and adoption of open banking, as it results in unregulated handling of the most sensitive details of account information. Early indications show that existing screen scraping based services intend to continue this practice beyond the transition period.

If the discretion to contract (and define solution) for the purposes of identity federation remains, a two-tier model of fintech players could emerge, with those with sufficient commercial and demographic weight to be able to avail of this service at the top, and the remainder forced to interact in a second class category with poorer customer experience. This could limit the ability of new, innovative companies to gain customer traction and represent a barrier to entry.


Representation of the above points has been made to the EBA and FCA in similar terms. We suggest;

a.       The FCA give strong consideration to making account holder information available in the manner currently part of the OBIE design as a requirement for any ASPSP seeking an exemption under the guidelines set out in CP18-25.

b.       The FCA consult with the EBA, taking advice from experts in digital identity, and redraft opinion 33 in terms which correctly reflect the technical working of the redirect model of customer authentication.

c.       The FCA consult with the EBA, taking advice from experts in digital identity, with a view to expanding para 20.24 to more strictly govern the federation of digital identity, and ideally undertake a technical investigation into the adoption of an industry-standard framework to homogenise this approach across the ecosystem.