Hi! and welcome to this read. Now that you’re here, I hope you find it worth the time.
Having been in the Fin-tech sector for quite some time now, there is a lot that I have to learn. In most cases, it has been quite overwhelming but with support from my seniors, I always made sure I learnt something new. “So I thought it’s a good idea to share some things that I have learned during this time — because if I don’t I’ll surely forget it all myself” (This is How Globus Works — V. Kazimirchik).
One may be asking what is CORE banking?
Simply put, CORE (Centralized Online Real-time Exchange) banking is a banking system that processes banking transactions across all bank branches; i.e. where customers may access their bank account and perform basic transactions from any of the member branch, seamlessly.
Core banking system essentially includes:
- Customer relationship management (CRM) activities.
- Opening new accounts, managing existing accounts.
- Creating and servicing loan contracts.
- Processing cash deposits and withdrawals.
- Processing payments and cheques.
- Calculating interest
For the customer, core banking systems is therefore focused on enabling these clients to transact with greater freedom. With major improvements in technology, especially in banking IT and security, transactions are now safer, faster and less cumbersome. The fact that these transactions can be executed remotely, from any part of the world has made core banking systems a significant aspect of banking today.
For the banks, core banking always brings down operational costs considerably, ensuring lesser manpower requirement for execution. It also enables greater accountability of the customers. Software application based platforms make core banking systems user-friendly and more efficient. The benefits of core banking systems are multi-faceted — keeping pace with fast-evolving market, simplifying banking processes and making it more convenient for the customers, and expanding the outreach of the banks to remote places.
There are several core banking solutions/products such as Oracle’s Flexcube, Infosys’ Finacle, Nucleus FinnOne. Although, I must not forget to mention that these read will be based on Temenos’ Transact (Previously named T24).
So, what is it like to use T24 — IMO?
Temenos’ T24 is based upon a variety of functional features which have been developed to provide an end to end solution in banking. Some of T24’s prominent features that I have learnt about include:
- Fully integrated functionality: accounting, risk checking, control, messages, currency positions e.t.c all in a single piece of software.
- Time efficiency — batch and real time processing of transactions
- Multi Currency facility — a single transaction can use more than one currency, e.g. a USD AA Loan can be credited directly to a KES account without the need for Forex conversion.
- Core and Non-core banking.
Clearly, T24 can without a doubt substitute a combination of a number of banking systems that most financial institutions depend on for different business requirements. With T24, not all actions, business or non-business related, should be carried out online though. In some instances, there are boring and repetitive, usually lengthy, tasks which can be easily and efficiently avoided with T24. Such include interest calculation which is best triggered automatically as batch jobs at the end of a working day (Close of Business — COB).
I must also mention that in banking with T24, there exists some features which are CORE or rather CENTRAL to the banking system, and, of course, some that are not. What this means is that, for T24 to function appropriately, these features MUST be configured appropriately. Such include Customer, Accounts and Limits. On the other hand, non-core business modules, if I may call them so, are not really required for T24 to function accordingly — well depending on the business requirements. Such may include Forex and Securities. Meaning, these are optional and can only be procured if it is part of the bank’s business requirements.
Finally, T24 stands out with its Open Standard archetype and I would think that this is why most financial institutions prefer T24. Well, this archetype prevents lock-in and other artificial barriers to interoperability, and enhances choice of different technical solutions that the client is comfortable with. For example, JBASE i.e. J4 database does not support clustering hence only one database server can be used at a time. This is a direction a bank will wish not to take. Since T24 is independent thanks to its open standards, a database that supports clustering such as Oracle/DB2 can be used making it possible to install a single database across multiple serves — overall, sharing all kinds of data become smooth and with perfect fidelity.
Well, the adoption of Open Standards also ensures that the system users find it easy to migrate/upgrade to other solutions. Besides, what this means is that as a client, I will be at liberty to choose the specifics of the software that are fit for my purpose. Some of these factors may be cost, bulkiness of transactions over a given period, performance, support requirements e.t.c — this flexibility makes T24 versatile across small scale institutions to large multinational corporations.
A good example that I have been part of:
Bank X offers retail banking and therefore they have only procured only the application that are standard in this retail banking domain, however, if Bank X wishes to venture into a different domain, say, Corporate banking, they can then procure more business models/applications to cover this new domain without having to stop their business operations — the two domains may even share the same base for some applications such as Customer.
By the way, the applicable banking domains include but not limited to retail banking, private or trust banking, corporate banking, treasury and general banking.
To cut the long story short, let me just focus on what was my primary objective in the first place, Core T24, which as by my understanding is the most important aspect since it is central to T24 banking system architecture. Therefore, I may try to share my takeaways from:
- Customer information in the CUSTOMER table.
- Static tables related to customer such as INDUSTRY, SECTOR, DAO.
- Account information in the ACCOUNTS table.
- Accounting entries — such as mini-statements.
- Limits — that define the risk associated with any customer transaction made.
- External User s— Internet Banking.
However, as earlier mentioned, since T24 focus on scalability and flexibility among other philosophies — i.e. T24 does not function under such preset rigidity, my discussion will not be limited to the list above. Why? Bank X which operates under the retail banking domain may need to procure FUND TRANSFER (FX) which I believe is generally classified under Treasury.
Disclaimer: the materials used herein are for educational purposes only, unless stated otherwise, all trademarks are rightfully held by their respective owners.