A cutting-edge BaaS platform for an American bank

One of the pivotal revolutions taking place in the world of modern banking is a paradigm shift in the way banking services are sold. A large portion of in-office customer service has moved to the digital realm. For this new way of working, banks have two main channels: the more traditional approach that includes online banking apps or a newer type of system, born from the Fintech-led disruption, which consists of offering services through APIs. These interfaces connect external applications to the bank’s system and allow them to carry out operations using their banking infrastructure.

Connecting to a bank’s systems is no trivial matter. For good reason, banks are not willing to integrate third-party applications into their digital systems without careful consideration. What’s more, highly restrictive regulations such as the PSD2 in Europe, CMA Open Banking in the UK or the rules passed by the HKMA in Hong Kong regulate both the obligation to provide these services and how to manage their security and privacy.

But Sngular is well-versed in this world. So when a US bank approached us that wanted to launch an open API ecosystem to offer these sorts of services, we were ready. The bank wanted the services to include a marketplace that allowed the open APIs to be easily discoverable and integrated into clients’ applications, all while guaranteeing both security and performance scalability.

It’s important to put the importance of this project into context. That’s because, de facto, the project called for the creation of a fully cloud-based banking architecture. Despite using the client’s HOST as the Source of Truth, the cloud-based system would significantly reduce the client’s workload versus the same volume of transactions coming from the traditional system.

What made this project a good fit for Sngular? Our client got in touch with us because we’ve been working together for years. We’ve helped the bank create multiple digital channels for both corporate and commercial banking. The client knew that we were experienced in the banking sector as well as in creating integration systems, both with the client and other large, complex businesses. At the same time, Sngular is an important member of the Banking Industry Architecture Network (BIAN), a global entity whose goal is to work to create common business and IT standards for the financial services industry, so we are very familiar with the issues surrounding this type of project.

Our client’s business objective was clear: to come up with a new way of offering digital services, an extra channel to provide these services and to become allies with the fintech companies that have been eating up a significant part of the business of traditional banks. It was all to be based on a modern and elastic architecture that could be scaled up according to demand so as to serve any volume of transactions that could result from these alliances.

So, we got to work. Our teams created a complete layer for first-party services that encapsulated all the bank’s own internal services and provided access to those services through a system that guarantees security for both the bank’s clients and clients from third-party companies.

To create this entire layer of services, we opted for a microservices architecture that was developed with Java Spring Boot on top of containerized AWS infrastructure. It was developed under the “infrastructure as code” philosophy, meaning it had to be highly scalable and rapidly deployable in new environments, allow for low resource usage in moments of low volume but still be highly reliable and agile when faced with a high volume of simultaneous operations.

We also went with managed services to minimize the complexity and cost of operating a system with such a large scope and complexity. We are talking about a dozen of environments with more than 400 services deployed in each of them. It’s virtually a complete “bank as a service” that encapsulates the use of the banking HOST as the Source of Truth behind a CQRS pattern, which is particularly useful in complex environments based on events and because it allows for the use of different models for reading and updating information. Among its many advantages, it offers significant savings in the MIPS in the HOST and the consequent cost reduction.

It is worth noting that even though we are talking about an extremely complex system, it was designed to be extremely agile and robust, fully supported by infrastructure like code and a continuous integration and deployment system that allows for dozens of deployments per day during businesses hours, without interrupting the service at all. This is in stark contrast to the typical deployment cycles in banking environments, where deployments are minimized and have big impacts on operations. To make sure there were no surprises despite such agile deployment cycles, the integration pipeline included more than 6,000 test scenarios that run before each deployment to check their robustness.

The project even exceeded the ambitious proposed SLA, reaching higher than 99.95%, despite having a system that processes 130 million logs per hour or 12,000 requests per minute. All this with a full system of monitoring dashboards and alerts to ensure that absolutely everything is monitored.

Despite the inner complexity of the system, it is extremely easy to start using. All users have to do is register and receive a token with which they can connect to a sandbox. They can then use the sandbox to test the APIs as much as they want in an environment that is virtually identical to the production environment but without having to access real data and users. When users develop their implementation in the sandbox and are happy with it, they can move on to real environments using more advanced security systems. This helped achieve a perfect balance between power, ease of use and versatility. Meanwhile, all of the services provided are protected behind the bank’s security systems.

On the other hand, the API marketplace was developed with JavaScript + WebComponents technology, with Google’s Polymer library, which was eventually migrated to LitElement. This choice was made by the client due to the flexibility offered by these technologies and their high level of “future proofness.”

Several totally in-house Sngular teams worked to develop the project. Throughout, they were in direct contact with the client’s Product Owners. The work was done in SCRUM sprints. We carried out the development and the infrastructure, while the client was in charge of production support and in direct contact with customers who were consuming the services.

One of the biggest difficulties we faced came from the complexity of the APIs themselves. That’s because our client was the local branch of an international bank with an internal global API system designed to cover the needs of a number of different countries. As such, the internal API responses included a lot of data complexity that was unnecessary for serving American clients. So, one of the most important parts was to encapsulate that complexity to offer clients interfaces that were clean, clear and effective.

Another problem, which is quite typical for these kinds of services, had to do with the versioning. That’s because APIs are not stable and immutable “contracts,” and instead are constantly evolving as the services provided through them improve and get updated. However, when multiple applications access an API, changing that API can “break” the way they work. That means whenever APIs are involved or their results are received, access to the previous version must be stored to make sure nothing stops working. To do that, we worked to achieve a versioning system that was at once robust, easy to understand and maintain and easily customizable.

At the same time, being constantly on the cutting-edge of technology was an integral part of the service, which had to be as future-proof as possible. That led to multiple technology upgrades when major changes occurred (if they gave us obvious advantages) in the technologies we were relying upon like AWS services or other tools.

Working on this project has been highly enriching for our teams. That’s because it was an enormously innovative project. On top of learning about state-of-art technology, we were able to greatly expand our understanding of the business and the services its clients demand from this type of project, as well as what to offer to end customers, many of which are leading fintech companies, when developing APIs.

It couldn’t have turned out better. The system is now considered one of the best services in its category due to its versatility, robustness, ease of use and it even allowed our client to close a deal with Google that makes this the platform on which Google can offer its bank account services in the US.