What service does the Open Bank Project offer?
The Open Bank Project enables banks to offer an ecosystem of 3rd party Apps and services to their customers. We provide banks with an open API (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.
For which type of banks is this relevant?
Retail and corporate banks of all sizes.
What sort of applications use your API?
See a selection of these Apps here.
How do you ensure security?
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 will be tested and approved before being accessible to the end customers.
Why is the Open Bank Project better than building our own solution?
- We offer a modern and standards-based technology stack, tested and approved by Tier 1 banks
- You can get to market faster.
- Our growing ecosystem of 3rd party developers and applications enable your customers enjoy a true app store experience from day one.
- Open Bank Project is open source - so you can extend it yourself or get support from partners.
- Our solution will be more cost effective to maintain.
Is there an architecture diagram?
Can you summarize the deployment process for the bank?
- Connectors are modified to access core banking resources (bottom left blue box)
- Login page is branded for the bank and connected to bank’s authentication system (right blue box).
- Open Bank Project servers are installed behind Bank’s firewall or secure cloud (top blue box)
- Bank chooses Apps from OBP global App store / vendors.
- Customers can discover Apps on the bank branded OBP App store.
- Bank monitors and monetizes API.
How long does it take to deploy?
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.
What resources / features does the OBP API currently support?
- Banks - Banks and their Branches, ATMs and Products - available at this instance of the OBP API.
- Accounts - Accounts the current user has access to (including any public accounts)
- Transactions - For the specified account (includes metadata see below)
- Transfers - List transfer methods. Create a transfer. (results in transaction only on success)
- Cards - Held by a user.
- 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.
- 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.
- 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.
- 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.
- Monitoring and Control - Display API usage metrics and control which applications have access to the API (revoke or accept access of third party Apps).
- Sandbox - So developers can easily program against the API in the cloud or run it locally on their laptop!
- 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.
- 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.
- 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.
What if you don't support a certain resource / API endpoint / feature?
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).
Where is your Road Map?
Our Road Map is here.
How do I start using the API?
Start by using the sandbox. This tutorial explains how to do that here.
What can we do with the API?
- 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.
Which version of the API should I use?
You can find the latest stable version here
How much does it cost?
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.
How is the project licensed?
The Open Bank Project is dual licensed under open source and commercial licenses (see below).
What do you mean the project is open source?
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
What's the AGPL?
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
What about the commercial license?
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 knowlege 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.
How do you make money?
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.
Can we fork your source code?
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.
What do you mean by "fork"?
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.
How do I contribute source code changes.
Please fork, make your changes, and issue a pull request. Please sign our contributors license agreement (CLA) which can be found here.
What is Open Banking?
Gartner defines Open Banking as the provision of services in the context of users through API platforms; app stores and Apps. We believe three principles underlie the Open Banking vision (The three O’s)
- Open Standards based APIs that enable third party developers to build applications and services around the financial institution.
- Open Data options for account holders to enable easier financial transparency.
- Open Source technology to achieve the above securely, rapidly and cost effectively.
Who's behind the Open Bank Project?
The project was founded by Simon Redfern, CEO at TESOBE.
Why did you start the Open Bank Project?
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.
Is everything on github?
Most but not all. For instance, if we fork the code to add bank-specific features, that code will be private until its considered generic enough to merge. So please ask us if you don't see a feature.
What about generic API management solutions? How do you compare?
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 App 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.
How do I partner with you?
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