Compliance as software

Four links, each one a data structure rather than a paragraph.

Most compliance functions have the first and the last, badly. The obligation exists in a policy document, the evidence exists as a folder of screenshots, and the two middle links are performed by people. That arrangement is expensive, slow, and produces evidence whose quality depends on who was on duty.

Building the middle two is the entire exercise, and it is ordinary software work.

A rule that changes without a version is a rule that has erased its own history. When a supervisor asks why a transaction in March was not flagged, the answer has to be the rule as it stood in March, not the rule as it stands today.

That means every rule record carries an identifier, a version, an effective date, an end date, and a reference to the obligation it implements. Control executions store the rule version they used. Reprocessing history is allowed, but it produces a new result linked to the old one rather than replacing it.

Of every decision in this domain, this one returns the most and costs the least, provided it is taken at the start.

A control that finds nothing tells you almost nothing, because it is indistinguishable from a control that did not run properly. What carries information is the exception: a case that failed the rule, with enough context for a human to decide.

Design the exception object before the rule. It needs the subject, the rule and version that raised it, the values that caused it, a disposition taken by a named person, a reason for that disposition, and the time. Dispositions should be a closed set, because "reviewed and accepted" written forty different ways cannot be analysed.

Once exceptions are structured, useful questions become queries. How many of this type do we raise per thousand transactions, how has that moved since the rule changed, how long do they sit before disposition, which reviewer disposes of them fastest and does that correlate with anything worrying.

The question behind most findings is not whether a control works but whether it ran on everything it was supposed to run on. A control that examined ninety-four percent of the population and reported no exceptions has reported nothing.

Store the population definition with each execution: the query, the count, the boundaries. Then a gap becomes visible as a gap rather than as silence. Reconciling the control population against the operating population is itself a control, and it is the one that catches the failure modes nobody predicted, such as a new payment provider whose transactions were never included because the query filtered on a list of provider identifiers written eighteen months ago.

Automation here removes transcription, retrieval and arithmetic, not judgement. What it buys is judgement applied to the cases that need it, with the context already assembled.

The measure of a good compliance system is what the analyst sees when they open a case. If they have to go to three other systems to understand it, the system has automated the easy half and left the expensive half untouched.

An inspection stops being an event that consumes a quarter and becomes a query. The request "show us how you monitored this obligation over the last two years" is answered by exporting control executions, rule versions and dispositions, because all three exist as data.

The second change is quieter and matters more. When evidence is a by-product of operating rather than a separate task, nobody has to choose between doing the work and documenting it, and the documentation stops being a fiction written afterwards.