Wednesday, 2 December 2015

Agile banking needs a new core

If you had the chance to design a bank from scratch using only one system, what would it look like?

When we started to run our banking services, we had a look at the banking value chain. Banks produce services directly for clients 'at the front'. Less visible and much more important: 'in the back', banks provide complex technical infrastructure for processing, accounting and regulatory tasks. At the front, there’s plenty of new competition. Fintech start-ups usually pick cherries from the front-end banking businesses. But they still rely on crucial processes from the old banking infrastructure.

This article originally appeared on

We can observe that especially very fundamental and traditional banking processes like accounts, payments processing and credit administration remain untouched. So when we considered our new core banking solution, we wanted to be different. We built up a service that integrates front to back banking, including all accounting and regulatory activities within one system only.

So imagine you had the chance to design a bank from scratch using only one system. What would it look like?

100% automated

We want our bank to be 100% automated in every respect. Our banking processes must be designed to run fully automated. We made many compromises by reducing functionality to achieve this goal. For example, it is only possible to create an account using one of our online channels. But the online channels all used our API which allows a fully automated account registration.

We also automated our IT systems by using Infrastructure as Code. Amazon Web Services provides a service called CloudFormation. With CloudFormation the approach to manage infrastructure changes. Our infrastructure is managed with code. Code creates network, servers, firewalls and code also deploys our software in a way that our users are not affected. We treat this code as we treat our software. We store our infrastructure code in Git and we automatically test our infrastructure whenever a change is made to the code.

CloudFormation uses your description to spawn the infrastructure for a new bank within a few minutes. Whenever one of our engineers committed a change to our codebase, a new bank was created from scratch and all our integration tests were running inside that temporary bank. No human being has ever accessed our IT systems. We control our IT with machines and we test our IT like you test your software. This provides a new level of security and stability.

Real-time from the front-end to the back-end

One of the big problems in banks is managing risk. Risk is usually an aggregation of your bank so you need to know mostly everything to manage risk. But a bank has no idea what’s going on. They spread information across hundreds of systems, run batch jobs like crazy, but in the end, they never have a consistent view across all systems. They need weeks to analyse if they will eventually collapse if Greece exits the Euro. But we want to know that in real-time because we care.

If one of our customers changes currencies, our FX risk changes in the same second with our balance sheet – we need only one single source of information in real time.

On the shoulders of a giant

Banking business is volatile. People pay their rent and insurance, receive their salary all on a handful of days during a month.

On some days the volume of stock orders increases 10 or 100 times. That’s pretty bad for a fixed capacity IT system. That’s why we chose Amazon Web Services as our hosting provider. We can scale our capacity based on demand. If we need more servers at the end of month, they automatically start up. If our systems are bored, we remove a few servers.

We even bid on capacity to run our Value at Risk calculations, like we bid for stocks and bonds on all big exchanges around the world. On AWS you are able to bid on server capacity. For example you can bid $0.10 for a server per hour. If the market price goes above $0.10 you receive a short notice before your server is killed. But that’s not a problem if we talk about risk simulations. It’s enough to rerun your simulation a few minutes later. And if not, you always have the ability the pay the ondemand price to get stable servers. 

What we built: we now operate a 100% automated bank in real-time on the shoulders of a giant. Security is built in because we avoid human errors as much as possible and follow the principle of least privilege.

Tullius Walden Bank runs on AWS, exposes a REST API, follows the microservices idea and continuously pushes releases into production – engineered by C inovo for Tullius Walden Bank.

By Christian Burkhardt and Michael Wittig

No comments:

Post a Comment