Name the event before letting a date change the account

A date field looks precise. It has a day, a month and a year, and it can be sorted or compared without much discussion. That precision can obscure a more difficult question: which event does the date represent? In a loan operation, preparation, sanction, signing, booking and disbursement may occur at different times. A field used to monitor one activity can create an error if another process treats it as evidence of a different event. The computer will apply the chosen value consistently even when the business meaning behind it is wrong.

A date carries an interpretation

Operations teams use dates to coordinate work. We need to know when a file arrived, when a condition was checked and when a payment instruction was prepared. Those records help managers understand the sequence and identify delays. They do not all establish that money has been disbursed. When a date begins to affect servicing or customer charges, its definition needs explicit agreement from the responsible functions. The question is no longer only whether the field is populated. It is whether the event represented is the event that should determine the account treatment.

Our review after the RBI's April 2024 guidance found 86 accounts where an internal booking date had been used before actual disbursement. The error was not that the preparation record lacked a date. It was that the servicing process had assigned the wrong significance to a date that existed. Finance and compliance checked the actual disbursement evidence and validated ₹11.8 lakh in excess charges. Operations coordinated the correction, while technology examined the mapping. A useful response required each function to understand its part without allowing the handover between them to become an excuse for leaving the customer consequence unresolved.

The distinction between a system defect and a business-definition defect is helpful but should not become a debate about blame. A field may have been mapped exactly as an earlier specification requested. That does not establish that the specification expressed the right event. Equally, a clear business rule can be undermined by an incorrect implementation. I want the review to trace the event from its source through the systems that use it, so that the team can identify where the meaning changed. Assigning fault before understanding the sequence can make people defend a local action instead of reconstructing the whole effect.

Evidence of actual movement also needs an agreed interpretation. A prepared payment instruction and a completed transfer are different records. A failed or returned transaction may require further examination. I rely on finance and compliance to determine the applicable treatment and on the banking evidence to support the operational record. The COO's role is to make sure the process can provide that evidence and that an unresolved event is not silently converted into a convenient date. The relevant specialists must be able to examine a real account sequence, rather than approve an abstract description that never encounters an exception.

Correct the population, not only the complaint

A complaint can reveal an error without describing its full extent. If the company repairs only the account that brought the issue to attention, other affected customers may remain in the same position. We extended the review to identify the relevant population and validate each correction. The 86 accounts were the result of that work, not simply a list of people who had raised concerns. Defining the population required attention to the period, the event mapping and the account evidence. It would have been misleading to assume that every account in the system was affected or that only vocal customers needed a response.

The correction also needed to be explained plainly. One commercial view was that an adjustment against a later instalment would attract less attention than an explicit account correction. I preferred an approved remedy that made the error and the resulting adjustment understandable. Customers should not have to infer from an unexplained balance change that the company previously charged them incorrectly. The exact method of correction belonged to finance and compliance, with operations responsible for dependable execution and communication. Our role was to implement the agreed treatment and preserve evidence that it reached the intended account.

There is a temptation to describe a refund exercise through the number of instructions completed. That can be a useful progress measure, but it does not necessarily show that the customer received the remedy. An instruction may fail, a destination may need confirmation or a record may not yet reconcile. The review should establish which event is being counted at each stage. Otherwise, the correction programme can reproduce the very mistake that caused the original problem: allowing an administrative milestone to stand in for the outcome whose financial consequence matters. Completion needs a definition supported by evidence.

Customer communication should also respect the limit of what has been established. An identified date error does not mean every feature of the loan was wrong. The explanation should state the relevant issue, the correction and any action the customer needs to take, without hiding the error inside technical language or exaggerating its scope. A consistent response helps service colleagues answer questions accurately. It also gives the company a record that can be reviewed later if the customer disputes the adjustment. Clarity serves both the customer and the organisation better than a vague assurance that the matter has been handled.

Test the next account as well as repairing the last

The refund schedule addressed the identified population. It did not establish that future accounts would use the right starting event. We therefore treated the process repair as separate work with its own evidence. Technology tested cases in which preparation and disbursement occurred on different dates, using bank records to check the result. The review included the handover into servicing, not just the field displayed on the originating screen. A corrected label would have been insufficient if the downstream process continued to read the earlier value through another route.

Testing should reflect the situations that created the ambiguity. If every test account is booked and disbursed on the same day, an incorrect mapping can appear to work. The test design needs variation that makes the distinction observable. That is a general operating lesson: choose evidence capable of revealing the error you are trying to exclude. A demonstration that follows only the most convenient sequence can confirm that a system runs without establishing that it represents the business correctly. Operations can help technology identify those less convenient sequences because its teams encounter them in actual work.

For a board committee, I would report the customer remedy and the process repair separately. Directors should know the validated population and amount, the evidence of correction, the change made and any unresolved items. They should also understand who reviewed the treatment. A single statement that the issue is closed can conceal incomplete work in either part. The board need not approve each refund or inspect each test, but it should be able to challenge a conclusion that rests on an activity count rather than the consequence management claims to have addressed.

The broader lesson is that a date becomes a decision when another process relies on it. Its apparent precision is useful only if its meaning is preserved. Our correction required a financial remedy, a clearer event definition and a test capable of distinguishing the relevant dates. None could substitute for the others. I want operating teams to understand that responsibility before the next account is created, so that a routine entry is treated with the care appropriate to the customer consequences it may carry through the rest of the system.