Where Should a Compliance Decision Be Documented?
A compliance rule rarely belongs in only one document.
Consider a simple example:
High-risk customers require approval by the MLRO.
At first glance, this looks like a single requirement that could be placed in the AML Policy. But the rule raises several different questions.
What makes a customer high risk?
When must approval be obtained?
What information should be presented to the approver?
Does the MLRO have formal authority to make the decision?
Can the customer be activated before approval is recorded?
What evidence must be retained?
These questions do not belong to one document. They belong to different layers of the control framework. The challenge is therefore not simply deciding where to write the rule. It is deciding which part of the decision belongs where.
One decision can have several documentation layers
A well-designed framework separates the different functions behind a compliance decision.
Using the high-risk customer example, the decision may need to appear across several layers:
PolicyEstablishes the principle.
Risk MethodologyDefines the criteria.
ProcedureExplains the process.
Approval MatrixAllocates authority.
System or WorkflowSupports or enforces execution.
Case RecordProvides evidence that the decision was made.
Each layer answers a different question.
The purpose is not to repeat the same sentence six times.
The purpose is to make the decision operational, authorised and traceable.
The policy should define the principle
Policies should normally answer questions at the level of principle and organisational expectation.
For example:
Higher-risk customer relationships are subject to enhanced due diligence and appropriate approval before the relationship is established.
The policy does not need to describe every operational step. It should establish the rule and make clear that the organisation expects a higher level of control when higher risk is present.
A common problem is when policies become overloaded with detailed process instructions. This can make them difficult to maintain and creates duplication with procedures.
The opposite problem also occurs: a policy may contain a broad statement such as “high-risk customers require approval” without any supporting documentation explaining how the rule is applied.
In both cases, the issue is not the wording of the policy itself. It is the absence of a clear boundary between principle and implementation.
The methodology should define when the rule applies
The next question is:
What makes a customer high risk?
That question belongs in the Customer Risk Methodology. The methodology may consider factors such as:
customer type;
ownership structure;
business activity;
products and services used;
jurisdictions;
expected transaction activity;
delivery channels;
PEP exposure;
sanctions-related indicators;
cryptoasset exposure;
other risk factors relevant to the business model.
The methodology should define how those factors affect the risk classification and when the threshold for a higher-risk treatment is reached. Without this layer, the approval requirement may exist, but employees may apply it inconsistently. One team may interpret a particular customer as high risk while another may not.
The policy sets the principle.
The methodology determines when the principle becomes relevant.
The procedure should explain what happens next
Once a customer has been classified as high risk, the procedure should explain how the decision moves through the process.
For example:
when the approval request is initiated;
what due diligence must be completed first;
what information must be included in the approval package;
whether outstanding issues may remain;
how conditions are recorded;
what happens if approval is refused;
whether the customer can be re-submitted;
what happens when the customer’s risk later increases.
This is operational detail. It should be clear enough that two employees handling similar cases would follow broadly the same process.
A statement such as “refer the case to the MLRO” is usually not enough. The procedure should explain what the referral actually involves.
The approval matrix should define authority
The procedure may say that approval is required.
But another question remains:
Who has the authority to give it?
This is where an Approval Matrix or delegated authority framework becomes important.
It may distinguish between:
standard-risk customer acceptance;
higher-risk customer acceptance;
PEP relationships;
customers involving specific jurisdictions;
exceptions to policy;
risk appetite exceptions;
continuation of an existing relationship after a material risk event.
The matrix should make authority explicit. This helps avoid situations where procedures refer to “senior management approval” without identifying which role, committee or individual actually has the mandate to decide.
Authority should not depend on organisational habit. It should be documented.
The system should support the decision
A documented approval requirement becomes much stronger when the operating system or workflow supports it.
For example, if high-risk customers require MLRO approval, the onboarding workflow may:
automatically identify the approval requirement once the risk rating is assigned;
route the case to the correct approver;
prevent customer activation while approval is outstanding;
record the approver and decision date;
require a rationale;
capture any conditions attached to approval;
maintain an audit trail.
Not every compliance requirement can or should be automated. But when an important rule depends entirely on employees remembering to follow it, the risk of inconsistent execution increases.
Documentation therefore needs to consider not only what people are instructed to do, but also how the process is supported in practice.
The case record should provide evidence
The final layer is evidence.
The organisation should be able to show that the documented decision actually took place.
For a higher-risk customer approval, the record may include:
the customer risk classification;
relevant risk factors;
Enhanced Due Diligence completed;
issues identified during review;
approval rationale;
identity of the approver;
date of the decision;
any conditions or restrictions;
follow-up actions;
evidence that required actions were completed.
This is important because a control framework cannot be assessed only by reading policies and procedures. There must also be evidence that those requirements were applied to real cases.
The same logic applies beyond customer approval
The same documentation logic can be used for many other compliance decisions.
Example 1: Customers from a particular jurisdiction require Enhanced Due Diligence
The policy establishes the principle that higher geographical risk requires additional controls.
The jurisdiction risk methodology defines how the jurisdiction is assessed.
The Customer Risk Methodology determines how that exposure affects the customer rating.
The procedure defines the additional due diligence required.
The system triggers the relevant workflow.
The case file records the evidence obtained and the conclusion reached.
Example 2: Transactions above a defined threshold require escalation
The policy or control standard establishes the escalation principle.
The monitoring methodology defines the relevant threshold and risk logic.
The procedure explains how an alert is investigated and escalated.
The escalation matrix identifies who receives the case.
The monitoring system generates or routes the alert.
The case record captures the investigation and final decision.
Example 3: A material outsourcing incident must be escalated to senior management
The Outsourcing Policy establishes the oversight principle.
The incident classification methodology defines what is considered material.
The incident procedure explains the escalation process.
The governance framework identifies the responsible committee or senior manager.
The incident management system records status and escalation.
The incident file or committee record provides evidence of the decision and follow-up.
The subject changes. The documentation logic does not.
Why duplication becomes a problem
When the same decision is copied into several documents without a clear hierarchy, inconsistencies appear quickly.
One document may say that MLRO approval is required.
Another may refer to Compliance approval.
A third may require senior management approval.
The system may route the case to someone else entirely.
Each document may have been correct when originally written.
The problem appears later, after different documents are updated at different times.
This is why a framework should distinguish between a source of authority and documents that reference or operationalise that authority.
For example:
the Approval Matrix may be the authoritative source for decision rights;
the procedure may refer to the relevant approval requirement;
the policy may describe the principle without reproducing the full matrix.
This reduces unnecessary duplication and makes future changes easier to manage.
A useful question: where is the source of truth?
For every important compliance decision, the organisation should be able to identify the authoritative source for each element.
For example:
Decision element | Primary source |
Principle | Policy |
Risk criteria | Methodology |
Process | Procedure |
Decision authority | Approval Matrix |
Workflow restriction | System configuration |
Evidence | Case record |
This does not mean that the rule cannot be referenced elsewhere. It means that the organisation knows which source controls the answer if two documents appear inconsistent. Without this hierarchy, document interpretation can become subjective.
What should happen when the rule changes?
The placement of a decision also affects change management.
Suppose the organisation changes its approach and decides that a certain category of higher-risk customers now requires approval by a Customer Acceptance Committee rather than the MLRO. The change may affect:
the AML Policy, if the governance principle changes;
the Approval Matrix;
the Onboarding Procedure;
system routing;
committee terms of reference;
staff instructions;
management reporting;
approval templates;
evidence retained in the customer file.
If the organisation does not know where the different elements of the decision are documented, it becomes difficult to identify the full impact of the change.
This is one reason why clear documentation boundaries matter. They make the framework easier to maintain.
How to test where a decision should be documented
Take one important compliance decision and break it into six questions:
What principle is the organisation applying?
What criteria determine when the decision is required?
What process must be followed?
Who has authority to decide?
How does the system support or enforce the rule?
What evidence proves that the decision occurred?
Then identify where each answer currently sits.
If several answers are missing, the rule may not be fully operationalised.
If the same answer appears differently in several places, the framework may contain conflicting sources of truth.
If one document attempts to answer all six questions, it may be doing too much.
Documentation should support decisions, not just describe them
Good compliance documentation is not simply a record of what the organisation believes should happen. It should support a repeatable decision process. That requires more than a policy statement.
The principle must connect to criteria.
The criteria must lead to a process.
The process must have defined authority.
The authority must be supported by workflow.
And the outcome must leave evidence.
This is what turns a compliance requirement into an operating control.
Key takeaway
The question is not:
Which document should contain the rule?
The better question is:
What function does each layer of documentation need to perform?
A policy establishes the principle.
A methodology determines when it applies.
A procedure explains what happens.
An authority matrix identifies who can decide.
A system supports consistent execution.
A case record proves that the decision was made.
When these functions are clearly separated and aligned, compliance decisions become easier to apply, maintain and evidence.
Comments