How to document sanctions alert dispositions defensibly.

In short

• A defensible disposition lets another reviewer reach the same outcome from the same evidence, without asking you.
• Record which identifiers you compared, which list entry and list version you compared them against, and what made the difference.
• Use reason codes for consistency, but never let a code replace the reasoning.
• Escalate uncertainty to the person with authority, and record who decided.

What a disposition is

When a screening system flags a potential match between your customer, or one of its owners or officers, and an entry on a sanctions list, someone has to decide what the alert means. That decision is the disposition. In most programmes it ends in one of three places:

• False positive: the subject is not the listed party.
• Escalation: the reviewer cannot resolve the alert with the evidence and authority they have.
• True match: the subject is, or is reasonably believed to be, the listed party, and your policy for confirmed matches applies.

Most alerts are false positives. That is exactly why the documentation matters: the large volume of routine clearances is where shortcuts accumulate, and where a later reviewer is most likely to find a decision they cannot follow.

The reproducibility test

A useful standard for any disposition is simple: could a competent colleague, looking only at the record, reach the same conclusion for the same reasons? If the answer depends on something that lives only in the reviewer’s memory, an email thread or a screenshot on a desktop, the disposition is not defensible yet.

What the record should contain

1. The subject. Who was screened, and in which role: the customer, a director, a shareholder, a beneficial owner.
2. The list entry. Which list and which entry produced the alert.
3. The list version. Lists change. Recording the version tells a later reader exactly what the reviewer was looking at.
4. The identifiers compared. Name and spelling variants, date or year of birth, nationality, place of birth, registration number, address, or whatever identifiers both sides actually have.
5. The discriminating evidence. The specific fact that resolves the alert, and where it comes from (for example, a date of birth taken from an identity document on file).
6. The outcome. One of your defined dispositions.
7. The rationale. A sentence or two connecting the evidence to the outcome.
8. The reviewer and the time. Who decided and when.
9. Escalation and approval. If the alert was escalated, to whom, why, and what they decided.

Writing a rationale that holds up

The rationale is where most dispositions fail. Compare two clearances of the same synthetic alert:

• Weak: “Name match only. Not the same person. Cleared.”
• Stronger: “Cleared as false positive. The list entry records a year of birth of 1961; the subject’s passport on file shows 1984. Nationality also differs. No other identifiers overlap.”

The stronger version names the identifiers, states where the evidence came from, and makes the reasoning checkable. It takes seconds longer to write and saves hours when someone asks about it.

Some habits help:

• Lead with the outcome, then the evidence, then any remaining doubt.
• Name the source of each fact you rely on.
• Say when a match was cleared on weaker grounds, such as a partial name match with no other identifiers, and why that was acceptable under your policy.
• Avoid private shorthand that only your team understands.

Reason codes and consistency

Standard reason codes, such as “different date of birth” or “different nationality”, make dispositions consistent and easier to analyse. They work best alongside free-text rationale, not instead of it. A code says which category of reason applied; the rationale says why it applied in this case.

Review your codes occasionally. If a large share of clearances use a vague code such as “other”, that is a sign the codes do not match how reviewers actually reason.

When to escalate

Escalation is not a failure. It is how a programme routes uncertainty to the person who holds the authority to resolve it. Your policy should define the triggers, for example when identifiers are missing on one side, when the evidence conflicts, or when the alert concerns an owner or controller rather than the customer itself. A good escalation carries the work already done, so the next reviewer does not start again. Our guide to designing MLRO approvals and escalation covers this in more depth.

When lists change

A disposition is correct for the list version it was made against. When lists are updated, it should be possible to tell which version produced which outcome, and your policy should say when existing customers are screened again. Recording the version on every alert is what makes that possible.

Quality assurance

• Sample regularly. Re-review a sample of cleared alerts and check whether the record alone supports the outcome.
• Watch a few signals: how long alerts wait, the share that are escalated, and how often a second review reverses the first.
• Feed findings back. Recurring weak rationales usually point to unclear guidance, missing identifiers at onboarding or codes that do not fit.

Common failure patterns

• Clearing on name alone when other identifiers were available.
• Dispositions recorded in a spreadsheet or email, separate from the customer record.
• Rationale copied and pasted between unrelated alerts.
• No record of which list version was used.
• Escalations that end in an informal conversation, with no recorded decision.