Briefings · 11 May 2026
When recoveries in the case system never reach the ledger
A fraud-monitoring application can show a case as recovered while cash and the general ledger tell another story. Here is how we test that split in Malaysian institutions.
Investigators close a case as recovered. Finance never sees the money. Or finance books a recovery that the application still carries as a loss. Both failures are common once a fraud-monitoring application has been live for a few years and the original posting design has been patched by workarounds.
The first question is not “is the application accurate?” It is “what financial event is this status supposed to represent?” Recovered, written off, refunded to customer, released from hold, and charged to a business unit are different events. If the application uses one status for several of them, the ledger will never stay in step.
In fieldwork we lock a period — often a quarter, sometimes a financial year — and extract every case whose status implies money moved. We then ask finance for the accounts that should have moved: recovery income, loss expense, customer liability, suspense, and the bank or clearing account. A three-way match follows. Breaks are not treated as IT defects until we have ruled out timing, a journal posted to the wrong cost centre, or a recovery collected by a branch that never told the financial-crime desk.
Malaysian institutions sometimes keep recoveries in a branch suspense account for weeks because the application cannot emit a posting file. That is a design choice with an accounting consequence. The management letter should say so, rather than blaming the investigator who marked the case complete.
If you only sample alerts, you will miss this. Alerts are a workload measure. Recoveries are a financial measure. Audit the money, then decide whether the application’s status model is fit to carry it.