Global-to-Local AML/CFT Operating Model

A global bank cannot run financial-crime compliance by writing one policy at head office and telling every country to follow it literally. Nor can it allow every local entity to design its own programme independently. The first approach ignores differences in law, supervisory expectations, products, reporting routes, privacy rules and market infrastructure. The second destroys consistency, weakens group oversight and makes it difficult to understand customers and risk across borders. A mature operating model has to do both things at once: establish a defensible group-wide minimum and translate that minimum into controls that are lawful, proportionate and executable in each jurisdiction.

The easiest mental model is global baseline, local legal overlay, controlled exception. The global baseline expresses the bank's minimum expectations for risk assessment, customer due diligence, screening, transaction monitoring, suspicious-activity escalation, governance, training, quality assurance and information sharing. The local overlay identifies what the law and supervisor in a particular jurisdiction require in addition to, differently from, or more strictly than that baseline. A controlled exception handles the difficult cases where local law prevents the group from implementing a group standard, or where a global process cannot be used exactly as designed because of data localisation, secrecy, reporting confidentiality, technology or operating constraints.

This is not simply a policy topic. It is an operating architecture. The model determines who owns requirements, how local obligations are discovered, how controls are designed, what data may cross borders, how customer and transaction information is shared within the group, which decisions can be centralised, which must remain local, how regulatory change reaches production systems, how exceptions are approved, and how the bank proves to home and host supervisors that the programme works in practice.

A global-to-local AML/CFT model converts international standards and group risk appetite into local legal requirements, executable controls, evidence and assurance.

Start with the legal hierarchy, not the organisation chart

Many weak implementations begin with the bank's existing organisation chart. Teams ask whether a control belongs to global compliance, regional compliance, the local MLRO, operations or technology. That is important, but it is not the first question. The first question is: what obligation applies to this legal entity, activity and customer relationship, and where does that obligation come from?

FATF provides the international standard. Its Recommendations are implemented by countries through their own legal, regulatory and supervisory frameworks. The FATF Recommendations, updated through June 2026, explicitly recognise that countries have different legal and financial systems and therefore implement the international standard through measures adapted to their circumstances. A bank should therefore use FATF as a global design anchor without presenting FATF text as though it were directly enforceable law in every country.

For a financial group, FATF Recommendation 18 is central. It expects financial groups to implement group-wide AML/CFT programmes, including policies and procedures for sharing information within the group. Its Interpretive Note says those programmes should apply to branches and majority-owned subsidiaries, include appropriate internal policies, compliance management, training and independent audit, and support the sharing of customer, account and transaction information when necessary for AML/CFT purposes. It also recognises the home-host problem: where host-country minimum requirements are less strict than home-country requirements, the group should apply the home-country requirements to the extent host law permits. If host law prevents proper implementation, the group should apply additional measures, inform the home supervisor and be prepared for further supervisory action if risk cannot be adequately managed.

That framework gives a bank a strong design principle but not a complete rulebook. The actual legal requirements may come from statutes, regulations, regulator rules, FIU reporting instructions, sanctions legislation, data-protection law, banking secrecy, court decisions, licensing conditions, sector guidance or supervisory findings. A global operating model therefore needs an obligation inventory that is linked to legal entities and controls, not simply a library of PDFs.

A useful obligation record answers at least these questions: which legal entity is affected; what customer, product or transaction scope is covered; what action is required; what threshold or trigger applies; what timing is required; what records must be retained; what reporting or escalation route applies; whether the rule is mandatory or guidance; when it takes effect; and which source proves the requirement. Those fields sound administrative, but they are what allow policy and technology teams to build something testable rather than interpret a paragraph differently in every project.

Group standard does not mean identical local procedure

Consistency is often confused with uniformity. A global bank needs consistent outcomes and minimum control principles, but the local procedure may legitimately differ. Consider suspicious transaction reporting. The group can require every business to escalate suspicion promptly, preserve evidence, prevent tipping-off and route cases through an approved reporting decision. Yet the statutory reporter, filing portal, legal threshold, filing deadline, confidentiality rules and ability to share the filed report within the group can differ materially by jurisdiction.

The same distinction applies to customer due diligence. A global standard can define minimum identity, beneficial ownership, purpose and expected-activity principles. Local law may then prescribe specific acceptable identity documents, verification methods, beneficial ownership thresholds, national identifiers or record-retention periods. A system designed around only the global fields may not capture legally required local evidence. A system designed separately for every country may create thirty incompatible customer models. The operating model has to separate the common information model from the local evidence and rule overlay.

A well-designed global standard therefore says what must be achieved, what controls are mandatory, what risk tolerances apply, what evidence is required and where local variation is permitted. It avoids writing operational details that are known to vary unless those details are deliberately defined as a non-negotiable group requirement. Local procedures then translate the standard into the jurisdiction's law, products, channels and operating reality.

This also prevents a common compliance failure: using the phrase "local requirements prevail" as a blanket escape route. Local law should prevail where it is legally binding, but that does not mean a local entity may simply weaken a group control because the law is silent. The group may choose standards above the local legal minimum based on risk appetite, safety and soundness, correspondent expectations, customer protection or enterprise policy. The local entity needs to distinguish legal requirement, group minimum, supervisory expectation and business choice because they have different change and exception processes.

The stricter-standard principle needs careful engineering

Banks often summarise global-to-local design with a simple rule: "apply whichever standard is stricter." That is useful as a starting point, and the Basel Committee's current consolidated AML/CFT guidance supports a group-wide approach in which local policies remain consistent with group policy and stricter host requirements can be adopted. But "stricter" is not always a single linear comparison.

One jurisdiction might require verification at a lower monetary threshold, while another requires a different set of documentary evidence. One might permit simplified due diligence in a lower-risk case while another does not. One may prohibit sharing an STR or certain related information outside the country, while the group policy expects centralised investigation. A mechanically coded MAX(global_rule, local_rule) cannot resolve those differences.

