The foundational piece that is needed by any institution that works with financial products. Whether a Bank or a FinTech company.
This post as a third part in the series of posts. I have to say this part is the part I'm most excited to write about. In my journey of building a fintech company this part was the most fun to build. I think during the toughest of times the excitement of building the core banking was what kept me going.
Let's first answer the question of why core banking is needed in banks and fintech companies.
Why Core Banking?
As humans we have multiple ways of handling money. We are evolving from using physical objects and transitioning into more abstract ways of representing money. The modern economy has multiple versions of money, physical cash, cards, and more recently mobile / digital wallets on our devices.
Cash is one way of doing accounting. It is using physical representation to do accounting of how much value one person has in physical form in their wallet. The wallet exists only to hold physical cash. Imagine you have 10 $100 notes in your physical wallet, you go and buy something for $500, you will physically hand over that 5 $100 notes and be left with 5 $100 notes leaving you with $500 in total balance in your wallet. I would say physical cash is a representation of an abstract concept of "accounting".
Now let's imagine the transaction above of purchasing items happening 10,000 times, each with different values and with different people, happening all at once. That's basically how our economy works! When you make a purchase, you are only responsible for how much you spend, the merchant is responsible for how much she has collected. Each party in the transaction is doing their own accounting.
Given that we're now transitioning to a more 'digital' economy. Money will become once again a more 'abstract' concept. You will only experience money in digital form. In fact there is no wallet. The concept of digital wallet exists only on your device to make it easy for the users to comprehend. Naturally if you wanted to have digital systems that keeps track of all the transactions and the ledgers of all the members in the economy everything will need to be digitized! This is the purpose behind core banking systems. Digitizing money enables many more possibilities! Your money is shapeless and formless. They can be accessed on any of your devices and you can send money to anyone no matter how far away they are! You can use your money to purchase goods on online stores, pay for services you use all without ever leaving your house.
How does Core Banking Work?
One of the most basic component of the core banking is the ability to handle transactions. Transactions represent intention to move funds from one place to another. That's all it is. In the above example of buying something. All you are doing is moving $500 from your wallet into the merchant's cash register. Eventually the merchant will 'move' that money collected into some kind of 'bank account' for safe keeping.
Now that we've established what a transaction is. This means you will need some kind of 'source' and 'destination' to keep track of this flow of funds. This also means that there has to be some kind of ledger system within the core banking. Let's take a moment to understand how transactions and general ledgers work.
Let's start with Deposit
Let's imagine you have $1000 physical cash and you wanted to digitize it. In the modern day and age, you would go to the bank open an account and deposit your cash. Once you deposit your cash, you can then access your money using your smartphone or even your watch. Let's take a look at that step-by-step starting with depositing your cash.
You can probably understand the image above. The question may arise "how does this look digitally?". Usually banks will use some sort of centralized database to store this information. Let's take a look at how this would look in the database. Do note that this is a simplified example to illustrate a point. In reality the design may be much more complex.
We'll start with just the account opening. In this case the account opening means the balance will start at zero. The 'deposit' transaction will have to be represented separately. We'll call the table of entities that has the ability to 'hold' an account 'holders'. The actual record that keeps the balance is called the 'accounts'. Given that 1 holder may have many accounts it's better to have this sort of structure.
Next we'll take a look at how a transaction is represented. Given that we've established that a transaction is the 'movement' of fund from source to destination. Cash has to be represented in our system somehow. The transition from physical to digital has to be created in some way in our system. Let's take a look at how that would work.
What we can do is add a 'system' entry with it's own 'account'. The balance is zero but we'll make the 'minimum_balance' infinity since we do not know the limit of cash 🤣. In systems you can represent infinity in many ways. However I won't go into that in this post. We now have a system level 'holder' and has an account with zero balance but infinite 'minimum_balance'.
All we have to do now is create a transaction that represents the movement of this 'Cash' to 'John's' account. We'll introduce a new tables into the mix let's call it 'transactions' and 'changes'.
We use the 'transaction' record as the main record that 'encapsulates' the 2 changes that happened on 2 accounts. The change on each account is recorded separately. We can also use the 'transactions' table to record the 'maker_id' if we wanted, however to keep focus on the actual funds movement in this case we will keep it simple.
You can see that in this case we are removing $1000 from the 'Cash' account. Both the changes are grouped by the same 'transaction_id'. This means 1 transaction will be able to show exactly what happened.
In this case we moved $1000 from the 'Cash' account in the system which has the account_id 2 to 'John's' account which has the account_id 1.
All the entries in the database should represent a complete picture of how the deposit happened when you open an account in a core banking system. This is just one design. There can be many other designs based on requirements.
At this point one may wonder, "how does this get displayed on my devices?". That's a great question. This is where APIs come in!
What is an API?
APIs in full form are "application programming interfaces". In this post I won't go into the full detail, however APIs are essentially a way to expose functionality of some systems to the outside world. They're usually secured with some authentication. This is why when you use your mobile banking application you have to login using your password and your OTP token of some kind.
APIs enable your mobile device or web interfaces, to talk to the core banking in a secure way, and enables your device to retrieve your information from the core banking system.
Making Transfers
Now that we understand APIs and core banking and how they keep track of funds movements inside the system, we can now take this to the next level.
Let's imagine you have a friend who also happens to have an account in this same bank and has deposited. The database would look something like this.
I've also added the maker_id field to track who the "maker" for a given transaction is.
Let's assume that John wants to transfer $500 to Dave. You could assume some kind of UI like this.
Finally in the database a new transaction would be created with the changes to move 500 from John's account to Dave's account.
This is a simple example illustrating the core mechanics of what one possibility of the main components of a core banking system would look like. There are many possibilities depending on requirements.
Complexities
Generally when building core banking, though it may look simple in reality there are many challenges that can cause difficulties in developing such a system. For example. Since creating these transactions can take time to fully execute, you cannot always afford to 'do everything all at once'. Imagine you had 1000s of transactions coming in, you would have to make sure the system can operate asynchronously. Which means you break operations into small parts and put them inside a some sort of queue and distribute the workload.
There are also other problems like race conditions which can crop up. This means you will have to take into account things like locking accounts when a transfer is in progress so double deductions do not happen. It would be terrible for an account holder to have $1000 but due to lack of proper operations enabling the holder to spend $2000 accidentally.
You'll also want to use databases that support transactions of some kind to ensure that all the necessary updates and insertions happen in a single database transaction. If one of those entry fails, it should rollback.
There are also issues of handling double transactions. How do you prevent customers from accidentally creating 2 of the same transactions.
These are just the beginning of the list of common issues that can crop up in core banking systems. Proper engineering and due process need to be put in place to ensure the integrity of the system.
Keeping things secure is another important factor. Since everything is stored in centralized database, ensuring proper procedures are in place to restrict database access is critical. Imagine a hacker hacks into the database and replaces the value of an account from 1000 to 1,000,000. That would not be good would it!
Conclusion
There are many ways to build Core Banking. The same mechanics can be used to power lending products, cross border payments, digital wallet systems and many other types of financial products. Having access to such technologies would have been extremely difficult many years ago. There are platforms like this for sale however they are very expensive and since it's an off the shelf product it may be difficult to customize to serve unique business requirements.
Having the ability to build and maintain a reliable core banking system can be a huge advantage for any organization providing financial services.
There are many more things to explore with the concept of core banking. In this post we only covered account to account transfer within the same bank. How would this work in a cross-bank transfer. We will explore such topics and much more in future posts!
If you are interested in learning more please subscribe. I'm also very versatile when it comes to building such complex systems. I have experience in various industries if you are interested in working with me you can reach me from my consultancy business artellectual.com
Top comments (0)