Policies, Procedures, Training and Awareness

A financial-crime programme fails surprisingly easily even when the bank has a well-written policy. The reason is simple: a policy is only one layer of an operating system. Staff need to know what the policy means for their role, procedures must translate principles into actions, systems must support those actions, training must build enough competence to use them, and management must be able to prove that people followed the current version at the right time.

That chain matters because money laundering, terrorist financing, proliferation financing, sanctions evasion, fraud-linked laundering and other forms of financial crime do not arrive in a bank as neat legal questions. They appear as a customer who cannot explain an ownership structure, a payment with unusual routing, an alert whose facts do not fit the standard closure reason, a trade document containing a risky counterparty, a frontline colleague noticing behaviour that feels wrong, or a technology release that changes which data an investigator can see. The institution needs a dependable way to turn its legal obligations and risk appetite into decisions at those moments.

The strongest mental model is therefore not “policy plus annual e-learning”. It is a controlled translation chain:

external obligation and risk assessment → policy → standard or control requirement → operating procedure → system and job aid → role-based training and awareness → execution → evidence → quality review and feedback → controlled update.

If one link is weak, the bank can have a programme that looks mature on paper and still performs badly in practice. A policy may say enhanced due diligence is required for higher-risk customers while the onboarding procedure does not explain who can approve an exception. A sanctions standard may require escalation of unresolved ownership risk while the case tool has no field to capture the ownership analysis. A training course may explain suspicious transaction reporting but use examples that have no connection to the products handled by the learners. A procedure may be accurate when approved and obsolete six months later after a system release.

This chapter explains how to design the chain so that policy, procedure, training and awareness reinforce each other instead of operating as separate compliance activities.

Policy-to-practice operating model showing how obligations and risk assessments become controlled policies, procedures, training, execution evidence and feedback.

The global baseline: what FATF actually requires

FATF Recommendation 18 is the most useful global starting point, but it should be read carefully. FATF does not prescribe one universal corporate policy template, one annual training frequency or one learning-management platform. In its Interpretive Note, FATF says financial institutions' AML/CFT programmes should include internal policies, procedures and controls, appropriate compliance management arrangements, adequate employee screening, an ongoing employee training programme and an independent audit function to test the system. FATF also states that the type and extent of measures should be appropriate to the institution's ML/TF risk and the size of the business.

That is important because it establishes both minimum components and proportionality. The bank needs a programme, and training is part of that programme, but the content, population, frequency, depth and evidence should reflect actual exposure. A teller, trade-finance document checker, sanctions investigator, relationship manager, transaction-monitoring modeller, board member and software engineer do not all need the same learning experience. They do need enough knowledge to perform the financial-crime responsibilities attached to their roles.

FATF's June 2026 Recommendations also continue the group-wide dimension of Recommendation 18. Financial groups should apply group-wide AML/CFT programmes to branches and majority-owned subsidiaries and maintain policies and procedures for relevant information sharing, subject to confidentiality safeguards and local law. For a global bank, that creates a practical design question: what belongs in a common group standard and what must be implemented through a legal-entity or jurisdiction-specific procedure? The answer cannot simply be “the strictest rule wins”. Some obligations conflict, some data cannot move freely, and some local laws require different processes or accountable roles. Good governance makes those differences explicit.

The Basel Committee's current guidance on sound management of ML/TF risk reinforces the broader idea that AML/CFT should sit inside the bank's governance and risk-management framework rather than being a detached compliance document set. The Basel guidance is not itself a universally binding law. It is supervisory guidance whose legal force depends on jurisdictional implementation. That distinction should be preserved in both policy drafting and training.

Policy, standard, procedure and job aid are different things

Banks often use these words loosely, which creates confusion during audit and delivery. A workable hierarchy separates purpose from execution.

A policy sets the institution's principles, mandatory expectations, risk position, accountability and governance. It should answer questions such as: what must the institution achieve, what is prohibited, who is accountable, what must be escalated, and which exceptions require formal approval?

A standard or control standard turns the policy into measurable requirements. It may define mandatory minimum data, screening expectations, control frequency, documentation rules, approval levels, quality thresholds or evidence that must be retained. Some banks combine policy and standards; others separate them. The name matters less than whether the hierarchy is clear.

A procedure tells a person or team how to perform the work. It should identify triggers, inputs, steps, decision points, escalation routes, system actions, required evidence and hand-offs. A procedure should not force an investigator to make a legal judgement that belongs to a sanctions specialist, nor should it tell a frontline employee merely to “follow policy” without explaining what action to take.

A runbook, job aid or playbook gives task-level help for recurring operational situations. Examples include how to handle a sanctions alert when date of birth is missing, how to document source-of-funds evidence, how to raise a suspicious-activity referral, or what to do if the screening service is unavailable. These materials can change more frequently than policy and may need tighter linkage to technology releases.

A system rule can operationalise part of the requirement, but the rule itself is not the policy. A transaction-monitoring threshold, mandatory KYC field or workflow approval step should be traceable to an approved requirement. Otherwise the bank eventually accumulates controls whose purpose nobody can explain.

Finally, training and awareness are mechanisms for creating knowledge and behaviour. They do not replace the control. A bank cannot cure an unusable procedure by telling employees to be more careful, and it cannot cure a poorly designed screening workflow by adding another e-learning module.

Policy hierarchy and traceability diagram linking external obligations, enterprise policy, standards, procedures, system rules, job aids and evidence.

What a usable financial-crime policy contains

A strong AML/CFT or financial-crime policy should be readable enough for decision-makers and precise enough to govern the programme. It does not need to contain every operational step. It should normally make clear its purpose, scope, legal entities or businesses covered, core principles, prohibited or restricted activity, key responsibilities, mandatory control expectations, escalation requirements, exception governance, ownership, approval authority, review cycle and effective date.

Scope is particularly important in a group. “Applies globally” is not sufficient if local entities have different regulatory duties. The policy should identify whether local supplements are required and how conflicts are resolved. If the group policy requires information sharing for AML/CFT purposes but local banking-secrecy or data-protection rules constrain a particular transfer, the local procedure needs an approved way to manage that conflict rather than leaving staff to improvise.

Policies also need effective dating. An auditor investigating a 2025 case needs to know which policy and procedure were in force in 2025, not merely see today's version. Version history should show what changed, why, who approved it and when it became effective. Historical versions should remain retrievable under controlled retention rules.

A good policy avoids false universality. For example, terms such as MLRO, BSA Officer, nominated officer or AML/CTF compliance officer may carry specific meanings in particular jurisdictions. A global policy can define a generic accountable compliance role and map local titles separately. The same discipline applies to suspicious-reporting deadlines, cash-reporting thresholds, sanctions blocking rules and record-retention periods. They should not be copied from one country into a global document unless the bank has intentionally adopted the requirement as a group minimum and can lawfully do so.

What makes a procedure operationally useful

Procedures are where many programmes become fragile. A procedure written primarily for an auditor may describe governance well but still fail the person doing the task. An operational procedure should allow a trained employee to answer six questions without searching through multiple documents: when does this procedure apply, what information do I need, what must I do, what decisions am I allowed to make, when must I escalate, and what evidence must I retain?