The control model should instead compare requirements by obligation dimension. For onboarding, those dimensions could include identification fields, verification method, beneficial ownership, purpose, source of funds, PEP treatment, risk rating, approval and review frequency. For transaction monitoring they could include data inputs, scenario coverage, thresholds, alert retention, escalation, reporting and quality assurance. The result is a rules matrix in which some local rules augment the group baseline, some replace a global method with an equivalent local method, and some create a genuine legal conflict requiring an exception.

This approach matters for business analysts and architects because it changes the data structure. A policy engine needs effective dates, jurisdiction, entity, product and rule priority. It needs to know whether a rule is additive, overriding, conditional or prohibitive. It also needs a human-readable rationale, because a control decision that cannot explain which rule won is difficult to test and almost impossible to defend during an inspection.

The local decision flow distinguishes a stricter local requirement, a compatible group baseline and a genuine legal conflict that requires documented mitigation and escalation.

Home country, host country and the legal entity problem

A financial group may be managed globally, but regulation usually attaches to legal entities, branches, licences and activities. The parent bank may be headquartered in one country, operate branches in several others, own separately incorporated subsidiaries, provide services cross-border from a booking centre, and use shared service centres elsewhere. The AML/CFT operating model has to understand those distinctions.

A branch is normally part of the same legal person as its head office, but is subject to host-country rules for its local operations. A subsidiary is a separate legal person and may have its own board, licence, regulator and statutory compliance officer. A shared service centre may perform KYC or alert review for multiple entities without itself owning the regulatory decision. A regional hub may run technology while legal accountability remains with each regulated entity.

The operating model should therefore map every control to both an execution owner and an accountable regulated entity. If analysts in Country B investigate alerts for customers booked in Country A, the workflow should preserve the Country A legal basis, reporting threshold and MLRO decision rights even if the investigator sits elsewhere. If a global screening service blocks a payment for a subsidiary, the case record should identify which sanctions or AML rule applied to that subsidiary rather than treating the group as one undifferentiated institution.

This distinction becomes especially important when supervisors ask for evidence. A group dashboard may show that monitoring is performed centrally, but a host supervisor may want to know whether the local board understands its risk, whether local customers are covered, whether local typologies are reflected, whether local reporting is timely, and whether the local entity can access its own evidence. Centralisation does not remove local accountability.

Build the operating model in layers

A practical global-to-local model can be designed in five layers.

The standards layer contains FATF, Basel, applicable regional frameworks and the group's risk appetite. It provides principles and common terminology.

The obligation layer contains binding local law, regulation, licences, FIU requirements and documented supervisory expectations, effective-dated by jurisdiction and legal entity.

The policy layer translates those sources into group standards and local addenda. It establishes mandatory control objectives and approved variations.

The control layer turns policy into customer journeys, system rules, operational procedures, case workflows, decision rights and reporting.

The evidence layer proves execution through data lineage, case records, approvals, audit logs, testing results, quality assurance, management information and issue remediation.

A failure between any two layers creates what auditors often describe as a traceability gap. A law may change but the policy is not updated. A policy may change but system rules stay old. A system may change but test coverage does not prove the local requirement. A control may operate but evidence is not retained. The operating model should make those links explicit so that regulatory change can be traced from source to production and then to assurance.

Group-wide information sharing: necessary but not unlimited

A global financial-crime programme needs information to move across the group. Criminal activity does not respect entity boundaries. A customer may hold accounts in several countries, use one subsidiary for payments and another for investments, or move funds between group entities. A central compliance function cannot assess the total risk if each entity sees only its own fragment.

FATF Recommendation 18 supports group-wide sharing for AML/CFT purposes and its Interpretive Note specifically contemplates group compliance, audit or AML/CFT functions receiving customer, account and transaction information from branches and subsidiaries when necessary. It also stresses safeguards for confidentiality and use of the information, including preventing tipping-off. FATF's information-sharing guidance further explains the value of group-wide sharing while recognising legal and privacy barriers.

This is where simplistic global architecture can fail. A central data lake may be technically convenient, but legal permission to transfer customer, transaction, STR-related or investigative information can vary. Data-protection law may require a lawful basis, purpose limitation, minimisation, retention controls, cross-border transfer safeguards or local storage. Banking secrecy may restrict disclosure. STR confidentiality can impose even more specific limits. FATF Recommendation 2 also recognises the need for compatibility between AML/CFT requirements and data protection/privacy rules.

The solution is not to stop sharing. It is to make sharing purpose-based and governed. The bank should classify information by sensitivity and use case, determine which data elements are necessary for which group functions, identify legal permissions and restrictions, and build technical controls accordingly. Some data may be centrally replicated. Some may be tokenised or pseudonymised. Some may be accessed through federated queries without leaving the country. Some may require local approval before release. Some may not be shareable at all.

A useful information-sharing register records the source jurisdiction, receiving entity, data category, purpose, legal basis, retention period, access roles, transfer mechanism and any restrictions. That register can then be translated into technical access control rather than remaining a legal memo disconnected from systems.

Local suspicious-activity reporting cannot be reduced to a global workflow status

Suspicious transaction or activity reporting is one of the clearest examples of why global and local roles must be separated. FATF Recommendation 20 establishes the international expectation that financial institutions report promptly to the FIU when they suspect or have reasonable grounds to suspect that funds are criminal proceeds or related to terrorist financing. But the precise threshold, terminology, process and legal treatment are implemented domestically.

A global case-management platform can support intake, evidence collection, investigation, escalation and governance. It can provide a consistent case narrative structure and help identify linked activity across countries. It should not assume one global filing decision, one reporting deadline or one permissible sharing model.

