MaPS: Building for the Pensions Dashboard, Part 2

The Pensions Dashboard is evidence that the influence of open APIs and the open everything agenda is growing beyond the confines of open banking and into the wider world of open finance.

As I covered in the first blog, having access to more sources of value, such as pension accounts, is vital to its potential being realized and improving the lives of consumers of financial services.

The Dashboard, as a flagship project of the Money and Pensions Service (MaPS), has ploughed a significant furrow in the pensions sector.

As the report by PwC highlights, many provider’s schemes are not digitized. In the words of the report:

“Non-electronic records ranged from small numbers to thousands of pension entitlements.” PwC

Converting these schemes from printed matter into accessible, digital format, and then providing that data through appropriately secured APIs, is fundamental to making the Dashboard a success.

However, the Dashboard platform itself doesn’t need to be brand new. It’s already being built and some decisions around architecture and standards have already been taken.

There is significant value in what’s already been built for open banking and the themes being drawn from open finance. There is potential for reuse in the Dashboard implementation.

Building for the Pensions Dashboard

The headline goal of the first iteration of the Dashboard is to provide the means for UK citizens to search and see a consolidated view of their pension pots, including their state pension.

These could be made up of both pensions they know about or ones they have forgotten. The search parameters include attributes such as name, National Insurance Number (which every person over 16 years old in the UK has), and date of birth.

Some features apply to implementing the Pensions Dashboard that defines what can be drawn on from open banking, what influence open finance has, and how this can be manifested in the final solution:

• Users must be able to assert strongly their identity to use the Dashboard.
• Pension providers must trust the veracity of the user’s identity as presented by the Dashboard.
• Pension providers must act with the consent of the user and provide the data to the dashboard.
• Pension providers must be able to match search parameters provided by the user to search for a pension.

Each of these features or themes provides answers and asks further questions:

• The assertion of user identity is currently provided for in open banking by the banks. Unless subject to an SCA exemption — where their internet banking facilities are “wrapped” in OpenID Connect with ready-rolled Know Your Customer (KYC) and Anti-Money Laundering (AML) implementations. To achieve similar levels of success, the Pensions Dashboard must be able to do the same without relying on pension providers, of which only a subset provides the equivalent of internet banking.
• Given the lack of a common facility for digital user identity at the pension providers, the Dashboard aims to play the role of the identity provider. In doing so, it needs to prove to the pension provider that the user is who they say they are and that they could potentially be a customer of that provider.
• For both provisions of user consent, a relevant consent approach and protocol need to be employed that can accommodate both first- and third-party consent (e.g., users need to consent to data access at their pension providers, as well as third parties such as independent financial advisors being able to access the Dashboard on behalf of users).

This mechanism needs to be robust in terms of the granting of access and ensuring that users can provide only some data access to third parties to help guard against fraud.

Moreover, authorization should where enabled by the user be strongly asserted using the biometric capabilities or their mobile phone, ideally supported by open standards such as FIDO2.

Each of these areas brings about potential solutions that can draw on the existing features of the UK open banking implementation across several areas useful to the Pensions Dashboard, with four key themes:

• Reuse appropriately.
• Establish Proofs of Identity.
• Encourage openness.
• Enable Access Management.

With these themes in mind, the Pensions Dashboard can reap huge benefits from what has gone before.

Reuse appropriately the open banking Directory

The Pensions Dashboard will need to establish an operating framework that allows different parties with different roles, therefore, different responsibilities to interact with the platform.

The Open Banking Directory was created to facilitate such interactions and was always intended as an extensible, open platform. In terms of establishing roles for the Pensions Dashboard, it already includes the required capabilities.

For example, the Directory established the PSD2 “non-banking” roles such as Account Information Services Provider (AISP) and Payment Initiation Services Provider (PISP), collectively known as Third-Party Providers (TPPs).

