Most AML/CTF Program Manuals fail not because they’re missing content, but because everything sits at the same level of detail. A document that tries to state your governance philosophy, describe a step by step process, and explain which button to click in a piece of software all in the same paragraph ends up being too vague for staff to actually follow, and too cluttered for a senior manager or an examiner to quickly verify. This isn’t a new problem, and it isn’t unique to AML/CTF. It’s exactly the document architecture challenge every quality management system has to solve, and the same three layer structure that works for ISO 9001 works here.
Here’s how to actually separate these layers, and why it matters more than it might first seem.
The three layers, explained simply
A policy is a statement of intent. It answers “what do we do, and why.” It’s short, stable, and rarely changes. “Our agency conducts customer due diligence on every buyer and seller before a transaction is completed” is a policy statement. It doesn’t explain how, it establishes the commitment.
A procedure answers “how do we actually do this.” It’s the step by step process a staff member follows for a given situation. “How we conduct customer due diligence for an individual buyer” is a procedure. It sets out the sequence: what identification is collected, what’s checked, what triggers escalation.
A work instruction is the most granular layer, and it answers “exactly how do I perform this specific task, right now, using this specific tool.” “How to run a PEP and sanctions check through our screening provider” is a work instruction. It might include screenshots, exact field names, and the precise sequence of clicks.
The reason this distinction matters isn’t academic. Each layer serves a different reader, and each layer changes at a different pace.
Why conflating these layers causes real problems
When a Program Manual mixes all three into one undifferentiated document, two things go wrong at once.
For staff trying to actually do their job, the document becomes hard to use quickly. An agent who needs to know how to verify a company buyer doesn’t want to wade through governance philosophy and policy justification to find the actual steps. They need the procedure, fast, without noise around it.
For anyone reviewing the program, whether that’s your own senior manager, an independent reviewer, or an AUSTRAC examiner, a conflated document makes it hard to see whether the policy intent is actually reflected in real practice. Separating the layers lets a reviewer check each one against what it’s meant to demonstrate: does the policy make a genuine commitment, does the procedure genuinely implement that commitment, and does the work instruction match what staff are actually doing on a screen right now.
There’s also a practical maintenance reason. Policies rarely change, your commitment to conducting due diligence on every customer isn’t going to shift year to year. Procedures change occasionally, as your risk assessment evolves or your process matures. Work instructions change constantly, because they’re tied to specific tools and systems, and those get updated far more often than your underlying policy commitments do. If everything lives in one document, updating a screenshot because a software provider changed their interface means touching the same file that contains your governance statements, which is both unnecessary risk and unnecessary friction.
The same obligation, expressed at all three levels
Take one core AML/CTF obligation and see how it looks at each layer.
Policy: “Our agency verifies the identity of every customer, and identifies beneficial owners for non individual customers, before a transaction proceeds, in line with our documented risk assessment.”
Procedure: “For a company buyer, our agent collects the company’s ASIC details and confirms current registration. We then identify individuals who own 25% or more of the company, or who otherwise control it, and verify each of them individually. Where the company is listed on a recognised exchange, this step is not required. Any structure involving trusts, offshore entities, or unclear ownership is referred to the Compliance Officer before proceeding.”
Work instruction: “Open the CDD workflow in the Lead Comply portal. Select ‘Company’ as the customer type. Enter the ABN to auto populate registered details. Add each identified individual under ‘Beneficial Owners’ and complete their verification using the identification upload tool. If the system flags an incomplete beneficial ownership chain, do not proceed, escalate to the Compliance Officer immediately.”
Notice how each layer down gets more specific and more tied to a particular tool or moment in time. The policy could survive a decade unchanged. The procedure might be revised as your risk assessment develops. The work instruction will need updating the moment your screening provider or portal changes its interface.
What this looks like in practice for document control
A practical way to apply this: keep policies in a short, stable core document that rarely gets touched. Keep procedures in a separate section or document that’s reviewed periodically, perhaps annually or when your risk assessment changes. Keep work instructions as living, more frequently updated material, potentially even outside the formal manual itself, close to wherever staff actually do the work.
Version control matters more at the procedure and work instruction layers, since these are the documents that change. Each should carry a version number and a date, so when something is updated, staff can tell immediately they’re looking at the current version rather than one that’s quietly gone stale.
How this helps in an actual audit
This structure isn’t just tidier, it’s what a genuine management system looks like when someone reviews it properly. An auditor reading a well structured program can move through the three layers and check each one against what it’s meant to prove: does the policy make a real, specific commitment, does the procedure genuinely operationalise it without gaps, and do the work instructions match what staff can actually demonstrate they do day to day. A program where all three align, cleanly and visibly, reads as a functioning system. A program where they don’t, where the policy promises something the procedure doesn’t actually deliver, is exactly the kind of gap an examination is designed to find.
Where Lead Comply fits into this structure
This is where a well built portal genuinely earns its place in your program, rather than just being a convenient tool. The Lead Comply AML Portal effectively becomes your work instruction layer for the tasks it handles: the CDD workflow guides staff through exactly what to enter and in what order, which means your Program Manual doesn’t need to carry pages of screenshots that go out of date every time an interface changes. Your policies and procedures stay stable in the document; the day to day mechanics live in the tool your staff are already using.
Our custom written AML/CTF Program Manual is built with exactly this three layer structure in mind from the start, so your governance commitments, your operational procedures, and the practical mechanics of your day to day work are properly separated rather than tangled into one document nobody can navigate quickly. If your current program (or the template you’re working from) reads more like one long document than a genuine structured system, that’s precisely the kind of gap our free Compliance Gap Audit is built to identify.
Create your free account and book No Obligation Compliance Gap Audit→ Lead Comply AML Portal