The local reporting decision should identify the reporting entity, competent FIU, legal threshold, decision maker, filing date, confidentiality status and any follow-up obligations. Where information from another group entity contributes to the case, the system should preserve provenance and any restrictions on onward use. If the fact of filing cannot legally be disclosed to certain users or jurisdictions, role-based access and notification design must reflect that.

This is also why local MLRO independence and authority matter. A group financial-crime head may set standards and challenge decisions, but local law may assign personal or statutory responsibilities to a local officer. The operating model must make clear where group escalation ends and statutory authority begins.

A global risk assessment needs local granularity

Group-wide risk assessment is not achieved by adding together local risk scores. The group needs a consolidated view of customer types, products, channels, countries, legal entities, transaction flows and control effectiveness. At the same time, local entities need enough detail to understand the risks created by their own market, customer base, distribution model and criminal environment.

The February 2025 FATF changes to Recommendation 1 strengthened the language around proportionality and lower-risk measures. The current FATF framework expects higher-risk situations to receive stronger measures while countries allow and encourage simplified measures where lower risk is established. A group operating model should therefore avoid turning headquarters conservatism into indiscriminate friction everywhere. The global baseline must be strong, but it should still permit evidence-based local calibration within approved boundaries.

This matters for financial inclusion. A global rule created for one market can unintentionally exclude legitimate customers in another market where identity infrastructure, income documentation or payment behaviour differs. FATF's June 2025 financial inclusion guidance reinforces the need for proportionate controls rather than treating risk-based compliance as a zero-risk exercise. A mature group should be able to explain why a simplified local measure remains within the global framework and why a higher-risk local scenario receives enhanced controls.

The group assessment should also identify cross-border concentration. A product may appear moderate risk within each entity but create high group risk when the same intermediary, correspondent, merchant network or customer group spans several jurisdictions. Central analytics can reveal those patterns if the information-sharing model permits them.

Policy architecture: one core, controlled local addenda

A workable policy hierarchy normally has a small number of levels. The group policy defines principles, governance and minimum control expectations. Group standards provide more detailed mandatory requirements for domains such as CDD, screening, monitoring, investigations and reporting. Local addenda capture legally required differences and formally approved local enhancements. Procedures tell staff exactly how to execute the control.

This hierarchy prevents two extremes. If every local rule is inserted into the global policy, the document becomes unreadable and changes constantly. If all detail is pushed into local procedures, the group loses a coherent baseline and cannot compare performance. The goal is traceability without duplication.

Each local addendum should identify its parent group requirement and explain the difference. "Local law applies" is not enough. The addendum should say whether the local rule is stricter, different but equivalent, additional, or conflicting. It should cite the source, state the effective date and identify the impacted control. When the source changes, the addendum should be reviewed automatically through the regulatory-change process.

Retired rules also matter. A bank needs to know what standard applied on the date a customer was onboarded or a transaction was reviewed. Effective-dated policy and rules help reconstruct historical decisions. Overwriting old thresholds or deleting an old legal interpretation destroys auditability.

Control ownership and the three lines

The first line owns execution and the risk created by the business. That may include onboarding teams, operations, product teams and business management. The second line sets financial-crime policy, advises, challenges, monitors and escalates. Internal audit independently assesses design and effectiveness. In practice, global-to-local models become confused when central operations, shared services and compliance functions perform overlapping tasks.

A RACI chart helps, but decision rights are more important than labels. For every significant control, the bank should know who sets the global requirement, who interprets local law, who approves local deviation, who operates the control, who owns the technology, who signs off testing, who monitors performance, who accepts residual risk and who reports material issues to senior management or supervisors.

The Basel Committee's consolidated AML/CFT guidance, published in its current consolidated form in January 2026, emphasises group-wide risk management, a group AML/CFT officer, consistent policies across branches and subsidiaries, proactive sharing of higher-risk customer information and supervisory visibility into local implementation. That does not prescribe one corporate organisation, but it supports the principle that a global group needs accountable central oversight rather than merely a collection of local programmes.

The control architecture links group standards, local legal interpretation, shared technology, local execution and independent assurance without losing legal-entity accountability.

Technology architecture: common services with jurisdiction-aware rules

The technology problem is similar to the policy problem. Fully separate local platforms produce duplication, inconsistent controls and poor group intelligence. A single global platform hard-coded for one jurisdiction creates legal and operational errors elsewhere. The strongest architecture usually uses common services with jurisdiction-aware configuration.

A global customer-risk service can use common data definitions while allowing local factors and weighting. A screening platform can share matching technology but load different lists and rule sets according to legal entity. A transaction-monitoring platform can share scenarios while applying local thresholds, products and typologies. A case platform can provide one investigation framework while enforcing local reporting permissions and confidentiality.

The key design object is applicability. Every rule should know to which entity, product, channel, customer type, country and effective period it applies. If applicability is implicit in code branches or manual instructions, changes become risky. A rules catalogue should make those conditions visible and testable.

Configuration also needs governance. A local compliance team should not be able to weaken a global control in production without approval. Equally, headquarters should not deploy a global rule change that breaches local law because local review was skipped. Changes need maker-checker controls, impact assessment, testing, release evidence and rollback capability.

For a bank operating dozens of entities, this is essentially policy-as-data. It does not mean replacing legal judgement with code. It means representing approved legal and policy conclusions in structured form so systems can execute them consistently.

Data lineage is part of legal compliance

A global AML/CFT programme relies on data from core banking, payments, cards, securities, trade finance, customer master data, digital channels, screening vendors and external intelligence. The same logical field can mean different things in different countries or systems. A country field might mean nationality, residence, incorporation, booking location, merchant location, IP location or payment destination. Using the wrong interpretation can create a false local rule trigger.

