What makes an investigation defensible to a reviewer

Defensible does not mean correct. Reasonable investigators looking at the same facts sometimes reach different conclusions, and a decision that turns out to have been wrong is not automatically a failure of the process that produced it. Defensible means reconstructable: someone with no memory of the case, no access to the analyst who worked it, and no knowledge of what happened afterwards can open the file, follow the reasoning, and see how the conclusion was reached from what was known at the time.

That is a higher bar than most files clear, and it is almost entirely a documentation discipline rather than an analytical one.

The four questions every reviewer asks

What brought this to your attention?

The trigger, precisely: which alert, which rule, which screening hit, which referral, which external request. Not just that an alert existed, but which one, on what date, on what activity.

What did you look at?

The scope of the review. Which accounts, which period, which counterparties, which internal systems, which external sources. Including — and this is the one that is nearly always missing — the things you checked that showed nothing.

What did you conclude, and on what basis?

The reasoning that connects the facts you set out to the disposition you reached. If the reasoning is a single line saying the activity is consistent with the customer profile, the file has asserted a conclusion rather than supported one.

Who agreed, and could they have disagreed?

The approval. A checker who cannot realistically refuse is not a control, and a checker who is the same person as the maker is not a checker at all.

Writing the narrative for someone who was not there

Most weak case files are weak in the same place: the narrative mixes fact and inference, so a reviewer cannot tell which parts are observations and which are the analyst's reading of them. Separating the two is most of the work.

1  Subject          who the customer is, how identified, since when
2  Trigger          what raised this, when, and on what activity
3  Expected         what the profile says this relationship should look like
4  Observed         the activity as fact: dates, values, counterparties, channels
5  Gap              the specific difference between 3 and 4
6  Enquiries        what was checked, including checks that found nothing
7  Explanation      what the customer or the record explains, and what it does not
8  Assessment       the reasoning from 5 and 7 to a conclusion
9  Disposition      the decision, the reason code, and what happens next

• Keep sections four and eight apart. Facts in the fact section, reading of the facts in the assessment. A file that says the transfers were suspicious has skipped the step where it says what the transfers were.
• Write values, dates and counterparties out. A reviewer cannot check an assertion about a pattern against a description of a pattern.
• Record the negative results. An enquiry that found nothing and an enquiry that was never made look identical in a file that only records findings, and they are not the same thing at all.
• Say what you could not establish. An honest limitation is a strength in a file; a gap that the file does not acknowledge is the thing a reviewer will find and ask about.
• Avoid internal shorthand and unexplained abbreviations. The reviewer in three years will not have your team's vocabulary.

Evidence hygiene

1. 01Snapshot, do not reference

   Screening results change when the list is updated, customer profiles change when the customer is reviewed, and risk ratings change when the model is re-run. A case that links to the live record shows what is true today, not what the analyst saw. The file needs to hold what was true at the moment of the decision, together with the version of the list or the profile it came from.

2. 02One subject per case

   Files that accumulate several customers because their transactions touched each other become impossible to review and impossible to report from: the reviewer cannot tell which evidence supports which subject, and neither can the person drafting the report. Related subjects belong in linked cases, not in one case.

3. 03Keep the identifiers, not only the screenshots

   An image of a screen is evidence of what a screen showed. The record identifier behind it is what lets a reviewer go back to the source, and it is what makes the file survive a system migration.

4. 04Do not let the file lose its own chronology

   When the decision was made matters as much as what it was, particularly where the regime imposes a time-bound obligation once suspicion is formed. An audit trail that records the order and timing of actions — and that cannot be quietly edited afterwards — is what turns the chronology from a claim into a fact.

Language that survives review

Two words do more damage in case files than any others. The first is suspicious, used as a synonym for unusual. Unusual is an observation about activity; suspicion is a conclusion with consequences attached, and a file that uses the words interchangeably has blurred the moment the conclusion was reached. The second is appears, standing in for reasoning that was never written down: the customer appears to be operating a money service business does not tell a reviewer what was observed or why it points there.

• Prefer the observation with the inference attached: the stated occupation is X, the recorded inflows are Y from Z counterparties, and the two are not consistent because —
• Do not assert intent. You can establish what happened and what the customer said about it; you cannot establish what they meant, and a file that claims to have will be discounted where it matters.
• Distinguish the customer's explanation from your acceptance of it. Recording that an explanation was given is a fact. Recording that it was satisfactory is a judgement, and it needs a reason.
• Write for a reader outside the team. If the file only makes sense to someone who already knows the customer, it is not a file, it is a reminder.

Four eyes is a control, not a formality

The review step exists so that one person's judgement is not the last word on a decision with regulatory consequences. It only works if three things are true: the checker is a different person from the maker and the system enforces that rather than trusting it; the checker has enough of the file to form an independent view; and refusing is a normal outcome rather than an escalation. A checker approval rate at or near one hundred per cent is not evidence of a high-quality queue.

• Record the checker's reasoning, not just the click. An approval with no comment is indistinguishable from an approval nobody read.
• Make the maker and the checker identities immutable once recorded, with the timestamps.
• Give a rejection a route: what the maker must do, and where the rework is recorded, so that a returned case is visibly a returned case rather than a re-opened one.

The quality bar as a checklist

1. The trigger is identified specifically, not generically.
2. The subject is identified, and only one subject is the subject of this file.
3. The scope of review — accounts, period, sources — is stated.
4. Observed activity is set out as fact, with values, dates and counterparties.
5. The expected profile it was compared against is stated, with the date that profile was captured or last reviewed.
6. Enquiries made are recorded, including those that produced nothing.
7. Customer explanations are recorded separately from the assessment of them.
8. The reasoning from facts to conclusion is written out.
9. Limitations and unresolved questions are acknowledged.
10. The disposition carries a governed reason code, not only free text.
11. Evidence is snapshotted with its source version, not linked live.
12. Maker and checker are different people, both recorded, with the checker's reasoning.
13. The chronology of the file is intact and cannot be silently altered.
14. Where a report was made, the file shows what was reported and on what basis; where one was not, it shows why not.

The last line is the one teams most often leave out. A decision not to report is a decision, it is reviewable, and in a well-run programme it is documented to the same standard as a decision to report.