Consider a transaction-monitoring alert. A poor procedure might say, “Investigate the alert in accordance with AML policy and escalate suspicious activity.” A strong procedure explains the evidence sources available, how to compare activity with the customer profile, how to handle missing information, what closure rationale is acceptable, which facts require escalation, how to link related alerts, what confidentiality rules apply, and which fields are mandatory before the case can close.

The procedure should also distinguish a control requirement from a suggested investigative technique. If a step is mandatory, the bank should be able to test it. If professional judgement is allowed, the document should identify the decision principle and evidence standard rather than force artificial consistency. Overly prescriptive procedures can be as dangerous as vague ones: criminals adapt, products differ, and not every unusual transaction fits a fixed sequence.

Procedures should follow the actual technology. Screenshots and field names become obsolete quickly, so a mature design separates durable decision logic from highly changeable interface instructions. A job aid may carry the screenshots while the formal procedure describes the control. This reduces the risk that every minor interface release makes the policy library inaccurate.

Training is a control-enablement process, not an attendance exercise

The weakest training metric is “percentage completed”. Completion is necessary in many programmes, but it only proves that the institution recorded an event. It does not prove that the employee understood the content, can recognise the relevant risk or will follow the procedure under pressure.

The United States provides a useful jurisdiction-specific illustration. The FFIEC BSA/AML Examination Manual states that banks must provide training to appropriate personnel and says training should cover requirements relevant to the bank and its risk profile. It also describes tailoring training to specific responsibilities, targeted content for particular business lines, orientation for new staff, periodic training for compliance staff, foundational training for boards and senior management, and records such as materials, dates, attendance and overdue completion. These are U.S. supervisory expectations, not a global timetable.

The United Kingdom provides another example. FCA SYSC 6.3.7 says a firm should include appropriate employee training in its money-laundering systems and controls and should document its risk-management policies and their application. The FCA Financial Crime Guide also contains examples showing why role-specific training is stronger than generic training, particularly in riskier business activities such as trade finance.

Australia's framework changed materially in 2026. AUSTRAC guidance published for the reformed regime says personnel performing AML/CTF functions require initial and ongoing training, tailored to their functions, relevant ML/TF risks and responsibilities under the entity's AML/CTF policies. The guidance also emphasises training effectiveness, records and updates following legal, risk, programme or assurance changes. Those are Australian requirements and expectations under the reformed AML/CTF framework; they should not be presented as a universal frequency rule for a global bank.

The practical lesson across these examples is consistent: the training population and curriculum should come from risk and role, not convenience.

Build a training-needs analysis from the operating model

A training-needs analysis should start with the bank's financial-crime risk assessment and control inventory, then map responsibilities to people. The question is not “who works for the bank?” but “who can create, operate, approve, challenge, change or oversee a financial-crime control?”

A customer-facing employee may need to recognise suspicious behaviour, collect KYC information correctly and know how to refer concerns without tipping off the customer. An onboarding analyst needs deeper instruction on beneficial ownership, PEPs, adverse information, source of funds, source of wealth and enhanced due diligence. A payments operator needs to understand sanctions holds, payment-data quality and escalation. A transaction-monitoring investigator needs typology, evidence and narrative skills. A modeller needs scenario governance, data lineage, threshold behaviour and validation concepts. A developer may not need investigator-level typology knowledge but does need to understand why dropping a party field, changing transliteration logic or altering a workflow status can create a control failure.

Managers need additional learning because they approve exceptions, allocate resources and interpret management information. Senior management and the governing body need enough understanding to oversee risk and challenge whether the programme is effective. They generally do not need the same procedural training as operations staff.

Third parties require deliberate treatment. If an outsourced service provider performs KYC review, alert investigation, screening support or other AML/CFT activity, the bank cannot assume the vendor's generic compliance training is sufficient. Contractual expectations, due diligence, role mapping, evidence and oversight should cover competence as well as completion.

Awareness and training are related but not identical

Training is structured learning tied to competence or a defined responsibility. Awareness keeps financial-crime risk visible in everyday decisions. Awareness may include short typology alerts, intranet stories, team briefings, lessons from incidents, manager talking points, newsletters, targeted warnings before a product launch or reminders after a control failure.

Awareness is especially valuable when the risk changes faster than the annual curriculum. If a new scam typology begins producing mule activity, waiting months for the next mandatory course is not sensible. A controlled awareness notice can quickly explain the indicators and referral route while the formal training material is updated.

But awareness communications need governance too. An unapproved message that contradicts policy creates confusion. The owner should know the intended audience, source, effective period and whether the message changes required behaviour or merely provides information. If behaviour changes, the underlying procedure or job aid normally needs updating as well.

Decision flow showing how a change in law, risk, product, control or incident triggers policy impact assessment, procedure updates, targeted training and effectiveness evidence.

Change management is where policy and training prove their value

Policies and procedures should not be reviewed only because a calendar says twelve months have passed. Scheduled review remains useful, but event-driven review is essential. Triggers can include regulatory change, a new product, entry into a new country, a material system release, a new typology, an audit finding, a regulatory examination, a significant incident, a sanctions regime change, data-quality failure, outsourcing change or repeated quality-assurance errors.

The change process should answer four separate questions. First, does the policy position change? Second, does the operating procedure or control design change? Third, which systems, data or workflow artefacts must change? Fourth, who needs to learn something before the change becomes effective?

This sequencing matters. Training staff before the final procedure exists creates rework and contradictory material. Releasing a procedure before the system supports it creates non-compliance by design. Deploying a system change without updating policy traceability makes later assurance difficult.

For material changes, readiness should therefore be treated as a release gate. The bank should know whether the current document is approved, system changes are deployed, impacted roles are trained, unresolved exceptions are accepted by the right owner and evidence is retained. Emergency legal changes may require a temporary instruction before the full document lifecycle completes, but the temporary route should be controlled, time-limited and later absorbed into the formal hierarchy.

The evidence chain

A regulator or auditor may ask a deceptively simple question: “How do you know the people operating this control were trained on the correct procedure at the time?” A mature institution should be able to answer without assembling evidence manually from email.

Useful evidence includes the policy and procedure version, approval and effective date; the role population in scope; training content and version; assignment date; completion date; assessment result where used; overdue status; exemptions or extensions; manager escalation; remedial training; attestation; and evidence of later effectiveness testing. The institution also needs confidence that HR changes, role transfers, contractor onboarding and leavers are reflected in the population.

The system architecture often spans a policy repository, GRC platform, HR system, identity directory, learning-management system, case-management tools and reporting layer. If the employee population is loaded monthly while people move roles daily, the institution has a known coverage gap. If the learning platform records completion but not content version, it may be impossible to prove which policy an employee was trained against. If local contractors sit outside the main HR feed, they may disappear entirely from the training population.

Evidence timeline connecting policy version, procedure effective date, learner population, assignment, completion, assessment, exceptions and assurance.

Measuring effectiveness without pretending one metric tells the story

