The Open Bank Project enables banks to comply with regulation, accelerate application development, and offer an ecosystem of 3rd party apps and services to their customers. We provide banks with 400+ banking, management and open finance APIs as well as middleware (for partners and 3rd party developers), an app store (through which end-customers discover the apps made available by the bank) and a strong community of 3rd party developers already familiar with the API.

Retail and corporate banks of all sizes.

Many types of applications use the Open Bank Project API. Some examples include:

See a selection of these apps on our ecosystem page here.

The bank deploys and operates the API stack behind its firewall ensuring a level of security equivalent to any other application it runs.
We use state-of-the-art and industry-standard security practices. No app developer has access to the end customer credentials (we use OAuth). Every app is tested and approved before being accessible to the end customers.

  1. Our technology stack is battle-tested and approved by Tier 1 banks
  2. You can get to market faster
  3. Our vibrant ecosystem of developers and applications enables your customers to enjoy a true app store experience from day one
  4. Open Bank Project is open source – so you can extend it yourself or get support from partners
  5. Our solution is more cost-effective to maintain

The diagram below shows an overview.

  1. Connectors are modified to access core banking resources (bottom left blue box)
  2. Login page is branded for the bank and connected to the bank’s authentication system (right blue box)
  3. Open Bank Project servers are installed behind Bank’s firewall or secure cloud (top blue box)
  4. Bank chooses apps from OBP global App Store/vendors
  5. Customers can discover apps on the bank branded OBP App Store
  6. Bank monitors and monetizes API

It depends on the bank and the core banking system we integrate with. We offer a risk-free proof of concept to determine scope and timescale for live deployment. Banks enjoy a fully fledged API at the end of this PoC generally using test data or test systems.

  1. Banks – Banks and their Branches, ATMs and Products – available at this instance of the OBP API.
  2. Accounts – Accounts the current user has access to (including any public accounts)
  3. Transactions – For the specified account (includes metadata see below)
  4. Transfers – List transfer methods. Create a transfer. (results in transaction only on success)
  5. Cards – Held by a user.
  6. Metadata management – Authorised users can read / write data that is linked to accounts, counterparties and transactions etc.. including urls, tags, comments and geographical information tags. For instance a service specialising in geo tagging could tag transactions and other Apps could leverage this data.
  7. Entitlements management – Users can manage views / roles on their accounts so the API reveals a subset of account information and only allows certain actions. For example a view called “date-plus-category” might only contain the transaction date and a category. Or an account holder could allow their accountant full read access to transactions, or a charity could give limited read access to their donors or even the public. For another role, one user could initiate a transfer but another user has to confirm it. These roles can be mapped to internal permission systems.
  8. Challenges / Responses – In addition to primary authentication, the API provides a generic challenge / response mechanism for operations that require further security checks. e.g. to progress a transfer, the user must supply a mobile TAN.
  9. OAuth user authentication – Neither the Apps nor the API see the account holder’s credentials. Users login via an industry standard system called OAuth so the bank remains the gate-keeper of authentication. This is better for security because there is no copy of passwords outside the bank and good for the bank because it’s an additional customer touch point. We or the bank provides a bank branded login page that all Apps authenticate against.
  10. Monitoring and Control – Display API usage metrics and control which applications have access to the API (revoke or accept access of third party Apps).
  11. Sandbox – So developers can easily program against the API in the cloud or run it locally on their laptop!
  12. App Store – We provide an App Store (with it’s own API) so that Apps using the API can be browsed, filtered by platform etc.
  13. Connector architecture – We’ve built the Open Bank Project API from the outset to be core banking agnostic. A connector / mapping layer means that resources, such as entitlements, can either be stored locally (for the sandbox) or access the bank’s own internal system over message queues internal SOAP or REST services, databases or a combination of the above. The same applies for meta data and core banking resources.
  14. Starter SDK’s – We publish hello world style applications on github that already contain the OAuth flow and make some simple calls to the API so developers can hit the ground running.

Open Bank Project is a flexible and dynamic API management middleware that can adapt to its environment. You can easily create new endpoints in a few minutes without knowing how to code using the OBP tools. Otherwise, you can fork the code and modify the code to suit your needs. You must either abide by the terms of the AGPL or pay us a commercial license (see below).

Our Road Map is here.

Start by using the sandbox. This tutorial explains how to do that here.

  • Access account information and transaction history
  • Enrich transactions with metadata (tags, comments, pictures and geolocation)
  • Create/Access different views on accounts. Each view has a subset of the data to a restricted group of users
  • Transfer funds
  • Manage cards, etc.

Please also see above and the API doc for more details.

See a selection of these Apps here.

You can find the latest stable version here

