PSU Identity, Historic challenges and how to solve them

The emergence of customer-facing, third-party products has stalled in the UK, with only 8 available to personal banking customers, and only two of these (MoneyBox and SafetyNetCredit/Tappily) offering distinct and valuable services. The remainder focus on the relatively common personal finance management category, which historically haven’t seen significant customer demand and have struggled to generate revenue. One of the enduring challenges faced by Fintechs is being forced to take risk on customer identification, as they are unable to identify those Payment Service Users (PSUs) who authenticate on banks’ platforms to authorise the flow of data. This paper examines the history, technical detail, challenges posed and solutions to this problem.

The History

At the outset of the Open Banking movement, Article 98 (d) of the Second Payment Services Directive (PSD2) mandated the European Banking Authority (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 Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA), 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. 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 is confirmed at paragraph 17.34 of the FCA’s Opinion on the 2017 Payment Services Regulation.

From the beginning, the regulations underpinning the open banking initiative excluded the possibility of identity being included as part of the designs that would form the basis of Account Servicing Payment Service Providers’ (ASPSPs) platforms built to fulfill compliance objectives. A continuing theme has been the appearance of contradictions between the Directive and Regulatory Technical standards, another being PSD2 requiring ASPSPs to enable direct access, then the RTS requiring ASPSPs to apply SCA on each customer accessing their account, effectively preventing direct access (see here).

From a technical perspective, this presented relying parties with a potential challenge, in that they would, when licensed, have a right of access to data where consent was granted by a resource owner, but have no ability to confirm the identity of the resource owner, whether at point of inception or an ongoing basis. Early EBA opinions on the RTS suggested that Third Party Providers (TPPs)(as relying parties) would not have to issue their own credentials, on the basis that they could rely on the credentials issued by the ASPSP. At para. 14 of their Report on the RTS on SCA, the European Banking Authority (EBA) stated “The interface should enable the account information service providers, payment initiation service providers and payment service providers issuing card-based payment instruments to identify themselves to the account servicing payment service provider. It should also allow account information service providers and payment initiation service providers to rely on the authentication procedures provided by the account servicing payment service provider to the payment service user.” This approach was then confirmed in the Financial Conduct Authority (FCA) PS18-24. This is also a stipulation of the Payment Services Regulation 2017 (PSR) at 100(4).

Standards Emerge

In early 2017, the Open Banking Implementation Entity began to work on its Read/Write Standard, this being largely in response to the UK Competition and Markets Authority (CMA) Order on Retail Banking, but with a view to supporting PSD2 compliance, which later specification versions have focussed on. In tandem with this, a security standard was developed taking elements of the OpenID Foundation’s Financial-Grade API standard (FAPI), OpenID Connect (OIDC) and OAuth2 to create a hybrid profile or implementer’s draft. In very simple terms, this meant that a PSU, having agreed to data sharing (or consented) with a TPP, would be redirected to the ASPSP, where the TPP had previously registered a consent (previously intent) and the ASPSP had responded with a ConsentId. The PSU would then authenticate using credentials supplied by the ASPSP, authorise the consent, and return to the TPP with an authorisation code, which could be exchanged for an access token. The minimum standard required this access token only to include an ephemeral ID of the consent as its subject identifier - an alphanumeric identifier immutable only to the specific instance of agreement between the TPP and the PSU, rather than to the individual PSU.

OpenID Connect provides for, and is intended to identify resource owners on an immutable basis. This can be done by means of an opaque but immutable user identifier, such as an alphanumeric code (see below), but the absence of this as a requirement in the early versions of the OB standards meant that continuing relationships between TPPs and their customers were always going to be challenged. This was particularly evident in the re-authentication aspect of the account information APIs. Whilst a customer can grant an open-ended consent to a TPP to access data on an ongoing basis, there are good reasons (from a security point of view) for the customer to have to be authenticated at certain points, for example to ensure they want access to continue, or that they are still the account owner. The OB specification allows ASPSPs to issue access tokens which have a limited validity period, with the expectation that customers re-authenticate consents at intervals of their choosing, the minimum being the 90 day requirement of the RTS. To date, most of the ASPSPs in the UK and Ireland are yet to implement this, meaning that the consent is live for 90 days, after which point the user must go through a completely new consent journey.

The significance of this becomes clear when remembering that the information returned post-consent authorisation does not include a user identifier. A TPP with a long lived consent from a PSU will have registered them and issued credentials, effectively creating a new user identity in their own application which is tied to the PSU bank account, identified using its sort code and account number. Every time a new consent object must be created, there is a risk that the user will, on redirect, either not be the same (at the ASPSP) authenticating user as the initial journey, or will select a different account. This effectively breaks the relationship between the user identity created at the TPP, and the account it has been linked to. Additionally, where there are multiple parties to an account, there is the danger of a false positive, where a user going through a consent journey has access to the same ASPSP account, but is a different authenticating user to that involved in the initial journey.