Training effectiveness should be evaluated through a combination of evidence. Knowledge checks can show immediate understanding but can be gamed or forgotten. Scenario exercises test application. Quality-assurance results can show whether trained staff apply the procedure. Incident analysis can identify missed red flags. Escalation quality, repeated errors, audit findings and manager observations may reveal gaps that completion rates hide.

Metrics should therefore separate coverage, timeliness, knowledge and behaviour. Coverage asks whether all required people were assigned. Timeliness asks whether training happened before or soon enough after the relevant responsibility began. Knowledge asks whether the learner understood. Behaviour asks whether the person applies the requirement in real work.

A bank should be cautious with simplistic targets. A 100% completion rate can coexist with poor investigations. A difficult quiz can produce low scores without improving behaviour. A fall in suspicious referrals could indicate better prevention or weaker awareness. Metrics need interpretation against risk, role and operating outcomes.

Common failure modes

The most common policy failure is document theatre: a large collection of formally approved documents that staff cannot find or use. The most common procedure failure is copying policy language into operational instructions without explaining decisions. The most common training failure is one generic annual course for everyone. The most common awareness failure is broadcasting messages without linking them to action.

Other recurring failures include stale links, contradictory group and local procedures, missing effective dates, uncontrolled local workarounds, inaccessible training, poor contractor coverage, weak evidence of overdue escalation, systems that do not identify role changes, and training content that is updated after the control change rather than before it.

A subtler failure is treating policy exceptions as harmless. If a business repeatedly asks for extensions because a control is operationally difficult, the pattern is telling management something about feasibility, resources or design. Exception data should feed policy and control review rather than disappear after approval.

Roles in a healthy operating model

The governing body and senior management set tone, approve or oversee material policy according to the bank's governance model, provide resources and challenge effectiveness. Financial-crime compliance interprets obligations, maintains programme standards, advises on risk and monitors adherence. Business and operations own the day-to-day execution of controls allocated to them. Learning or HR teams may provide platforms and instructional expertise but should not decide the financial-crime content alone. Technology and data teams implement system controls, data flows and evidence. Legal advises where law is uncertain or conflicting. Quality assurance and compliance testing identify inconsistency. Internal audit provides independent assurance.

The exact allocation varies by institution and jurisdiction. What matters is that responsibilities are explicit and that the owner of a control cannot avoid accountability merely because another team performs the task.

Governance map showing the roles of governing body, senior management, financial-crime compliance, business operations, learning, technology/data and independent assurance.

What business analysts, architects, developers and testers should look for

A business analyst should be able to trace a requirement from the source obligation or policy decision through procedure, system behaviour, training impact and evidence. A requirement such as “all higher-risk correspondent relationships require enhanced review” is incomplete until the analyst knows how the relationship is identified, which data drives the risk classification, who performs the review, what approval is required, where evidence is stored and which roles need new guidance.

Architects should make effective dating and auditability first-class design concerns. Policy and training systems are not merely document libraries. They are evidence systems. Integrations with HR, identity and GRC should preserve role and organisational context so that historical reconstruction is possible.

Developers need controlled acceptance criteria. If a release changes a screening workflow, it should identify whether procedures, job aids and training are release dependencies. If the software can close a case without mandatory evidence required by procedure, that is a control-design problem, not only a documentation problem.

Testers should include negative and temporal scenarios: an employee changes role after the training assignment; a contractor is missing from HR; a policy becomes effective while a learner is on leave; an emergency procedure supersedes a standard procedure; a local entity is excluded from a group policy; a user follows an obsolete bookmark; a manager approves an extension after the due date; or training is completed against the wrong content version. These are realistic failure paths.

A practical case: an instant-payment control changes before the training does

Imagine a bank introduces a new instant-payment product. The financial-crime risk assessment identifies increased scam and mule-account risk. Compliance updates the monitoring standard and operations procedure so that certain beneficiary-risk signals require immediate escalation before release. Technology deploys the new signal to the payment decision engine on Monday. The annual AML course is not due for another four months, and the learning team schedules an update for the next quarterly release.

On Wednesday, an operations analyst sees the new field but interprets it using the old job aid. A payment is released. Quality assurance later finds that the new procedure had been approved but was stored in the policy portal under a new folder and no targeted communication was sent. Management initially calls the problem a “training failure”. That diagnosis is too narrow.

The root cause is a broken change chain. The risk assessment changed, the standard changed, the procedure changed and the system changed, but training readiness and job-aid distribution were not release dependencies. The corrective action should therefore include release governance, ownership, document discoverability and role-based communication, not merely refresher training for the analyst.

A stronger implementation would have identified affected roles during change impact assessment, updated the job aid before production deployment, assigned a short scenario-based module, required completion before the employee could approve the new escalation type, and monitored early cases for correct use. That creates evidence that the institution did not merely publish a rule; it operationalised it.

The central lesson

Policies, procedures, training and awareness are not four separate compliance deliverables. They are connected layers of one control environment. Policy states the institution's position. Procedures make the position executable. Training gives people the competence to act. Awareness keeps risk visible as circumstances change. Systems make the required behaviour possible and capture evidence. Assurance tests whether the whole chain works.

A bank that can demonstrate that chain is much better placed to explain its programme to staff, senior management, auditors and supervisors. More importantly, it is more likely to make the right decision when a real financial-crime risk appears in front of an employee.

Operational deep dive: turning policy into repeatable bank behaviour

The base chapter established the translation chain from external obligation and risk assessment to policy, procedure, training, execution and evidence. This deep dive looks at the hard operational questions: how to structure the document hierarchy, how to keep global and local requirements aligned, how to determine who needs training, how to manage exceptions and how to prove that the programme remains current after change.

Design the hierarchy around decisions, not documents

A policy library becomes difficult to manage when every team creates a new document for each problem. The better starting point is the decision architecture. Ask what decisions the institution must make consistently and what evidence is required to support them. The document hierarchy should then provide the right level of instruction for each decision.

For example, customer due diligence may be governed by a group AML/CFT policy, a customer-risk standard, legal-entity-specific CDD procedures, a source-of-funds job aid and system guidance embedded in the onboarding platform. Those artefacts should not repeat one another word for word. The policy might require risk-based due diligence and define escalation expectations. The standard might define minimum customer categories and evidence. The procedure might explain how analysts collect and verify data. The job aid might show acceptable evidence for common scenarios. The onboarding system might enforce mandatory fields and routing.

Traceability is the control that keeps these layers coherent. Each lower-level artefact should identify the governing requirement above it. When policy changes, the bank can then identify affected procedures, system rules, training modules and controls. Without traceability, a regulatory change becomes a manual search exercise and old instructions survive unnoticed.

The traceability model should also work in reverse. If an auditor challenges a workflow rule, the bank should be able to explain which procedure and policy requirement it implements. If nobody can explain why a mandatory field exists, either the requirement is stale or the rationale has been lost.

Separate group minimums from local overlays

Global institutions need common standards because criminals move across products, legal entities and borders. But common standards cannot erase local law. A practical operating model uses a group baseline plus controlled local overlays.

