What Your Auditor Asked Three Months Later

Your fraud team approves and declines hundreds of thousands of transactions a day. Three months later, an internal auditor walks in and asks one specific question: why did you reject this customer’s transfer on March 12?

Most banks today cannot answer cleanly. The rule that triggered the rejection has been edited twice since. The fraud model has been retrained on more recent data. The third-party device-intelligence vendor has updated its scoring tables. The original inputs the engine actually saw — the request payload, the model version, the configuration state — were never preserved in a way that can be reconstructed. The bank has a row in its decisions table saying rejected, and a vague paragraph from the on-call analyst, but no defensible explanation behind the call.

A second scenario, from the other side of the same problem: a Chief Risk Officer wants to approve a rule change. The proposal looks reasonable, but the question on the table is concrete — which past decisions would this rule have flipped? Without a way to replay history against the new logic, the answer is a guess. Banks routinely deploy rule changes without quantifying their backward-looking impact, then discover the consequences in next month’s chargeback reports.

Both questions sit at the heart of fraud governance, and today neither has a clean answer in most fraud platforms. RTD shipped two capabilities this month — Decision Audit Records and Audit Replay — that, taken together, give the fraud team a defensible answer to the first question and a quantifiable answer to the second. You can see the full release notes for the April 2026 sprint.

Decision Audit Records: a self-contained record per evaluation

A Decision Audit Record is a frozen snapshot of what the engine actually saw at the moment it produced a verdict. Not a reconstruction stitched together from logs after the fact — the actual inputs, preserved.

Each record captures the request payload (with sensitive fields encrypted at rest), the rule outputs that fired and the values they evaluated, the version hash of the fraud model in effect, and the tenant configuration as it stood at decision time. If a customer’s transfer is declined at 14:32:17 because a velocity rule triggered on a 30-day threshold and the model returned a 0.87 risk score, that is the record. Three months later the rule may read differently and the model may have shifted, but the original is untouched.

The records are stored alongside the decision data — designed to support data residency requirements, since audit data lives where decision data lives. For an on-premise deployment, that means the audit trail never leaves the bank’s infrastructure. There is no separate audit pipeline shipping snapshots to a vendor cloud, and no reconciliation question about whether the snapshot in the cloud matches the row on the bank’s servers.

This solves the first half of the auditor’s question. When an investigator asks why was this transaction rejected, the bank pulls the record and points to the inputs, the rules, and the scores that were live at decision time. How the FDE engine works is unchanged; what changed is that the bank now has receipts.

Audit Replay: rerun any decision through today’s engine

Audit Replay solves the second half. Given a stored Decision Audit Record, the engine replays it through the current rule set and the current model, and returns a structured verdict comparing the original output to the present-day output.

The verdict has four distinct outcomes:

• Match. The decision still holds under today’s rules and model.
• Drift within tolerance. Risk scores moved by less than the configured threshold; the decision class did not change.
• Changed by rule. A specific rule edit flipped the outcome. The replay names the rule and the version delta.
• Changed by model. The rules are unchanged; the retrained model produced a different score and the threshold logic now resolves differently.

The first use case is audit and dispute investigation. When a customer escalates that their legitimate transfer was wrongly declined, the fraud team can separate two questions that today get conflated: was the engine wrong at the time, and would the engine make a different call today? A “changed by rule” verdict is a clean answer — the call was correct under the rules in force at decision time, and the bank has since adjusted those rules. That is a categorically different conversation from the engine was wrong, and it lets the bank close the dispute without conceding a fault that was never present.

The second use case is safe rule iteration. A risk officer contemplating a new velocity threshold, or a tighter device-intel weight, can replay the last 90 days of decisions through the candidate rule set before pushing it to production. The output is concrete: this change would have flipped 1,247 decisions over the period — 891 from approve to review, 356 from review to decline. The team can quantify the impact before it becomes operational, rather than discovering it in next month’s metrics.

Three things this changes operationally

The capability matters in three concrete ways for a fraud-prevention organisation:

Defensible decisions on file for internal audit. Audit trails designed to support internal review and regulator examinations now include the inputs, not just the outputs. The fraud team can produce a per-decision record on demand, with the rule logic and model version in effect at the time. The auditor’s question — why this one — has an answer that doesn’t depend on the institutional memory of an analyst who may no longer be on the team.

Quantifiable rule-change risk before deployment. Rule changes stop being a leap of faith. The risk team approves a change knowing how many past decisions it would have moved, and in which direction. This shortens the cycle between identifying a fraud pattern and deploying the rule that catches it — one of the slowest links in most banks’ fraud-response chains.

Faster customer-dispute resolution. When a customer disputes a decline, the bank’s response window is measured in days, not weeks. The team retrieves the record, runs a replay, and replies with a precise account: here is what the engine saw, here is what the rules said at the time, here is what would happen today. Customers get a clearer answer; banks get fewer escalations to ombudsmen and regulators.

The shift is from records to evidence

Banks have always had decision records — rows in a table, log lines on a server, comments in a case-management tool. What they have rarely had is decision evidence: the actual inputs, the actual rules, the actual model state, frozen at the moment the call was made and reproducible on demand.

For Southeast Asian banks operating under regulatory frameworks that increasingly emphasise auditable decision-making, the distinction between record and evidence is the difference between a paragraph in a board report and a transcript in a regulator’s review pack. It is also the difference between a CRO who guesses at the impact of a rule change and one who can name the number. That is what shipped in the FDE engine this month, and it is available in pilot deployments now. Pilot terms start at our competitive mid-market pricing — talk to us about scope.

Run-True Decision is building a fraud decision engine purpose-built for Southeast Asian banks — with audit trails designed to support internal review and regulator scrutiny. Talk to us to learn more.