The Open Banking Implementation Entity (OBIE) has built a great standard. What makes it even better is the suite of software and services that help banks and third parties reduce compliance risks and increase market adoption.

In January 2018, the UK’s largest current account providers (the CMA9) started to go live with Open Banking APIs based on version 1 of the standard developed by the OBIE. This was mandated by the CMA Order and can be considered a precursor to the requirement for all payment service providers (ASPSPs) in Europe to provide either a dedicated (i.e. API) interface or a suitably modified fall-back (i.e. screen scraping) interface by September 2019, so that regulated Third Party Providers (TPPs) can use these to provide payment services to end customers.
 
Version 3 will enable any ASPSP to meet their PSD2 obligations for the provision of a dedicated interface.

Version 3 of the OBIE standard was published in September 2018. This is a significant upgrade from v2, which ASPSPs went live with in the same month. It is a rich standard which contains detailed technical specifications for all PSD2 in-scope accounts, in all currencies, and is broken down as follows:

• Account and Transaction API Specification - v3.0 - allows an Account Information Service Provider (AISP) to register an intent to retrieve account information by creating an "account access consent". This registers the data "permissions", expiration and historical period allowed for transactions/statements that the customer (PSU) has consented to provide to the AISP, and the AISP subsequently retrieves account and transaction data.
• Payment Initiation API Specification - v3.0 - allows a Payment Initiation Service Provider (PISP) to register an intent to stage a payment order consent, subsequently submit the payment order for processing and optionally retrieve the status of a payment order consent or payment order resource. This includes single, future-dated, recurring, bulk, batch, FX payments and file upload payments.
• Confirmation of Funds API Specification - v3.0 - allows a Card-Based Payment Instrument Issuer (CBPII) to register an intent to confirm funds by creating a "funds confirmation consent" resource with an ASPSP for agreement between the PSU and ASPSP. This consent is long-lived, and contains the length of time (expiration date) the PSU would like to provide to the CBPII; the CBPII subsequently makes a request to confirm funds are available. Funds can only be confirmed against the currency of the account.
• Event Notification API Specification - v3.0 - allows ASPSPs to deliver event notifications to TPPs. The ASPSP API endpoints described here allow a TPP to register a callback URL with an ASPSP to receive event notifications and optionally read, update or delete a registered callback URL. The TPP API endpoint described here allows an ASPSP to notify a TPP that an event has occurred.
   

Version 3.1 of the OBIE standard is due to be published at the end of November 2018, which fixes a number of minor issues, allows for fund checks for PISPs and extends the request and response payloads of all APIs to cater to any type of corporate account.
 
OpenID Alignment
Critically, OBIE has now aligned further with the OpenID Foundation (OIDF) for the security model. OBIE has adopted the following specifications and is actively working with OIDF to finalise drafting. The OpenID Financial-grade API (FAPI) Working Group recommends approval of the following specifications as OpenID Implementer’s Drafts:
 

• Financial-grade API - Part 1: Read Only API Security Profile
• Financial-grade API - Part 2: Read & Write API Security Profile
• Financial-grade API - JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)
  
  

The FAPI Working Group is also finalising drafts for:

• The Client Initiated Backchannel Authentication (CIBA) profile – enables the decoupled use cases defined later on in this post.
• The Dynamic Client Management Specification – extends the Dynamic Client Registration Specification and facilitates the automated onboarding of TPPs with ASPSPs to meet the requirements of RTS regarding eIDAS certificates being relied on by ASPSPs for identification of TPPs.

 
This alignment with OIDF and the FAPI Working Group is critical to offer best-in-class security, protecting ASPSPs, TPPs and end customers. It also has significant support from many global vendors, thus reducing delivery costs and risks.
 
Customer Experience is Essential to the Success of Open Banking
The standard goes much further than technical specifications. Based on significant feedback from the industry since Jan 2018 and after further clarifications from the regulators over the last few months, OBIE has developed a comprehensive set of Customer Experience Guidelines.
 