The group baseline should describe principles, minimum risk-management expectations, common control objectives, information-sharing assumptions and governance. Local overlays should identify where law, regulation, supervisory expectation, product design or legal-entity structure changes the implementation. The overlay should not silently weaken the group baseline. If the local entity cannot implement a group requirement, the difference should be documented, assessed and approved through a formal conflict or exception process.

This is particularly important for suspicious-activity reporting, tipping-off restrictions, sanctions implementation, employee screening, data sharing and retention. The applicable terminology and legal details vary materially. A training course that tells staff in several jurisdictions that one reporting deadline or one role title applies everywhere can create operational error while appearing consistent.

Localization also includes language and usability. A translated procedure should preserve the control meaning, not merely convert words. Changes to a group document should trigger assessment of translations and local supplements. Otherwise the English master becomes current while local staff continue to use a prior version.

Build the procedure from a control walkthrough

One of the most effective ways to improve a procedure is to walk through the control with the people who perform it. Start from a realistic case rather than the document. Ask the operator to show the trigger, systems used, data obtained, decision points, hand-offs, escalations and evidence. Compare what actually happens with what the procedure says.

This often exposes invisible workarounds: a spreadsheet used to track overdue information; a team chat used to obtain specialist advice; a manual query that is not described anywhere; a second approval performed because staff do not trust the automated status; or a local checklist created because the official procedure is too abstract. Workarounds are not automatically bad. Some solve genuine design gaps. But an uncontrolled workaround can become a shadow control that is never tested or governed.

The walkthrough should distinguish three categories. Required steps are mandatory and testable. Judgement points allow professional interpretation within defined boundaries. Guidance helps staff work efficiently but is not itself a control obligation. Mixing these categories makes procedures either too rigid or too vague.

A good procedure also describes failure paths. What happens if customer data is missing? What if the screening system is unavailable? What if two source systems disagree? What if an approver is absent? What if a regulatory deadline approaches while an investigation is incomplete? Normal-path instructions alone do not prepare staff for the situations that create the highest operational risk.

Create a role inventory before designing training

Training governance starts with role data. The bank should identify roles that perform or materially influence financial-crime functions, rather than assigning the same course to everyone and assuming the problem is solved.

A useful role inventory records the business area, role, legal entity, jurisdiction, financial-crime responsibilities, systems used, key controls operated or approved, required training, assignment trigger and refresher logic. It should include employees and relevant contractors or outsourced personnel where they perform bank controls.

The inventory is more reliable when linked to authoritative HR and identity data. Manual lists quickly become stale. People transfer teams, return from leave, take temporary roles, join projects or move from operational work into approval positions. The training system needs rules for those events.

Role-based design does not mean hundreds of unique courses. A modular curriculum can combine a common foundation with targeted modules. A relationship manager and payments investigator may both receive a financial-crime foundation but then diverge into customer-risk and payment-investigation content. A developer working on sanctions screening may receive a short module on list data, party fields, matching and control evidence rather than investigator training.

The central design question is: what mistake could this role make that would weaken the financial-crime programme, and what knowledge or skill would prevent that mistake?

Training-needs analysis should use risk evidence

The training-needs analysis should draw from more than policy. Relevant inputs include the enterprise-wide risk assessment, product and customer risks, typology updates, regulatory change, quality-assurance findings, audit issues, incidents, suspicious-reporting quality, monitoring performance, complaints, system change and supervisory feedback.

Suppose quality assurance finds that investigators repeatedly close alerts without explaining why rapid onward payments are consistent with the customer's business. The answer is not necessarily a general AML refresher. The gap may be specific to evidence evaluation and narrative writing. A targeted case exercise can be more effective than making the entire population repeat a broad course.

Likewise, if a sanctions programme changes how ownership and control are assessed, the impacted population may include onboarding, relationship management, screening operations, legal, sanctions specialists and relevant technology teams. Training should follow the control impact, not the organisational chart alone.

Training needs can also decrease. If a task becomes fully automated and the employee no longer makes the decision, the old detailed course may no longer be necessary. The person may instead need awareness of the automated control, exception indicators and escalation route. Keeping unnecessary modules creates fatigue and can obscure genuinely important learning.

Distinguish awareness, instruction, competence and attestation

These are often mixed together.

Awareness tells people that a risk or requirement exists and what they should notice or escalate. Instruction teaches how to perform a task. Competence means the person can apply the knowledge correctly. Attestation records that the person acknowledges a statement or responsibility. An attestation does not prove competence, and a completed course does not prove that the person will apply the procedure correctly.

A bank may need all four. Senior leaders might attest to understanding key accountability. Investigators may need scenario-based competence assessment. All staff may receive basic awareness of suspicious behaviour and escalation. Operations staff may receive step-by-step instruction on a new workflow.

The learning method should fit the objective. E-learning is useful for scalable foundations. Instructor-led sessions help where judgement and discussion matter. Simulations work well for complex investigations. On-the-job coaching can reinforce procedures. Short awareness messages can respond quickly to emerging risks. Reference material supports memory after training.

The assignment lifecycle is a control

Training assignment should be governed like other controls. Define the trigger, population, due date, escalation, exception rules, evidence and owner.

New joiners may require foundational training within a defined onboarding period. Role transfers may trigger additional modules before the person exercises a new authority. A policy change may create a targeted assignment to a specific population. Contractors may be assigned through a separate identity process. Senior leaders may receive scheduled briefings rather than the same e-learning as frontline staff.

Overdue training should have a risk-based consequence. A reminder alone may be appropriate for low-risk awareness content. A person who has not completed mandatory training for a high-risk approval role may need temporary restriction from that activity. The consequence should be defined in advance and supported by access or workflow controls where appropriate.

Extensions and exemptions should be controlled. An employee on long-term leave is different from a manager who ignored repeated reminders. The system should capture the reason, approver and revised date. Repeated extensions can indicate an organisational weakness that management should see.

Measure whether people can use the procedure

A quiz at the end of an e-learning module is only one data point. More meaningful effectiveness measures connect learning to operational outcomes.

For investigators, quality-assurance samples can test whether evidence is gathered and decisions documented correctly. For onboarding, monitoring can show whether required beneficial-ownership or enhanced-due-diligence steps are missed. For frontline teams, referral quality can reveal whether staff recognise relevant indicators. For managers, exception decisions can show whether escalation criteria are understood. For technology teams, defect analysis can reveal misunderstandings of control requirements.

The institution should avoid claiming causal certainty where it does not exist. An improvement after training may also reflect a system change or process simplification. The practical goal is to build a body of evidence that training is current, relevant and associated with competent performance.

Manage policy exceptions as risk decisions

Policies sometimes require exceptions because a product, jurisdiction or system cannot meet the standard immediately. The exception process should capture the requirement, reason, risk, compensating controls, scope, owner, approval, start date, expiry date and remediation plan.

An exception should not silently become the new operating model. Expiry should trigger review. Repeated renewal should escalate because it may indicate that the policy is unrealistic, the business has not funded remediation or the control design is wrong.

Training impact must be considered. If a temporary process changes how staff perform a control, the affected population needs controlled instruction. When the exception ends, the temporary guidance should be retired so that obsolete material does not remain discoverable.

