Open banking is a global phenomenon in which banking data is becoming more and more accessible for third-party developers and end-users. Through standardized APIs, banks can more seamlessly integrate with FinTech companies that are building new tools and visualizations of this data. This movement is allowing users to have better ownership and control over their financial data, and is in effect reshaping financial planning.

Open banking is undoubtedly unlocking new business models and innovations for the financial sector. However, not every country is in 100% agreement on how exactly banking data should be exposed. Different regions have varying open banking implementation standards and different developer experiences.

For example, the European Union was the first major body to regulate open banking with PSD2. The United States has yet to issue a sweeping regulation and instead is allowing the market to encourage adoption. There’s also the Fintech Law in Mexico, The Consumer Data Right in Australia, open banking in Brazil, and others. Though the exact laws may vary, what unites them is that many will require a standardized format for financial data access, typically through APIs. In addition to the data exchange method adopted, the industry will require financial-grade security to protect data in transit.

Developer Experience Across Open Banking Standards

The circumstances around open banking have birthed an entirely new class of standards. And arguably, the standards themselves set the tone for how open banking will be approached in a commercial setting. Specifically, they set a precedent for the developer experience (DX) expectations around integration. But, not all standards have excellent developer portals that treat developers as first-class citizens.

Take the UK Open Banking Standards — the developer portal is publicly available on the web, providing straightforward information on API details in a well-known location. Comparatively, the Berlin Group‘s open banking standard is publicly available yet provides documentation in PDF format. This isn’t terrible, but is less accessible and is certainly not machine-readable. At the other end of the spectrum, Financial Data Exchange (FDX), the salient standard in North America, paywalls its standards. So, only paying participants have access to the relevant documentation.

Open Banking Brazil is another example of an aggressively growing open banking standard. Yet, their developer portal provides a myriad of information, which is somewhat challenging to navigate and build against, let alone respond to changes, said Wood, who has firsthand experience integrating with the standard.

The Role Banking Standards Play In DX

Standards are important because they level the playing field for an industry. But how far does their role extend? Well, first off, says Wood, standard bodies should communicate baseline technical standards — the design of what the API should look like — as well as a technical operating model for how third-party banks should interact, including governance, security, and SLAs.

In addition to baseline technical expectations, “the standards bodies across the world have an important role to play in developer experience,” said Wood. For one, he believes these groups can act as a helpful backstop for developers looking for answers — they have a wealth of knowledge to aid the developer community when the banking portals don’t cut it. This includes updating the community with new features and expectations, making style recommendations, setting a roadmap for the future, and assigning spokespeople to advocate for developer needs.

“Standards bodies should champion the needs of developers,” said Wood. “Developers need standards bodies to work for them.” The success of the developer community will drive the success of open banking, and the same can be said for other sectors that are opening up too, such as open energy, open government, and open healthcare.

Financial-Grade Security Standards

There are the open banking standards themselves, and there are also the emerging financial-grade profiles for securing APIs. Understanding both is fundamental to securely enacting open banking. Regarding financial-grade security, there’s a high-stakes imperative to carefully onboard third parties to ensure they’re trustworthy. One example of a leading regulatory security standard is Strong Customer Authentication (SCA), an EU requirement under PSD2.

As we’ve covered many times on the blog, OpenID Connect and OAuth 2.0 can be used in conjunction to enable a standardized token-based architecture to access APIs and enforce centralized strong user authentication. The OpenID Foundation is evolving financial-specific standards, like the Financial-grade API (FAPI) Profile, which we’ve covered previously.

The most widely used OAuth flow is the Code Flow. “It’s natural to start using this in an open banking role,” said Daniel Lindau, Solution Architect, Curity. The Code Flow uses an external Authorization Server to authorize the user and issues a token for the client to use to access API endpoints.

Consider The Lodging Intent Pattern

However, the common Code Flow does present some limitations, notes Lindau. For one, client authentication typically hinges on a secret, which presents potential flaws. Mutual TLS can be used to provide more secure client authentication. However, Mutual TLS has limitations since certificates expire, and it’s hard to let clients outside of the public key infrastructure (PKI) in, he describes.

Another issue is concerning payment transactions. The user should be able to consent to every individual transaction, not just once per scope. The solution, says Lindau, is the Lodging Intent Pattern. This flow enables clients to retrieve transactional access tokens that allow users to consent to specific transactional data. The Lodging Intent Pattern leverages sender-constrained tokens that are only valid for a single request, enabling end-users to consent to specific transactions.

There are other intricacies at work too. Lindau recommends the OAuth extensions JWT-secured authorization request (JAR) and its counterpart, JWT-secured authorization response (JARM). FAPI allows either MutualTLS or JAR/JARM, but Lindau notes that many are moving away from MutualTLS to adopt these newer standards. He also mentions Rich Authorization Requests (RAR) as an important upcoming standard to follow.

Final Thoughts

Standards bodies themselves play an important role in fostering the open banking ecosystem. And, the developer experience the standards themselves set could trickle into expectations around commercial-facing portals. Thus, there’s an incentive to make these standards intuitive and easy to use.

Accessibility is especially critical for security standards that are key to protecting user data. By following the above open standards, organizations can move to adopt open banking in a secure manner.