The operating model should therefore map data lineage from source to control. For each critical field, teams should know the source system, business definition, transformation, quality checks, timing, permitted use and consuming controls. If a local law requires a particular attribute that the group model does not collect, that is a control gap, not merely a data issue.

Cross-border data movement adds another layer. A shared service may need customer information to investigate an alert, but the source jurisdiction may restrict transfer of some data. Architects should design for selective disclosure, attribute-level access, local processing or federated analysis where necessary. The legal restriction should be represented in the data-access model so investigators do not rely on informal workarounds.

Evidence must also survive change. If a risk rating was calculated using model version 7 and local rule set 2026.3, the case should retain those versions. Otherwise a later reviewer may see only the current rule and be unable to understand why the original decision was reasonable.

The evidence map shows how legal sources, local interpretations, rule versions, source data, case decisions and assurance records must remain linked through time.

Regulatory change is the heartbeat of the model

A global-to-local programme fails if it works only on the day it is designed. Law, sanctions, FATF standards, supervisory guidance, national risk assessments, products and criminal methods change continuously. The operating model needs a controlled pathway from external change to production.

The process starts with horizon scanning and source ownership. A local legal or compliance function identifies a change and records the authoritative source, publication date, effective date and affected entities. The group assesses whether the change affects global standards or only local implementation. Policy owners translate the change into requirements. Control owners identify impacted procedures, data, rules, training and management information. Technology teams implement and test changes. Compliance validates readiness. After go-live, assurance confirms the intended outcome.

The critical distinction is publication date versus effective date. A law may be published months before it applies. A supervisor may expect earlier preparation. A system rule may need phased deployment. The change record should therefore track regulatory publication, internal decision date, implementation deadline, production date and any transitional period separately.

The EU AML package is a useful current example of why this matters. Regulation (EU) 2024/1624 establishes directly applicable AML/CFT requirements that generally apply from 10 July 2027. It also contains group-wide policy and information-sharing provisions. The AML Authority, AMLA, is preparing a harmonised supervisory framework and, according to its current public timeline, will select entities for direct supervision in 2027 and begin direct supervision in 2028. A bank operating in the EU therefore has to distinguish what is already legally in force, what begins to apply in 2027, and what supervisory arrangements start in 2028. Treating the whole package as either "already applicable" or "future only" would both be inaccurate.

Conflicts of law need an explicit exception process

The hardest cases are not those where local law is stricter. They are those where the group cannot lawfully implement its normal control. FATF Recommendation 18 anticipates this. If host-country law prevents implementation of home-country AML/CFT measures, the group is expected to apply appropriate additional measures and inform the home supervisor; if risk remains insufficiently mitigated, further supervisory action may be necessary.

A bank should therefore maintain a legal impediment register, not rely on email chains. Each item should describe the group requirement, host restriction, legal analysis, affected data or control, risk created, compensating measures, accountable owner, approval, supervisor communication where required, review date and exit plan.

Compensating controls must address the actual risk. If customer data cannot leave the country, a reasonable mitigation may be local screening and monitoring with group-level aggregated risk indicators, federated queries or controlled case escalation. If the group cannot receive STR-related information, it may still receive other risk information that local law permits. The solution should not be a ceremonial statement that "local law prevents compliance" with no analysis of alternatives.

Legal impediments can change. Privacy rules may be clarified, a new transfer mechanism may become available, a regulator may issue guidance, or technology may enable local processing. Exceptions should therefore expire or be reviewed rather than becoming permanent architecture by inertia.

Supervisory relationships are both local and group-wide

Cross-border banks face home supervisors, host supervisors and sometimes multiple specialised authorities. The Basel Committee's AML/CFT guidance emphasises cooperation and information exchange between prudential and AML/CFT supervisors and recognises the need for cross-border coordination. A bank should assume that supervisors will compare the group's story with the local entity's story.

If group compliance says a control is global and consistent but the local entity cannot explain how it works, that is a governance weakness. If the local team describes a special process that group risk management does not know exists, that is also a weakness. The operating model should maintain one evidence base with local views, not separate narratives prepared for each inspection.

Supervisory findings should feed back into group design. A local finding may reveal a weakness that exists elsewhere. The issue-management process should ask whether the root cause is local or systemic and whether a horizontal review is needed across other entities. This is especially important for data gaps, ineffective scenarios, weak beneficial ownership controls or delayed reporting, which often arise from shared systems.

Management information should show control health, not just activity

A global dashboard that reports numbers of alerts, cases and filings can look sophisticated while hiding control failure. Good management information asks whether obligations are implemented, whether controls work, whether local exceptions are increasing and whether the group can see material risk.

Useful measures include overdue regulatory changes, unimplemented local obligations, open legal impediments, policy exceptions, control-test failures, data-quality defects, aged alerts, late reporting, repeat audit findings, local rule overrides, model coverage gaps, high-risk customer concentrations and remediation status. Trends should be segmented by legal entity and risk, not only aggregated to a group total.

A global metric also needs a common definition. If one country counts an alert when it is generated and another when it enters a case queue, comparing closure times is misleading. Metric dictionaries are therefore part of the operating model.

Senior management should be able to see where the group standard is not operating as intended and what risk that creates. Local boards should see the same information filtered to their entity, plus any group dependencies they rely on. This supports both enterprise oversight and local accountability.

Operational failure modes

Several recurring failures appear in global programmes.

The first is policy-only globalisation: the group publishes standards but local controls are not mapped or tested. Evidence is a signed policy attestation rather than proof of implementation.

The second is local autonomy without group visibility: each country meets its own rules, but the group cannot see cross-border customer or transaction risk, compare control quality or enforce minimum standards.

The third is centralisation without legal design: investigation, data or decisioning is moved to a global hub without understanding local statutory roles, confidentiality or data-transfer restrictions.

The fourth is configuration drift: global platforms begin with common rules but local changes accumulate without governance, producing hundreds of undocumented variants.