Change impact assessment should produce a learning impact statement

Every material financial-crime change should answer whether policy, procedure, job aids and training are affected. This can be built into the change-management template.

A useful learning impact statement identifies affected roles, behaviour that changes, learning method, completion requirement, dependency on system release, local-language needs, evidence owner and post-implementation monitoring. For high-risk changes, training readiness may be a deployment gate.

This is particularly important when the change is technology-led. A new field, model score, case status or API can alter a financial-crime decision even if the project is classified as “technical”. The learning assessment should focus on changed behaviour, not on the project label.

Evidence and retention architecture

Training evidence should be reconstructable at the individual, role and programme level. The bank should be able to answer who was required to take a module, which version they received, when it was assigned, when it was completed, whether they passed an assessment, whether an extension existed and which policy or procedure the module supported.

That evidence often requires integration between HR, contractor records, identity management, the learning platform, policy repository and GRC. Reconciliation controls should detect mismatches. For example, compare active users in a high-risk system with people assigned the relevant training. Compare employees in a role family with the training register. Compare current procedure versions with linked training content.

Retention requirements are jurisdiction and record-type specific, so a global programme should not invent one universal period. The policy should define how local retention schedules apply and ensure that historical evidence remains available for examination or investigation as required.

Management information that reveals real weakness

Useful MI goes beyond completion percentages. It can include population coverage, overdue training by risk role, late assignment after role changes, assessment failures, repeat failures, remedial training, exception ageing, training content older than the linked procedure, quality findings by trained population, incident themes and local-entity gaps.

Leaders also need denominator quality. “98% complete” is meaningless if the population is wrong. A strong dashboard explains where the population comes from and how unmatched users, contractors or role changes are handled.

Trends matter more than isolated numbers. If one operations centre has repeated training failures and higher case-quality errors, management should investigate the relationship. If a team completes training promptly but still makes the same mistake, the training may be irrelevant or the procedure may be unusable.

Operational deep-dive case: policy update across five legal entities

A banking group changes its customer-risk policy after a new group risk assessment identifies higher exposure in certain payment corridors. The group standard requires enhanced review when defined factors combine. Five legal entities use different onboarding platforms and local CDD procedures.

A weak implementation sends the new group policy to every entity and assigns a generic e-learning module. Each entity interprets the rule differently. One applies it to all customers from the relevant countries. Another applies it only at onboarding. A third cannot capture one of the required data elements. The fourth adopts a manual spreadsheet. The fifth delays implementation because its local policy committee meets quarterly.

A stronger implementation begins with local impact assessment. Each entity maps the group requirement to local law, data availability, systems, procedures and accountable roles. Gaps become documented actions or exceptions. Procedures are updated with the actual decision logic. System changes are tested. Training is targeted to affected roles and uses local scenarios. Implementation evidence shows when each entity became compliant, and management can see any temporary residual risk.

The lesson is that consistent policy does not automatically create consistent behaviour. Consistency must be engineered through procedures, systems, learning, evidence and local accountability.

Advanced practice: policy engineering, learning effectiveness and controlled change

Mature financial-crime programmes treat policy, procedure and learning as connected control components with versioning, traceability and measurable outcomes. This supplement focuses on the delivery problems that appear at scale: mapping obligations to controls, keeping content current, proving training effectiveness, governing generated or automated guidance, and testing the full chain after change.

Build obligation-to-control traceability

A bank should be able to explain why a policy requirement exists. The strongest traceability model links an external obligation or approved risk decision to a policy clause, control objective, procedure, system requirement, training impact and evidence source.

This does not mean every sentence needs a regulatory citation. It means material requirements should have a defensible source. A control inventory can hold identifiers that connect the pieces. When regulation changes, the bank searches by obligation and identifies impacted controls. When a procedure changes, it can identify which training modules are linked. When a control fails, investigators can see whether the weakness came from design, procedure, technology, competence or execution.

Traceability also protects against accidental policy inflation. Banks sometimes add internal requirements during remediation and later treat them as if regulators mandated them. Internal risk standards can be stricter than law, but they should be labelled as internal choices. That improves future change decisions and avoids misleading staff.

Use effective dating as a core data attribute

Policy and training evidence should be time-aware. Every material artefact should have a version, approval date, effective date, owner and status. Procedures and job aids should indicate which policy or standard they implement. Training content should identify the relevant policy or procedure version where practical.

Effective dating matters during investigations and regulatory review. If a case was handled on 4 May, the reviewer needs the rules and instructions applicable on 4 May. Replacing files in place without preserving history destroys that evidence.

System logic also needs effective dating. A policy may become effective on 1 July while a model threshold changes on 3 July because of deployment constraints. That gap is a risk event that should be visible. The bank should know whether temporary controls existed and who accepted the residual risk.

Treat generated guidance and AI assistance carefully

Banks increasingly use search, copilots and generative tools to help staff find procedures or summarise policy. These tools can improve usability, but they create a new control question: is the employee seeing the approved source or an interpretation that may be incomplete?

A safe design keeps the approved document as the authoritative source, shows provenance and version, limits the assistant to approved repositories where appropriate, and makes high-impact decisions traceable back to the actual requirement. The tool should not invent thresholds, legal duties or exception authority. Where the answer is uncertain, it should direct the user to the owning function rather than fabricate certainty.

Testing should include outdated documents, conflicting group/local sources, revoked procedures, similar terminology and jurisdiction-specific questions. The risk is not merely a hallucinated sentence; it is an employee acting on an answer that appears official but is not governed.

Make training content change-controlled

Learning material can become stale just like a procedure. A training module should have an owner, version, review trigger and linked source documents. If the governing procedure changes materially, the owner should assess whether the learning content must change and whether existing learners need targeted retraining.

A change does not always require everyone to retake a course. The impact assessment should ask whether behaviour changes. A formatting update may require no action. A new escalation threshold may require targeted communication. A new sanctions ownership rule may require role-based training and assessment. A new system interface might require a job aid rather than a full compliance module.

The content owner should also manage examples carefully. Scenario facts age. Payment rails evolve, products change and regulatory terminology moves. Examples should be periodically checked so learners are not trained on a process the bank no longer uses.

Evaluate effectiveness at four levels

A useful evaluation model separates four questions.

Was the right population reached? Population coverage uses HR, contractor and role data.
Did people understand the content? Assessments, scenario discussion or observation can provide evidence.
Did behaviour change? QA, error rates, referral quality, control breaches and manager observation help answer this.
Did control outcomes improve? This may be visible through fewer repeat findings, better investigation quality or faster correct escalation, but causation should be interpreted carefully.

These levels prevent a completion dashboard from masquerading as effectiveness evidence. They also help management choose remediation. If population coverage is poor, fix data and assignment logic. If understanding is poor, redesign content. If understanding is strong but behaviour remains weak, the problem may be procedure complexity, workload, incentives or system design.

Use incidents to test the learning system

Every material financial-crime incident should include a people-and-guidance question: did the affected staff have an accurate procedure, were they trained for the task, was the guidance usable, and were known gaps already visible in QA or training data?

