How to Integrate With the Open Banking Ecosystem?


Open banking is a financial services term. In terms of financial technology it refers to:

   -   The use of Open APIs that enable third party developers to build applications and banking services for financial institutions.

   -   Greater financial transparency options for account holders ranging from Open Data to private data.

   -   The use of open source technology to achieve the above.


Open Banking, as a concept, could be considered as a subspecies to the Open Innovation concept, a term promoted by Henry Chesbrough. It is linked to shifts in attitudes towards the issue of data ownership illustrated by regulations such as GDPR and concepts such as the Open Data movement.


The financial services industry has long embraced standards as a way to simplify banking data exchange and Open Banking API integration between banks, clients, central banks, securities firms, and other market infrastructures. But, some would argue that there are too many standards, and as new standards are introduced, the old ones are never retired. For example, the European Central Bank mandated the use of the ISO 20022 XML standard for SEPA payments, but elsewhere in the world, the ISO 20022 standard is being used alongside decades-old domestic payments formats and information reporting standards.


Open banking APIs provide the technological means for banks to connect their payments and data services to third parties, which is the core intent of PSD2. This collaboration enables veterans and challengers alike to use customer data and account information and innovations to create new revenue streams and more contextual Open Banking API integration services. But there are obstacles to overcome in developing these interfaces.


Payment services directive PSD2 requires financial institutes to share customer data with regulated third-parties only if the customer explicitly gives consent. But, as Sahana Hussein, HSBC’s head of open banking, explains, there is no explicit requirement for banks to share data via APIs, as the regulation doesn’t mandate a specific technology.


Problems in Open Banking

One of the main challenges facing open banking is security. The majority of companies that are championing open banking are small FinTech companies, not tech giants like Apple and Google, and a lack of homogenous technical standards, such as certain security requirements, combined with complex internal technology systems may make the process susceptible to corruption and fraudulent activity. By creating complex chains of transaction data access, it also makes it harder to prove who was at fault following a breach.


Another concern about open banking is liability, as inserting third-party providers into the banking process increases the risk of scammers gaining access to customer information, account information and finances. Under open banking, consumers should have any losses reimbursed by their banks unless there is reason to suspect fraud or negligence. But, with both banks and FinTechs alike facing increased security threats, without proper legal clarification it’s inevitable that providers will try and blame third parties.


Finally, a lack of education and awareness around open banking capabilities has made consumers less likely to consent to their transaction data being shared, limiting banks and FinTechs ability to innovate. Recent research by Accenture shows that two-thirds of consumers would not be willing to share their personal financial data with third-party providers while in September, an independent consumer review body, revealed that 92% of consumers had never heard of open banking. To negate this, banks and FinTechs must educate consumers on the ways in which open banking can improve how they organize and take control of their finances, including through monitoring spending and making better saving and investment decisions.




Implementation of standardized APIs for banking

Each bank has implemented the open banking standards differently. This lack of standardization is bad for everyone: It increases costs and complexity for each bank, it opens the door to insecure solutions that expose banks and their customers to unnecessary risk, and it hinders adoption by software developers who only have capacity to write one or two open APIs at the most.


The standards that have been created/proposed leave a lot of room for improvement. The U.K. open banking API, 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 for charging the caller a fee. The Berlin Group standard is very complex.


If open banking is to reach its full potential, here's what should be done - the top banks worldwide should jointly fund the creation of a worldwide open banking standard. The creation of the API should be done by a commercial vendor selected by the banks. Presumably, it would be a vendor that specializes in open banking APIs and also has expertise in secure, instant micropayments.


The chosen vendor for the API design should seek input from all parties in the ecosystem: small business, consumers, banks, service providers, software developers, system integrators, regulators, and security experts.


To be a global standard, it’s really best that it starts with global support. Trying to take a standard from a single region or country and get the other countries to adopt it is harder (especially one that has been designed by committee).


The best standards are created by small teams of highly competent people working together in close proximity. In contrast, “design by committee” efforts take a 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 devices were all created by commercial vendors, not by nonprofits or industry consortiums. Choosing multiple vendors to work together is also infeasible. Great products aren’t created this way.


Getting input from all stakeholders is not controversial. Importantly, however, this doesn’t mean vendors should accept it all blindly. A good design is always an iterative process and input is often conflicting.


The API should be simple and low-level, somewhat analogous to the BIOS layer in personal computers: the simplest possible API that safely exposes the offered banking functionality and handles authorization and consent management in a consistent, secure manner. This would enable vendors implementing other open banking API specifications to build on top of this core layer. For example, the OFX standard has worked very well over time 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.


The API standard should specify things at a high level, for instance a payment request that can include metadata, and let the meta data itself be self-describing. Higher-level APIs could translate the metadata to/from a variety of formats.


It 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 because the security is built into the architecture. In 2018 the API should also 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.


To integrate with the Open Banking Ecosystem the API should be available as a commercial product from at least one commercial vendor so banks don’t have to write it themselves. The specs should be sufficiently detailed that all implementations operate identically. 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 a very sophisticated consent management, yet a bank only has to implement eight simple API calls.




How to simplify the integration?

Additionally, the API should use modern security and software methodologies for authentication and authorization/SCA. There must be no shared secrets between the owner of the account and the bank.


It should not support the use of insecure standards. For example, OAuth2 is fundamentally insecure. It was designed to be insecure because the designers wanted it to be easier for programmers to implement. Sadly, we see OAuth2 specified in pretty much every open banking standard proposal. This is a huge mistake; basing open banking protocols on OAuth2 is a recipe for never-ending security problems for the next 50 years.

The API should work for retail as well as corporate 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. The API should be designed to be extensible so it can last for at least 50 years. And it should support charging API callers for the service(s) provided so that banks can make money, for example by secure instant micropayments that work worldwide.


Archer-Soft has over 17 years of experience in developing high quality software and our portfolio includes mobile applications, web services, and online platforms. If you have any questions about using bank APIs for app development, please contact us via email at