Designing MLRO approvals and escalation.

In short

• Start from decisions, not people: list the decisions that need more authority, then decide who holds it.
• Define escalation triggers so escalation is predictable rather than a matter of nerve.
• An escalation must carry the work already done: context, evidence, the open question and a recommendation.
• Record every approval with who, when, why and on what evidence, and turn conditions into tracked actions.
• Design for the MLRO’s time: delegate routine authority so the MLRO sees the decisions that need them.

What approvals and escalation are for

Most compliance programmes give a senior role, often the MLRO or an equivalent head of compliance, authority over the decisions that carry the most risk. Approvals and escalation are the mechanism that delivers those decisions to that role. They fail in two directions: too little, and higher-risk decisions are made without the authority your policy requires; too much, and the MLRO becomes a queue that slows every case without adding judgement.

Which roles hold which authority is set by your policy and the rules that apply to you. This guide is about designing the workflow around that policy, not about what the policy should say.

1. Build an authority matrix

List the decision types your team makes and, for each, the level of authority required. A simple matrix might cover:

• Onboarding a client rated standard risk.
• Onboarding a client rated higher risk.
• Accepting a client with conditions or restrictions.
• Resolving a possible true match from screening.
• Overriding a calculated risk rating.
• Granting an exception to policy, such as accepting an alternative document.
• Ending a client relationship for compliance reasons.

For each row, record who may decide, who must approve, and whether the person who prepared the case may also approve it. Your policy determines that last point. Separation of duties is valuable where risk justifies it, but applying it to every decision by default multiplies work without improving outcomes.

2. Define escalation triggers

Escalation should not depend on how confident a reviewer feels that day. Write the triggers down. Common ones include:

• The decision type requires more authority than the reviewer holds.
• Evidence conflicts, or a required piece of evidence is unavailable.
• A screening alert cannot be resolved with the identifiers available.
• The case falls outside documented policy.
• The reviewer has a conflict of interest.

3. Decide what an escalation must carry

An escalation that says “please review” transfers the whole case. A good one transfers a question. It should arrive with:

1. The client and the specific decision needed.
2. A summary of the work done and the evidence reviewed.
3. The open question, or the reason the reviewer cannot decide.
4. The reviewer’s recommendation, if they have one.
5. Any deadline that matters, such as a pending transaction or an expiring document.

4. Use explicit approval outcomes

Approvers need more options than yes or no. A practical set is:

• Approve.
• Approve with conditions: for example, documents to follow, restricted services, or an earlier review.
• Request more information: the case returns to the reviewer with a specific question.
• Reject.

“Approve with conditions” is only safe if every condition becomes a tracked action with an owner and a date. Otherwise conditions are forgotten and the approval quietly becomes unconditional.

5. Record approvals properly

An approval is itself a decision. Record who approved, in which role, when, on which evidence and why. Approvals given by email or in a meeting and transcribed later are weaker evidence that the required authority was exercised. Our decision record reference sets out what a complete record contains.

6. Keep the MLRO from becoming a bottleneck

• Tier authority. Delegate routine decisions to a Compliance Manager or senior reviewers under documented limits, and reserve the MLRO for the decisions that need them.
• Name deputies. Absence should not stop decisions; deputies with defined authority should.
• Watch queue age. How long escalations wait is the clearest signal that the design is not working.
• Review patterns. If the same kind of case is escalated repeatedly, the policy or the guidance probably needs to change.

7. Test the design before you rely on it

Walk five realistic, synthetic scenarios through the workflow: a standard onboarding, a higher-risk onboarding, a possible true match, an approval with conditions and an exit. For each one, check that the right person was asked, that they had what they needed, and that the record would let someone else reconstruct the decision.