What a compliance decision record is and why it exists.

A definition

A compliance decision record is the complete, reconstructable account of a single compliance decision: onboarding a client, accepting a risk, clearing a screening alert, approving an exception or ending a relationship. It answers six questions without anyone having to remember anything:

1. What was decided, and about whom.
2. Who decided, and who approved.
3. With what authority: why that person or role was entitled to make the decision.
4. On what evidence: the documents, information and screening results relied on, in the version that was used.
5. Why: the rationale, in the decision maker’s own words, tied to that evidence.
6. What happens next: conditions, follow-up actions and the next review.

Why it exists

Compliance decisions outlive the people and the context that produced them. A client onboarded today may be questioned years later by an auditor, a regulator, a bank or your own board, long after the reviewer has moved on and the original emails are hard to find.

A decision record turns that moment from reconstruction into retrieval. It also makes decisions consistent: when every decision has to state its evidence and rationale, similar cases are easier to decide in a similar way, and differences are explained instead of accidental.

What a decision record is not

• Not an activity log. A log shows that something happened. A record explains why it was decided.
• Not a form. A completed checklist shows that steps were taken. It does not show how the evidence was weighed.
• Not a policy. The policy says what should happen. The record shows what did happen in one case, and under which version of the policy.

The anatomy of a decision record

1. Context

The subject of the decision, such as a person, a company or an alert, the client relationship it belongs to, and the specific question being decided. A record that does not say what question it answers cannot be reviewed.

2. Evidence

References to the documents, declarations, ownership information and screening results the decision relied on. Evidence should be referenced in the version that was used, so that a later update does not silently change what the decision appears to rest on.

3. The decision and the decision maker

A clear outcome from a defined set, such as approve, approve with conditions, request more information or reject, made by a named person. Where software assembles information or suggests a summary, the record should still show that a person made the decision.

4. Rationale

A short explanation written for a future reader who has none of today’s context. Good rationale names the evidence it relies on and explains how risk factors were weighed. “Approved, low risk” is a conclusion, not a rationale.

5. Approvals and authority

Who reviewed or approved the decision, in which role, and when. If your policy requires a second level of review for some decisions, the record should show that the required authority was obtained, not just that someone clicked approve.

6. Conditions and follow-up

Anything the decision depends on: documents to be provided, restrictions, a shortened review cycle. Conditions only work if they become tracked actions with owners and dates.

7. Audit trail

The sequence of actions that led to the decision, with who did what and when. The audit trail supports the record; it does not replace the rationale.

8. Sealed evidence

For decisions that may need to be shown to someone outside the team, a sealed package of the record and its evidence, fixed at a point in time, gives reviewers something they can rely on.

Principles that make records useful

• Write for the stranger. Assume the reader has never seen the case and cannot ask you.
• Decide in the system, not in email. A decision made in a chat thread and copied into the record later is a weaker record.
• Make authority explicit. Approvals should reflect who is entitled to decide under your policy, not who happened to be available.
• Keep evidence and reasoning together. A rationale that cannot be traced to its evidence is an opinion.
• Close the loop. Conditions and review dates belong to the record and must be followed up.

A quick test for any decision record

Pick a decision made six months ago and give it to someone who was not involved. Without asking anyone, can they say what was decided, by whom and with what authority, which evidence was relied on, why the outcome was reasonable, and whether the conditions were met? If not, the record is incomplete.

The template

The free template sets out the sections above as fields you can adapt to your own policy and tools. It is generic: it does not reflect the record-keeping requirements of any particular jurisdiction, and it is not a description of AMIN’s data model.

• Download the decision record template (Word)
• Download the decision record template (PDF)

No form, no email address required.

Where the record sits in the operating loop

AMIN organises compliance work into six stages: Know → Assess → Work → Decide → Govern → Prove. The decision record is created at Decide, but it draws on everything before it: who the client is (Know), how risk was assessed (Assess) and the review work done (Work). It is then what Govern controls, through approvals and conditions, and what Prove produces when someone asks how the decision was made.