# It’s time for a serious open banking standard
Author:  Pal Sinha, Barnali 
Author URL: https://financedigest.com/author/pal-sinha-barnali
Published: 2018-07-06
Category: BANKING
Category URL: https://financedigest.com/category/banking
Meta Title: Open Banking Insights: The Future of Open APIs
Meta Description: Explore the key insights on open banking, regulations, standardization, and global support in this comprehensive overview by Steve Kirsch, CEO and Founder of
URL: https://financedigest.com/its-time-for-a-serious-open-banking-standardhtml

![undefined](https://prod.superblogcdn.com/site_cuid_cm5qst7v3003gwirgwqtxn8i8/images/fd060718-1-1-1736840307846-compressed.jpg)

_**Steve Kirsch**, CEO and Founder, Token_

There are four things that should now be crystal clear to everyone involved in open banking:

1.    Open banking has arrived. It was the #1 topic at Money 20/20 Europe. [Open banking](https://www.financedigest.com/why-open-banking-is-safe.html "WHY OPEN BANKING IS SAFE?") regulations are now appearing in other parts of the world beyond the EU.
2.    Open banking is so irresistible that even [banks that aren’t required to adopt](https://www.financedigest.com/why-banks-cant-adopt-digital-identities-fast-enough.html "Why Banks Can’t Adopt Digital Identities Fast Enough") open APIs are doing it voluntarily. Wells Fargo, for example, has implemented APIs to [support over 20 use cases](https://www.financedigest.com/kiwi-hit-by-new-virus-case-souring-risk-sentiment-supports-yen-swiss-franc.html "Kiwi hit by new virus case; souring risk sentiment supports yen, Swiss franc") that it thought were compelling.
3.    There is a lack of standardization. Of the APIs now available, only a handful of banks in the UK and Ireland are using the same API. And they only did that because the UK regulator required them to do so. But each [bank implemented the standard](https://www.financedigest.com/standard-chartered-rolls-out-digital-bank-in-hot-singapore-market.html "Standard Chartered rolls out digital bank in hot Singapore market") differently. This lack of standardization is bad for everyone: it increases costs and complexity at each bank, it [opens the door](https://www.financedigest.com/fed-delivers-small-rate-hike-opens-door-to-pause-in-tightening-cycle.html "Fed delivers small rate hike, opens door to pause in tightening cycle") to insecure solutions which expose banks and their customers to unnecessary risk, and it hinders adoption by software developers who only have bandwidth to write to one or two open APIs at the most.
4.    The standards that have been created/proposed leave a lot of room for improvement. The UK [open banking API](https://www.financedigest.com/the-future-of-financial-services-how-apis-are-fuelling-the-rapid-rise-of-open-banking.html "The future of financial services – how APIs are fuelling the rapid rise of Open Banking"), for example, is only usable by human beings, and it took about two minutes and 15 screens for a typical human to approve a simple access request. None of the [standards allow](https://www.financedigest.com/esg-innovation-allowing-everyone-to-meet-the-standard.html "ESG innovation: Allowing everyone to meet the standard") for charging the caller a fee. The Berlin Group standard is very complex.

If [open banking](https://www.financedigest.com/how-can-open-banking-help-smbs-navigate-the-cost-of-living-crisis.html "How can Open Banking help SMBs navigate the cost-of-living crisis? ") is to reach its full potential, it’s critical that points 3 and 4 are resolved. Here’s what I think should be done:

1.    The top banks worldwide should jointly fund the creation of a worldwide open banking standard.
2.    The creation of the API should be done by a commercial [vendor selected](https://www.financedigest.com/gumgums-accredited-contextual-solution-verity-selected-as-newest-contextual-vendor-by-mediamath.html "GumGum’s Accredited Contextual Solution, Verity™, Selected As Newest Contextual Vendor by  MediaMath") by the banks. Presumably, it would be a vendor that specializes in [open banking APIs and also has expertise in secure](https://www.financedigest.com/open-banking-as-a-means-to-enhance-social-commerce-security.html "Open banking as a means to enhance social commerce security"), instant micro-payments.
3.    The chosen vendor for the API design should seek input from all parties in the ecosystem: business, consumers, banks, [service providers](https://www.financedigest.com/sleep-service-providers-market-report.html "Sleep Service Providers Market Report"), software developers, system integrators, regulators, security experts.

Here’s why:

1.    To be a global standard, it’s really best that it starts with global support. Trying to take a single region/country standard and get other countries to adopt it is harder (especially one that has been designed by committee).
2.    The best standards are [created by small teams of highly competent people working](https://www.financedigest.com/deployed-raises-4m-to-redefine-how-statements-of-work-are-created-and-projects-are-planned.html "Deployed raises M to redefine how Statements Of Work are created and projects are planned") together in close proximity. In contrast, “design by committee” efforts take a very long time to come to fruition and the results are generally subpar. For example, all the computer platforms we use today to [develop software on desktop and mobile](https://www.financedigest.com/sony-to-buy-mobile-game-developer-in-push-beyond-consoles.html "Sony to buy mobile game developer in push beyond consoles") devices were all created by commercial vendors, not by non-profits or industry consortiums. Choosing multiple vendors to work together is also infeasible. Great [products aren’t created this way](https://www.financedigest.com/four-innovative-ways-to-pay-for-products-online.html "Four Innovative Ways to Pay for Products Online").
3.    Getting input from all stakeholders is not controversial. Importantly, however, this doesn’t mean the vendor should accept it all blindly; good design is always an iterative process and input is often conflicting.

Finally, the direction given to the selected vendor should include things such as:

01.    The API should be simple and low-level, somewhat analogous to the BIOS layer in personal computers: the simplest possible API which safely exposes the offered [banking functionality and which handles authorization and consent management](https://www.financedigest.com/pragma-investments.html "Pragma Investments on Wealth Management versus Private Banking") in a consistent, secure manner. This would enable vendors implementing other [open banking](https://www.financedigest.com/four-years-of-open-banking-2022-may-be-the-best-year-yet.html "Four years of Open Banking: 2022 may be the best year yet ") API specifications to build on top of this core layer. For example, the OFX [standard has worked very well over time](https://www.financedigest.com/beijing-meets-state-air-quality-standards-for-first-time-in-2021.html "Beijing meets state air quality standards for first time in 2021") for data and it is very simple. By contrast ISO-20022 is very complex. We should always be asking: do we need this complexity at the core layer? More often than not, the answer is no.
02.    The API standard should specify things at a high level, e.g. a payment request that can include meta-data, and let the meta-data itself be self-describing. [Higher level](https://www.financedigest.com/u-s-dollar-drifts-higher-yen-heads-toward-level-that-prompted-intervention.html "U.S. dollar drifts higher; yen heads toward level that prompted intervention") APIs could translate the meta-data to/from a variety of formats.
03.    The API should be fully open and not assume a particular style of API access. For example, it should not specify the interaction between a PSU and PISP/AISP; that should be out of scope. The API should assume the callers are evil and not compliant with any regulations. For example, Bitcoin and Ethereum are designed to be callable by anyone and it [works extremely well](https://www.financedigest.com/biden-says-he-is-doing-well-working-after-testing-positive-for-covid.html "Biden says he is ‘doing well,’ working after testing positive for COVID") because the security is built into the architecture.
04.    The API should be easy to read, understand, and use by programmers. For example, Plaid and Stripe APIs are examples of APIs that are easy to understand, well documented, and easy to use.
05.    The API should be available as a commercial product from at least one commercial vendor so [banks don’t](https://www.financedigest.com/dont-play-second-fiddle-how-disruptor-banks-can-leverage-music-and-audio.html "Don’t Play Second Fiddle: How Disruptor Banks Can Leverage Music and Audio") have to write it themselves.
06.    The spec should be sufficiently detailed that all implementations operate identically.
07.    The back-end of the API server should be easy for a bank to implement. For example, Token offers banks a full PSD2/RTS compliant API including very sophisticated consent management, yet a [bank only has to implement eight simple API calls](https://www.financedigest.com/analysis-powerful-swiss-central-bank-faces-reform-calls-in-wake-of-credit-suisse-rescue.html "Analysis-Powerful Swiss central bank faces reform calls in wake of Credit Suisse rescue").
08.    The API should use modern [security and software methodologies for authentication](https://www.financedigest.com/behavioral-biometrics-simple-and-secure-way-to-authenticate-consumers-digital-identities.html "Behavioral Biometrics: Simple and Secure way to Authenticate Consumers’ Digital Identities") and authorization/SCA. There must be no shared secrets between the owner of the [account and the bank](https://www.financedigest.com/scams-avoided-how-to-prevent-bank-account-scams-in-2023.html "Scams Avoided: How to Prevent Bank Account Scams in 2023").
09.    The API should not support the use of insecure standards. For example, OAuth2 is fundamentally insecure. It was designed to be insecure because they wanted it to be easier for programmers to implement. Sadly, we [see OAuth2 specified in pretty much every open banking](https://www.financedigest.com/europes-banks-brace-for-russia-fallout-while-u-s-banks-see-limited-pain.html "Europe’s banks brace for Russia fallout while U.S. banks see limited pain") standard proposal. _This is a huge mistake; basing open banking protocols on OAuth2 is a recipe for never ending [security problems](https://www.financedigest.com/no-collateral-no-problem-here-is-what-you-need-to-know-to-secure-a-business-loan.html "No Collateral, No Problem: Here is What You Need to Know to Secure a Business Loan") for the next 50 years._
10. The API should work for retail as [well as corporate](https://www.financedigest.com/corporate-wellness-market-insights-by-leading-companies-and-emerging-growth-till-2026.html "Corporate Wellness Market Insights by Leading Companies and Emerging Growth Till 2026") applications. For example, the API should not assume that there is a human being/user interface making the transaction: it should be computer-to-computer. Human interaction should be layered on top of the API, not designed into it.
11.   The API should be designed to be extensible so it can last for at least 50 years.
12.   The API should support charging API callers for the service(s) provided so that [banks can make money](https://www.financedigest.com/digitisation-of-banking-the-impact-of-digital-money.html "Digitisation of Banking: the impact of digital money"), e.g. by [secure instant micro-payments that work](https://www.financedigest.com/the-importance-of-information-security-in-a-post-pandemic-hybrid-working-world.html "The importance of information security in a post-pandemic hybrid working world") worldwide.
13.   The API should allow for [instantly pushing payments](https://www.financedigest.com/the-latest-trends-in-instant-payments-and-how-they-impact-banks.html "The latest trends in instant payments and how they impact banks") worldwide, not just a local payment push.
14.   There should not be any sacred cows, e.g. directives such as “you should start with the xyz standard and build off of that.”

Following this [process will create a solid foundation for building great applications](https://www.financedigest.com/chemical-process-mixers-industry-2021-includes-the-major-application-segments-and-size-in-the-global-market-to-2028.html "Chemical Process Mixers Industry 2021 Includes The Major Application Segments And Size In The Global Market To 2028") and benefit all parties.


---
This blog is powered by Superblog. Visit https://superblog.ai to know more.
---