Audit logging is the least interesting item on any procurement checklist. It gets a tick, a line in the security questionnaire, and no further thought, because it sounds like plumbing.
It is worth a few minutes on the day it stops sounding like plumbing.
The conversation it exists for
An examiner has picked a sample of cases. Usually not the difficult ones. Often the ones closed quickly, because a fast disposition is the cheapest thing to test. For one of them, from twenty-two months ago, they ask some version of this:
Walk me through how this was cleared.
There are two ways that goes, and the difference has nothing to do with whether the original decision was any good.
In the first, someone opens the case and reads the note. It says the counterparty was verified. Verified against what, and when? The screening vendor's record has refreshed since, so what you can see today is not what the analyst saw. The analyst has moved on. The manager who approved it remembers the customer but not this case. Everybody in the room is now doing forensics on their own file, in front of a regulator.
In the second, the record shows what was retrieved, when, from which source, what state it was in at the time, what the analyst was looking at, what they decided and which standard was in force. That takes four minutes.
The decision might have been perfectly sound in both. What differs is whether you can show it, and being able to show it is what is actually being tested.
What a thin answer costs, and who pays it
Worth being concrete here, because this is where it stops being abstract.
An MLRO is personally accountable. Not the vendor, not the platform, not the compliance function in general. A named individual who signed, whose professional standing, and in some jurisdictions whose personal liability, turns on whether the programme was running as described.
The finding in these situations is often not that a decision was wrong. It is that the firm could not evidence its process. That reads as a governance failure, it tends to generalise from the sampled cases to the whole programme, and the remediation costs several times what the original work did.
So the audit trail is not really a record of what you did. It is what determines whether what you did counts.
Why a case note is not an audit trail
Most firms have something here. Usually a case note, written after the decision, by the person who made it.
There are three problems with that, and none of them are anyone's fault.
It is written from memory. The note records what you recall considering, not what you actually opened. Those drift apart, and they drift most under time pressure, which is exactly when the questionable dispositions happen.
It does not capture state. A note saying the counterparty was screened is not the screening result. Vendors update, registrations lapse, sanctions lists change. Two years on you can prove a screen happened but not what it came back with, which is the part that mattered.
It can be edited. A record that can be revised afterwards carries much less weight than one that cannot, and an examiner knows the difference. In a system with no version history, a good-faith clarification and a quiet tidy-up look identical.
What we do instead
Three things, and they are the kind you can ask to be shown rather than told about.
Evidence is kept, not referenced. A screening result, an address attribution or a chain lookup is stored with the time it was captured, as it stood at that moment. Not a pointer to a live record that will have moved on. Some things cannot be reproduced after the fact at all, so they are simply retained: the fiat value of a transfer at the time it was assessed stays permanently, because you cannot go back and derive what one vendor's rate was at one instant.
The record cannot be edited, and that is enforced by the database rather than by policy. The application's own role has its update, delete and truncate permissions revoked on the audit table. It can append and it can read. It cannot revise. Each entry also carries a hash over its validated contents, so an altered record would no longer match itself.
That distinction is worth more than it sounds. "We do not edit audit records" is a policy. "The service has no permission to edit audit records" is an architecture, and only one of those survives a change of staff.
Versions are recorded, not just outcomes. Every recommendation carries the version of the standard it was assessed against, every case note the version of the template it came from, every audit entry the version of the schema it was validated against. So you can answer not only what was decided but what the rules were on the day, which is the question an examiner reviewing a two-year-old case is really asking.
This is also what holds the rest of this series together. The agent gathers, it advises, you decide, and the record is what makes all three defensible later. Without it you have a faster process and exactly the same exposure.
The awkward part
You are not buying an audit trail for today. You are buying it for a conversation you cannot schedule, about a decision you have not made yet, with someone whose job is to find the gap.
That is a hard thing to feel any urgency about during a procurement, which is precisely why it gets a tick and no scrutiny.
It is the one part of the system that has to work on your worst day.