There’s also a role for the banks, known as the ASPSP. These roles describe the participants in the open banking ecosystem and allow the security model to function. They can be extended to incorporate pension roles, such as the UK Government, the Pensions Dashboard itself, and pension providers.

At the outset, there will be no equivalent TPP roles. However, once the Dashboard is established, having the means to quickly onboard such a role would hold enormous value for the growth of the ecosystem. By providing for this now, the Directory would allow for a seamless transition to future phases of growth within the open pensions sector.

In the meantime, having the facility to create new roles, onboard the pension providers, and use existing mechanisms in the directory, such as Software Statements and how they facilitate OAuth 2.0 Dynamic Client Registration — has the potential to accelerate the implementation of the Dashboard.

Establish Proofs of Identity: OpenID Connect

The current plans for the Dashboard require citizens to register as users and verify their identity via several associated services. These services will provide the means for users to create a user profile and assert their identity to Level of Assurance 2.

This will give them the ability to search for and retrieve their pension details across all providers. However, proving identity is one thing. Being able to assert that identity across multiple providers is another.

The UK Open Banking standards addressed this by using OpenID Connect — a protocol developed to provide an identity layer on top of OAuth 2.0. This ensures implementation was watertight through their work on and integration with the Financial-grade API Profile (FAPI).

While the implementation of OpenID Connect in the UK Open Banking has had its challenges — mostly ensuring there is a consistent user identifier presented as part of the ID Token. It delivers a robust framework for providing proofs-of-authentication between participants.

This lends itself towards the Pensions Dashboard, which can implement relevant claims that allow for an effective federation of the identity implemented at the Dashboard across pension providers.

Pension providers will not be responsible for initially authenticating the users of the Dashboard in the same way as banks authenticate account holders in open banking, as this will be in the remit of the Dashboard.

However, by using OpenID Connect rather than a bare OAuth 2.0 profile, the Dashboard can offer much better non-repudiation for pension providers, given the proofs-of-authentication provided out-of-the-box.

True, a contextual Bearer Token such as a JSON Web Token can provide similar features, but in the spirit of reuse, the Pensions Dashboard should look at how it can leverage what open banking has already brought to the market.

This approach also builds for a future of federated identity across providers, whereby pensions providers can potentially take advantage of the Dashboard as an Identity Provider, enabling them to improve their platforms for the benefit of users.

As open banking grows into open finance and users access more services across different sectors, the ability to federate identity across them is going to be critical to its success.

It can also provide benefits to the pension providers as participants of the digital identity framework. For example, being part of the trust framework, they also can assert that identity elsewhere, providing authorized access to data that has already undergone KYC validation to enable seamless onboarding to utility companies, for example.

Encourage openness: Open APIs, standards, and platforms

Enterprise integration and government programs are littered with standards and documentation that are often counterproductive for developers aiming to get their jobs done.

What are their jobs? They involve getting from the start of a project to having running code access a service or API as quickly as possible.

With appropriate levels of quality and assurance testing, their application is “right.” This is normally a “good thing” not just for developers, but for their organizations who get their projects running quickly and API Providers who aim to turn developers into paying customers as quickly as possible.

Key features

One of the key features of an API Provider getting this experience right for developers is the adoption of open standards. Of course, the Open API specification — and coupling this with an easy means of publication.

In the UK Open Banking implementation, this was pertinent given the need for banks to implement their APIs according to the standards being built by the CMA9.

The OpenAPI specification made this job easier as the interface was defined by the contract, ensuring the expectations were clear.

Moreover, the publication method through a source code repository like GitHub made it quite easy for consumers of the specification — both the banks and TPPs — to monitor changes and see exactly what had changed.

Of course, just having the specification does not allow a complete integration to be created and UK Open Banking has ensured the remainder of the guidelines and standards are accessible.

The Pensions Dashboard has several challenges to open banking, such as the need to specify the bounds of the appropriate string (“fuzzy”) matching, so pension providers know their operating boundaries in terms of returning potential matches for a given search.

