The banking project has turned a corner.
Status
The development of the last eight months has led to a barebones functional banking core with a REST and CLI API and mobile application. With a few rewrites under the belt tests have been written, error handling has been implemented, and benchmarks have been included. The mobile application has been written in a few languages with the final choice being React.
The system is stable and allows for:
- Account CRUD
- Authentication using tokens, and per device
- Payments
- Deposits
The reason for the development hold has been due to the next steps for the application.
From here to where
As most of you are aware, the financial industry is incredibly closed, especially when it comes to anything involving accounts, payments, or security. For the banking sector, and any core banking application, those points cover the entire application. This leaves us at a bit of a cross roads, but first let’s talk about security.
Integration and NDAs
Many primary service providers in the banking sector require you to sign an NDA in order to write an application that integrates with their stack. Unfortunately, these service providers control the network in such a way that you have to integrate with them. The ones we are most interested in for the UK are:
- Bacs - Direct Debit
- Chaps - Real time, big value transfers
- Link - ATMs
- Faster Payments - Real time payments
These companies require you to be a member in order to have access to the documentation. Most of the time the documentation itself is then under NDA. The only reasons I can think of for NDAs for integration documentation is “security” or because there is genuinely something novel about their implementation.
Aside: when I was looking into integrating with a prepaid provider, the integration documentation was under NDA. I can’t think of how this is justified.
Reason 1: Security
Security by obscurity is not a valid argument. Certain core parts of the security infrastructure can be kept secret, but integration documentation should not. The integration documentation would by necessity deal with public-facing services. By their nature they have to be open to the world (the companies whom they are serving) and as such are open to attack.
Here are more articles on why security through obscurity is not a good idea:
A great quote on this:
Security through obscurity would be burying your money under a tree. The only thing that makes it safe is no one knows it’s there. Real security is putting it behind a lock or combination, say in a safe. You can put the safe on the street corner because what makes it secure is that no one can get inside it but you.
If you are from a provider and running on old systems, please get in touch. I would love to help modernize.
Reason 2: Genuine innovation
The second argument would be that these companies have implemented something genuinely novel and exposing this would harm their customers or put them in jeopardy from competition.
As we are dealing with the application layer, they company exposes what is needed for applications to integrate not how their system works internally. APIs abstract functionality, so calling a generic function (“Make payment”) can result in proprietary algorithms, checks, fraud prevention or anything else being executed on the back end.
Having said all of this, the argument for genuine innovation through workflow or API endpoints doesn’t stand strong in the current ecosystem. Most everything that is done has been done before.
The bottom line on NDAs and integration into necessary services: they should not be in force. Companies, developers, researchers should be able to ask a question about how the financial system works and be able to find the answer without paying fees or joining a club. This is a genuine barrier to innovation.
Real world integration
The first, and preferable, option is to integrate into the real world. The two most attractive outcomes are:
- Building core banking infrastructure
- Building a bank using our core banking infrastructure
In order to achieve either of these outcomes there are several needs to be met from our side, by far the biggest being knowledge on how to integrate into the various systems.
In the UK, the Bank of England seems pretty open to getting more competition into the banking sector. Great initiatives like the ODI could also be a massive help in supporting the goals we have. With the project being open source there is a lot of value to both of these players and the industry as a whole.
In developing markets there is a lot of room for disruption. The barrier to entry on a software level is very high, while the systems in place are often antiquated. We are actively looking at getting involved with start ups in these spaces (Africa, South America, India, etc). Please reach out if you want to chat more.
Documentation is the biggest challenge. Once we have that, we can start opening up this sector and really push innovation.
An isolated system
The second option is to build an isolated system which would serve as more of a thought experiment, implementing various standards and flows. The main problem here is that the system will probably stay isolated.
Even in the presence of various (and many) standards, these are hardly adhered to. Banks and providers who adhere to these standards do it in their own implementation, making it less of a standard and more of a guideline.
There is still value in this approach. We can open up the financial system to a point, showing how various centers speak to one another, the code for doing so, protocols around this implementation, etc. There is a lot that can be discovered through a “software project” approach.
Conclusion
The project still draws a lot of attention, and we are currently looking at some great opportunities. If you are keen to get involved with the project, want to use the software in a venture, or have some insight to give please get in touch.
The banking project is still very much moving forward. As the various hurdles are overcome, development will ramp up once more.