Even where the re-authentication journey proposed by the OBIE’s Customer Experience Guidelines has been implemented, the absence of an immutable user identifier means that the TPP must rely on the ASPSP checking that (1) the user is the same authenticating user as who authorised the consent when created and, (2) the user is still a resource owner for the account subject to this first consent. Unless these two checks are applied, there is the danger of a false positive. Offline feedback has shown that at least one major ASPSP in the UK is only applying check (2), leaving open the possibility that a different user who has access to the same account re-authenticates, breaking the relationship with the TPP, but without their knowledge.

Revocation is not authenticated

Nowhere do these problems become more apparent than in the revocation of consent. Throughout the history of the API specifications, there have been three resources which manage a consent object held at an ASPSP, this being the technical representation of the PSU’s permission to the TPP to access data, and the principle method by which access to data is controlled.

  1. POST /account-access-consent - This API effectively allows the AISP to send a copy of the consent to the ASPSP to authorise access to account and transaction information

  2. Re-authentication (see above) – the process by which a user re-authenticates against a long lived consent as required by Article 10 of the RTS on SCA.

Both of these resources require the customer to perform SCA using the credentials issued by the ASPSP. The consequence of this is that only a verified identity (and credential set) which is tied immutably to the account held at the ASPSP, and accessible only following SCA, can be used to grant access to data. This protects the user, the TPP and the ASPSP in ensuring that the owner of the resource/bank account is controlling access.

  1. DELETE /account-access-consent - If the PSU revokes consent to data access with the AISP, the AISP must delete the account-access-consent resource with the ASPSP before confirming consent revocation with the PSU. This is effected by calling this resource at the ASPSP and supply the ConsentID.

This resource does not benefit from being accessible based on SCA, but only requires the TPP to authenticate. Consequently, the TPP is faced with the challenge they have no ability to confirm that the original user who granted consent after strongly authenticating themselves is the same as the one requesting severance of the TPPs access. For those use cases where open banking rails are used by TPPs to create financial value or automate savings for the user, revoking access is a significant step, as it will cause these benefits to cease. For anyone who has revoked consent under GDPR, they will have experienced the need to identify themselves with credentials (e.g. passport) before organisations will act on an instruction. This is a control, both for the user and the TPP, as it protects both from a malicious or accidental revocation of consent where there may be unexpected financial impact. In the absence of this ability, it is likely that many TPPs will have to manually identify customers before calling the DELETE resource, which will mean a great deal more friction in the customer journey. Whether this is a positive development is open to debate - for the moment it will result in very different experiences of consent revocation, depending on the TPP business in question.

Fraud Risk and the CRA process

It is useful to consider a specific business context when analysing the impact of an identity risk. The most common experience of having to identify oneself in a financial services context is assessment for credit. The vast majority of lenders today, obliged by regulation to carry out credit risk and affordability assessments of potential customers, will take identity documents (e.g. passport) and combine them with a proof of address (e.g. utility bill), then details of the customer’s account, often through bank statements in hard or soft copy. These are then sent to a credit reference agency, who will assess the risk of lending to the individual and give a likelihood score of the account being owned by the same individual as the person who has provided identity documents. It is important to note that this is not identity verification, but rather a risk based confirmation of a resource being owned by a disparate identity.

The process can be streamlined using the current open banking flows, where a user registers personal details about themselves directly with the TPP, then is redirected to their bank to authenticate and authorise the flow of data, including details of their account. The TPP will then have to go through the same checking process, as the account details do not include identity information about the user who has authenticated and authorised the flow of data. Some will point to the recent expectation set by the FCA, that the name of the account holder is expected to be included in account payloads. This does not solve the problem for a wide range of use cases, as the name of the account holder may be a business, may include multiple individuals, but ultimately does not allow immutable or continuing identification of the authenticating user. Additional identity claims are required for this to be the case - see below for further details.

The challenge that even the absence of a unique identifier for the user poses relates to the ongoing relationship between the TPP and PSU. The TPP, using details registered and the account payload, can go through the identity checking process in a similar manner as has been used to date, and offer the consumer a credit product based on this well known process. However, without long lived consent, re-authentication and an immutable user ID implemented by the ASPSP, there is always the potential that the relationship will be broken and a new consent journey will have to be started. This effectively invalidates the CRA checks done at the outset of the relationship, as the relationship is, technically, completely novel. Whilst the TPP can check to see if the account payload is the same when a new consent is authorised, there is always the potential that the resource owner has changed, or that a different user with access to the same resource has authenticated. If either of these is the case, it will be opaque to the TPP.

