Reconciliation – The process of matching two or more data sets and identifying the outliers / differences. A simple process to define and understand but equally difficult and complex to implement especially in a financial institution.
In this post, I will present my view of this simple yet very important process in a financial world. Reconciliation as per my definition above, it just about looking at two or more data sets / lists, comparing them on a common key / variable and identifying the differences. If this look at this, we usually do this in our daily lives on a regular basis. Whenever we go out for shopping and pay the bills, most of us will quickly run past the bill to check if everything that has been purchased is there, the prices are correct and there are no additional items on the bill which are not purchased. In short, we reconcile our finances on a regular basis. Another example I can think of is paying the bills at a restaurant. We always check what is there on the bill before handing over the card/cash for payment.
A financial institution also has to do similar things but at a much larger scale. A typical banking software estate processes hundred and thousands of transactions on a regular basis. These transactions originate from different sources (customers doing purchases with the debit/cards online, physical purchases are stores; customers doing online transfers; interbank transfers and settlements; incoming payments; and so, on and so forth). The varied number of sources are also linked with varied numbers of destinations (merchant accounts, customer accounts, interbank GLs, NOSTRO accounts, VOSTRO accounts, inter-branch GLs, and many more). The larger the customer base, the larger the number of services offered, the larger is the transaction base. With such a large transaction base, the reconciliation process tends to get more and more complex but at the same time, it is more and more critical to ensure that the financial transaction status stays intact, healthy and to detect potential anomalies and potential frauds. These reconciliation processes are further compounded by refunds, reversals, manual overrides.
When a financial institution provides a new service to its customers, the first and foremost task it should undertake is to ensure that all the possible transaction types, sources and destinations are included in the reconciliation process. At the same time, while developing and implementing the reconciliation process, the institution must also ensure that the outcome of these processes is verified and relevant resources/stakeholders are made aware of the discrepancies as soon as they detected. This will ensure that any inconsistencies detected are acted upon before they start slipping in cracks and someone down the line taking advantage of these and conducting a fraud.
In today’s financial world, all institutions are moving rapidly to come up with new services and more digital channels to offer to their customers but at the same time, they should ensure that proper due diligence is done on the reconciliation part as well. If this is not given the due time and effort, it would ultimately lead to someone picking it up and conducting a fraud which might not be detected early enough to take the necessary preventive measures. Having said that, no fraud can go undetected forever. Sooner or later it will come to light. How soon it can be identified will depend on how robust the reconciliation processes were developed. The more robustness built into these processes the earlier they can detect and alert about the potential frauds.
Another very important use-case of reconciliation is the system resilience, disaster recovery and business continuity. In these scenarios when the one of the system components fail and the recovery process kicks it, reconciling all the systems and transactions is of utmost important to ensure that the entire estate is consistent after recovering from the failure. Most of the scenarios tested usually follow the happy path where a controlled failover is triggered and IT and business users are asked to check if everything is in place. Even though this is a risky proposition but the DR systems should be failed over for testing in an inconsistent state to ensure that the proper recovery mechanisms are validated and above all the reconciliation process is able to pick up the missing pieces and notify the users so that corrective actions can be taken to fix these missing transactions.
- 48 views