Governance
The model documentation a supervisor will actually ask for
Teams deploying their first model inside a financial crime control usually prepare for the wrong conversation. They arrive with performance metrics — precision, recall, an AUC figure, a lift chart — because that is what the modelling work produced and it feels like the answer to "does it work".
It is the answer to a question nobody is really asking. Performance is table stakes; a model that did not perform would not have been proposed. The questions that actually get asked are about control, and they are answered from documentation rather than from notebooks.
The question underneath every other question
Reduced to one sentence, what a supervisor wants to establish is: if this system made a wrong decision, would you know, and could you explain it?
Everything below is a specific instance of that. It is worth keeping in mind because it tells you what a good answer looks like even for a question you have not anticipated.
Purpose and boundary
What decision does the model participate in, and what does it not do?
This sounds trivial and it is where a surprising number of conversations go wrong, because the answer has usually drifted. A model built to rank an alert queue gets quietly used to suppress the bottom decile. That is a different control with a different risk profile, and if the documentation still describes ranking, the firm has an undocumented control change.
State the decision boundary explicitly: what the model outputs, what a human does with it, and what the model is specifically not permitted to determine on its own.
Data lineage
Where does each feature come from, and what happens when its source changes?
This is the least interesting section to write and the one that most often reveals a genuine problem. Features derived from fields that are populated inconsistently, maintained by a team that does not know the model exists, or subject to definitional changes at the source system are a live risk to model performance that nobody is monitoring.
The documentation needs the feature list, the source of each, the owner of each source, and the change-notification path. If there is no change-notification path — if the upstream team can redefine a field without anyone telling the model owner — that is a finding, and it is better to write it down yourself than to have it found.
Training data and its limitations
What was the model trained on, over what period, and what does that population fail to represent?
For supervised models in this domain the honest answer usually involves an uncomfortable admission: the labels are historical dispositions made by analysts under operational pressure, and their quality is variable. Say so. A documented acknowledgement of label noise, with an estimate of its scale from QA data, is far stronger than a confident silence.
Note the coverage gaps too — customer segments, products or geographies thinly represented in training. Those are exactly the places where performance will be worst and where the model should be trusted least.
A documented weakness is a controlled risk. An undocumented one is a finding waiting for an examiner.
Explainability, at the level of the individual decision
Not a paragraph about the method being interpretable. A concrete demonstration: pick a real alert, show what the model output was, and show which factors drove it — in language an investigator can use in a narrative and a supervisor can follow.
The test is practical rather than technical. If an investigator cannot say, in their own write-up, why the system ranked this case where it did, then the explainability arrangement does not work no matter what the method supports in principle.
"The model is a black box but it performs well" is not a position. It may be survivable in a low-consequence application; inside a control that determines what gets investigated, it is not.
Drift monitoring and the challenger
What tells you the model has degraded, and how quickly?
Performance degrades because the world changes — customer mix, product behaviour, typologies, upstream data. The question is whether you find out from a monitoring signal or from an outcome.
The documentation needs: which metrics are monitored, at what frequency, against what thresholds, and what happens when a threshold is breached. That last part matters most. A drift dashboard with no defined action is decoration.
A challenger arrangement — something running in parallel, whether a simpler model or the preceding rule set — is the strongest single piece of evidence a firm can hold here. It converts drift detection from a statistical inference into a direct comparison: the production model and the challenger disagree more than they used to, and here is when that started.
Validation independence
Who validated this, and what is their relationship to whoever built or bought it?
The answer needs to be a named person or function outside the development line. Not a different individual on the same team. Not the vendor. If the validation was performed by the people with an interest in the model being approved, the validation carries very little weight, and everyone in the room knows it.
For a smaller firm without a dedicated model validation function, this is genuinely hard. The workable answer is usually a documented second-line review with defined scope, supplemented by external validation at implementation and at material change. What does not work is asserting independence that the organisational chart contradicts.
Approval and change history
Who approved deployment, in what forum, on what date — and every material change since, with the same three facts attached.
Model change control is where good programmes most often fall down. The initial deployment is well documented because it was a project. Eighteen months of retraining, threshold adjustments and feature updates then accumulate with no equivalent record, and the model in production no longer matches the model that was approved.
Define what counts as material in advance — retraining on new data, feature changes, threshold moves, scope extension — and require the same approval for each.
The human control around it
What does the person do with the output, and what stops the model's judgement becoming the only judgement?
Where a model suppresses or deprioritises, this is the most important section in the document. An alert that is never seen is a control that cannot be evidenced, so suppression needs mandatory sampling of the suppressed population, logging that makes it reversible, and a defined rate at which someone checks what was thrown away.
The shortest useful version
If you are starting the documentation and want the order that de-risks fastest:
- Purpose and decision boundary — one page, precise.
- Feature list with source and source owner.
- Training population, period, and stated limitations including label quality.
- A worked explainability example on a real case.
- Monitoring metrics, thresholds, and the action on breach.
- Validation, by whom, independent of build.
- Approval record and change log.
- Human review design, especially around anything suppressed.
That is eight sections and none of them require a data scientist to write. Which is the point: the hard part of putting a model inside a compliance control was never the modelling.