These are concerned with the PSU journey from a TPP’s online app or browser, through authentication within the ASPSP domain and completion in the TPP domain.
 
They cover both redirect and decoupled authentication methods, with example journeys for all PSD2 use cases (AIS, PIS and CBPII). They define what an ASPSP (and in some cases, a TPP) must do in order to comply with PSD2/RTS and should do in order to meet market needs and deliver the best possible user experience.

Fig 1: Example decoupled authentication flow

The customer experience guidelines are based on three core principles:

1. The PSU needs to go through a Strong Customer Authentication (SCA) at their ASPSP in order for a TPP request to be actioned by the ASPSP.
2. The PSU should be able to use their same, preferred authentication elements when interacting via a TPP as they do when interacting directly with the ASPSP.
   
3. The experience available to a PSU when authenticating via a TPP should involve no more steps, delay or friction in the customer journey than the equivalent experience they have with their ASPSP when interacting directly.

 
In other words, these guidelines require ASPSPs to allow parity between TPP-driven interactions and direct PSU interactions, so that TPPs are not penalised by ASPSPs and can offer services which offer a great customer experience.
 
Certification is About More Than Compliance
Over the last year, OBIE has developed a suite of tools which allow ASPSPs (and now TPPs) to test that they have correctly built against the OB security profile. When the tester is happy they have passed all tests, they can submit results to OBIE, who will validate and publish a certification. OBIE also publishes (with the participant’s permission) notes explaining any failures and a planned fix date, in the event the participant wishes to communicate this to the ecosystem.

Fig 2: OBIE Security Profile Certifications (as of 12 Oct 2018)

OBIE is now extending the suite and certification process to cover:

• FAPI Profile (OP and RP tests).
• CIBA Profile (OP tests).
• Functional APIs (tests for all AISP, PISP and CBPII use cases).
• Customer Experience Guidelines (again for all AISP, PISP and CBPII use cases).
   

OBIE will issue certifications which not only show conformance to the OBIE standard, but will also show which elements of the standard have been implemented over and above the regulatory requirements. This will allow ASPSPs to evidence conformance to the regulators. It will also allow ASPSPs and TPPs to demonstrate how they have met additional market needs by delivering a certain standard of customer experience.
 
This last point can be used by ASPSPs to promote where they have a best-in-class API and hence can help these ASPSPs grow customers and revenue via partnering with TPPs.
 
Where Next for the OBIE Standard?
OBIE has developed a standard which has been road tested by ASPSPs and TPPs since January 2018. Version 3 builds on this and now enables compliance with PSD2 and RTS regarding a dedicated interface. However, this only works if implemented well.

The OBIE Customer Experience Guidelines will help ASPSPs and TPPs deliver Open Banking products which offer best-in-class security and a seamless customer experience. The conformance tools and certification process will allow participants to prove that they have not only met regulatory requirements, but also how well they meet additional market needs.

And OBIE will continue to deliver a roadmap of agreed changes, with version 4 of the standard due to be published in March 2019. They will also continue to build out tools and services which help the Open Banking ecosystem gain wider adoption, such as a platform for reporting performance and availability.

Open Banking has the potential to transform payment services. It should result in personal and business customers being offered better ways to move, manage and make more of their money. Payment APIs could eventually provide a faster, more secure and lower cost alternative to card schemes.

Without standards, this would be much harder to achieve. But, as we’ve seen over the last year, standards on their own are not enough. Great standards need great implementation, along with a relentless focus on the end user—the customer.

To hear more about how secure, open standards are transforming the financial system, please join me at IDENTIFY London on October 16, 2018, where I will be participating in a panel on “Enhancing Customer Experience in Financial Services” and presenting along with RAiDiAM’s John Heaton-Armstrong during a session on “The Future of Open Banking through Standards Conformance and Certification”.