Audit Trails and Logging in Treasury Systems

A treasury audit trail is the complete, tamper-evident record of who did what, when, and to what — and in a system whose entire purpose is to move money, that record is foundational, not optional. Segregation of duties and approval workflows decide who may act; the audit trail is what proves those controls actually operated. Every other control in the landscape rests on it, because a control you can't evidence after the fact is a control you can't prove you had.

Why the audit trail is foundational

A treasury system holds financial data and executes payments and trades — it moves funds out of the company. That is exactly why the other controls exist: separations, four-eyes approvals, limits. But those controls are claims. Segregation of duties says one person couldn't both create and release a payment. The only way to know that claim held — for this payment, on this day — is a record of who created it and who released it. The audit trail is where control design stops being policy and becomes something you can demonstrate.

That framing matters because it tells you what to capture. You are not logging for the sake of logging; you are building the evidence that will be asked for after an incident, in an audit, or in a dispute. The question isn't "does the system log?" It's "can we prove the thing that matters?"

What to capture

A treasury audit trail needs to cover the actions that move money or change the conditions under which money moves:

• Transactions. Create, change and delete of deals, payments and settlement instructions — including cancellations and reversals.
• Static and master data. Changes to beneficiary bank details, standing settlement instructions, counterparties and approval limits. This is the quiet fraud path, so it needs the same rigour as payments themselves.
• Approvals and releases. Who approved what, at what level, and when — the record that makes the four-eyes control provable rather than assumed.
• Access and privileged actions. Login and access events, role changes, and administrator or "break-glass" activity, which is precisely the activity most capable of bypassing everything else.
• System and interface events. Feed failures, reprocessing, and reconciliation breaks, which connect to interface monitoring and reconciliation — an integration that fails silently is its own kind of unlogged event.

The distinction that separates a real audit trail from a weak one is the before-and-after. Knowing that a bank account was changed is nearly useless; knowing it went from this IBAN to that IBAN, by whom, at that time, is what lets you investigate. Log the what changed, not just the that it changed.

The properties that matter

Capturing events is necessary but not sufficient. The trail has to hold up, and that comes down to a handful of properties:

• Completeness. Gaps are the finding. An audit trail that covers payments but not master-data changes has a hole exactly where fraud tends to live.
• Immutability and tamper-evidence. A log that the same privileged user can quietly edit or delete proves nothing. The record must be protected from the people it records — write-once, protected, or independently held.
• Attribution to a real individual. Every entry has to trace to a named person, which means no shared accounts. "Changed by SVC_TREASURY" is not attribution; it's an alibi for everyone.
• Accurate timestamps. Sequence and timing are half the story — an out-of-hours change, an approval that came before the request. Clocks have to be trustworthy and consistent across systems.
• Retention. The record must survive for the required period. The action you most need to explain is often the one furthest in the past.

"

A log you can edit proves nothing, and a log under a shared account proves nothing about anyone. Completeness, immutability and attribution aren't features of the audit trail — they are the audit trail.

None of these can be bolted on after an incident. Attribution depends on identity being clean in the first place, which is why the audit trail and access management and user provisioning are the same problem seen from two ends: you can only attribute an action to a person if each person has their own account and their access is known.

Use it, don't just keep it

A passive log is only useful after the loss. The step that turns a record into an actual control is monitoring and alerting on the events that carry risk: a changed beneficiary bank account, a payment released outside business hours, a new admin role granted, a limit raised just before a large deal. These are the patterns that precede real losses, and catching them as they happen is the difference between prevention and forensics.

The audit trail nobody reads still has value as a deterrent and as evidence — but the same data, watched in near real time, stops being a post-mortem tool and starts being a control in its own right. Decide which events deserve an alert, and route them to someone who will act.

Docs vs reality

On paper, every treasury system "logs everything." That belief holds right up until the first incident, when someone finally goes looking. Then the pattern repeats with grim reliability: the one action that mattered turns out to have been written to a table nobody retained past ninety days, or performed under a shared service account nobody can tie to a person, or captured only as "record updated" with no before-image of the field that was changed. The logging existed; the evidence didn't.

I've watched teams discover, mid-investigation, that the control they were most confident about was the one they couldn't prove. The lesson is uncomfortable and simple: decide what must be provable before you need to prove it. Walk the sensitive actions — payment release, bank-detail change, limit override, privileged access — and for each one ask whether, a year from now, you could show who did it, when, and what the value was before and after. Wherever the answer is "probably not," that's not a logging gap. That's an unprovable control, and in a system that moves money, an unprovable control is the one that will be tested.

That's why treasury architecture treats the audit trail as a first-class design concern rather than a switch you turn on at the end. It's the layer that makes every other control real.

Part of the Treasury Systems Architecture guide. See also segregation of duties and the reference architecture. The newsletter sends one finance-systems pattern every two weeks.