Most of the core banking solutions today still follow the traditional monolithic architecture at the core. The front-end and modularity added seems like a top covering but under the hood they are still using the data structures which remind us of legacy code.
Recently I started reading about the #blockchain technology and how it is providing a different approach to have a new form of data store. A store that is immutable and works on the basis of consensus. A shared model where data once committed cannot be changed (immutable) and that to commit a data set, a consensus is needed from the participating entities.
Looking at the what this technology works, it got me into thinking on how it can be used in the modern day financial industry. The most heard uses-case of this technology in the financial services is about "Trade Finance" (#tradefinance) where multiple parties are involved and need a more transparent and shared technology foundation to conduct transactions without the need for a lot intermediaries but still being effective and efficient.
However, my thoughts were about using this at the core within the enterprise and not just across multiple enterprises. The main struggles I have seen in my experience with the financial industry is of sharing of data across multiple systems in a quick and consistent way. Additionally there have been use-cases where multiple channels/applications also need to update this shared data. Given the fact that blockchain attempts to create a shared ledger of transactions which can be updated any participating entity, I believe this can serve as the foundation to address these challenges.
But before I get into my thought process here, I took a very high level birds-eye view of what components make up the core of the financial industry. I can see that there are 3 major categories which make up this.
- Customers
- Accounts and Transactions
- General Ledger / Accounting Rules
Let me just briefly touch upon these before moving further. For a financial institution, it has to server its customers (Retail, Wholesale, Commercial, Corporate, and so on and so forth). There are attributes to each class of the customers but in a nut-shell this category of data is all about customer identification and the relevant non-transactional attributes.
Once a customer is on-boarded in the system, the customer would hold multiple type of accounts (Current, Savings, Loans to name a few). The basis characteristics of this category is that each account has a current state (balance) and a set of transactions (credit or debit). There is nothing else to be included here as a data set. There would be rules on how and by how much a credit or debit would happen on a specific account (the rules) but for the account dataset category the most important elements are balance and transactions.
The last category is more for the financial institution to do its own internal accounting to server its customers and maintain their working model. These are also similar to the "Accounts and Transactions" but are only used for the operations of the institution. For example: as and when cross-currency transactions are happening in the customer accounts, the institution needs to track of how much of which currency the balance should be maintained. In parallel, the various markups and fee charges captured from the customer transactions also need to be distributed to the different internal entities like treasury, operations and different business lines of the institute.
Once we understand the basic foundation data set or categories of the financial industry, the next in line is the rules to add data into these categories. This is specific to just the addition of data because to maintain the consistency of data sets, a system should never delete any data instead any incorrect entries should be corrected with compensating entries rather than updating and/or deleting existing transactions. This notion is very important as this is the one which if not followed strictly will lead to downstream issues and impact the reputation of the institute.
Now that we have looked at the basics, I wanted to share my view on how blockchain can help in creating a future core banking software. To start with, the software would rely on various chains in each of these categories. Also the most important part of the software would not be these chains but the #smartcontracts that live on these chains. To quickly recap, a "Smart Contract" is a piece of code (set of rules if you may say so) which can add data to the chain on which it resides depending the condition defined in the contract. The smart contract is what would define the rules on how and what data is added to the chain. For example: a credit to account via an incoming funds transfer is done via specific smart contract for such scenario. Since this smart contract is specific to scenario, it would know what else to do and which type of entries to pass on not just the accounts chain but also trigger the necessary accounting entries on the other chains like "General Ledger" ones.
The software would then consist of two broad components. The chains of data and the wide variety of smart contracts sitting on top of these chains. Whenever a new type of rule needs to added (for example a new loan product needs to be defined) a new smart contract can be created. Now these new contracts would not be entirely new but minor changes to some of the existing contracts so as a base the closest matching contract can be copied into it and the changes added to it to make it a new contract. This way whenever a code change is needed for a specific scenario, the change would need to be done only on that specific smart contract. This will ensure that any change in a specific area of code cannot impact any other area or scenario. Additionally, this aligns the software to a more #agile and #cloudnative deployment relying truly on #devops to attain the efficiencies even further.
- 271 views