The fifth is regulatory-change breakage: legal updates are captured in spreadsheets, but there is no traceable link to system changes and tests. A policy is marked complete while production still uses old logic.

The sixth is false harmonisation: the group uses the same risk thresholds everywhere for simplicity even though the local risk environment, product mix or legal threshold differs.

The seventh is over-compliance by default: every uncertainty is resolved by using the most restrictive rule globally, creating unnecessary customer exits and financial exclusion without evidence that the control is proportionate.

The eighth is local-law exception as a loophole: teams claim a conflict without formal legal analysis, compensating control or time-bound review.

Each failure has the same root cause: the bank cannot trace from obligation to control to evidence across the group.

Practical case: one customer, three countries, one group

Consider a corporate customer headquartered in Country A with operating subsidiaries in Countries B and C. The group bank provides a current account in A, trade finance in B and payment services in C. The customer is rated medium risk locally in each entity. A transaction-monitoring alert in C identifies payments to a newly formed intermediary. Separately, the trade-finance team in B has unusual invoice documentation involving the same intermediary.

If the bank operates only locally, neither team sees enough information to understand the pattern. A mature group model allows relevant customer and transaction risk information to be shared, subject to legal permissions. The group case view links the intermediary, payment activity and trade documents and raises the customer to enhanced review.

Now add a constraint: Country B restricts transfer of certain customer documents outside the jurisdiction. The correct response is not to ignore the B evidence or upload everything to a global case platform anyway. The local team can retain the protected documents, provide an approved summary or risk indicator, and make specified evidence available through a controlled local review process if group compliance requires it. The information-sharing design follows the legal restriction while preserving enough group intelligence to manage risk.

Suppose the combined facts create suspicion. Each relevant legal entity then applies its own reporting law. Country C's MLRO may file with its FIU. Country B may have a different threshold or reporting route. The group should coordinate risk management without assuming one filing automatically satisfies all local duties or that the fact of one filing may be shared without restriction.

The case demonstrates the essence of global-to-local AML/CFT: share what the law permits, apply the right local obligation, preserve group visibility, and document why the model differs where it must.

What business analysts should specify

A BA working on this operating model should be able to convert policy into structured requirements. Start with scope: legal entities, countries, products, channels and user roles. Define the source-of-truth obligation register and how rules inherit from global to regional to local level. Define effective dating and precedence. Define which fields are global and which are local extensions.

Then specify decisioning. What determines jurisdiction? Is it booking entity, customer residence, transaction country, service location or multiple factors? Which rule sets apply when a transaction crosses entities? What happens when two rules conflict? Which outcomes require local approval? Which decisions can be made centrally?

Specify data sharing explicitly. Which data categories may cross borders? Which users can access them? What happens when data is restricted? Is there a federated or local-processing alternative? How is access logged? How is STR-related information protected?

Specify regulatory-change behaviour. Can a future-dated rule be loaded in advance? Does the system activate it automatically on the effective date? Can a rollback restore the prior version? Are open cases re-evaluated when rules change? Are historical decisions preserved against the rule version used at the time?

Specify evidence. Every decision should expose the applicable entity, rule, version, data used, decision maker, timestamp, rationale and downstream action. For exceptions, capture legal basis, compensating controls, approval and expiry.

What architects should design

Architects should avoid building country logic directly into multiple applications. Centralise rule metadata and expose it through controlled services where practical. Keep identity, customer, transaction and case data models stable enough for group analytics while supporting local extensions.

Design for data residency from the start. A global analytics architecture may use local data zones with governed federation rather than a single physical repository. Encryption, attribute-level access and data masking should support legal restrictions but not be used as substitutes for legal analysis.

Separate the control plane from the data plane. A central policy service can distribute rule versions and configuration while sensitive customer data remains local. This can help the group enforce standards without requiring every data element to move internationally.

Build observability. The bank should know which rule version is active in each entity, whether deployments succeeded, whether data feeds are complete and whether local overrides exist. A control that depends on configuration no one can inventory is not genuinely global.

What testers should prove

Testing should go beyond happy-path functionality. For each jurisdiction, testers need positive cases that trigger local requirements and negative cases that prove unrelated entities are not affected. They should test effective dates, legal-entity routing, product scope, local thresholds, group minimums and conflict precedence.

Cross-border tests should verify that permitted information is shared and restricted information is not. Role tests should prove local MLRO decisions cannot be overridden by unauthorised group users. Historical tests should confirm an old case still displays the rule version that applied at the time.

Regulatory-change regression should include future-dated rules, emergency changes, partial deployment failure and rollback. Data-quality tests should simulate missing jurisdiction codes, duplicate customer identifiers and inconsistent entity mapping because those defects can send a customer through the wrong legal path.

Exception testing should be explicit. If a jurisdiction is approved to operate a compensating control because the normal group process is legally blocked, test that the alternative control actually executes and that its evidence reaches the required oversight function.

Governance and assurance

The global financial-crime committee should own the overall framework and material exceptions. Local legal entities should retain clear accountability for compliance with their own law. A global MLRO or group financial-crime officer can coordinate standards, risk assessment and oversight, while local officers retain statutory responsibilities where applicable.

Second-line monitoring should test whether local controls remain aligned with group standards and local law. Internal audit should assess both design and effective execution, including the quality of information sharing, exception management and regulatory-change traceability. Assurance should sample real cases rather than rely only on policy attestations.

Supervisory cooperation is increasingly important. The Basel Committee's 2020 revisions on supervisory cooperation and its current consolidated 2026 guidance emphasise information exchange between prudential and AML/CFT supervisors in both domestic and cross-border contexts. A bank should expect questions about how the home function oversees foreign operations, how host concerns are escalated and how information reaches decision makers.

Governance separates group standard setting, local legal accountability, operational execution, change ownership and independent assurance while keeping escalation paths visible.