This should not turn into automatic blame. Many “human errors” are system or process errors in disguise. If staff repeatedly miss a step because the workflow hides the required information, more training is unlikely to solve the problem. Root-cause analysis should separate competence, clarity, design, capacity and technology.

Where a genuine knowledge gap exists, remediation should be specific. The bank can issue targeted learning, reassess competence and monitor subsequent cases. The incident should also update the training-needs analysis so the lesson becomes part of the programme rather than a one-off email.

Design training for judgement roles differently

Rules-based operational tasks can often be trained with clear steps and examples. Judgement roles need a different approach. Investigators, sanctions specialists, EDD analysts and MLRO teams must weigh incomplete evidence and explain reasoning.

Scenario-based learning is stronger because it exposes ambiguity. Present a customer whose activity has both legitimate and suspicious explanations. Ask what additional evidence matters, what can be concluded, what cannot, and when escalation is required. Compare reasoning rather than rewarding one memorised phrase.

Calibration sessions can supplement formal training. Reviewers examine the same cases, discuss differences and agree interpretation. The outcome should feed procedures or job aids where ambiguity is recurring. Calibration is not a substitute for independent decision-making, but it improves consistency without pretending every case is identical.

Incorporate accessibility and comprehension

Training is ineffective if employees cannot understand it. Accessibility should cover disability needs, language, reading level, device compatibility and time available for completion. Complex financial-crime concepts benefit from plain explanations followed by deeper technical material where roles require it.

Translated content needs quality assurance by people who understand both language and control meaning. Literal translation can distort legal or technical terms. Local examples should reflect actual products and escalation routes.

The same principle applies to procedures. A fifty-page document may be formally complete but operationally unusable. Good design uses clear headings, decision tables where useful, linked definitions and concise task guidance while preserving enough depth for complex cases.

Control third-party and outsourced learning

Outsourcing does not remove the bank's need to understand whether people performing its financial-crime processes are competent. The contract and operating model should identify who provides training, which standards apply, how completion and competence are evidenced, how changes are communicated and how the bank obtains records for assurance.

A vendor's generic AML certificate may be useful but may not cover the bank's procedures or risk profile. Role-specific instruction remains necessary where the vendor operates the bank's controls. Significant policy changes should flow through formal vendor change management rather than informal relationship-manager communication.

The bank should also know what happens when vendor staff rotate. High turnover can create a persistent competence risk even when headline completion appears strong.

Test the control chain end to end

Testing should not stop at checking whether a document exists. A strong end-to-end test selects a material requirement and follows it through the chain.

For example, take a requirement that high-risk customer reviews need senior approval. Confirm the policy states the expectation, the procedure defines the trigger and approver, the system routes the case correctly, training covers the responsibility, affected staff were trained before exercising the role, a sample of cases contains the approval evidence, and management information captures exceptions. Then test a negative scenario where the approver changes role or the workflow is unavailable.

Another test can start from a training record and work backwards. Is the learner actually in the role? Was the content current? Which procedure did it support? Did the learner have access to the correct job aid? Is there evidence of competent execution afterward?

These tests reveal gaps that isolated document or LMS reviews miss.

BA acceptance criteria for a policy-to-training capability

For a change-management or learning-platform feature, useful acceptance criteria can include:

each controlled document has owner, version, approval status and effective date;
superseded documents remain historically retrievable but are not presented as current guidance;
document changes can identify linked controls, procedures and learning modules;
role assignments derive from an approved population source and support contractors where required;
role change can trigger new learning without waiting for the annual cycle;
training completion records include content version and completion time;
extensions and exemptions require reason, approver and expiry;
overdue high-risk assignments can trigger escalation or access restriction according to policy;
management information distinguishes assignment coverage from completion rate;
evidence can be reconstructed for a past date;
local entities can maintain approved overlays without altering the group source silently;
audit logging captures material content and assignment changes.

The exact controls will vary by bank, but the acceptance criteria should prove that governance is built into the capability rather than dependent on manual memory.

Testing scenarios delivery teams should include

Positive tests should confirm that a new employee receives the correct foundation; a transferred investigator receives the additional investigator module; a policy update assigns targeted learning to impacted roles; and historical training remains linked to the version used at the time.

Negative tests should include an unknown role code, duplicate employee identity, contractor without HR record, expired exception, training completion after access is granted, local overlay conflicting with group policy, stale bookmark to a retired procedure and a failed integration between HR and the learning system.

Temporal tests are especially important. Change an employee's role, effective-date a new procedure, delay a training assignment and confirm what the system reports at each point. Many real control gaps occur because two systems update on different schedules.

Resilience tests should cover unavailable policy repositories or learning platforms. Staff still need an approved way to perform critical controls. Business-continuity arrangements should prevent teams from falling back to uncontrolled personal copies.

Advanced case: the completion rate that hid the gap

A bank reports 99.6% annual AML training completion. A regulator samples payment-screening analysts and finds several new contractors were never assigned the specialist module. The corporate course was completed, so the dashboard counted them as trained.

The immediate reaction is to change the dashboard. The deeper problem is the training model. The institution measured course completion, not role coverage. Contractors entered through a vendor identity feed that did not populate the specialist role field. The learning platform therefore had no way to know which additional module was required.

A sustainable fix maps control roles to identity data, reconciles system access against training entitlement, defines vendor onboarding requirements and reports coverage separately from completion. The bank can then answer the more important question: has every person who can operate this control demonstrated the required competence?

That is the difference between training administration and financial-crime control assurance.

Practice close: inspect the control, not the training catalogue

This close turns the chapter into practical review prompts for compliance professionals, operations teams, business analysts, architects, developers and testers. The objective is to assess whether policy, procedure and learning form one controlled operating chain.

A ten-question reviewer walkthrough

Choose one important financial-crime requirement, such as enhanced due diligence for a high-risk customer, sanctions escalation, suspicious-activity referral or a monitoring-case approval. Then ask:

What external obligation, risk assessment or approved internal risk decision is this requirement based on?
Which current policy or standard states the requirement?
Which legal entities, products, channels and roles are in scope?
Which procedure tells staff how to perform the requirement?
Which systems and data make the procedure possible?
Which roles need awareness, instruction or demonstrated competence?
How does the bank know those people received the current learning before exercising the responsibility?
What evidence proves the control was performed in a particular case?
How are exceptions, overdue training and temporary workarounds governed?
What feedback tells management whether the policy and training are actually effective?

If the team cannot answer these questions without reconstructing the process manually, the control environment is probably weaker than the policy library suggests.

Worked exercise: a new suspicious-activity referral procedure

A bank changes its referral process so that customer-facing employees must use a new structured form when they see suspicious behaviour. The form asks for the observed behaviour, customer context, transaction references and urgency. The aim is to improve referral quality and reduce incomplete escalation.

The policy does not need major amendment because the duty to escalate concerns already exists. The operating procedure does change. The CRM adds a new referral link. A short role-based learning item shows staff when to use the form, what useful factual information looks like and why they must not tell the customer that an AML referral is being considered.

What should the bank test?

