Trade Finance Automation
In this story I wish to walk the readers through the process how trade finance was automated in ANZ Grindlays Bank in India. This is a story of good work recognised as well as that remained recognised.
When in Jan 1991 I was transferred to Connaught Circus branch from Technology entire trade processing was manual. There was a customer liability system, meant for credit admin, working on a PC. I was not aware of the source of its update since all the records were manual. Also in place was a dBase application for sales proceeds collections for Brooke Bond India. My initial deployment was in domestic bills where the workload was extremely high.
The manual process involved were: for each bill discounted / purchased apart from passing accounting entries collection schedules were to be prepared, the discount / purchase was to be entered in the customer’s rate wise liability accounts maintained in the customer liability ledgers (CLL), entering the amounts in the rate control cards (RCC) maintained product & rate wise. For the bills payments were realized during the day these were to be recorded in RCC and CLL under specific rates.
Every month end interest used to be calculated on daily products for each product / rate and accrual entries passed. Life used to be miserable at quarter end as interest was to be recovered for the quarter from the customers. This process used to start by 10th / 11th of March, June, Sept and Dec. when the last balance for the cut off date used to be repeated and interest calculated for each customer product / rate. Similarly RCC used to be closed out by repeating the balances and interest calculated.
Daily movements after cutoff date till month end, however, used to be recorded in the respective sheets. Adjustment entries for these movements were to be accounted for in the following month for accrual and following quarter for the recovery. After all this the balance in IENC (interest earned not collected) account should have become nil after quarterly recovery. But due to some error or the other some residual balance would remain in some of these accounts. Identification process to rectify the mistake was extremely tedious.
Many things could be done to help the department handle the load. Luckily we had one staff member who was MCA and couple of others was comfortable in programming. Upon identifying the resources I discussed the matter with branch manager and the chief manager. After deliberating the issue from various aspects we decided to create programs for maintenance of Customer Liability Ledgers and RCC. Once approved by CM these were developed by the dedicated in-house team in 5-6 weeks. The output formats were created in the existing CLL and RCC forms. Since it was not a processing application we were not to capture too many details. Customer and product data was entered in the master file to start using it. To give it a try initially we picked up only one product in domestic bills. Started it from 1st of the month and entered all the bills – select customer and product enter bill amount, maturity date and rate and IENC / UID only. IENC /UID was required since some bills were handled on upfront interest basis. Remaining UID was computed by system and updated. Additionally it would update the RCC as well.
As part of daily exercise one person was to enter all discounts and payments daily in this application. This was in addition to the normal manual process. Initially it took 15 – 20 minutes per day for a person but as more n more domestic products were added it took 1 – 2 hours for a person per day. Periodically we used to print Customer Liability Ledger summary from the application and compare it with manual ledgers. Any discrepancies would be identified and corrected. At month end accrual was run in the package and Rate Control Card were printed. It was compared with Rate Control Cards, popularly known as RCC, maintained manually as per extent standard procedure. Everything was going smooth and we documented all the reports as test cases. Beginning a new calendar quarter we also started looking at recovery aspect.
Once the adjustment figures to be carried over to next quarter were ready in the manual process these were entered in the package through an exceptional process created for short period. Fruits of the efforts could be seen the month of the quarter end. On cutoff date when the process of interest calculation started manually, we also did a temporary closure till month end in the package and generated RCC and customer wise recovery sheets. These were filed separately. The closure data was kept in a temp file in the package, the closure impact undone in the main data and used normally till month end. At month end after running end of month routines we generated the accrual adjustment products using the temp closure data file.
The manually calculated recovery and interest adjustment were compared with those generated from the package. These were documented and kept as exhibits for the possible audit of the application. The entire process of parallel run continued for one more quarter documenting each report and its validation. After that we sought the audit of the application so that it could be formally used and rolled out to other units. But unfortunately for whatever reason that never happened.
Hence we could never do away with parallel posting. However we started fortnightly reconciliation of package CLL outstanding with manual ledgers, documenting these. At quarter end we stopped the exercise of manual calculation of interest and started recovering based on the package figures.
There were three main benefits we got (1) saving those treacherous 3-4 weeks when we used to work till midnight, (2) recovery of interest was actual upto date not approximation, and (3) Calculations of adjustments were done away with. Later on we created application for maintenance of forward contracts.
When the bank developed and rolled out the trade finance package CLLBills, takeover of domestic bills at Connaught Circus was very easy since soft data was available.
At the time of CLLBills implementation we decided to introduce back office processing concept in trade finance in our branch. For this a separate enclosure was made out and all CLLBills workstations were installed in it. All processing after the bills approved for processing used to take place here. Final printouts of covering schedules along with the bills sent back to the respective departments for dispatching docs and maintaining their copies / records. This version of CLLBills did not have Foreign Currency Cheque purchase module. This module was developed and implemented by the bank’s in-house technology team in due course.
CLLBills Package:
In view of growing operational compulsions automation of Trade Finance was growing momentum. Global Head Office of the bank was evaluating some suitable off the shelf package but somehow was taking much longer than anticipated. Also the modules developed by New Deihi were not acceptable by India Management for rollout due to variety of reasons. Hence it was decided to develop a new package with proper auditable documentation. This development was thought to be an interim solution till a global package was identified and implemented in India. Anticipated life span of the package to be developed was taken to be 2 – 3 years. Hence a development team was formed and put into action.
The package development planning had gone through a lot of brain-storming to identify and include not only the ways to transcribe current processes / products requirements but also to visualize the possible changes in the products / exchange rate patterns to be used. The basis used for such visualization was the trends in changes that had taken place over previous 5 years.
Hence the CLLBills package that was developed was a feature packaged software. Later any package identified by the global HQ was assessed against the features available in CLLBills. But unfortunately no global package could be found to match the CLLBills functionalities till the acquisition of ANZ Grindlays Bank by SCB was announced.
Hence the package that was developed as a makeshift arrangement turned out to be state-of-art package that sunk with the ANZ Grindlays Bank in Sept 2002.