The open banking APIs are designed to reflect the legislative impetus for continuing relationships. The CMA Order referenced the potential for sweeping, this being a process where a PSU grants a TPP continuing access to an account and payments resource, and the TPP automatically moves money, based on certain conditions, to save the PSU money or take advantage of improved interest rates. In some cases it may be used to avoid punitive fees, for example from unauthorised overdrafts or declined transactions. Use cases of this type, in contrast to a loan with a set of repeating payments for specified amounts, require a continuing relationship between the TPP and PSU, hence the need for the TPP to be sure that it is continuing to interact with the same person. Without the ability to confirm this, the market will be inhibited to repeat the existing use cases, rather than moving to smart credit models where, for example, TPPs can send push notifications to PSUs on detection of increased current account balances, offering them savings on interest if they pay early in their payment cycle.

Ultimately, in the absence of the ability to confirm the user, the fraud risks facing TPPs in the lending space will remain the same as prior to the implementation of open banking, inevitably stifling innovation and consumer benefit.

Solutions?

So far, this paper has focused on challenges. On a more positive note, the good news is that many of these problems can be solved with very limited technical change. The inclusion of a unique ID in the “sub” value of the ID token would enable a TPP to confirm returning users, and substantially de-risk many of the elements referred to above. This does not even require an extension in the consent models, no identity claims (i.e. name, address etc.) are served to the TPP, only a unique and repeatable user ID. This could be transferable (i.e. specific only to the user) or tied to the TPP (i.e. specific to the user and a particular TPP) - either option provides TPPs the ability to have multiple consent objects with a single PSU and ASPSP, safe in the knowledge that it is the same user they are interacting with each time, regardless of the API resource to which access is being granted. When use cases which require both account information and payments access are considered, this is particularly important, as these must necessarily be separate consent objects.

Returning to the suggestion of the RTS, this model also enables the TPP to build a service under the OpenID  Connect model where they act as the relying party, and the PSU registers, for the purpose of authentication on an ongoing basis, using a bank issued credential set. Instead of the TPP issuing credentials to each new user, it can prompt customers of those ASPSPs who are able to support unique identifiers to ‘register with Bank X’, and then based on security policy decision, allow them to authenticate using the same redirect journey on an ongoing basis. This limits the number of credentials sets a user is required to use, and enables them to rely on an authentication method they trust. It removes the need to specifically run a user through a bespoke re-authentication a journey to fulfill the regulatory need to run SCA every 90 days, as the user will be performing  SCA when they authenticate to access the TPP, effectively re-starting the 90 day clock. This reduces the build requirements on the ASPSP, as they are supporting more complete user authentication, as opposed to for particular cases., The issue of consent revocation is resolved, as the TPP can require the user to authenticate via SCA, then allow them to revoke access based on the length of the session as dictated by the lifetime of the issued id_token.

Finally, this approach paves the way for federated identity. This is a commonly used model with identity providers allowing users to share information about themselves with services they wish to register with, the obvious examples being Facebook and Google. As a minimum, this means less form filling for users, reduced fraud risk and better customer inception rates for TPPs, and increased customer retention for ASPSPs, as customers can use their bank IDs for a wider range of services. Should ASPSPs be concerned about internal subject identifiers being shared externally, there is the objection to create a pseudonymous identifier for each customer and link this to the internal identifier.

Both this approach, and the implementation of a login with ‘ model where only a unique customer identifier is served by the ASPSP are not trivial activities. Perhaps most complex are implementations where the ASPSP wishes to communicate levels of assurance aligned to different identity claims. There are also concerns about how to implement GDPR-compliant consent journeys, and the possibility of giving the user dynamic control over the identity claims to be shared. These are questions which require technical, security and legal expertise, and knowledge of the products required to support a complete Identity Access Management platform. In short, it is equally as easy to talk about as it is difficult to implement.

The future and how Raidiam can help

Raidiam consultants are already engaged with a range of fintechs and ASPSPs, assisting them in understanding the  concepts and supporting technology, developing strategies and supporting implementations across Europe. As experts in the fields of open banking, digital identity, and commercial negotiation to support relationships, we are uniquely placed to assist those organisations wishing to solve challenges and take advantage of opportunities in ways which promote the best customer outcomes. We are keen to speak to all those interested, whether you would simply like a deep-dive into the concepts and some areas of concern likely to be faced, or would like to become a full blown identity provider, serving highly-assured identity assets with wide claimsets attached to them.

We would like to see the world of open banking develop into one where customers can use their bank resources to  access more developed services based on trust, where fraud prevention is prioritised, but not at the expense of excellent customer experience. We recognise that there are many challenges to solve in this new world, and complexities that won’t be addressed quickly.

If you take one message away from this paper, it should be that there is real market potential and that Raidiam are here to help you deliver solutions to enhance the customer journey and open additional channels of opportunity.

Get in touch, to understand how we Raidiam can help info@raidiam.com