First, confirm the right population receives the new guidance. Customer-facing employees, relevant contact-centre staff and relationship managers may be in scope. Second, test the form itself. Can the user submit a concern if some transaction information is unavailable? Does the system prevent sensitive referral notes from appearing in customer-visible channels? Does the referral reach the correct queue? Third, test timeliness. Are urgent matters identifiable? Fourth, test evidence. Can the bank show which staff were told about the new process and which version of the procedure applied?

After implementation, review referral quality. If referral volume increases but useful facts decrease, the learning or form design may be poor. If one business area produces almost no referrals, investigate whether the population, risk exposure or awareness differs. Do not assume more referrals automatically mean a better control.

Acceptance criteria for delivery teams

A policy-and-training change is not ready merely because the policy has been approved. For a material change, acceptance criteria should establish that:

the current policy or standard is approved and effective-dated;
impacted procedures and job aids are identified and updated;
group and local differences are documented;
systems support the required behaviour or an approved temporary control exists;
affected role populations are defined from reliable data;
training or awareness content matches the final procedure;
required learning is assigned in time for the change;
content version and completion evidence are retained;
high-risk overdue cases have a defined escalation route;
post-implementation quality monitoring is scheduled;
obsolete material is retired or clearly marked as superseded;
exceptions have owners, approvals and expiry dates.

These criteria are deliberately end to end. They prevent each function from declaring its own component complete while the combined control remains incomplete.

Negative test pack

A strong test pack should include failure conditions, because real policy governance breaks at the edges.

Role change: an employee moves from a general operations role into sanctions investigations. Confirm specialist training is triggered and approval access is not silently available before readiness requirements are met.

Contractor onboarding: a vendor analyst receives production access but is not present in the main HR system. Confirm the population logic still identifies the person and assigns required learning.

Policy supersession: a user opens an old bookmarked procedure after the new version becomes effective. Confirm the repository redirects or clearly shows that the document is superseded.

Local conflict: a group policy requirement cannot be implemented as written because of local law. Confirm the conflict follows approved legal and governance escalation rather than being solved through an unofficial local note.

Emergency change: a sanctions measure changes faster than the normal document cycle. Confirm temporary instructions are approved, distributed, time-limited and later incorporated into the formal procedure.

LMS outage: mandatory learning evidence is temporarily unavailable. Confirm business-critical control operation does not depend on an unverified spreadsheet workaround and that evidence is reconciled after service restoration.

Stale training: a module still describes a retired workflow. Confirm content-review triggers detect the mismatch and that learners receive corrected guidance where behaviour is affected.

Extension abuse: a high-risk team repeatedly extends training due dates. Confirm the issue becomes visible to management and is not hidden inside aggregate completion reporting.

Misconceptions to avoid

“Everyone completed the course, so training is effective.” Completion proves attendance or system interaction, not competent behaviour.

“The policy is approved, so the control is implemented.” Approval establishes governance intent. Implementation requires procedures, systems, people and evidence.

“Annual training is the global rule.” FATF requires an ongoing employee training programme, but exact frequency and content depend on applicable law, risk and the institution's operating model. Jurisdictions may set more specific expectations.

“Group policy overrides local law.” A group can set a strong baseline, but local legal conflicts need controlled analysis and approved treatment.

“Awareness emails are enough when a process changes.” Awareness may be useful, but if staff behaviour changes, procedures, systems and targeted instruction may also need updating.

“Training fixes human error.” Sometimes. Repeated human error can indicate a poor workflow, unclear procedure, workload problem, weak data or unsuitable system design.

“Outsourced staff are the vendor's training problem.” The operating model must still give the bank confidence that people performing its regulated control are appropriately prepared and that evidence is available.

Knowledge check

Why is FATF Recommendation 18 central to this topic? Because its global standard connects internal policies, procedures and controls with employee screening, ongoing training and independent audit, while allowing proportionality according to risk and business size.

Why should policy and training use effective dates? Because the bank may need to prove which requirement and learning content applied at the time of a historical decision.

What is the difference between awareness and competence? Awareness helps a person recognise a risk or requirement. Competence means the person can perform the relevant responsibility correctly.

What is the strongest evidence of training effectiveness? There is no single strongest metric. Coverage, understanding, operational behaviour, QA, incidents and assurance results should be interpreted together.

Why are role changes important? A person can acquire a new financial-crime responsibility without being a new employee, so onboarding-only assignment logic misses material risk.

Why should developers care about policy training? Technology changes can alter how a financial-crime control operates. Developers need enough control context to understand mandatory data, workflow, evidence and change dependencies.

Final practitioner checklist

Before closing a policy or training review, confirm that the document hierarchy is understandable, the current version is discoverable, local applicability is clear, procedures match actual work, training is risk- and role-based, assignment populations are reliable, overdue cases and exceptions are governed, evidence is historically reconstructable, and feedback from QA, incidents and audit can trigger change.

The best outcome is not a larger policy library or a longer training catalogue. It is a workforce that can make the right financial-crime decision using current instructions, supported by systems that make the required behaviour practical and evidenceable.

Masterclass: when a policy is correct but the bank still fails

This case study follows a fictional international bank, Northbridge Banking Group. The facts are illustrative, but the failure pattern is common: legal requirements were understood, the policy was approved, and training completion looked strong. The control still failed because the document, technology and learning lifecycles were not joined.

The change

Northbridge operates retail and corporate banking in several jurisdictions. A sanctions and AML risk review identifies that its existing customer-review process does not consistently capture changes in beneficial ownership for higher-risk corporate customers. Compliance decides that any material ownership change in a higher-risk relationship must trigger review of beneficial owners, connected parties and relevant screening results before normal servicing continues.

The group policy is amended. The new clause is clear. Senior management approves it and the effective date is set for 1 October. A control standard defines the required review. Each legal entity is asked to update procedures and systems.

On paper, governance looks sound.

The local implementations diverge

Entity A has a modern onboarding platform. It adds an event-driven review trigger and prevents case closure until ownership data and screening are complete. The local procedure is updated, analysts receive scenario-based learning and the change goes live on time.

Entity B uses a legacy system. The platform cannot detect ownership change automatically, so relationship managers must raise a manual referral. The local procedure is updated, but the referral form does not contain the new reason code. Staff are told to use “other”. Management expects to replace the workaround within three months.

Entity C interprets the group requirement as applying only at periodic review because its procedure owner assumes “customer review” means scheduled KYC refresh. No formal conflict is raised. Training content is copied from the group policy and does not explain the local workflow.

Entity D outsources part of KYC operations. The vendor receives the updated procedure but the contract change process does not identify training as a deliverable. Vendor staff continue using the old job aid for six weeks.

Entity E has the correct procedure and workflow, but the learning-management system receives role data monthly. Several analysts who move into the high-risk customer team during October are not assigned the specialist module until November.

The group dashboard still shows 98.9% completion of mandatory AML training.

The incident

In November, Entity B receives information that a long-standing corporate customer has changed ownership. The relationship manager knows the customer needs review and submits a manual referral using the “other” category. The operations queue prioritises explicit KYC triggers above generic referrals, so the case waits.