It’s free to use our sandbox for testing. Using live data may be subject to charges depending on the bank. Contact us to learn more about pricing options.

  1. Banks – Banks and their Branches, ATMs and Products – available at this instance of the OBP API.
  2. Accounts – Accounts the current user has access to (including any public accounts)
  3. Transactions – For the specified account (includes metadata see below)
  4. Transfers – List transfer methods. Create a transfer. (results in transaction only on success)
  5. Cards – Held by a user.
  6. Metadata management – Authorised users can read / write data that is linked to accounts, counterparties and transactions etc.. including urls, tags, comments and geographical information tags. For instance a service specialising in geo tagging could tag transactions and other Apps could leverage this data.
  7. Entitlements management. Users can manage views / roles on their accounts so the API reveals a subset of account information and only allows certain actions. For example a view called “date-plus-category” might only contain the transaction date and a category. Or an account holder could allow their accountant full read access to transactions, or a charity could give limited read access to their donors or even the public. For another role, one user could initiate a transfer but another user has to confirm it. These roles can be mapped to internal permission systems.
  8. Challenges / Responses – In addition to primary authentication, the API provides a generic challenge / response mechanism for operations that require further security checks. e.g. to progress a transfer, the user must supply a mobile TAN.
  9. OAuth user authentication – Neither the Apps nor the API see the account holder’s credentials. Users login via an industry standard system called OAuth so the bank remains the gate-keeper of authentication. This is better for security because there is no copy of passwords outside the bank and good for the bank because it’s an additional customer touch point. We or the bank provides a bank branded login page that all Apps authenticate against.
  10. Monitoring and Control – Display API usage metrics and control which applications have access to the API (revoke or accept access of third party Apps).
  11. Sandbox – So developers can easily program against the API in the cloud or run it locally on their laptop!
  12. App Store – We provide an App Store (with it’s own API) so that Apps using the API can be browsed, filtered by platform etc.
  13. Connector architecture. We’ve built the Open Bank Project API from the outset to be core banking agnostic. A connector / mapping layer means that resources, such as entitlements, can either be stored locally (for the sandbox) or access the bank’s own internal system over message queues internal SOAP or REST services, databases or a combination of the above. The same applies for meta data and core banking resources.
  14. Starter SDK’s – We publish hello world style applications on github that already contain the OAuth flow and make some simple calls to the API so developers can hit the ground running.

You can fork the code and modify the code to suit your needs. You must either abide by the terms of the AGPL or pay us a commercial license (see below).Please also see above and the API doc for more details.

Our Road Map is here.

The Open Bank Project is dual licensed under open source and commercial licenses (see more here).

All the core Open Bank Project code is open sourced (anyone can read and modify a copy of the code) and it also uses open source technology (databases, frameworks, languages, message queues, operating systems) by default. We use the AGPL license (and offer commercial licenses when required). You can check our code and contribute here

The AGPL is the original open source license updated for the web. You can read it here: http://www.gnu.org/licenses/agpl-3.0.html

Our commercial license provides you with an exemption to the AGPL, commercial support and community building services. This means you can use the Open Bank Project as a solid basis for your API in the knowledge that you can enhance it however – and whenever – you like. The license is yearly and structured so heavy users pay more than lighter users. You can offset the license costs by choosing to contribute back some of your enhancements. The license is paid yearly. We can offer assurances that license cost increases are limited.

By charging for annual commercial licences that include support and maintenance. We also advise banks on API strategy and organise hackathons.
Get in touch for more information about pricing options.

Yes. We are on github. You can either use the AGPL and contribute your changes back to the community – or buy an annual commercial license which includes support.

Fork means to copy the code in such a way that updates from your copy of the code and our copy of the code can be easily synchronised.

It depends on the bank and the core banking system we integrate with. We offer a risk-free proof of concept to determine scope and timescale for live deployment. Banks enjoy a fully fledged API at the end of this PoC generally using test data or test systems.

Please fork, make your changes, and issue a pull request. Please sign our contributors license agreement (CLA) which can be found here.

Open Banking is both a movement and an increasingly common banking practice that enables customers to share their financial data with third-party fintech providers through Application Programming Interfaces (APIs). Fintech companies use this data to create innovative new applications and services.

We believe four principles underlie the Open Banking vision (The four O’s)

  • Open APIs: Open APIs are not public APIs. Financial institutions can expose their APIs in a controlled manner and set limits on their API calls.
  • Open Innovation: The aim of open banking is to drive innovation. The open innovation model encourages organisations to put in place a culture of openness that fosters creativity.
  • Open Standards: Adopting open standards allows financial institutions to save time and produce better APIs by leveraging industry best practices
  • Open Source: Choosing enterprise open source can mean having no vendor lock-in and maintaining tight control over the building blocks of your open banking initiative. Open source components for open banking enable financial institutions to innovate and develop at their own speed

The project was founded by Simon Redfern, CEO at TESOBE.

We were thinking about corruption and fraud and that more financial transparency could help make the world a better place. We were also not happy with the online banking interfaces we had to use.

Most but not all. For instance, if we fork the code to add bank-specific features, that code will be private until it’s considered generic enough to merge. Please ask us if you don’t see a feature.

We are a semantic API solution for banks and the financial services industry. Out of the box, developers have access to a common data model exposed via our RESTful API. This means an application written at Bank X will work at Bank Y without any modification. We provide some features expected from a generic API solution such as developer on-boarding, API logging and monitoring but you can also place a generic solution before the OBP API.

We have a partnership program for those who want to sell/integrate Open Bank Project. Please get in touch if you would like to learn more.

If you would like more information about the Open Bank Project, please get in touch here

Another question?