There is an opportunity to ensure this works as cohesively as possible by referencing open standards and methods on both machine learning to improve gradually the quality of the matches and the matching algorithms used.

By taking the same approach as open banking and landing on a specific algorithm and defining guidelines around its use and pointing to an open standard for implementation, the Dashboard can reap the same benefits.

Delivering the standards this way has lent itself to setting expectations across the industry on what the banks’ API platforms will look like. Such an approach could allow the Pensions Dashboard to establish readily a collective understanding of both the requirements and the implementation across all participants.

Enable Access Management: UMA + CIBA

Having a workable access management model has been crucial to Open Banking in the UK becoming established. Using a common Consent model, TPPs can describe what rights they require from one or more accounts.

For example, to the account balance or to statement data — agree that with the Customer and then orchestrate the process of permitting both OpenID Connect and the use of APIs at the target bank.

This manifested itself in a dedicated Consent endpoint in each of the accounts and payments API, with an enumerated list of permission “codes.”

This model is not without its flaws. As the permission codes are fixed at each release of the standards, the interface is perceived as being relatively brittle and as permission codes change, admittedly infrequently, TPPs are required to delete and recreate the Consent of their customer, as update operations are not supported.

As the Pensions Dashboard currently has no TPP role, the Consent model from open banking is likely to be more difficult to implement and manage. Responsibilities for consent will fall on the Dashboard itself and the approach may not translate effectively.

Flexible approach

There are existing protocols that are well-suited to a more flexible approach to access management. OpenID Connect makes use of scopes from the underlying OAuth 2.0 specification, but this is still driven by the TPP.

However, User-Managed Access (UMA is already being discussed and offers a potentially more flexible solution with the means for the Resource Owner. This means the real human being using the Pensions Dashboard — to set access rights at a policy level, assigning them across multiple providers.

Moreover, it allows for other humans, such as independent financial advisors to request and be granted access to pension details via the policy.

UMA can therefore provide for an open, flexible framework well-suited for the needs of the Dashboard. However, being an OAuth 2.0 specification, it lacks the out-of-the-box proofs-of-authentication that OpenID Connect can deliver.

Authorization decisions could also take a significant amount of time — potentially days. This is where one of the FAPI profiles, Client-Initiated Backchannel Authentication (CIBA), could provide additional assurances of authentication for the Dashboard.

CIBA is geared towards asynchronous authentication and authorization flows, which allows for an out-of-band activity to be orchestrated by the Authorization Server.

In scenarios where a Requesting Party needs to respond to a notification and submit claims that they have the right to access the data, CIBA would neatly wrap the UMA protocol and provide significant levels of non-repudiation for participants in the Dashboard.

With the spirit of both reuse and using the right tools for the job, using the CIBA profile could provide significant advantages for the implementation of the Dashboard.

Final thoughts

Building the Dashboard with a mind to what has gone before in open banking can offer significant advantages for the Dashboard ecosystem.

The biggest challenge will be with technology provision. As highlighted above, significant digitization of pension providers’ records needs to happen before the implementation can take place.

Once digitized, providers will need an appropriate means to surface securely that data using APIs and the security and access management protocols specified in the final design.

This investment is vital for both the success of the Pensions Dashboard and for pension providers’ place in the open finance economy. It should be viewed as a strategic move that allows them to grow their offering, work with new partners and customers, and power new markets.

Providers who already have a suitable platform to support the Dashboard with appropriate API Management capabilities are placed to take advantage of the growing momentum in the open finance space. However, they should take stock and ensure those capabilities are fit-for-purpose.

For example:

• Is there support for security standards such as UMA?
• Does the platform have the means to serve the traffic that will be generated by the Dashboard?
• Can that platform effectively shield backend systems from this traffic? Affirming such capabilities are in place is vital to success.

By embracing the opportunity, meeting the requirements of the Dashboard can allow providers to create a platform ready for the promise of open everything.