A practical design checklist

Before calling a global-to-local model mature, a bank should be able to answer these questions without assembling a special task force:

  • Which group standards apply to every branch and majority-owned subsidiary?
  • Which local requirements are stricter, additional, different or conflicting?
  • Which legal entity owns each customer and regulatory obligation?
  • Which AML/CFT information may be shared across the group, for what purpose and under what safeguards?
  • Which controls are centralised, which are local and who remains accountable for the outcome?
  • Which rule version was active for a historical decision?
  • Which legal impediments prevent full group implementation, and what compensating controls exist?
  • How does a regulatory change move from source text to policy, system, training, testing and assurance?
  • Can group management see local control failures and can local boards see their dependence on group services?
  • Can the bank prove all of this with evidence rather than explanation alone?

If the answer to those questions is clear, the operating model is doing its job. If the answer relies on personal knowledge, email history or undocumented local workarounds, the programme is fragile even if no regulator has yet found the weakness.

Key takeaways

A global AML/CFT programme is not a choice between centralisation and local autonomy. It is a controlled translation mechanism. FATF sets an international baseline, group policy establishes minimum standards, local law determines legally binding obligations, and the bank's operating model connects those layers to executable controls.

Recommendation 18 makes group-wide programmes and information sharing a core expectation, while also recognising that host-country law can limit implementation. Basel guidance reinforces the need for group-wide oversight, consistent policies, local accommodation and home-host supervisory visibility. Current EU reforms show how a regional framework can add another layer, with harmonised rules applying from 2027 and AMLA preparing direct supervision from 2028.

The strongest model is traceable: source to obligation, obligation to policy, policy to control, control to data and workflow, and workflow to evidence and assurance. It is jurisdiction-aware without becoming fragmented, global without becoming legally blind, and risk-based without treating proportionality as a reason to weaken controls.

For practitioners, the test is simple. A bank should be able to explain what rule applied, why it applied to that entity and activity, how the control executed, what information was shared or restricted, who made the decision and what evidence proves it. That is what turns a global AML/CFT policy into a real operating model.

Operational deep dive: making the global model work in real entities

The base chapter set out the architecture: a group baseline, a local legal overlay and a controlled way to handle genuine conflicts. This deep dive focuses on the operational questions that make or break the model after policy is approved. These are the questions raised by local MLROs, shared-service investigators, data architects, product owners and supervisors when one customer, one control or one investigation crosses legal entities.

The obligation-to-control matrix

A useful implementation artefact is an obligation-to-control matrix. It should not be a spreadsheet that exists only for an audit. It should act as a structured catalogue linking authoritative requirements to the controls that implement them.

Each obligation record should identify the source authority, legal instrument or supervisory source, jurisdiction, affected legal entity, product or activity scope, effective date, requirement type, control objective and evidence expected. It should then point to the global standard, local addendum, procedure, system rule, operating team, test case and management information that demonstrate implementation.

The value comes from traceability. Suppose Country X changes its beneficial-ownership verification rule. The bank should be able to query the catalogue and identify every onboarding journey, periodic-review flow, corporate data field, screening process, customer form, training module and test pack affected by the change. If impact assessment still depends on asking experienced staff who happen to remember where the rule is used, the operating model is not under control.

The matrix should also distinguish a legal obligation from a policy choice. A group may decide to collect source-of-wealth evidence more widely than local law requires. That is a legitimate risk decision, but it should be labelled as a group standard rather than falsely attributed to the local regulator. Accurate provenance matters because future change decisions depend on knowing why a control exists.

Rule precedence in practice

A jurisdiction-aware rules engine needs a precedence model that humans can understand. One practical pattern is to evaluate rules in this order: legal prohibition; mandatory local requirement; mandatory group minimum; approved local enhancement; risk-based configuration; operational preference. The exact hierarchy will differ by institution, but mandatory law should not be mixed with optional tuning.

Consider a customer review frequency. The group standard might require review every three years for medium-risk corporate customers. Local law in one country might require every two years. That is a simple stricter overlay. Another country may not prescribe a fixed cycle but require event-driven review when specified triggers occur. The system may therefore need both a two-year timer in one entity and a global event-driven mechanism in all entities. "Take the strictest number" does not solve the second case because the rules are different in kind.

Now consider suspicious-activity reporting. The group may define a common investigation quality standard, but the filing threshold and confidentiality model may be statutory and local. A global case platform should not use precedence logic to decide that one country's filing rule is "stricter" and therefore suitable for every entity. It should route the case to the correct local decision authority and preserve the legal basis.

This is why rule metadata should include rule_type, jurisdiction, legal_entity, scope, effective_from, effective_to, priority, decision_owner and source_reference. The technology can then execute a policy conclusion that lawyers and compliance officers have already approved, rather than attempting to invent legal hierarchy through code.

Central operations with local accountability

Many global banks centralise onboarding operations, screening review, transaction-monitoring investigations or quality assurance. Centralisation can improve consistency and specialist expertise, but it creates a frequent governance misunderstanding: the team doing the work is not necessarily the entity carrying the obligation.

A shared-service investigator in one country may review an alert for a customer of a bank licensed in another country. The case should therefore carry the booking entity and local control context from the moment it is created. The investigator needs the correct local procedure, thresholds and escalation options. The local regulated entity needs access to the case evidence and remains accountable for legally required outcomes.

Service-level agreements should reflect this distinction. They should define not only turnaround time but also decision rights, data access, quality expectations, local escalation and outage behaviour. If the shared service cannot access legally restricted information, that limitation should be designed into the workflow. If the service fails, the local entity needs a continuity plan because it cannot tell its supervisor that a group hub outage removed its regulatory responsibility.