During the delay, the customer makes payments to a new counterparty. One payment creates a sanctions-screening alert because a party name resembles a listed entity. The alert is closed as a false positive based on the immediate name and country information. The analyst does not know that an ownership-change review is pending because the referral and screening tools are not connected.

The payment itself is not necessarily prohibited; the problem is the bank cannot show that the required ownership review happened before continued servicing. A later quality review discovers the overdue referral and escalates the case.

The first diagnosis is wrong

Management initially calls this a staff-training issue. The relationship manager should have escalated more clearly, the queue analyst should have recognised urgency, and the screening analyst should have looked further.

That explanation is attractive because it creates a quick action: retrain the teams. But the evidence shows that the people behaved largely in line with the tools and procedures available to them.

The relationship manager used the only available referral code. The queue prioritisation logic treated “other” as lower priority. The screening analyst had no visibility of the ownership-change referral. The local procedure did not describe how manual referrals interacted with sanctions screening. Training had explained the policy principle but not the system workaround.

The failure was a translation-chain failure.

Root-cause analysis

The review identifies six connected causes.

First, the group change process did not require each entity to prove operational readiness against defined criteria. An email confirmation that the local procedure was “updated” was accepted as sufficient.

Second, the control standard did not map the ownership-change requirement to the actual system trigger and queue priority in Entity B.

Third, the local procedure described the review but not the end-to-end hand-off between relationship management, KYC operations and payment screening.

Fourth, the learning impact assessment treated the change as a policy update and assigned knowledge content. It did not test whether staff could execute the new process in local systems.

Fifth, management information measured course completion but did not show whether all people with high-risk customer roles had completed the relevant specialist module.

Sixth, the temporary workaround had no explicit expiry, owner or compensating monitoring.

No single mistake explains the incident. That matters because a remediation plan focused only on employee behaviour would leave the structural weakness in place.

Designing the sustainable fix

Northbridge creates a standard change-readiness pack for material financial-crime policy changes. Each legal entity must map the requirement to local obligations, procedures, controls, systems, data, roles and learning. Material gaps require a time-limited exception with compensating controls and senior approval.

Entity B adds an ownership-change referral reason and gives it an appropriate priority. Until the technology change is complete, a daily reconciliation compares ownership-change notifications from relationship management with open KYC cases. The workaround has an owner and expiry date.

The group policy repository is linked to procedure metadata. When a policy clause changes, owners of linked procedures receive an impact task. Procedures record the applicable legal entity and effective date.

Learning changes as well. Instead of a generic module, affected staff receive short local scenarios showing exactly how the new trigger appears and what to do. Analysts must complete the module before they receive access to approve the relevant case type. Contractors are included through the identity-management feed rather than a vendor spreadsheet.

The screening team receives awareness of the ownership-change signal and the case platform exposes relevant pending KYC review status where legally and operationally appropriate. The aim is not to merge all case work, but to prevent one control from operating without context held by another.

What the BA should write

A business analyst working on this remediation should avoid requirements such as “system must support the new AML policy”. That is not testable.

A buildable requirement might say: when a relationship manager records a material ownership change for a customer classified as high risk, the customer-review platform shall create an event-driven review with the approved trigger code, record the source and time of the event, route the case to the high-risk review queue and prevent the relevant review from closing until required beneficial-owner and connected-party checks are completed or an approved exception is recorded.

Another requirement might say: before a user can approve a high-risk ownership-change review, the access-control process shall verify that the user holds the required role and has completed the current role-specific training module, except where an approved emergency-access process applies.

For the learning platform: each training completion record shall preserve learner identity, role, legal entity, module identifier, module version, assignment date, completion date, result where assessed, and any extension or exemption reference.

These requirements connect behaviour to evidence.

What the tester should prove

Testing should cover more than the successful case. Test an ownership change for a low-risk customer and confirm the correct proportional response. Test missing ownership data. Test a user who changes role on the effective date. Test a contractor. Test a local entity whose procedure becomes effective one day later than the group policy. Test the emergency workaround. Test the interface between the customer-review and screening environments. Test whether an obsolete job-aid URL still resolves to retired content.

Then test evidence. Can the bank reconstruct which procedure and training module applied to a case six months later? Can it identify users who had approval access before training? Can it show who approved a temporary exception and when it expired?

The governance lesson

The board or senior committee does not need to review every training slide. It does need credible information about whether material policy changes have been operationalised. Management reporting should therefore distinguish policy approval, local implementation, system readiness, training coverage, open exceptions and post-implementation quality.

A “green” policy status should not be allowed to hide an amber system gap or incomplete training population.

The deeper lesson from Northbridge is that policies, procedures, training and awareness are not administrative evidence around the AML/CFT programme. They are mechanisms through which the programme becomes real. When they are designed as one connected change system, the bank can adapt safely. When they are managed as separate document, technology and learning processes, formally correct policy can still produce incorrect behaviour.

References and further reading

The sources below were used to anchor the chapter. FATF provides the global AML/CFT baseline; Basel Committee material is supervisory guidance rather than a universally binding rule; FFIEC, FCA and AUSTRAC material is jurisdiction-specific and should be applied only within the relevant legal and supervisory context.

Global standards and supervisory guidance

FATF Recommendations, current version updated June 2026 — Recommendation 18 and its Interpretive Note cover internal policies, procedures and controls, compliance management, employee screening, ongoing employee training, independent audit and group-wide programmes.
FATF Guidance for a Risk-Based Approach: Banking Sector — explains how banks and supervisors apply proportional AML/CFT controls according to risk.
Basel Committee: Sound management of risks related to money laundering and financing of terrorism — banking-sector governance and risk-management guidance; the Basel Committee states that these guidelines are not Basel standards and their implementation depends on jurisdictions.

United States

FFIEC BSA/AML Examination Manual: Training — U.S. examination guidance on risk- and role-appropriate BSA/AML training, new-employee orientation, specialist and board training, records and overdue-completion evidence.
FFIEC BSA/AML Examination Manual — broader U.S. examination framework for the BSA/AML compliance programme and related controls.

United Kingdom

FCA Handbook SYSC 6.3: Financial crime — UK rules and guidance on financial-crime systems and controls, including appropriate employee training and documented risk-management policies.
FCA Financial Crime Guide — practical FCA examples of good and poor financial-crime systems and controls, including the value of training relevant to the role and business risk.
JMLSG current guidance — UK industry guidance approved or otherwise designated according to its published status. Users should check the status of any revised text before relying on it as current approved guidance.

Australia

AUSTRAC: AML/CTF training — guidance for the reformed Australian AML/CTF regime on initial and ongoing, role-relevant training, effectiveness, records and updates when risk or programme responsibilities change.
AUSTRAC: Review and update your AML/CTF program — Australian guidance on keeping the AML/CTF programme current as business, risk and obligations change.

European Union institutional context

AMLA and EBA complete handover of EU-level AML/CFT mandates — confirms the 1 January 2026 transfer of EU-level AML/CFT mandates from EBA to AMLA and continuity of existing EBA AML/CFT guidelines until AMLA replaces them.