Open banking standards: account data

Comparing features of open finance APIs. Part one of several.

Exactly how different are Open Banking standards?

I still imagine a world of open banking with a universal standard, so I compared four specifications that have reportedly enabled tens of millions of people to access their banking accounts from third-party apps:

• OpenBankingUK

• NextGenPSD2

• STET PSD2

• Open Financial Exchange (OFX)

Technically, these specifications share some helpful properties; they are all public RESTful APIs with a common transport protocol (HTTP) and data format (JSON). But they have some key differences too.

Specification overviews

If you’re familiar with the specifications, feel free to skip to the Feature comparison section.

NextGenPSD2

NextGenPSD2 was developed by the ‘Berlin Group’, formed in 2004. It functions alongside a legacy standard known as FinTS (formerly HBCI), an XML/SOAP-based protocol used by German banks to connect to each other across all three banking pillars.

Despite its German origins, the specification is considered pan-European. The Berlin Group reports that NextGenPSD2 has been implemented by more than 75% of European banks.

STET PSD2

STET PSD2 is a specification created by the French clearing house, STET, which has participants from major banks in France.

STET also has representation in the Berlin Group, making their goals somewhat aligned and may be a harbinger of consolidation between the two standards.

OpenBankingUK

OpenBankingUK is a specification developed by the UK company Open Banking Ltd, also known as the Open Banking Implementation Entity (OBIE), created by the CMA in 2016. Like NextGenPSD2 and STET PSD2, OpenBankingUK was designed as a blueprint for banks to offer PSD2-compliant APIs.

Open Banking in the UK is growing fast, with the latest figures indicating close to six million customers at an accelerating pace. The UK also has more market participants (banks and third parties) than the rest of Europe combined. This is likely thanks to over 90% of UK current accounts sharing a single specification that relies heavily on widely-agreed open standards like OpenAPI/Swagger and FAPI.

Open Financial Exchange (OFX)

The first version of OFX was created in 1997 by Financial Data Exchange (FDX) for the North American market. It’s widely considered an industry initiative as opposed to the other three specifications initiated by European law.

FDX has recently reported that more than 16 million consumers have benefited from its API with very rapid growth in recent years.

Feature comparison

Let’s look at how each specification approaches its account servicing features (we’ll look at payment features in a separate article).

We can classify account data features into nine categories.

1. Consent data

Features that allow apps to interact with customer consent.

Both OBUK and NextGenPSD2 offer comprehensive features for handling customer consent, allowing third-party apps to create, retrieve and delete authorisations. These functions closely match a proposed extension to OAuth2 that could soon standardise this type of consent/grant management.

By comparison, OFX and STET PSD2 offer very basic functionality for consent.

2. Account state data

Features that allow apps to read basic account information and balances.

All four specifications provide high-level account data, but you’ll notice that the last three features are almost identical to the first three. NextGenPSD2 treats card accounts differently from regular accounts but could possibly consolidate this into a single data model as the others have done.

3. Payee data

Features that allow apps to interact with a customer’s payees.

OFX offers the most comprehensive ability for third-party apps to programmatically manage payees, while other specifications simply allow apps to retrieve payee information. To enable fully programmable banking, customers should be able to add, remove and update payees through secure channels.

4. Customer identity data

Features that allow apps to read account identity information.

Even though standards don’t seem to agree on features in other categories, there is near consensus to provide third-party apps with access to customer identity data.

5. Customer product data

Features that allow apps to read product information relevant to their customer.

Given the popularity of credit card reward programs in North America, it’s no surprise that OFX has distinct features. The OpenBankingUK and NextGenPSD2 standards support product information, but only OpenBankingUK has a feature that supports product offers. And for whatever reason, STET PSD2 appears to have decided not to handle product features.

6. Automated payment data

Features that allow apps to read information about automated payments.

OpenBankingUK appears to stand alone in offering a comprehensive view of direct debits, standing orders and future one-off payments. It’s hard to think of a good reason why this information isn’t an option in other specifications, considering how ubiquitous direct debits are. It will be interesting to see how these data models change over time, especially given the recent addition of variable recurring payments (VRP) to OpenBankingUK.

7. Statement data

Features that allow apps to read information about statements.

Statement data are useful for apps that work with banking statement periods, including some accounting software. OFX offers statement images that can be downloaded, while OpenBankingUK, maybe inessentially, allows apps to retrieve transactions within a given statement period.

8. Transaction data

Features that allow apps to read information about transactions.

All specifications facilitate the main task of getting transactions for an account. Interestingly, OBUK and STET PSD2 allow transactions to be accompanied by ambiguous supplementary data.

Again, NextGenPSD2 adds a potentially redundant feature by separating transactions for card accounts.

The North American standard, OFX, allows apps to fetch transaction images, namely cheques. This highlights an interesting discrepancy between banking apps in different regions. Cheques have seen a global decline in usage, but banks still support them. Additionally, cheque payments are not covered by PSD2. If they were, STET PSD2 may have also included this feature, given that ~80% of French bank customers own chequebooks.

(We’ll need a separate article to deep dive into the transaction data model.)

9. Tax form data

Features that allow apps to interact with tax documents.

Tax form data is unique to the OFX specification, which supports the management of tax documents typically found in North American banking apps.

Thoughts

Every project is an opportunity to learn, to figure out problems and challenges, to invent and reinvent. - David Rockwell

Studying open banking in different markets feels like figuring out fundamentally what makes a banking account. And we still haven’t evaluated all specifications or even all features of these four specifications!

Some of the differences between specifications seem to come from differences in financial practices between countries, but others seem arbitrary. For example, even a feature set like tax form data, commonly adopted by North American banks, doesn’t seem to justify a separate specification when you consider this:

Banks typically only implement a subset of a specification’s features.

As with any API design, the structure and quality of any particular Open Banking specification will determine its usability. Currently, there are 20+ other countries with Open Banking APIs or plans to launch their version with hardly any interoperability.

I don’t have any judgement of any particular approach. But after four years of Open Banking, I think it’s worth re-examining what we’re building. The best customer experience will likely come from thoughtful standardisation.