Quality assurance should sample by legal entity and risk. A global 98% quality score can hide a serious weakness if one small jurisdiction has repeated reporting or CDD defects. Local boards and MLROs need entity-level evidence even where production is centralised.

Information sharing: separate the purpose from the transport

Financial-crime teams often discuss information sharing as a technical question: can the data be copied to the group data lake? The better question is: what information is needed for what AML/CFT purpose, and what lawful mechanism can support that purpose?

FATF Recommendation 18 and its Interpretive Note support group-wide AML/CFT information sharing, including customer, account and transaction information when needed for group risk management. The same text also calls for confidentiality safeguards and recognises national decisions about the scope of sharing. Recommendation 2 explicitly highlights compatibility with data-protection, privacy and similar requirements such as data localisation.

A bank can therefore design several patterns instead of one all-or-nothing data transfer. Full replication may be lawful for ordinary KYC data in some jurisdictions. Pseudonymised risk attributes may be enough for central analytics in another. Federated analytics can send a query to a local data store and return a controlled result. A local investigator can provide a structured risk summary where raw documents cannot move. Highly sensitive STR-related information may require separate access rules from ordinary transaction-monitoring data.

The architecture should record not only where data is stored but also why it is processed, who may receive it, what restrictions apply and how access is logged. That helps legal teams review the real data flow rather than approve a vague statement that "AML data is shared globally."

What to do when host law blocks the group standard

A genuine legal impediment should trigger a formal sequence.

First, document the exact group requirement that cannot be implemented. Second, obtain an approved local legal interpretation describing the host-country restriction and its scope. Third, assess the financial-crime risk created by the gap. Fourth, identify feasible additional measures. Fifth, determine whether home-supervisor notification or another regulatory engagement is required. Sixth, approve the residual risk at the correct level. Finally, review the exception periodically and close it when the impediment no longer exists.

The additional measure should match the risk. If a local secrecy rule prevents central access to raw customer files, the bank may use local quality assurance plus central review of permitted metadata, aggregate risk indicators and sampled evidence through an approved mechanism. If a country prevents some STR information from leaving the jurisdiction, group risk management may still receive other legally shareable facts about the customer's risk. If local technology cannot support a global real-time screening control, an interim local service may be used while remediation is delivered.

The important point is that "local law" is not itself a compensating control. It explains why the normal model cannot be used. The bank still has to manage the resulting risk.

Effective dating and historical reconstruction

Global policy platforms often fail because they focus only on the current rule. Financial-crime investigations and regulatory reviews frequently look backward. A supervisor may ask why a customer was accepted two years ago, why a payment was released before a sanctions change, or whether a periodic review was completed under the correct standard at the time.

Every material rule should therefore have an effective period. Systems should preserve the version used for a decision, not dynamically reinterpret old cases using today's configuration. This applies to risk-rating models, PEP definitions, country-risk classifications, onboarding thresholds, review cycles and reporting logic.

Regulatory change can also require lookback analysis. If a rule change reveals that historical cases were treated incorrectly, compliance needs to identify the affected population. That is far easier when the bank can query which customers or transactions were processed under a specific rule version.

This creates a direct BA requirement: do not store only the final status. Store the rule identifier, version, input evidence and decision timestamp. The extra data turns a workflow into an auditable control.

Local typologies inside global monitoring

A global transaction-monitoring library can improve consistency, but local risk has to influence design. Predicate offences, payment methods, customer sectors and criminal methods vary by market. A scenario that is useful in one country may create meaningless alerts in another, while a locally important typology may be invisible to a generic group rule.

The operating model should therefore distinguish global scenarios from local scenarios and locally calibrated versions of global scenarios. Global governance should set minimum coverage for material risks and define tuning standards. Local compliance should contribute country-specific risk intelligence, FIU guidance, law-enforcement typologies and market knowledge.

Calibration decisions should be documented and periodically reassessed. A local threshold should not be lower merely because a regulator once asked a question, nor higher because alert volumes are inconvenient. It should be linked to risk, data distribution, effectiveness testing and operational capacity.

Where the same customer or network spans entities, group analytics can identify patterns that local monitoring cannot. The model should define how those group insights become local alerts or cases without bypassing local decision rights.

Mini case: regulatory change across a shared platform

Assume a banking group uses one onboarding platform for six countries. A new rule in Country D changes the information that must be obtained for certain legal arrangements and becomes applicable in four months. The other five countries are unaffected.

The local compliance team records the authoritative source, affected customer population and effective date in the obligation register. Group policy determines that the change is a local legal overlay rather than a change to the global minimum. The BA maps the new requirement to the onboarding data model and discovers that one required relationship type is not currently represented.

The architect adds the relationship type to the common data model because it is useful without harming other countries, but configures the field as mandatory only for the affected Country D entities and customer types. The user interface shows the field only where relevant. The rule service activates the requirement on the effective date. Existing in-scope customers are queued for a controlled remediation campaign according to the legal transition plan.

Testing covers Country D positive cases, unaffected-country negative cases, the effective-date boundary, API onboarding, branch onboarding and migrated customers. Compliance signs off evidence before release. After implementation, management information confirms that all affected new customers provide the required information and that remediation is progressing.

This is what good global-to-local implementation looks like. The bank reuses common architecture but does not force a local rule onto unrelated entities. The local requirement is traceable to law, production configuration and testing. Future reviewers can reconstruct the decision.

The operating model during an incident

Normal governance is not enough. A group needs to know how local obligations operate during major incidents: screening vendor outage, case-platform failure, sanctions-list feed failure, cyber incident or loss of access to a shared-service centre.

Business continuity should be jurisdiction-aware. A global incident commander can coordinate restoration, but the impact assessment should identify which legal entities are unable to meet time-sensitive requirements. A reporting deadline in one country may require a different contingency response from an ordinary monitoring delay elsewhere.

Fallback controls should be pre-approved. If screening uses cached lists during a vendor outage, define how current those lists must be and which products may continue. If cases are handled manually, preserve minimum evidence and reconcile them back into the system. If data cannot cross borders because a regional network link is unavailable, local operations should know whether they can continue safely or must restrict activity.

Post-incident review should ask whether any regulatory notifications, retrospective screening, lookbacks or customer remediation are required. Operational resilience and AML/CFT are connected when the unavailable service is itself a regulatory control.

Assurance questions that expose weak models

Reviewers can quickly test maturity by asking for one obligation and following it end to end. Show the source. Show the interpretation. Show the policy requirement. Show the production rule. Show a passed test. Show a real case where the control executed. Show the management information. Show who owns the issue if any element fails.

Then reverse the test. Pick a production rule and ask why it exists. If nobody can link it back to an approved requirement, the bank may be operating legacy compliance logic without a current rationale.

A third test is cross-border. Choose one customer with relationships in multiple entities and demonstrate what each entity can see, what group compliance can see, what is restricted, and why. The explanation should match actual access controls rather than policy wording alone.

Finally, test an exception. Ask for the legal impediment, compensating control, approval, review date and evidence that the mitigation works. Mature programmes make exceptions visible. Weak programmes hide them in local knowledge.

The global-to-local model is successful when those tests can be answered from controlled evidence. Its purpose is not to eliminate local difference. Its purpose is to make every necessary difference deliberate, lawful, risk-based and explainable.

Advanced practice: BA, architecture, testing and assurance

A mature global-to-local AML/CFT model should survive change without relying on personal memory or manual workarounds. This section converts the policy ideas into delivery controls for shared platforms serving multiple legal entities.

Resolve jurisdiction explicitly

Financial-crime systems should not treat country as one universal attribute. A customer can be incorporated in one country, resident in another, booked to a legal entity in a third and send a payment to a fourth. The correct control set can depend on several of those facts.

A BA should define a jurisdiction resolver using inputs such as booking entity, branch, product, customer residence or incorporation, service location, transaction origin and destination, currency and channel. The output should be applicable rule-set identifiers and data-handling conditions, not a vague country label. Legal and compliance owners should approve this logic because it encodes policy conclusions, and testers should include cases where different jurisdiction attributes point in different directions.

Treat configuration as a controlled asset

Global AML/CFT platforms depend on configuration: risk weights, country tables, review cycles, scenario parameters, screening rules, approval levels and reporting routes. Material configuration needs a rationale, owner, approver, test evidence, effective date and deployment record. Local overrides should be visible and classified as legally required, risk-based or temporarily approved.

This prevents configuration drift after acquisitions, migrations or local tuning. A group dashboard should be able to show which entities differ from the baseline and why.

Build regulatory change as a traceable flow

A regulatory change should move through controlled states: authoritative source, applicability assessment, structured obligation, impact analysis, policy/control change, implementation, testing, readiness approval and post-implementation assurance. An item should not be marked complete merely because a policy document was updated. If the legal change affects data, a system rule, a procedure or training, those dependencies must also close or have an approved exception.

For urgent changes, the timeline may compress from months to hours, but the same evidence should exist: source, scope, rule change, validation, owner and communication.

Test inheritance, overrides and legal conflicts

Testing should have three layers. Global component tests prove the common service works. Jurisdiction configuration tests prove local overlays and overrides are correct. End-to-end entity tests prove a real customer or transaction reaches the correct service with the correct legal context.

Negative testing is equally important. A local rule must not leak into unrelated entities. A future-dated rule must not trigger early. An expired exception must not remain active. A user without authority must not access restricted case information.

Active legal impediments also need test cases. If raw KYC documents must remain local, prove the global platform cannot retrieve them and that the approved alternative, such as a structured summary or federated review, still works. If investigation information cannot be transferred, test both the restriction and the local escalation path.

Design access around purpose and sensitivity

A global case platform should use purpose-based access. An investigator may need transaction data without needing access to a locally filed STR. Group compliance may need cross-entity risk information without every identity document. Where cross-border transfer is restricted, the workflow should make the limitation visible so a reviewer knows how to obtain an approved summary or local review rather than assuming no evidence exists.

Practical acceptance criteria

A strong delivery story should prove that the system resolves the correct entity and rule set; inherits the group baseline unless an approved local rule changes the outcome; records local overrides with source and effective period; enforces data-sharing restrictions; preserves local statutory decision rights; records the rule version used; supports future-dated changes; surfaces failed deployments as control incidents; and invokes approved compensating controls for legal impediments.

These criteria are more useful than a requirement such as "the system shall comply with local AML laws" because they can be tested and evidenced.

Final practitioner test

Before releasing a cross-border AML/CFT control, take one realistic customer and walk the entire journey. Identify the regulated entity, resolve the applicable rules, distinguish group requirements from local law, show what information may be shared, trigger a higher-risk event, route it through investigation, show the local decision authority, change a rule's effective date, reconstruct the historical decision and simulate an active legal impediment.

If the platform, people and evidence tell the same story, the operating model is coherent. If the answer changes depending on which team explains it, the design still relies on organisational memory rather than controlled implementation.

Accuracy boundary

The FATF Recommendations are international standards that countries implement through domestic frameworks; they are not presented in this chapter as a single directly enforceable global law. The Basel material is supervisory guidance and sound practice rather than a substitute for local legal requirements. EU Regulation 2024/1624 is used only as an EU example: its main application date is 10 July 2027, while AMLA's current public timeline anticipates selection of directly supervised entities in 2027 and the start of direct supervision in 2028. Those EU dates and requirements should not be generalised to non-EU jurisdictions.

References and further reading

These sources were used to validate the global-to-local operating principles in this chapter. FATF and Basel material provides international standards and supervisory guidance; jurisdiction-specific law still has to be identified and applied by the relevant legal entity.