Regulators, Supervisors and Law Enforcement

Financial-crime work becomes much easier to understand once one question is answered correctly: which public authority is acting, under what power, for what purpose? Banks routinely interact with regulators, supervisors, financial intelligence units, police, prosecutors, courts, sanctions authorities, tax agencies, customs authorities and central banks. These bodies may cooperate closely and, in some countries, several functions may sit inside the same institution. That does not make their powers interchangeable.

A supervisor may ask whether a bank’s transaction-monitoring framework is effective. A financial intelligence unit may receive a suspicious transaction report and request additional information. Police may obtain records through a subpoena, production order, warrant or another lawful instrument. A prosecutor may seek restraint or confiscation. A sanctions authority may require an asset freeze, receive reports, issue licences or investigate a suspected sanctions breach. The same customer can therefore appear in several public-sector processes at the same time, each with a different legal basis, confidentiality rule, deadline and bank owner.

This chapter develops a practical operating model for those interactions. It is written for people who must turn law and supervisory expectations into processes, systems, controls and evidence: compliance specialists, investigators, operations staff, business analysts, architects, developers, testers, product owners and students. The central idea is simple: do not route an external authority request by the authority’s name alone; route it by function, legal power, jurisdiction, legal entity, information sensitivity and required outcome.

A mental model: standard, supervision, intelligence, investigation and enforcement

The public financial-crime ecosystem can be understood as five connected layers.

The first layer is standard setting and legislation. International bodies such as the Financial Action Task Force (FATF) establish global standards, but FATF itself does not write the domestic criminal law of each country and it does not supervise every bank in the world. FATF’s Recommendations are international standards that countries implement through their own legal, regulatory and institutional frameworks. As of June 2026, the FATF Recommendations remain organised as a comprehensive framework covering preventive measures, competent authorities, supervision, operational powers and international cooperation. Recommendations 26 and 27 address regulation and powers of supervisors; Recommendation 29 addresses financial intelligence units; Recommendations 30 and 31 address law-enforcement and investigative responsibilities and powers; Recommendation 40 addresses other forms of international cooperation.

The second layer is regulation and supervision. Legislatures and governments create obligations; regulators and rule-making authorities may translate them into binding regulations, technical standards, rules or guidance; supervisors assess whether regulated firms comply and whether their risk-management systems work in practice. The same body may regulate and supervise, but the distinction helps a bank understand whether it is dealing with a new rule, an examination, a request for information, a remediation direction or an enforcement action.

The third layer is financial intelligence. A financial intelligence unit, or FIU, is designed to receive and analyse suspicious transaction reports and other relevant financial information and disseminate the results of its analysis to competent authorities where appropriate. FATF Recommendation 29 provides the international standard. The Egmont Group describes FIUs as national centres for receipt and analysis of suspicious transaction reports and relevant information and for dissemination of analytical results. An FIU is therefore not simply “the police mailbox.” It occupies a specialist intelligence role.

The fourth layer is criminal investigation and prosecution. Law-enforcement agencies investigate offences using powers granted by domestic law. Prosecutors and courts play different roles depending on the legal system. Compulsory evidence gathering, warrants, production orders, subpoenas, account-monitoring orders, restraint and confiscation mechanisms are jurisdiction-specific. A bank should never assume that a term used in one country has the same legal effect in another.

The fifth layer is administrative or criminal enforcement and remediation. Supervisors may impose administrative measures, restrictions, fines or formal remediation. Law-enforcement and prosecutorial processes may lead to criminal charges or asset-recovery action. Sanctions authorities may take civil or criminal enforcement action under their own frameworks. The bank may therefore face institutional accountability for weak controls at the same time that a customer is being investigated for suspected criminal activity. Those are related but distinct risks.

This layered model prevents a common analytical error: treating “government interest” as a single event. A bank needs a different workflow for a thematic supervisory review, an FIU request for supplementary information, a police production order, a court restraint order and a sanctions-authority licence condition.

FATF’s architecture of competent authorities

FATF deliberately separates the roles of supervisors, FIUs and investigative authorities. That separation is useful even where one organisation performs more than one function.

Recommendation 26 requires financial institutions to be subject to adequate AML/CFT regulation and supervision. The risk-based approach means supervisors should understand the ML/TF risks of sectors and institutions and allocate supervisory attention according to risk. FATF’s risk-based supervision guidance explains that effective supervision requires access to relevant information, understanding of entity risk profiles, proportionate supervisory intensity and the ability to respond to weaknesses.

Recommendation 27 concerns supervisory powers. A supervisor needs sufficient authority to monitor or supervise compliance and to compel information relevant to that function. The exact legal powers vary by jurisdiction. Some supervisors can impose administrative sanctions directly; others may refer matters to another authority.

Recommendation 29 requires an FIU to act as a national centre for receipt and analysis of suspicious transaction reports and other relevant information and for dissemination of analytical results. The FIU should be able to obtain additional information from reporting entities and have access to the financial, administrative and law-enforcement information needed for its functions. Operational independence and information security are critical because FIUs receive highly sensitive intelligence.

Recommendations 30 and 31 address law-enforcement and investigative authorities. They deal with responsibility for money-laundering and terrorist-financing investigations and the powers needed to obtain evidence and trace, restrain or seize property as applicable. The important bank lesson is that an FIU’s intelligence role and a law-enforcement agency’s evidence-gathering role are not identical.

The FATF framework also expects domestic and international cooperation. A cross-border bank should therefore expect that information relevant to one legal entity or jurisdiction may become relevant to another authority through lawful supervisory, FIU or law-enforcement channels. That does not remove the bank’s own need to respect secrecy, privacy, localisation and suspicious-report confidentiality requirements.

Regulator and supervisor: similar words, different questions

In daily bank conversation, “regulator” is often used as shorthand for any authority overseeing the bank. For requirements work, that shorthand is dangerous.

A regulator or rule-maker asks, in effect, “what requirements apply?” A supervisor asks, “is this institution complying, and is its control framework effective in practice?” The same authority may answer both questions, but the bank’s evidence and response process are different.

Suppose a jurisdiction introduces new beneficial-ownership requirements. The regulatory-change process identifies the obligation, maps affected entities and products, changes KYC procedures, updates system fields and trains staff. Months later, the supervisor examines a sample of corporate customers. It may test not merely whether the policy was updated but whether beneficial owners were identified correctly, whether evidence was collected, whether exceptions were approved, whether screening was performed and whether higher-risk relationships received appropriate enhanced due diligence. A compliant policy with poor execution is still a weak control environment.

Supervisors increasingly test the full lifecycle of a control. For transaction monitoring, that can include the underlying risk assessment, data sourcing, scenario or model design, segmentation, thresholds, validation, alert generation, investigator quality, suspicious-reporting outcomes, tuning, issue management and management information. For sanctions screening, it may include list governance, data quality, matching configuration, alert handling, rescreening, ownership/control analysis and escalation. For KYC, it may include customer identification, verification, expected activity, beneficial ownership, PEP treatment, source-of-funds or source-of-wealth evidence and periodic or event-driven review.

This is why a bank cannot prepare for supervision only through policy teams. Supervisory evidence reaches into architecture, data engineering, operations, case management, model governance, QA, audit and product ownership.

Risk-based supervision in practice

Risk-based supervision does not mean that lower-risk firms are exempt from rules. It means supervisory resources and intensity are directed according to risk.

A supervisor may consider the institution’s customer base, products, delivery channels, geographies, cross-border footprint, transaction volumes, correspondent relationships, exposure to cash, virtual assets, trade finance, private banking, high-risk sectors and history of control weaknesses. It can combine those inherent-risk factors with information about governance, staffing, technology, audit findings, remediation and previous supervisory outcomes.

For a large international bank, risk-based supervision can result in multiple layers of scrutiny. A home supervisor may assess group governance. Host-country supervisors may examine local branches or subsidiaries. A prudential supervisor may focus on safety and soundness implications while an AML/CFT supervisor examines financial-crime controls. A conduct authority may consider customer outcomes. Data-protection authorities may become relevant where information processing is questioned. Sanctions authorities may exercise separate powers.

The Basel Committee has emphasised that weak AML/CFT risk management can create reputational, operational, compliance and concentration risks and that cooperation between prudential and AML/CFT supervisors matters. Its 2020 guidance on supervisory cooperation covers authorisation, ongoing supervision and enforcement. In the Basel Committee’s consolidated guidance current in 2026, ML/TF risk remains connected to the overall safety and soundness of banks rather than being treated as an isolated compliance specialty.

For architects and BAs, this has a direct implication: do not design a “financial crime platform” that cannot produce evidence outside its own application boundary. Supervisors may need to understand data lineage from channel to core system, payment engine, screening service, monitoring platform, case manager and regulatory reporting layer. The control story has to survive end-to-end.

Supervisory examinations: what a bank is really being tested on

A supervisory examination can be routine, thematic, risk-driven, event-driven or part of a broader review. Terminology varies: inspection, exam, review, supervisory assessment, skilled-person review, thematic review or another local term. The method can be on-site, off-site or hybrid.

The request may begin with documents: policies, procedures, enterprise risk assessments, governance minutes, model inventories, scenario lists, KYC standards, sanctions frameworks, internal-audit reports, quality-assurance results, training records, management information and open remediation items. That is only the first layer.

Supervisors often then test the relationship between documented design and actual operation. They may select customer files, alerts, cases or transactions and ask the bank to reconstruct what happened. If a bank says a high-risk customer requires senior approval, can it show the approval? If a monitoring rule depends on a customer-risk rating, can it prove the rating that was effective at the time of the transaction? If a payment was released after a sanctions alert, can it show the matched fields, analyst reasoning, supporting evidence and approval? If a SAR/STR was filed, can it show the internal case history without exposing protected information to people who should not have access?

The strongest evidence is contemporaneous evidence: records produced as the control operated. Reconstructed evidence created after a supervisor asks a question is weaker because it cannot reliably prove what the bank knew and decided at the time.

A mature control therefore leaves an audit trail by design. That means timestamped decisions, identities of decision-makers, source data, rule/model version, screening-list version where relevant, case notes, attachments, approvals, overrides, status transitions and immutable or appropriately protected event history.

The supervisory evidence chain

Think of every material financial-crime control as having an evidence chain:

obligation or risk → policy → control design → system implementation → operational execution → quality check → management oversight → remediation.

A failure anywhere in that chain can make the whole control difficult to defend.

For example, suppose the bank has a transaction-monitoring scenario intended to detect rapid movement of suspected mule-account proceeds. The enterprise risk assessment identifies scam and mule risk. The policy requires monitoring. The scenario uses inbound credits, transaction velocity, beneficiary changes and account age. The data pipeline populates these features. Alerts go to investigators. QA reviews closures. Management tracks alert ageing and suspicious-report conversion. Tuning reviews thresholds. Internal audit later tests the framework.

If investigators discover that one payment channel was never fed into the monitoring platform, the problem is not merely “an IT defect.” The bank must ask how long the gap existed, which customers and transactions were affected, whether alerts were missed, whether a lookback is needed, whether regulatory notification is required, what interim control is appropriate and how effectiveness will be validated after repair.

That is the level at which supervisors think about sustainable remediation.

Financial intelligence units: intelligence, not verdicts

An FIU is a central part of the AML/CFT system because no single bank sees the whole financial network. One institution may see an incoming payment; another sees rapid onward transfers; another sees conversion into a different asset; a reporting business sees the commercial transaction behind the flow. An FIU can combine reports and other information to identify patterns that are invisible to individual institutions.

FATF Recommendation 29 and Egmont Group materials describe the core FIU cycle as receipt, analysis and dissemination. In practice, an FIU may perform operational analysis on specific cases and strategic analysis on broader trends and typologies. It may request additional information from reporting entities under its legal framework, access government or commercial information and exchange intelligence with foreign FIUs.

An FIU’s receipt of a SAR/STR does not mean the customer has been convicted, charged or even necessarily investigated by police. A suspicious report is a protected disclosure based on the applicable reporting threshold. It is an input into an intelligence process.

This matters deeply for data design. A customer master should not contain a simplistic field such as criminal=true because an STR exists. Suspicion, reporting, intelligence interest, law-enforcement investigation, charge, conviction and sanctions designation are different concepts with different evidentiary weight and disclosure rules.

A bank should also avoid using SAR/STR filing as a substitute for risk management. Filing a report does not automatically answer whether the relationship should continue, whether transactions should be restricted where legally permitted or required, whether enhanced monitoring is needed, or whether the bank must take separate action under sanctions or fraud controls.

Operational independence and confidentiality of FIUs

FIUs handle information whose unauthorised disclosure can compromise investigations, expose reporters, harm customers and damage international intelligence cooperation. The Egmont Group stresses operational independence, secure information exchange and confidentiality. Its public materials also make clear that the Egmont Group itself is not a law-enforcement body and does not investigate individual transactions.

For a bank, FIU confidentiality affects several system and process choices. Suspicious-report records should have narrower access than ordinary customer-service cases. Search results should not expose SAR/STR filing status to front-office staff who have no need to know. Analytics environments need access controls. Data extracts for unrelated purposes should not casually include protected reporting flags. Production support staff may require technical access without business-content visibility.

Where local law prohibits tipping off or otherwise restricts disclosure of suspicious-report information, customer messaging must be designed carefully. A customer may legitimately ask why a payment is delayed or an account relationship is under review. The bank needs approved communication that does not disclose protected information or misrepresent the situation.

Because these rules are jurisdiction-specific, global systems should support policy configuration rather than one universal message. “Do not tell the customer a SAR exists” is broadly sensible; the precise legal boundary around related information, consent regimes, disclosures to group entities, litigation or data-subject requests must be governed locally.

FIU feedback and the learning loop

FIUs do not only receive information. Many publish typologies, alerts, indicators, strategic assessments or feedback intended to improve reporting quality and detection.

A mature bank turns that feedback into a controlled learning loop. Compliance assesses relevance. Financial-crime strategy maps the typology to products and customer segments. Detection teams review scenarios or models. KYC teams consider new risk indicators. Investigators receive targeted guidance. Data teams determine whether the required data exists. Product owners consider whether new controls create customer or operational impact. Governance records the decision, including cases where no change is justified.

The important point is traceability. “We read the FIU bulletin” is not evidence of implementation. A supervisor may reasonably ask: What did the bank assess? Which products were in scope? What control changes were made? How was effectiveness measured?

Law enforcement: from intelligence to evidence

Law enforcement investigates offences. The bank’s role changes when an authority moves from intelligence interest to formal evidence gathering.

A request can arrive in many forms. Depending on jurisdiction and agency, it may be a subpoena, production order, court order, warrant, statutory notice, summons, information requirement, preservation request or another legal instrument. Some requests are compulsory; some seek voluntary cooperation; some have secrecy provisions; some allow or require the bank to challenge or clarify scope.

There is no safe global rule saying “police request = disclose.” The bank must validate the requesting authority, legal basis, jurisdiction, legal entity served, scope of information, date range, deadline and restrictions. Legal counsel or a specialist authority-response function should determine whether disclosure is permitted or required.

Identity verification is fundamental. Fraudsters can impersonate authorities. Requests should arrive through known official channels or be independently verified using trusted contact information. A phone number or email address printed on the request should not be the sole verification method where risk is material.

The bank also needs to distinguish a pointer request from a demand for complete records. In the United States, for example, FinCEN’s Section 314(a) mechanism allows specified law-enforcement requests to be sent through FinCEN so financial institutions can identify accounts or transactions associated with named subjects. A positive match does not itself mean the bank should send the full customer file to the requesting agency; further legal process may be required. That example is specific to the U.S. framework and should not be generalised globally.

The external-request lifecycle

A strong external-authority workflow begins before data collection.

Receipt and registration. The bank records the request in a restricted system, captures the authority, contact, jurisdiction, reference number, date received and apparent deadline, and preserves the original document.

Authentication. The bank verifies the authority and, where necessary, the individual officer or official. It checks the request through approved channels rather than relying only on contact details contained in the message.

Legal classification. Legal or an authorised specialist determines the legal instrument, whether compliance is mandatory or voluntary, which bank legal entity is addressed, which jurisdiction applies and whether secrecy or non-disclosure conditions exist.

Scope interpretation. The bank converts narrative wording into a precise data scope: customer identifiers, accounts, date ranges, transaction types, communications, devices, KYC records, payment messages, cases or other information.

Preservation. If applicable, a legal hold or preservation instruction prevents relevant records from being deleted under normal retention schedules.

Collection. Data owners extract information from approved systems while preserving provenance. The process should avoid unnecessary disclosure outside scope.

Quality assurance. The response is checked for completeness, correct customer identity, date range, legal entity and excluded information. Sensitive material may require privilege or confidentiality review.

Approval and release. Authorised staff approve disclosure and transmit it through a secure channel.

Evidence of response. The bank retains what was sent, when, by whom, through which channel and with what acknowledgement.

Follow-up. Further questions, renewed requests, legal-hold changes or internal risk actions are linked to the original authority matter without exposing restricted information to unnecessary users.

The workflow should support partial responses and clarification. A bank may need to tell an authority that some requested data belongs to a different legal entity, does not exist, falls outside the retention period or requires additional legal process. Silent assumptions create risk.

Legal holds and preservation

Records-management schedules normally delete or archive data after defined periods. A preservation obligation can override normal deletion for records relevant to a legal matter.

Technically, a legal hold is not simply a boolean on the customer. The scope can be narrower or broader than one customer and can include linked accounts, communications, payment messages, onboarding evidence, call recordings, employee communications, investigation notes or system logs. It may apply from a specified date and remain until formally released.

A legal-hold capability should therefore record the authority matter, legal basis, custodians or systems in scope, data categories, effective date, release authority and audit history. When systems are decommissioned or data is migrated, holds must survive the change.

Testing is essential. A bank should prove that data subject to a hold is not deleted by a scheduled purge and that release of one hold does not delete records still protected by another.

Chain of custody and evidential integrity

Financial institutions are not police evidence laboratories, but they still need defensible evidence handling.

If a bank extracts transactions in response to legal process, it should be able to explain the source system, extraction method, date/time, filters applied and any transformations. If original payment-message data is converted into a report, the bank should preserve enough provenance to distinguish source content from presentation formatting.

For high-risk matters, hashes, immutable storage, controlled export, dual review or documented transfer procedures may be appropriate. The exact control should be proportionate to legal and operational risk.

The key principle is reproducibility: another authorised person should be able to understand what data was provided and how it was obtained without relying on the memory of the analyst who handled the request.

Prosecutors, courts and asset measures

Prosecutors and courts introduce another set of actions that banks should not confuse with ordinary information requests.

A restraint, freezing or seizure order can affect the bank’s ability to permit transactions. A confiscation order can affect disposition of assets. An account-monitoring order may require provision of information over time. A warrant may authorise search or seizure under defined conditions. Terminology and powers vary widely.

Operationally, these orders require precise implementation. The bank must identify the correct customer and assets, apply the correct restriction, record the legal basis, prevent unauthorised release and handle permitted transactions where the order or law allows them.

The system should distinguish the reason for restriction. A court-ordered restraint, a sanctions asset freeze, a fraud hold, an AML relationship restriction and an operational block are not the same thing. Combining them into one generic blocked status can create serious errors when the bank later decides whether funds may be released.

Sanctions authorities are a separate control domain

Sanctions authorities administer restrictive measures under their respective legal frameworks. Their responsibilities may include guidance, licensing, reporting, list administration and enforcement.

In the United Kingdom, the Office of Financial Sanctions Implementation (OFSI), part of HM Treasury, describes its role as supporting the understanding, implementation and enforcement of UK financial sanctions. In the United States, the Office of Foreign Assets Control (OFAC) administers and enforces U.S. economic and trade sanctions under multiple legal authorities. In the European Union, restrictive measures operate through EU legal instruments and national competent authorities, with institutional responsibilities depending on the measure and Member State.

The bank should not assume that filing a suspicious transaction report satisfies a sanctions reporting obligation. A sanctions obligation may arise without any suspicion of money laundering. Conversely, a suspicious AML case may have no sanctions nexus.

Licensing is also distinct. Some regimes permit activity that would otherwise be prohibited under general or specific authorisation. A licence should be treated as structured legal authority, not a free-text “exception.” Systems should record issuing authority, legal entity relying on the licence, covered parties or activity, validity period, conditions, reporting duties, relevant transactions and approval.

One authority can wear several hats

Institutional names can mislead.

AUSTRAC is a useful example because it publicly describes itself as both Australia’s AML/CTF regulator and its financial intelligence unit. A bank dealing with AUSTRAC should therefore determine which function is engaged in a particular interaction rather than assuming every contact is either supervisory or intelligence-related.

FinCEN is another example of a body with combined characteristics. It is the U.S. FIU and also exercises regulatory functions under the Bank Secrecy Act framework. Federal banking agencies and other functional regulators have supervisory roles over institutions within their remits. Law-enforcement agencies use financial intelligence and legal process for investigations. The institutional map therefore cannot be reduced to “FinCEN is regulator, police is investigator”; functions overlap but legal powers remain distinct.

In the European Union, the institutional model changed materially in 2026. On 1 January 2026, the EBA and the new Authority for Anti-Money Laundering and Countering the Financing of Terrorism (AMLA) completed the transfer of EU-level AML/CFT mandates from the EBA to AMLA. Existing EBA AML/CFT guidelines and standards remain in force until replaced under the new framework. AMLA coordinates supervisory convergence and FIU cooperation and is preparing for direct supervision of selected high-risk cross-border financial institutions beginning in 2028. Its 2026 preparatory work includes data collection and selection methodology; the first selection is planned for 2027. The EBA continues to address ML/TF risk from a prudential perspective and cooperates with AMLA.

That example shows why training material must be date-aware. An organisational chart from 2024 can be wrong in 2026 even though the underlying AML principle is unchanged.

Regulatory colleges and cross-border supervisory cooperation

A global bank may have one customer relationship and one technology platform but many regulated legal entities. Supervisors therefore need mechanisms to understand group-wide risks.

Supervisory colleges and bilateral or multilateral cooperation can help authorities exchange information on governance, controls, incidents and remediation. The Basel Committee’s supervisory-cooperation guidance stresses interaction between prudential and AML/CFT supervisors at authorisation, ongoing supervision and enforcement stages.

For the bank, this means a serious finding in one jurisdiction may not remain local. If the same sanctions engine, transaction-monitoring platform or KYC utility serves multiple legal entities, another supervisor may ask whether the weakness affects its entities too.

A remediation programme should therefore include an impact-assessment dimension. When an issue is discovered, the bank asks: Which legal entities use the same control? Which products and channels share the data source? Which countries apply different rules? Does the defect affect historical periods? Are other supervisors already aware? Is local notification required?

A narrow fix to one country front end may be insufficient if the root cause sits in a common service.

The role of the bank’s regulatory affairs and legal functions

External-authority engagement needs clear ownership.

Regulatory affairs or a similar function often coordinates supervisory relationships, examinations and commitments. Financial-crime compliance provides subject-matter ownership. Legal interprets compulsory process and disclosure authority. Privacy or data-protection specialists assess personal-data constraints. Records management supports retention and legal holds. Cybersecurity may be involved where secure transfer or digital evidence is relevant. Business and operations teams provide source records. Technology teams explain system behaviour and lineage.

The purpose of coordination is not to centralise every answer through one team. It is to prevent inconsistent, unauthorised or contradictory responses.

A central authority register can be useful, but access should be segmented. A general regulatory-exam request may be visible to a broader remediation team; a sensitive police investigation or FIU request may require a restricted compartment. The system must support both enterprise oversight and need-to-know confidentiality.

The authority taxonomy a bank should maintain

A practical bank taxonomy can classify an external matter along several dimensions:

The point is not to create bureaucracy. The taxonomy allows workflow rules to be explicit.

Data and systems: what a response platform actually needs

An authority-response platform should not be designed as a document upload folder. It is a controlled case-management system.

At minimum, it needs an authority record, verified contact details, jurisdiction, matter type, legal basis, bank legal entity, received date, deadline, confidentiality classification, data scope, assigned owner, approvals, source systems, collected evidence, correspondence, response history and closure status.

For complex banks, the platform should also link to customer identifiers and accounts without copying every sensitive dataset into the case tool. References to source records may be safer than duplication. Where copies are necessary for evidential reasons, retention and security must be defined.

The system should support versioning. If the authority narrows a request from five years of transactions to two years, the bank should preserve the original and amended scope. If the bank sends an initial response and later a correction, both versions should remain visible to authorised users.

Deadline logic needs care. “Ten days” may mean calendar days, business days or a jurisdiction-specific calculation. The due date may run from service, receipt, acknowledgement or another event. Systems should not hard-code a global interpretation.

A response also needs a reliable export. If a case contains 200 documents, the bank should be able to show exactly which 73 were sent, not merely that “the folder was shared.”

Customer and account identity resolution

The most dangerous authority-response defect is often not an incorrect paragraph in a cover letter. It is retrieving the wrong person’s data.

Names are not unique. A request for “Mohammed Ali,” “John Smith” or a company with a common name cannot safely be matched by name alone. The bank should use the identifiers supplied by the authority—date of birth, address, account number, company registration, tax identifier, passport number or other attributes as lawful and available—and apply controlled entity-resolution procedures.

Where identity remains ambiguous, the bank should clarify rather than guess.

This is particularly important for historical data. Customer records change. Addresses, names, beneficial owners and account relationships have effective dates. A response for activity in 2022 may require the customer profile and ownership structure that existed in 2022, not only today’s master record.

Payment-data retrieval and provenance

Payment investigations expose the limits of simplified reporting databases.

A law-enforcement request may require the original payment message, not just a statement line. For a cross-border ISO 20022 payment, relevant evidence can include debtor and creditor parties, ultimate parties, agents, addresses, remittance information, purpose, identifiers and timestamps. For legacy messages, field structures differ. Intermediary systems may enrich, truncate or transform data.

A response should therefore distinguish:

• data as received from the customer or upstream bank;
• data added or enriched by the bank;
• data transformed for routing or clearing;
• data stored in the ledger;
• data displayed in customer channels;
• data extracted for the authority.

If the bank cannot distinguish these layers, an investigator may mistake bank-generated enrichment for original customer-provided information.

Architects should preserve source-message identifiers and lineage. BAs should define whether an authority request requires “what was received,” “what was sent,” “what was booked” or all three.

Alerts, cases and authority interest

A law-enforcement or FIU request can itself become relevant risk information, but it is not proof of wrongdoing.

The bank may decide, subject to law and policy, to review the customer, connected parties and recent transactions. It may raise an internal case, enhance monitoring or assess whether suspicious reporting is required. But the trigger should be described accurately: “law-enforcement interest received” is not the same as “customer committed crime.”

Case-management systems should therefore record the source and status of intelligence. A request could relate to a suspect, victim, witness, counterparty or unrelated third party. Overstating the meaning can lead to unfair account exits, unnecessary payment restrictions and poor risk decisions.

The reverse connection also matters. A bank investigation may identify information relevant to an existing authority matter. Governance should define when and how that information can be disclosed, whether a supplemental SAR/STR is appropriate and whether legal process is required.

Supervisory findings versus customer investigations

Banks often confuse these two because both are handled by financial-crime teams.

A supervisory finding concerns the bank’s control environment. It may say transaction-monitoring coverage is incomplete, CDD refreshes are overdue, sanctions tuning is weak or suspicious-report quality is inadequate.

A customer investigation concerns activity associated with a customer, account, transaction or network.

The same event can create both. Suppose police identify a mule network that used the bank for eighteen months. Customer investigators assess the accounts and reporting obligations. Separately, compliance asks why monitoring did not detect the pattern earlier. That may become a control issue and potentially a supervisory matter.

The workflows need different owners, evidence and closure tests. Closing all mule accounts does not remediate the monitoring defect. Deploying a new scenario does not complete the customer investigations.

Remediation: from finding to sustainable closure

Regulatory remediation is where vague commitments become expensive.

A strong remediation plan starts with the exact finding and legal or supervisory concern. It defines root cause, affected population, historical period, interim risk mitigation, target-state control, technology change, data repair, operational procedure, training, accountable executive, milestone dates, validation method and closure evidence.

Root cause should go beyond “human error.” If investigators repeatedly missed a risk indicator, ask whether the alert displayed the necessary data, whether procedures were clear, whether workload was excessive, whether training covered the issue, whether QA detected the pattern and whether management information showed the failure.

The affected population matters because a defect can pre-date discovery. If a sanctions-screening field was missing from a payment feed for twelve months, the bank may need a lookback. If beneficial ownership was not captured for a segment, remediation may involve customer outreach and restrictions.

Interim controls matter because the target solution may take months. Manual review, temporary rules, lower thresholds or restricted product access may reduce risk while technology is fixed. Interim controls themselves require capacity, QA and exit criteria.

Sustainable closure requires proof that the new control works. “Code deployed” is not closure. The bank may need post-implementation testing, operating-effectiveness evidence, sample reviews, monitoring metrics and independent validation.

Supervisory findings close on evidence through containment, root-cause repair, validation and formal closure.

Where the bank discovers the breach itself, the same discipline applies: contain the issue, assess it honestly, determine applicable notification duties and any voluntary disclosure with Legal and Compliance, meet the relevant deadlines, and demonstrate remediation.

Formal enforcement programmes

In some jurisdictions, serious weaknesses can result in formal enforcement orders, undertakings, consent orders, monitorships, licence conditions or other mandated programmes. The terminology and legal effect vary.

For delivery teams, the discipline is requirement traceability. Every work item should map to an obligation, finding, commitment or remediation milestone. If a project changes scope, governance should show whether the underlying commitment is still met.

Traceability should continue into testing. A test case that proves a screen renders correctly is not enough if the regulatory commitment requires completeness of a customer population. The bank may need population-level reconciliation, data lineage tests, negative tests, exception tests and evidence that historical defects were addressed.

The closure package should be designed from the beginning. Waiting until the end to ask “what evidence will prove this?” often leads to rework.

Public-private partnerships and information sharing

Financial-crime effectiveness can improve when public authorities and financial institutions share threat information lawfully.

Public-private partnerships may provide typologies, tactical indicators, priority threats or feedback on reporting. They can help banks focus detection on behaviour that matters rather than generating volume without intelligence value.

But information sharing is permissioned, not unlimited. Privacy, secrecy, confidentiality and competition law can constrain what a bank may disclose. The bank must distinguish mandatory sharing from permitted sharing and internal group sharing from external sharing.

The United States provides a useful jurisdiction-specific example. FinCEN’s Section 314(a) framework enables eligible law-enforcement requests to reach financial institutions through FinCEN for account and transaction searches. Section 314(b) provides a safe harbour for qualifying financial institutions and associations that meet the programme requirements to share information with one another for specified purposes. FinCEN issued an updated Section 314(b) fact sheet on 12 June 2026. These are U.S. mechanisms; they should not be copied into another jurisdiction’s design without a legal basis.

FinCEN Exchange is another U.S. example of public-private information sharing, bringing FinCEN, law enforcement, national-security agencies and private-sector participants together around priority illicit-finance threats.

The broader global lesson is architectural: a bank should know why it is sharing, under what authority, with whom, for what permitted purpose, which data categories, and with what safeguards.

International FIU cooperation

Criminal finance crosses borders easily; legal authority does not.

FIUs can exchange financial intelligence with foreign counterparts through frameworks including the Egmont network and bilateral or other lawful mechanisms. The Egmont Group provides a platform and principles for secure FIU cooperation. It does not itself investigate cases or order banks to freeze customer accounts.

A bank may see the practical outcome as a domestic FIU requesting information linked to a foreign inquiry. The bank should respond to the domestic lawful request according to local procedure rather than attempting to recreate the government-to-government intelligence route itself.

For global groups, this distinction protects against uncontrolled internal sharing. A branch in one country should not assume it can send SAR/STR data to another group entity because both are part of the same bank. Group information-sharing rules must account for local AML law, suspicious-report confidentiality, privacy and secrecy.

Cross-border law-enforcement requests

Cross-border requests are especially sensitive.

A foreign law-enforcement officer may contact a bank employee directly. Whether the bank can or must respond depends on applicable law, presence of the bank in that jurisdiction, treaties, mutual legal assistance frameworks, local production powers and other factors.

The safest operational rule is not “refuse all foreign requests” or “cooperate with police.” It is “route the request to the authorised legal process.”

The bank should record the foreign authority, country, requested entity, data location and any urgency, then obtain legal assessment. In some cases the authority may need to use mutual legal assistance or contact a domestic counterpart. In others, local law may permit direct service. The decision belongs in a governed legal workflow.

Confidentiality: four different problems often mixed together

Financial-crime teams use the word confidentiality broadly, but several different controls may apply.

Suspicious-report confidentiality. Local law may restrict disclosure of the existence or content of an SAR/STR and related information.

Investigation secrecy. A warrant, order or request may prohibit notifying the customer or other people.

Bank secrecy and privacy. Customer data may be protected from disclosure unless a legal gateway applies.

Legal privilege. Communications with lawyers or legal advice may have special protection depending on jurisdiction.

A response platform needs separate flags because these restrictions do not always overlap. A request can be confidential without involving an SAR. A document can contain privileged material even though disclosure of other account records is lawful.

Customer communication and operational impact

Authority engagement can affect customers even when the authority never contacts them.

A payment may be delayed while the bank assesses a court order or sanctions issue. An account may be restricted. A KYC refresh may be triggered. A relationship may be exited. Customer-support staff may receive questions they are not permitted to answer fully.

Poorly designed processes create two opposite risks. Under-restriction can breach law or compromise an investigation. Over-restriction can cause unnecessary financial harm and complaints.

The bank should therefore separate internal decision reasons from customer-facing reason codes. Customer communication should be truthful but must not expose protected information. Staff should have escalation routes for vulnerable customers, urgent salary or living-expense issues, mistaken identity and legal exceptions.

Service design matters. If an external order affects only one account, the system should not automatically block unrelated products unless policy and law require it. If only outgoing payments are restricted, an indiscriminate full relationship freeze may be wrong.

A decision tree for any external authority contact

A practical decision tree is more useful than memorising institutional names.

First ask: Is the authority genuine? Verify identity and communication channel.

Second: What function is being exercised? Supervision, FIU intelligence, criminal investigation, court/prosecutor action, sanctions administration or another function.

Third: What is the legal basis and is the request mandatory? Identify the instrument, jurisdiction and power.

Fourth: Which bank legal entity and data are in scope? Do not assume a group company can answer for another.

Fifth: What confidentiality, privilege, privacy or suspicious-report restrictions apply?

Sixth: What action is required? Provide records, preserve data, freeze assets, report, remediate, attest, seek clarification or another outcome.

Seventh: Who may approve and release the response?

Finally: What evidence must the bank retain?

Mini case study: one customer, four authorities

Consider Northstar Components Ltd, a medium-sized industrial customer of a global bank. The company has operated for seven years and historically paid suppliers in Europe and Asia. Over three months, its payment pattern changes. It begins sending larger transfers to recently incorporated intermediaries and receives credits from unrelated trading companies. The monitoring system generates alerts for rapid movement and unusual counterparties.

An investigator reviews the activity but closes the first alert because invoices appear plausible. A second alert reveals that one intermediary has common ownership with another customer previously reported for suspected trade-based laundering. The bank opens an enhanced investigation.

Stage 1: suspicious reporting

The investigation reaches the reporting threshold under the bank’s local legal framework. The bank files an STR with the national FIU. That filing is an intelligence disclosure. It does not prove Northstar committed a crime.

The bank records the filing in a restricted reporting system. Front-office staff cannot see the STR status. Relationship management receives only the approved instruction that the customer is subject to enhanced review.

Stage 2: FIU request

Two weeks later, the FIU requests additional information about counterparties and historical payments. The FIU workflow validates the request, retrieves the specified data and sends it through the authorised channel. The bank does not treat the request as a court order and does not disclose information outside the FIU’s legal gateway.

The FIU combines Northstar’s data with reports from other institutions and disseminates intelligence to law enforcement.

Stage 3: law-enforcement production order

Police later serve a production order seeking account opening documents, beneficial ownership, specified transactions and correspondence for a defined period.

The bank’s legal-response team authenticates the order, confirms the legal entity served, activates a preservation hold, maps the data scope to source systems and performs a quality review before disclosure. The response package records source provenance and exactly what was transmitted.

Separately, AML compliance assesses whether new information changes the customer-risk decision. The police order does not automatically mean the account must be closed.

Stage 4: supervisory examination

Months later, the AML supervisor conducts a thematic review of trade-finance and monitoring controls. It selects the Northstar case and asks why the first alert was closed.

This is a different question. The supervisor is not asking the bank to investigate Northstar for police. It is testing whether the bank’s monitoring and investigation control worked.

Review shows the first investigator could not see common ownership across customers because the case interface displayed only direct account parties. The relevant ownership data existed in KYC but was not integrated into the investigation workspace.

The bank now has a control deficiency: fragmented data impaired analyst judgement. Remediation includes entity-resolution integration, display of beneficial ownership in alert context, retrospective review of similar closures, revised procedures, QA checks and post-implementation validation.

Stage 5: sanctions authority

During the remediation period, one overseas counterparty is designated under a sanctions regime applicable to one of the bank’s entities. The sanctions team evaluates current assets and transactions, applies the legally required restriction and reporting process and determines whether licences or permissions are relevant.

The sanctions action is independent of the STR, police order and supervisory finding, even though all concern the same network.

This case demonstrates why a bank needs linked but separate records. One generic case marked “government investigation” would destroy the distinctions that drive legal action.

What a business analyst should specify

A requirement such as “send information to the regulator” is not testable and may be unsafe.

A BA should identify the authority function, legal entity, jurisdiction, request type, authentication process, data fields, source systems, date-range rules, approval roles, confidentiality class, response format, secure channel, deadline calculation, acknowledgement requirement, retention period and audit evidence.

For legal holds, requirements should define how data is placed on hold, how overlapping holds behave, what happens during system migration, how release is authorised and how deletion resumes.

For FIU reporting, the BA should separate report creation, approval, submission, acknowledgement, amendment or supplemental reporting, FIU follow-up and confidentiality.

For supervisory remediation, requirements should trace findings to controls, user stories, test cases and closure evidence.

For restrictions, the BA should define product-level effect. “Freeze account” is too vague. Does the system block debits, credits, securities movements, withdrawals, cards, standing orders and fees? Are interest accruals allowed? Are regulatory or licensed payments permitted? The answer is legal-framework-specific.

Architecture implications

Architects should assume that authority response cuts across the entire bank.

The customer domain provides identity, legal entity and ownership. The account domain provides relationships and status. Payment systems provide original and processed messages. KYC provides due-diligence evidence. Screening and monitoring provide alerts and control history. Case management provides investigations. Regulatory reporting systems provide SAR/STR records. Document stores provide evidence. IAM controls access. Records management enforces retention and holds. Data platforms support search and reconstruction.

The authority-response platform should orchestrate these systems, not silently become another uncontrolled copy of all customer data.

A good architecture uses stable identifiers, effective dating, data provenance and explicit security labels. It separates source data from annotations. It has a clear event model: request received, authenticated, scoped, hold applied, evidence collected, approved, sent, acknowledged, amended, closed.

Interfaces should preserve the distinction between a query and an instruction. A legal request to retrieve transactions should not directly invoke a payment block unless a separate authorised action requires it.

Developer considerations

Developers working on authority workflows need unusually strong attention to access control and auditability.

Role-based access alone may be insufficient. Attribute-based rules may be needed for jurisdiction, legal entity, case sensitivity or authority type. Highly sensitive cases may require named-user access.

Audit logs should capture meaningful events without leaking protected case content into broadly accessible logging platforms. For example, logging “user opened restricted case 123” may be appropriate; logging the full SAR narrative into an application trace is not.

Exports should be deterministic. If a user reruns the same approved export, the system should either reproduce the same content or record why it changed.

Error handling must be safe. A failed transfer should not mark a response “submitted.” A partial upload should not be treated as complete. A timeout should preserve retry state without duplicate disclosure.

Configuration changes—deadline rules, approved channels, authority contacts, templates—should be versioned and controlled.

Testing the external-authority process

Testing should cover more than the happy path.

A valid supervisory request should route to the correct owner and allow appropriate evidence collection. An invalid sender should be rejected or escalated. A request addressed to the wrong group entity should not expose data. An ambiguous customer identity should trigger clarification. A restricted SAR record should remain hidden from unauthorised users. A legal hold should defeat scheduled deletion. Two overlapping holds should survive release of only one. A deadline should calculate correctly around local business calendars where required.

Negative tests are particularly important for disclosure. Try to export an out-of-scope customer. Try to attach a document from a different legal entity. Try to release without approval. Try to send through an unapproved channel. Try to view a highly restricted FIU matter using a general compliance role.

For data lineage, tests should reconcile extracted transaction totals and identifiers back to source systems. For payment data, test both original and transformed messages. For historical KYC, confirm effective-dated ownership is retrievable.

For remediation, test that the control works at population scale, not only on a demonstration record.

Operational resilience and urgent requests

Authority requests do not arrive only during office hours.

Terrorism, sanctions, fraud and asset-restraint matters can be urgent. Banks need out-of-hours escalation, authorised decision-makers and resilient access to critical data.

Resilience planning should identify what happens if the case platform is unavailable. Can the bank authenticate an urgent court order? Can it implement a legally required restriction? Can it preserve records? Can it later reconstruct actions taken under contingency procedures?

Manual contingency processes need the same governance principles: identity, legal basis, scope, approval, evidence and later reconciliation.

Metrics that reveal control health

Counting the number of authority requests is not enough.

Useful operational metrics include response timeliness, overdue items, requests requiring clarification, data-extraction defects, correction rates, legal-hold failures, secure-transfer failures, unauthorised-access attempts and ageing of open matters.

Supervisory metrics can include remediation milestones, repeat findings, overdue commitments, validation failures and issues reopened after closure.

FIU-related metrics should be handled carefully because simple volume targets can distort behaviour. More SARs do not automatically mean a better programme. Quality, timeliness and relevance matter, subject to local expectations.

Metrics should be interpreted. A spike in law-enforcement requests could indicate growing criminal exposure, a major investigation, improved public-private engagement or simply a change in reporting practice. Management information should support questions, not replace judgement.

Common failure modes

One common failure is authority conflation. Staff treat an FIU, supervisor and police request as interchangeable because all are “government.” That can produce wrong disclosures and wrong customer actions.

Another is wrong-entity response. A global bank receives a request at group headquarters and discloses data held by a separately regulated subsidiary without checking legal authority.

A third is identity error. A common-name customer is matched incorrectly and the bank discloses another person’s records.

A fourth is scope creep. To be helpful, staff provide more information than requested, including protected or irrelevant data.

A fifth is post-hoc reconstruction. The bank cannot show how a historical alert was handled and creates a narrative months later. That is not equivalent to contemporaneous evidence.

A sixth is broken preservation. A system migration or retention purge deletes data after a legal hold should have protected it.

A seventh is SAR leakage. Suspicious-report status appears in a customer-service screen, analytics table or general data export.

An eighth is remediation theatre. Policies are rewritten and training delivered, but the underlying data or system weakness remains.

A ninth is licence overreach in sanctions. Staff treat a permission applying to one transaction, party or period as a blanket exemption.

A tenth is assuming authority interest proves guilt. This can cause unjustified exit decisions and poor customer outcomes.

Practical control principles

A strong operating model can be summarised in a few principles.

Know the function being exercised, not just the institution’s name.

Authenticate before disclosing.

Identify the legal basis, jurisdiction and bank legal entity.

Minimise disclosure to lawful scope.

Preserve data when required and protect evidential provenance.

Separate suspicious reporting, supervisory findings, criminal investigation and sanctions action.

Protect SAR/STR and investigation-sensitive information through need-to-know access.

Keep contemporaneous evidence.

Use external intelligence as a risk input, not a verdict.

Trace remediation from finding to validated operating effectiveness.

Design for cross-border differences rather than assuming one global rule.

Authority interaction matrix

The following matrix is intentionally simplified. Real powers depend on law and jurisdiction.

Current jurisdiction examples: use them to understand structure, not to universalise law

European Union

The EU model is particularly important in 2026 because responsibilities are transitioning to AMLA. The EBA and AMLA announced that the handover of EU-level AML/CFT mandates was completed on 1 January 2026. Existing EBA AML/CFT guidelines and standards remain valid until replaced. AMLA is developing the EU AML/CFT rulebook, supporting supervisory convergence and coordinating FIUs. It is preparing to select up to 40 high-risk cross-border financial institutions in 2027 for direct supervision starting in 2028.

This does not mean national AML supervisors disappear. The EU architecture combines AMLA with national competent authorities and FIUs. Prudential authorities such as the ECB and the EBA continue to have roles relevant to financial-system safety and prudential risk, with cooperation arrangements intended to avoid gaps and duplication.

For a bank, the implementation question is therefore “which authority has competence for this entity and issue at this date?” rather than “AMLA is the EU regulator.”

United Kingdom

The UK Financial Intelligence Unit sits within the National Crime Agency and has national responsibility for receiving, analysing and disseminating SAR intelligence. The NCA makes clear that SARs are not the same as crime or fraud reports. The FCA supervises AML compliance for firms within its relevant remit, while other sectors can have other AML supervisors. OFSI, part of HM Treasury, administers and enforces UK financial sanctions. Police, the NCA and other investigative authorities exercise law-enforcement functions under applicable powers.

This shows why one UK bank may interact with several authorities on one matter.

United States

FinCEN receives, maintains, analyses and disseminates financial-transaction data and exercises regulatory functions under the BSA framework. It also serves as the U.S. FIU. Federal functional regulators supervise institutions within their respective remits, and law-enforcement agencies use BSA information and legal process for investigations. Section 314(a) and 314(b) provide specific information-sharing mechanisms under U.S. law.

A global bank should encode these mechanisms as U.S. jurisdiction rules, not universal workflows.

Australia

AUSTRAC publicly describes itself as both the AML/CTF regulator and the Australian FIU. It regulates reporting entities and analyses financial reports and other information. Its dual role is a reminder that function must be captured at case level even where one institution owns both functions.

How to audit this control area

An internal audit or independent assurance review should test governance, not just files.

Start with the authority inventory. Does the bank know which supervisors, FIUs, sanctions authorities and law-enforcement gateways are relevant to each legal entity? Are contact channels current? Are responsibilities documented?

Sample requests from different categories. Verify authentication, legal review, identity matching, scope, approvals, secure transmission and retained evidence.

Test restricted access. Can ordinary customer-service staff discover SAR/STR filing? Can a general compliance analyst open a sealed law-enforcement matter? Are audit logs monitored?

Test legal holds end-to-end, including release and overlapping holds.

Inspect data lineage for several response packages. Can the bank trace exported data back to authoritative systems?

Review corrections and near misses. Wrong-recipient, wrong-customer and over-disclosure incidents often reveal control weaknesses better than policy documents.

For supervisory remediation, sample closed findings and verify sustainable operating effectiveness after closure.

Learning check: questions a strong practitioner can answer

After this chapter, a practitioner should be able to explain why an FIU is not simply another name for police, why a supervisory finding is not the same as a criminal allegation, why legal-entity scope matters in a global bank, why a SAR/STR flag should not appear in ordinary customer-service data, why legal holds need system-level enforcement, why a positive law-enforcement information-sharing match may still require further legal process, and why sanctions reporting can exist independently of AML suspicion.

A BA should be able to turn an authority request into testable requirements. An architect should be able to identify the source systems, lineage and access-control boundaries. An investigator should understand how authority interest changes risk without becoming proof of guilt. A tester should know which negative scenarios matter most. A product owner should understand customer impact and confidentiality constraints.

Takeaway

Regulators, supervisors, FIUs, law enforcement, prosecutors, courts and sanctions authorities form a connected financial-crime ecosystem, but they do not perform the same job.

Supervisors test whether the bank understands risk and whether controls operate effectively. FIUs receive and analyse financial intelligence and disseminate it where appropriate. Law enforcement investigates offences using powers defined by law. Prosecutors and courts can compel evidence or impose asset-related measures. Sanctions authorities administer restrictive measures, licences, reporting and enforcement. Prudential authorities care because weak AML/CFT control can become a safety-and-soundness issue.

The practical discipline for a bank is to preserve those distinctions while connecting the information intelligently. Every external matter should have a verified authority, function, legal basis, jurisdiction, legal entity, scope, confidentiality classification, accountable owner, deadline, response action and audit trail.

When that model is built correctly, authority engagement stops being an improvised emergency process. It becomes a controlled part of the bank’s operating architecture—capable of protecting investigations, meeting legal obligations, supporting supervisors, preserving customer rights and producing reliable evidence years after the original event.

References and further reading

• FATF — The FATF Recommendations, as amended June 2026: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html
• FATF — Guidance for a Risk-Based Approach: Effective Supervision and Enforcement by AML/CFT Supervisors of the Financial Sector and Law Enforcement: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Rba-effective-supervision-and-enforcement.html
• FATF — Risk-Based Supervision guidance: https://www.fatf-gafi.org/content/dam/fatf-gafi/guidance/Guidance-Risk-Based-Supervision.pdf.coredownload.pdf
• FATF — Methodology for assessing technical compliance and effectiveness, including Recommendations 26–31: https://www.fatf-gafi.org/content/dam/fatf-gafi/methodology/FATF-Assessment-Methodology-2022.pdf.coredownload.inline.pdf
• Basel Committee on Banking Supervision — Anti-money laundering and counter-terrorist financing consolidated guidance: https://www.bis.org/committees/bcbs/basel-consolidated-guidelines/module/afs/10
• Basel Committee on Banking Supervision — Sound management of risks related to money laundering and financing of terrorism: revisions to supervisory cooperation, 2 July 2020: https://www.bis.org/publications/202007-guidelines-sound-management-risks-related-money-laundering-and-financing-terrorism-revisions-supervisory-cooperation
• Egmont Group — Financial Intelligence Units: https://egmontgroup.org/about/financial-intelligence-units/
• Egmont Group — About the Egmont Group and FIU cooperation: https://egmontgroup.org/about/
• European Banking Authority — EBA and AMLA complete handover of AML/CFT mandates, 19 January 2026: https://www.eba.europa.eu/publications-and-media/press-releases/eba-and-amla-complete-handover-amlcft-mandates
• AMLA — About AMLA: https://www.amla.europa.eu/about-amla_en
• AMLA — FAQs, including the timetable for selection and direct supervision: https://www.amla.europa.eu/faqs_en
• AMLA — Preparing for the 2027 selection of directly supervised entities, 12 May 2026: https://www.amla.europa.eu/amla-takes-next-step-toward-2027-selection-entities-direct-supervision_en
• FinCEN — What We Do: https://www.fincen.gov/about-fincen/what-we-do
• FinCEN — Support of Law Enforcement and Section 314(a): https://www.fincen.gov/resources/law-enforcement/support-law-enforcement
• FinCEN — Section 314(a): https://www.fincen.gov/resources/section-314a
• FinCEN — Section 314(b) information sharing, including the June 2026 fact sheet: https://www.fincen.gov/resources/section-314b
• FinCEN — FinCEN Exchange: https://www.fincen.gov/resources/fincen-exchange
• National Crime Agency — UK Financial Intelligence Unit: https://www.nationalcrimeagency.gov.uk/what-we-do/crime-threats/money-laundering-and-illicit-finance/ukfiu
• National Crime Agency — Suspicious Activity Reports: https://www.nationalcrimeagency.gov.uk/what-we-do/crime-threats/money-laundering-and-illicit-finance/suspicious-activity-reports
• Financial Conduct Authority — Money laundering and terrorist financing supervision: https://www.fca.org.uk/firms/financial-crime/money-laundering-terrorist-financing
• Office of Financial Sanctions Implementation — About OFSI: https://www.gov.uk/government/organisations/office-of-financial-sanctions-implementation/about
• Office of Foreign Assets Control — OFAC mission and sanctions programmes: https://ofac.treasury.gov/
• AUSTRAC — About AUSTRAC: https://www.austrac.gov.au/about-us/what-we-do/about-austrac

Chapter 7 Advanced Practice — Regulators, Supervisors and Law Enforcement

This advanced section moves from “who does what” to the harder question a bank must solve: how do we respond lawfully, accurately, securely and consistently when an external authority asks a question, requests evidence, challenges a control or requires action?

The objective is not to teach one country’s legal procedure. The objective is to build a reusable operating model that can be configured for the legal entity, jurisdiction, authority and legal instrument involved.

Start with the authority, not the document title

Banks receive documents labelled notice, request, order, summons, subpoena, production order, warrant, information request, supervisory request or preservation notice. Those labels do not have a universal meaning. The same word can carry different legal force in different jurisdictions, and an authority may exercise several different powers depending on the matter.

A bank should therefore classify an incoming request using facts rather than assumptions:

• issuing authority and verified contact point;
• legal power or statutory basis stated;
• court or judicial involvement where applicable;
• bank legal entity addressed;
• jurisdiction and territorial scope;
• customer, account, transaction or control population in scope;
• requested information and date range;
• response deadline;
• confidentiality or non-disclosure conditions;
• preservation obligations;
• permitted response channel;
• internal owner and required legal/compliance review.

A workflow that stores only a PDF attachment and a due date is not sufficient for a large bank.

A practical request-triage decision model

A safe operating sequence is:

1. Authenticate the authority. Confirm that the request genuinely originates from the stated authority. Do not rely only on contact details printed on the incoming document if impersonation is possible.

2. Identify the legal entity. Determine which bank company, branch or regulated entity has the obligation to respond. Group branding is not a legal entity.

3. Establish the legal basis. Determine whether the request is compulsory, permitted, voluntary, supervisory or otherwise authorised. Legal review may be necessary.

4. Define scope. Translate the request into specific data objects, systems, customers, accounts, transactions, periods and documents.

5. Apply confidentiality and privilege controls. Identify material that may be legally privileged, subject to suspicious-report confidentiality, bank secrecy, data-protection restrictions or other limitations.

6. Preserve evidence. Where necessary, prevent relevant records from being destroyed under normal retention schedules.

7. Collect with provenance. Retrieve the requested information while preserving source-system identity, extraction time, transformations and responsible users.

8. Quality review. Confirm completeness, correct customer/entity, permitted scope, redactions where authorised, reconciliations and approval.

9. Deliver securely. Use the authorised channel and retain evidence of what was sent, when, by whom and to whom.

10. Separate the external response from the bank’s own risk decision. The request may trigger internal review, but it should not automatically label the customer guilty or suspicious.

That final separation is one of the most important design principles in this chapter.

Supervisory examination lifecycle

A supervisory review normally has a lifecycle rather than one exchange of documents. The precise process varies, but a useful bank model is:

notification → scope clarification → evidence request → evidence production → interviews/walkthroughs → sample testing → preliminary observations → factual accuracy review → findings → remediation plan → implementation → validation → closure.

During scope clarification, the bank should confirm legal entities, business units, products, systems and time periods. A vague scope creates inconsistent evidence later.

During evidence production, the bank should maintain a request register. Each item should show the external reference, internal owner, evidence source, due date, reviewer, delivery status and any caveat.

During interviews and walkthroughs, subject-matter experts should explain the actual control, not an idealised policy version. Material statements should be consistent with documented design and evidence.

During sample testing, the bank should be able to reconstruct why a customer, alert, screening match or transaction reached its recorded outcome.

During factual accuracy review, the bank should correct factual errors without minimising genuine weaknesses. A defensive response that contradicts evidence can damage supervisory credibility.

During remediation, findings should become traceable actions with sustainable closure evidence rather than presentation slides.

What “evidence” actually means

A control description is not the same as evidence that the control operated.

For example, a policy may say high-risk customers receive enhanced due diligence. Strong evidence may include:

• the customer-risk calculation and inputs used at the time;
• the applicable policy or standard version;
• triggered EDD requirements;
• documents and external information reviewed;
• analyst assessment;
• approvals and timestamps;
• unresolved exceptions;
• periodic-review schedule;
• subsequent monitoring or event-driven reviews.

Evidence should answer three questions:

1. What was the rule or control at that time?
2. What facts were available for this case?
3. What decision occurred, who made it and why?

A screenshot created today can demonstrate what a screen looks like today. It may not prove what happened eighteen months ago.

Evidence provenance and chain of custody

When data may support an investigation or compulsory authority response, provenance becomes essential.

A bank-grade evidence package should be able to identify:

• source system;
• source record identifier;
• extraction timestamp;
• extraction method or query where relevant;
• user or service account performing extraction;
• transformations or formatting applied;
• checksum or integrity control where used;
• reviewer;
• final disclosure package;
• transmission record.

This does not mean every ordinary supervisory spreadsheet requires forensic chain-of-custody procedures. It means the control should be proportionate to legal and evidential sensitivity.

A BA should therefore distinguish data retrieval, evidence preservation and external disclosure as separate capabilities.

Authority-request register

A central register becomes valuable when a bank receives requests across multiple entities and authorities.

High-sensitivity registers should themselves have restricted access. A general operations user should not automatically be able to see that law enforcement is investigating a customer.

Suspicious-report confidentiality: design for minimum disclosure

Suspicious activity/transaction reporting information can carry special confidentiality protections. Exact rules differ by jurisdiction, so a global platform should not encode one universal disclosure rule.

The system should instead support classifications such as:

• ordinary customer/account information;
• internal AML case material;
• suspicious-report metadata;
• report content;
• FIU correspondence;
• law-enforcement correspondence;
• legally privileged advice;
• sanctions case information;
• public information.

Access and disclosure rules can then be configured by legal entity and jurisdiction. Two documents about the same customer can have different disclosure restrictions.

A requirement saying “export all case documents to the authority” is therefore unsafe unless the authority, legal basis and permitted information classes are defined.

Privilege, secrecy and privacy are not the same control

Teams sometimes use “confidential” as one catch-all label. That is too weak.

Legal privilege can protect specified communications or work product under applicable law.

Bank secrecy or confidentiality can restrict disclosure of customer information.

Data protection/privacy governs processing and disclosure of personal data.

Suspicious-report confidentiality can restrict disclosure of reports or related information.

Investigative secrecy or non-disclosure requirements can restrict communication about an authority request.

These controls may overlap, but they are not interchangeable. A disclosure workflow should be able to apply more than one restriction simultaneously.

Legal holds and preservation

A legal hold should be capable of overriding normal deletion processes for the defined data population.

The hold itself needs scope, authority, start date, owner and release condition. Technology teams should test whether archival, data-lake and cloud-retention processes actually respect the hold. A flag in a case-management system is useless if the source platform continues deleting the underlying records.

Preservation and disclosure are also different actions. A bank may have to preserve a broader population than it is currently authorised or required to disclose.

Multi-authority coordination without an uncontrolled data pool

A major case can generate parallel engagement with a supervisor, FIU, police, sanctions authority and privacy regulator.

The bank needs coordination, but should not solve it by making every document visible to everyone.

A better pattern is a federated matter view:

• one master matter identifier;
• restricted sub-matters by authority and legal basis;
• shared factual data only where permitted;
• separate disclosure packages;
• separate deadlines;
• separate approvals;
• controlled cross-references.

This reduces contradiction while preserving legal boundaries.

Public-private information sharing

Information-sharing partnerships can improve detection because a bank sees only part of a criminal network while authorities may see a wider pattern. But useful intelligence sharing still requires rules.

The bank should establish:

• statutory or other legal basis;
• eligible participants;
• permitted purposes;
• permitted information types;
• restrictions on onward disclosure;
• retention requirements;
• customer-impact controls;
• quality and correction process;
• auditability.

The Egmont Group’s principles for FIU-to-FIU information exchange illustrate the broader importance of secure, authorised information exchange. They do not themselves create a bank’s domestic authority to share customer information.

That distinction — useful international standard versus applicable legal power — should remain visible throughout the course.

Sanctions authority engagement and licences

Sanctions authorities can create a different operational pattern from AML/FIU engagement. A bank may need to report frozen assets, respond to information requests, or rely on a general or specific licence.

A licence should be represented as controlled data rather than a free-text exception wherever feasible. Useful attributes include issuing authority, licence reference, affected legal entity, permitted parties, permitted purpose, value limits where applicable, effective period, conditions, reporting obligation and linked transactions.

If the licence expires while a standing instruction remains active, the system should not continue paying merely because operations forgot to update a spreadsheet.

From finding to sustainable closure

Regulatory remediation often fails because teams confuse completion with effectiveness.

Suppose a supervisor finds incomplete sanctions-screening data. The project adds the missing field and deploys code. That proves implementation, not sustainable control effectiveness.

A stronger closure package can include:

• original finding and root cause;
• affected systems and population;
• interim mitigation;
• approved target-state design;
• requirements traceability;
• test evidence;
• production implementation evidence;
• retrospective impact review where necessary;
• post-implementation monitoring;
• defect/exception results;
• control-owner attestation;
• second-line validation or independent assurance where required;
• documented closure approval.

The closure question is: can the bank demonstrate that the original risk is now sustainably controlled?

Worked case — transaction-monitoring examination

A supervisor asks the bank to demonstrate that its monitoring programme addresses mule-account risk in instant payments.

A weak response sends the scenario catalogue and says “mule rule enabled.”

A strong response reconstructs the control chain:

1. Enterprise and product risk assessments identify scam/mule exposure.
2. The detection framework maps this risk to relevant scenarios and analytics.
3. Data lineage shows the required instant-payment and customer fields reach monitoring.
4. Segmentation explains which customers are evaluated under which logic.
5. Threshold/model governance shows how settings were selected and approved.
6. Validation demonstrates performance and known limitations.
7. Alert-to-case metrics show operational capacity and ageing.
8. Investigation outcomes demonstrate whether generated alerts identify meaningful risk.
9. Tuning records show controlled improvement rather than queue-driven weakening.
10. Management information and issue logs show governance.

For the BA, the critical lesson is that a regulatory response often spans policy, risk, data, technology, operations and governance. It cannot be produced reliably if each system has unrelated identifiers.

Worked case — compulsory request for payment records

An authority issues a legally valid request concerning a corporate account and specified payment period.

A controlled workflow could:

1. validate authority and legal instrument;
2. confirm the correct legal entity and account ownership;
3. translate the date range into source-system retrieval criteria;
4. activate preservation where required;
5. retrieve customer, account and payment records;
6. maintain original payment-message and ledger references;
7. separate protected case/SAR material from ordinary transaction evidence;
8. conduct legal/privacy review;
9. reconcile record counts and periods;
10. approve the package;
11. transmit through the approved secure mechanism;
12. retain a controlled record of exactly what was disclosed;
13. trigger any separate customer-risk review without assuming wrongdoing.

This flow tests both legal governance and data architecture.

BA requirement patterns

Poor requirement:

The system must send requested information to law enforcement.

Better requirement:

When an authorised user records a validated external request, the system shall require the issuing authority, authority reference, bank legal entity, jurisdiction, legal basis, in-scope subject identifiers, requested period, response deadline and confidentiality classification before evidence collection can begin.

Poor requirement:

All documents should be downloadable.

Better requirement:

The disclosure package shall include only information objects marked as permitted for the selected request type and legal basis; restricted classes shall require an explicit authorised override or shall be excluded according to configured jurisdictional rules.

Poor requirement:

Keep an audit trail.

Better requirement:

The audit trail shall record creation, scope changes, evidence additions/removals, approvals, exports, transmissions, acknowledgements and closure, including user/service identity, timestamp and previous/new value for material changes.

The difference is testability.

Acceptance-test catalogue

A strong test suite should include more than the happy path.

Identity and authority

• verified authority and valid request;
• unknown sender impersonating an authority;
• request signed by an unauthorised officer;
• request addressed to the wrong bank legal entity;
• authority contact details changed after initial validation.

Scope

• one customer with multiple accounts;
• joint account with another person outside scope;
• corporate customer with several subsidiaries;
• request covering only specified payment dates;
• request expanded through formally approved amendment;
• duplicate request received through a second channel.

Confidentiality

• ordinary account records permitted;
• suspicious-report content restricted;
• legally privileged document present in case;
• protected personal data requiring specific handling;
• user without need-to-know attempts access.

Evidence

• source data changed after initial extraction;
• one source system unavailable;
• payment record exists but customer master has been migrated;
• original message differs from normalized display value;
• evidence file is replaced after approval;
• reconciliation count does not match source query.

Deadline and workflow

• urgent same-day order;
• preservation starts before disclosure approval;
• deadline extension approved;
• response rejected by secure channel;
• authority acknowledges partial receipt only.

Post-response

• follow-up request references the earlier package;
• internal AML review opens separately;
• relationship remains open with restricted customer messaging;
• remediation finding created from supervisory observation;
• closure evidence retrieved months later.

Quality gate before external release

For high-risk disclosures, reviewers should answer:

Authority: Are we responding to the correct verified authority under the correct legal basis?

Entity: Is the correct bank entity responding?

Subject: Are these the correct customers/accounts/transactions?

Scope: Does the package match the exact request and period?

Restriction: Have confidentiality, privilege, privacy and SAR/STR rules been applied?

Completeness: Are requested records present, or are gaps transparently explained?

Integrity: Can we prove the origin of the information?

Security: Is the transfer channel approved?

Traceability: Can we later reproduce exactly what was provided?

A single incorrect customer record can be more serious than a late cosmetic formatting change.

Management information that reveals control quality

Volume alone does not reveal whether the process works. Better indicators include:

• percentage of requests requiring legal clarification;
• percentage initially routed to the wrong legal entity;
• evidence-retrieval failure rate by source system;
• average age of unresolved authority questions;
• percentage delivered within applicable deadline;
• number of disclosure-quality defects;
• number of confidentiality/access incidents;
• repeat supervisory findings;
• remediation overdue rate;
• percentage of findings closed with independent validation where required;
• ageing of legal holds and preservation matters.

Metrics should support risk management, not encourage rushed responses.

Practice exercise — work through this before reading on.

Practical exercise — design the workflow

You are the BA for a new authority-response platform used by a banking group in several jurisdictions.

A request arrives concerning a corporate customer, three accounts and cross-border payments over twelve months. The request was issued to one bank subsidiary, while some payment records are stored in a shared group platform. The AML case system contains a previously filed suspicious report, and legal has marked one internal memorandum as privileged.

Design the workflow and answer:

1. Which objects must be represented in the data model?
2. Which information should be globally shared and which should remain restricted?
3. What must be validated before collection starts?
4. What preservation event is required?
5. How will you prove source-system provenance?
6. How will the workflow stop accidental export of the suspicious report or privileged memorandum?
7. How will a reviewer know the package is complete?
8. How will the bank prove exactly what it disclosed six months later?
9. What should trigger a separate AML/customer-risk assessment?
10. Which parts must remain jurisdiction-configurable?

If the design can answer those ten questions, it is moving from a mailbox process toward a defensible bank control.

Advanced takeaways

• Authority type and legal power must be identified separately from document labels.
• Group branding never replaces legal-entity analysis.
• Supervisory evidence should exist through normal control operation, not be recreated for an examination.
• Data retrieval, evidence preservation and external disclosure are separate capabilities.
• Authority requests can inform customer risk without proving wrongdoing.
• SAR/STR confidentiality, privilege, privacy and bank secrecy require distinct controls.
• Multi-authority coordination needs common facts but controlled access boundaries.
• A remediation is not sustainably closed merely because technology was deployed.
• BAs should model authority, request, subject, evidence item, legal basis, restriction, package, approval and transmission as explicit objects.
• The most important non-functional requirements are often access control, integrity, traceability, recoverability and secure transfer.

Advanced practice: examinations, investigations and authority-facing control design

The most mature banks treat external-authority interaction as a permanent capability rather than an occasional event. Regulatory examinations, FIU follow-ups, law-enforcement requests, sanctions reporting and enforcement remediation all test whether the bank can retrieve reliable information, identify accountable owners and explain its decisions without reconstructing the story manually.

Examination lifecycle

A major supervisory examination can be mapped as a lifecycle: notification, scope clarification, request intake, evidence production, interviews and walkthroughs, preliminary observations, factual accuracy review, findings, remediation, validation and closure.

Each stage requires governance. The bank should know who can speak on behalf of the legal entity, who owns factual accuracy and who approves commitments.

The examination office should distinguish a question from a formal finding. Teams should not launch uncontrolled remediation merely because an examiner asked for information; equally, repeated examiner questions can indicate a theme worth investigating internally.

Evidence inventory

For high-risk control areas, banks benefit from maintaining an evidence inventory before examinations begin.

For customer due diligence, evidence may include policy, procedure, system configuration, training, sample files, QA, exception logs and MI. For transaction monitoring, evidence can include risk assessment, scenario inventory, data lineage, tuning, validation, alert investigation, QA and governance minutes.

Maintaining this evidence during ordinary operations shortens examination response time and exposes missing records earlier.

Factual accuracy review

When a supervisor communicates preliminary observations, the bank should review factual accuracy carefully.

The purpose is not to argue against every criticism. It is to ensure conclusions are based on correct facts. If the supervisor misunderstood system behaviour, the bank should provide clear evidence. If the weakness is real, defensive wording only damages credibility.

A strong response separates factual correction from management disagreement about severity.

Commitment governance

Once management commits to a remediation date or action, the commitment should enter a controlled register.

The register should capture wording, authority, owner, due date, dependencies, evidence and status. Changes to a commitment should require appropriate governance and, where necessary, regulator engagement.

Verbal commitments made during meetings can be just as operationally important as written ones if the authority records them.

Finding decomposition

Regulatory findings are often broad. Delivery teams need to decompose them into specific control gaps.

A finding that “transaction monitoring is ineffective” could involve incomplete data, weak risk assessment, poor segmentation, badly tuned scenarios, investigation quality or governance. Treating the finding as one technology epic can miss the root causes.

Remediation should map each underlying issue to actions and closure evidence.

Closure evidence

A remediation is sustainable when the bank can demonstrate both implementation and operation.

For example, a new KYC procedure can be implemented on a date, but sustainable closure may require evidence that staff were trained, system changes deployed, affected customers remediated, QA results improved and no material defects remain.

The closure pack should tell that complete story.

Independent validation depth

Independent validation should be proportionate to the finding.

A minor procedure clarification may need simple verification. A material enforcement issue involving monitoring may need extensive data and case testing. Validators should be sufficiently independent from the remediation team and have access to source evidence.

Validation should challenge sustainability, not simply confirm action completion.

Authority interview preparation

Employees interviewed by supervisors or investigators should understand the process they actually perform. Coaching should focus on factual clarity, not scripted answers.

If a colleague does not know an answer, it is better to confirm and follow up than speculate. Inconsistent speculative answers can create unnecessary regulatory concern.

Demonstrating system behaviour

Live system demonstrations can be powerful evidence but also expose weaknesses.

Teams should use representative examples and explain system states accurately. Demonstrations should show audit trails, controls and exception handling, not only the happy path.

The system should never be manipulated temporarily to look better for an examiner.

FIU report quality assurance

Suspicious reports should be reviewed not only for filing timeliness but for usefulness.

QA can assess whether the report identifies relevant parties, explains why activity is suspicious, includes transaction chronology, avoids unsupported conclusions and supplies useful identifiers.

A report filled with raw transactions and little explanation may meet technical submission requirements while providing poor intelligence value.

Supplemental reporting

New information can emerge after an initial report. Jurisdictions can have mechanisms for supplemental or continuing reporting.

The case system should link supplements to the original filing and preserve the chronology. Analysts should be able to see what was already disclosed so later reports add value rather than repeat information blindly.

FIU acknowledgement and rejection

Electronic filing systems can reject submissions because of format or validation errors.

The bank should not treat “sent” as “filed successfully” until the submission status is known according to the local process. Technical rejection can create a missed filing deadline if not monitored.

Submission acknowledgements should therefore be part of the reporting evidence.

Law-enforcement production workflow

A complex production order may require records from several systems and legal entities.

A controlled workflow can allocate collection tasks while maintaining one response owner. Each source team should certify completeness for its data domain. The final response should be quality checked for scope and confidentiality before release.

This reduces the risk of incomplete or inconsistent production.

Privilege and protected material

Some internal legal communications can be privileged or otherwise protected depending on jurisdiction.

Response teams should not automatically include every document found by search. Legal review should determine whether material can or must be disclosed.

This is another reason external requests require specialist handling rather than ordinary data export.

Suspicious-report confidentiality

Law-enforcement or supervisory requests can intersect with suspicious-report records. Access and disclosure rules vary significantly by jurisdiction.

Systems should classify suspicious-report information so response teams do not accidentally include protected filing details in unrelated disclosures.

Where disclosure is permitted or required, the correct legal basis should be recorded.

Cross-border group requests

A parent bank may receive a regulator request asking for information about subsidiaries. The parent may have management access but not legal authority to disclose every local customer record.

Response governance should identify which entity is obligated to respond and whether local approvals or transfers are required.

A group coordinator can assemble the response while preserving entity-level accountability.

Supervisory colleges

Supervisory colleges allow authorities overseeing different parts of a banking group to exchange information and coordinate oversight.

For management, this means a material weakness identified in one jurisdiction may quickly become visible elsewhere. The bank should therefore assess shared-system findings for broader impact rather than assuming they remain local.

Enforcement theme analysis

Financial-crime compliance functions should analyse public enforcement themes across the industry.

The goal is not to copy another institution’s controls. It is to ask whether similar root causes could exist internally: fragmented customer data, weak sanctions governance, slow remediation, ineffective correspondent due diligence, poor monitoring or inadequate senior oversight.

Relevant themes can inform risk assessment and assurance plans.

Law-enforcement intelligence feedback

Where law and confidentiality permit, information from law enforcement can improve controls.

A request involving several mule accounts can reveal beneficiary patterns, devices or transaction corridors that monitoring teams should evaluate. A terrorism-financing alert can inform country or network risk assessments.

The feedback loop should be controlled so sensitive investigative information is not distributed broadly.

Public-private partnerships in practice

Formal partnerships can improve detection by providing focused intelligence about priority threats.

Banks should define who can receive partnership information, how it may be used, whether it can be shared internally and how resulting cases are handled.

Information from a partnership is not automatically proof. It becomes an intelligence input that the bank assesses alongside its own data.

Urgent requests

Some authority requests can be urgent, particularly where funds may move quickly or public safety is involved.

Banks should maintain an expedited process that preserves validation and approval while shortening handoffs. An emergency route should not mean “skip legal review”; it should mean predefined authority, on-call ownership and secure execution.

Out-of-hours coverage

Global banks can receive urgent requests outside local working hours.

On-call legal, sanctions or financial-crime arrangements should define who can make decisions and how evidence is captured. If no specialist is available when required, the operating model has a resilience gap.

Asset-freeze operations

A legal asset freeze can affect more than payment debits. It may affect securities, dividends, interest, corporate actions, fees and other dealings.

The bank should identify all relevant products held by the designated party and ensure restrictions propagate consistently. A freeze applied only to the current account while an investment account remains tradable is incomplete.

Licence controls across products

A sanctions licence can authorise limited activity across several systems. The bank should avoid one-off manual workarounds that different product teams interpret differently.

A central licence record with structured conditions can support consistent enforcement while still allowing product-specific implementation.

Authority-response data quality

External requests are one of the best tests of customer-data architecture.

If a request for “all accounts controlled by Person X” requires several weeks of manual name searching, entity resolution and beneficial-ownership data are weak. If one system reports a different legal name from another, the response team must reconcile them.

These problems should feed the data-remediation roadmap.

Metrics that matter

Authority-facing MI should focus on risk and reliability:

• response deadlines at risk;
• rejected FIU submissions;
• overdue regulator commitments;
• repeat information requests caused by poor initial response;
• legal holds not propagated to source systems;
• data retrieval defects;
• enforcement remediation milestones;
• frozen-asset reporting status;
• authority-request backlog by sensitivity.

Raw request volume alone says little about control quality.

Scenario: regulator tests a live sanctions case

A supervisor selects a payment alert and asks the bank to demonstrate the complete decision.

The bank should be able to show the incoming party data, screening list version, match logic, analyst evidence, legal regime, disposition, payment hold and eventual release or block. If the payment was repaired, rescreening should also be visible.

One case can test data lineage, operations, governance and auditability simultaneously.

Scenario: multiple authorities request overlapping data

An FIU and police both seek information concerning the same customer, while a supervisor is examining the bank’s handling of the relationship.

The institution should coordinate internally but maintain separate legal bases, disclosures and access restrictions. Each response record should state what was sent to whom and why.

Shared facts do not mean shared authority.

Scenario: enforcement remediation misses root cause

A regulator criticises overdue high-risk reviews. The bank temporarily hires staff and clears the backlog. Six months later the backlog returns because the review process remains manual and customer data arrives incomplete.

The remediation was not sustainable. A stronger programme would address data, workflow, capacity model and trigger design as well as the immediate queue.

Final practitioner test

A bank is ready for external scrutiny when it can answer authority requests accurately and securely, demonstrate controls using contemporaneous evidence, distinguish authority roles, preserve confidentiality, track commitments to sustainable closure and turn external intelligence into better internal controls.

Masterclass: regulators, supervisors, FIUs and law enforcement in the real operating model

Financial-crime teams often talk about "the regulator" as though every public authority performs the same job. In practice, a bank may interact with legislators, prudential supervisors, conduct regulators, AML/CFT supervisors, financial intelligence units, sanctions authorities, central banks, police, prosecutors, courts, customs agencies and tax authorities. Some countries combine several functions in one institution; others divide them across multiple bodies.

For a practitioner, the important question is not the organisation's name. It is the legal function being exercised.

Supervisor versus FIU versus law enforcement

A supervisor assesses whether the bank has an adequate and effective control framework, whether it complies with applicable requirements and whether weaknesses are identified and remediated.

A financial intelligence unit receives and analyses financial intelligence such as suspicious transaction or activity reports and disseminates relevant intelligence to competent authorities according to its mandate.

Law enforcement investigates criminal offences, gathers evidence and may use compulsory legal powers subject to the applicable legal framework.

A sanctions authority administers sanctions measures, licences, exemptions and reporting within its jurisdiction.

Those functions can intersect, but they should not be collapsed into one workflow.

Why the distinction matters to systems

A suspicious-activity report sent to an FIU is not the same object as a regulatory examination response. A law-enforcement production order is not the same as a supervisory data request. A sanctions licence application is not a suspicious report.

Each has different ownership, confidentiality, timing, evidence and approval requirements.

A good case-management architecture therefore identifies the authority type, legal basis, request type, jurisdiction, due date, confidentiality classification, accountable owner and response status.

Supervisory examination lifecycle

A typical examination or inspection may involve pre-examination information requests, data submissions, interviews, walkthroughs, file testing, control testing, observations, formal findings and remediation commitments.

The bank should treat examination evidence as a controlled record. Teams should know which version of a procedure, scenario, list configuration or risk model was operating during the period under review.

An examiner asking why a payment was released fourteen months ago does not need today's configuration. They need the control state that existed at the time of the decision.

This is why versioning is a financial-crime requirement, not merely an engineering convenience.

Case study: a supervisor questions transaction-monitoring effectiveness

Suppose a supervisor identifies that one scenario produces a very high alert volume but almost no useful escalations.

A weak response says, "The scenario is operating and all alerts are reviewed."

A stronger response asks whether the scenario still addresses the intended risk, whether the input data is complete, whether thresholds and segmentation remain appropriate, whether investigators receive enough context, whether alert ageing is acceptable, whether quality assurance shows meaningful reasoning and whether other detection methods cover the same typology.

This is the difference between control existence and control effectiveness.

FATF's supervisory guidance and Basel's AML/CFT framework both support risk-based, effective supervision rather than purely mechanical compliance.

Case study: a law-enforcement request arrives for a customer

The bank should not treat a lawful request as an ordinary service ticket.

The workflow should verify authenticity and legal authority, identify the correct legal entity and scope, preserve responsive records, apply confidentiality and need-to-know controls, meet the deadline, maintain an audit trail and avoid unauthorised customer disclosure.

The bank should also assess whether the request itself creates new financial-crime risk information relevant to the relationship, subject to applicable law and internal policy.

A request does not automatically prove criminality, but it may be a material event requiring review.

Case study: an FIU requests additional information

A suspicious report may lead to a request for supplementary information. The bank needs to retrieve the underlying transactions, KYC, ownership, prior alerts, case reasoning and relevant payment references without reconstructing the case from emails.

This is a strong test of case data lineage.

If the original report cannot be tied cleanly to the transactions and customer facts that supported it, the reporting process is not operationally mature.

Regulatory findings are not closed by writing a policy

A common remediation failure is to treat document publication as closure.

A finding about weak sanctions screening, for example, may require data remediation, configuration change, process redesign, training, historical lookback, quality assurance, governance and evidence of sustainable operation.

Closure evidence should prove that the underlying risk is addressed.

A useful remediation structure contains:

• root cause;
• affected population;
• interim risk mitigation;
• target-state design;
• implementation evidence;
• independent validation or challenge;
• sustainability period where appropriate;
• accountable executive;
• formal closure approval.

Enforcement risk

Where weaknesses are material, authorities may use enforcement powers such as directions, restrictions, penalties, remediation orders or other measures depending on jurisdiction.

The lesson for practitioners is not to memorise penalty amounts. Those change. The lesson is that weak financial-crime controls can become enterprise risk: management attention, remediation cost, restrictions on business growth, correspondent concern and reputational consequences can be substantial.

Public-private partnerships

In some jurisdictions, formal public-private partnerships allow banks and authorities to exchange typologies or intelligence within defined legal safeguards.

The value is that no single bank sees the full network. Authorities may know a threat pattern; banks may see transactions and customer relationships. Structured collaboration can improve detection.

However, information sharing must be lawful. "Useful for AML" is not itself a legal basis to share confidential customer information with another institution.

Data requests: the BA view

For every external-authority request process, the BA should capture:

1. authority and jurisdiction;
2. request type and legal basis;
3. intake channel;
4. validation steps;
5. legal-entity scope;
6. customer or transaction scope;
7. due date and escalation clock;
8. evidence sources;
9. approval chain;
10. confidentiality classification;
11. transmission mechanism;
12. acknowledgement and closure evidence.

This is much more robust than a generic requirement saying "support regulator requests."

Examination data should be reproducible

A bank should be able to reproduce, for a historic date where required:

• customer risk rating and drivers;
• KYC evidence available at that time;
• sanctions list version;
• screening configuration;
• transaction-monitoring scenario version;
• case decision and approver;
• payment state and relevant message data;
• policy and procedure version.

That is what turns governance into evidence.

Supervisory judgement and proportionality

Good supervision is risk based. FATF's guidance describes supervision that is proportionate to the size, complexity and risk of the sector and institution. Basel's January 2026 consolidated AML/CFT guidance similarly embeds ML/FT risk within the bank's overall risk-management framework.

This means a mature institution should expect supervisors to ask not only "Do you have the control?" but "Why is this the right control for your risk?"

Escalation inside the bank

Not every authority interaction belongs only to compliance.

Material findings may require executive management, board committees, legal, operations, technology, data, internal audit and business leadership.

A central tracking mechanism should distinguish observations, findings, commitments, internal issues and regulatory obligations. Mixing them into one undifferentiated action log weakens accountability.

Practitioner checkpoint

When an authority appears in a process, ask:

What legal function is this authority performing? What information can the bank share? What must remain confidential? What is the legal-entity scope? What deadline applies? What evidence proves a complete response?

Those questions prevent the common mistake of treating all external authorities as one generic stakeholder.

Further worked cases and independent practice

Use these explanations to apply the chapter's concepts. Read the lesson first, then allow additional time for the exercises and diagram interpretation. Exercise time is additional to the reading estimate.

Different authorities, different powers

A regulator or supervisor assesses whether the institution complies with laws, regulations and supervisory expectations. A financial intelligence unit receives and analyses financial intelligence under its statutory framework. Law enforcement investigates possible offences and may use subpoenas, production orders, warrants, account-monitoring orders or other lawful powers depending on jurisdiction. A sanctions authority administers or enforces sanctions measures. These functions can cooperate, but their legal bases and the bank's response obligations are not interchangeable.

The bank should therefore classify an incoming request before acting. Who issued it? Under what authority? Which legal entity received it? What data is requested? What deadline applies? Does the request prohibit customer disclosure? Does it require preservation of records or continuing monitoring? Which internal teams must be involved? A generic mailbox labelled "regulator requests" is not enough.

Worked case: one customer, three official interactions

A supervisor requests evidence of the bank's transaction-monitoring governance. Separately, law enforcement serves a production order for account statements and payment records relating to a customer. The FIU later requests supplemental information connected to a suspicious report. These three requests may involve some of the same systems and records, but the purpose, access controls, legal basis and response owners differ.

The supervisory response should demonstrate control design, governance, testing and remediation. The law-enforcement response should validate legal process, identify scope, preserve responsive records and maintain chain-of-custody or disclosure evidence as applicable. The FIU response should link back to the relevant report and provide requested information without breaching suspicious-report confidentiality.

Evidence preservation

When an official request arrives, the bank may need to preserve data that would otherwise be deleted under normal retention schedules. A legal hold or preservation instruction should be explicit, auditable and scoped. Systems should avoid silently overwriting transaction descriptions, customer profiles or case notes after the event. Investigators and reviewers need to know what the bank knew at the time.

A defensible response records the source of each document or data extract, extraction date, filters used, reviewer and delivery method. Screenshots may supplement evidence but should not replace structured transaction records where better evidence exists.

Practice exercise — work through this before reading on.

Response-workflow exercise

Design a workflow for a production order. Include intake, legal validation, conflict check, entity identification, scope interpretation, data retrieval, quality control, approval, secure delivery, deadline tracking, confidentiality, customer-contact restrictions, legal hold and closure evidence. Add edge cases: request names a closed account; records span a migrated legacy platform; customer data sits in another country; one transaction is missing from the archive; or the order is amended after work begins.

Then design a separate workflow for a regulatory examination request. Notice how control owners, evidence types and response governance differ even when some documents overlap.

Supervisory findings versus criminal allegations

A supervisory finding that a bank's controls are ineffective does not mean customers committed crimes. Likewise, a law-enforcement investigation involving a customer does not automatically establish a regulatory breach by the bank. Case systems and management reporting should preserve this distinction.

Banks should also avoid treating every official inquiry as proof of customer guilt. An information request can be exploratory. Adverse customer action should follow the applicable legal and risk framework, not simply the existence of a request.

BA and technology implications

A request-management platform should capture authority, jurisdiction, legal entity, request type, legal basis, received date, deadline, confidentiality level, customers/accounts/transactions in scope, internal owner, evidence collected, review status and proof of response. Role-based access is essential because law-enforcement and suspicious-report information can be highly restricted.

Search capability must be reproducible. If an analyst searches all transactions above a threshold between two dates, the system should preserve the query parameters and data snapshot or version so another reviewer can reproduce the result.

Final authority test

For each event, identify the likely authority type and bank response: an AML control examination; a request for transaction records in a criminal case; an FIU request for additional SAR/STR context; a sanctions blocking-report requirement; a central-bank payment-system information request; and a court order to freeze or restrain assets. Then explain why the same word—"regulator"—should not be used for all six.

A strong learner should finish the chapter able to route an official request correctly, preserve evidence, protect confidentiality and distinguish supervision, intelligence, enforcement and sanctions administration.

Extended case: responding to overlapping official requests

The following fictional case shows how authority classification changes a bank's work. The institutions, requests and counts are invented for learning. It does not prescribe a jurisdiction's legal powers or deadlines. Assume the bank's authorised legal team has validated the instruments described; the learner's task is to understand how that interpretation becomes a controlled response.

Northbank receives three communications during the same week. Its supervisor requests a sample of closed transaction-monitoring cases to assess investigation quality. A domestic law-enforcement agency serves a valid production instrument seeking specified account and payment records concerning a named company. The financial intelligence unit asks for supplementary information about a report previously submitted by the bank. The company appears in all three matters. That overlap creates an opportunity to reuse verified facts, but it does not create permission to distribute one combined investigation folder to every recipient.

Establish three matters before collecting one shared fact

The response manager opens separate records for the supervisory sample, the production instrument and the FIU follow-up. Each record identifies the bank legal entity, requester, verified contact route, legal or supervisory basis, requested population, permitted recipients, relevant deadline and release authority. Cross-links identify the overlap so that teams can avoid contradictory factual statements. The original communications remain attached to their respective matters, with access appropriate to their sensitivity.

Why not use one record with three recipient names? Because an amended request from one authority may change only that matter. A deadline extension in the supervisory examination does not extend the production deadline. A permission to provide supporting information to the FIU does not settle whether protected reporting information can be included in a different disclosure. Separate records allow the bank to coordinate the facts while preserving the distinct decisions.

An analyst notices that the company name in the production instrument differs slightly from the customer master. That is a resolution task, not a reason to quietly broaden the search to every similar name. The team compares the identifiers included in the request with available incorporation, address and account information. If ambiguity remains, the authorised response owner seeks clarification through the verified channel. The search record preserves the identifiers used, the matching reasoning and any limits agreed. The bank should be able to explain why a particular account entered or remained outside the response population.

Convert the request into an explicit population

For this example, the validated production scope is the company's specified account during a defined period. It includes payment instructions and their outcomes, including unsuccessful instructions. The supervisor, by contrast, wants a risk-based sample of monitoring cases across a wider customer population. The FIU wants additional information about particular counterparties and onward movements. These populations overlap but have different units: instructions, cases and financial relationships.

A data engineer initially provides 267 event rows for the specified account. A payment operations specialist identifies 250 distinct instruction identifiers; ten additional rows are retransmissions and seven are subsequent status updates. The engineer has not necessarily made an error. The extract and the response question use different units. The response team documents that distinction and retains the events needed to explain the instruction history. Deleting every repeated identifier would lose legitimate status changes, while presenting all 267 rows as separate payments would overstate activity.

The investigator then asks whether an incoming payment later returned belongs in the population. The answer depends on the validated request scope, not on whether the ledger's present balance is zero. A return may be a separate event relevant to the original instruction. Netting it away can erase evidence of the attempted or completed movement. The response should represent original and subsequent events intelligibly and explain how they relate. The bank does not make an external reader infer a return solely from an unexplained negative amount.

Time boundaries need the same care. The request may specify dates in a local jurisdiction, while event timestamps are stored in UTC and statements use a booking date. The approved extraction definition records the time basis and boundary treatment. An instruction near midnight can appear on different calendar dates without either system being wrong. A reproducible response explains which clock determined inclusion and preserves the original timestamps needed to interpret the sequence.

Reuse verified facts without reusing every document

The team can prepare a factual ledger of the company's identity, account relationship, instructions and relevant counterparties. Each entry points to its source and states whether it is verified, customer-provided or an unresolved interpretation. That factual ledger helps the different response teams avoid inconsistent dates or amounts. Access to it is still subject to the approved scope; a coordination mechanism is not an unrestricted data pool.

The documents produced for each matter remain separate. A monitoring case may contain protected reporting information, legal advice, internal quality-review comments and references to unrelated customers. Whether any of those materials can or must be disclosed requires the applicable legal analysis. An instruction to provide payment records should not be treated as automatic authority to export the entire case platform. Equally, an employee should not remove responsive information merely because it is inconvenient. The authorised review identifies the proper treatment and records the reason.

Redaction also needs traceability. The working copy, the approved disclosed copy and the retained original serve different purposes. Reviewers need to know what was withheld, on whose decision and under which basis, without placing protected content into an ordinary release log. A redacted PDF that can reveal hidden text when copied has not achieved the intended result. The validation method should fit the format used, including attachments and embedded metadata where relevant.

Review the response as a recipient would read it

Before release, a reviewer attempts to reconstruct one example instruction from the response package alone. Can they identify the original amount and currency, the parties, the instruction time, the outcome and any related return? Are unfamiliar field names explained? Does “completed” mean accepted by an internal application, settled at an infrastructure, or credited to a beneficiary? If the package contains several systems' statuses, the explanation must retain their different meanings.

The reviewer also checks the negative statements. “No records found” can mean that the bank has no relevant relationship, that the searched system contains no matching records, that the records fall outside its retention period, or that an extraction failed. Those are materially different statements. The response should say what was searched and what the result supports. A technical timeout must not become a factual assertion that the customer had no transactions.

The supervisory sample requires a different review. A case narrative written after the examination request must not be presented as the rationale recorded at original closure. A retrospective explanation may be useful if clearly identified as such, but it cannot repair missing contemporaneous evidence by changing its apparent date. The response should distinguish the original file, later clarification and any remedial action. That allows the supervisor to assess both the historical weakness and the bank's response to it.

For the FIU matter, the reporting team checks that the supplementary information is linked to the correct prior report through the approved local mechanism. It explains newly available facts and any correction to earlier information. The bank should not assume that sending an ordinary email, completing an internal case task or receiving a transport-level acknowledgement proves that the required submission has been accepted in the relevant reporting process.

Release, receipt and correction are separate events

The approved response is released only through the verified destination for that matter. The release record identifies the authorised approver, exact package, transmission method and time. A checksum can help distinguish versions of a digital file; it does not prove the underlying facts are correct or that the recipient has authority. The bank retains both the content review and the transmission evidence rather than using one as a substitute for the other.

After release, the team checks the relevant delivery outcome. A portal rejection may require a corrected submission. A recipient may ask for clarification or identify a file they could not open. The matter remains controlled through those events. Closing it because an employee clicked “send” can leave an actual response obligation unfinished.

Suppose the bank later finds that a timestamp label in the production package was incorrect. The response owner assesses the error's scope, preserves the original release, prepares a clearly versioned correction and obtains the appropriate approval for communication. Silently replacing the file in an archive would make the audit trail less reliable. The supervisory and FIU teams separately assess whether their own submissions used the same incorrect field. One defect can require several coordinated decisions without justifying a single undifferentiated disclosure.

What the case teaches about authority roles

The supervisor is assessing the institution's control framework and evidence. The law-enforcement production is responding to the validated instrument's specific requirements. The FIU follow-up is supporting financial-intelligence analysis through the applicable reporting channel. None of those roles makes the bank responsible for declaring that the company committed an offence. The bank's contribution is accurate, intelligible information and properly authorised action.

The four authority diagrams in the chapter can now be read as a practical workflow. The authority map identifies the function. The matrix distinguishes the kind of interaction. Request triage establishes scope and authority. The response flow takes that decision through evidence collection, review and release. The diagrams are most useful when the learner can explain why the same company produces three separate matter records and why a shared factual record does not imply shared disclosure permission.

Worked answer: what the response platform must preserve

The authority-response exercise earlier in this chapter asks how a group platform should handle a request issued to one subsidiary when relevant records sit in several systems. A defensible design begins with a request object, not a customer folder. The request object records the verified sender, addressed legal entity, authority or instrument, interpreted scope, relevant dates, responsible reviewer and authorised response channel. Each amendment creates a version. The platform then links the request to collection tasks and evidence objects; it does not treat every document about the customer as automatically disclosable.

A useful evidence object separates the original record from the proposed disclosure copy. The original retains source identifiers, extraction details and integrity information. The copy carries the disclosure decision, approved transformations or redactions, reviewer and destination. A legal hold, where required, operates on retention separately from access and disclosure. Preserving a record does not mean that every investigator or group affiliate may read it. Conversely, withholding material from one response does not justify deleting the preserved original.

Completeness is demonstrated against the interpreted scope. If the request covers three accounts across twelve months, the reviewer needs a coverage matrix for those accounts and periods, including closed or migrated records. An unexplained blank is not evidence of no activity. The matrix should distinguish confirmed absence, unavailable data, pending collection and material excluded from disclosure. This makes a qualified response intelligible without allowing an operational team to decide legal disclosure questions silently.

Finally, the platform should retain the exact approved package, its version, approval record, recipient and delivery evidence. A successful upload is evidence of transmission; whether it fulfils the request also depends on scope, readability and any required acknowledgement. The linked customer-risk review has its own decision owner and rationale. That separation prevents the fact that an authority asked a question from becoming an unsupported finding that the customer committed an offence.

References and further reading

The sources below are authoritative starting points for the roles, powers and cooperation models discussed in this chapter. They do not create one universal bank procedure. Legal-request instruments, disclosure gateways, suspicious-report confidentiality, sanctions duties, privacy restrictions, legal privilege and deadlines must always be mapped to the jurisdiction and legal entity handling the matter.

Global standards and supervisory architecture

• Financial Action Task Force (FATF) — The FATF Recommendations, amended June 2026: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html
• FATF — Guidance for a Risk-Based Approach: Effective Supervision and Enforcement by AML/CFT Supervisors of the Financial Sector and Law Enforcement: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Rba-effective-supervision-and-enforcement.html
• FATF — Guidance on Risk-Based Supervision: https://www.fatf-gafi.org/content/dam/fatf-gafi/guidance/Guidance-Risk-Based-Supervision.pdf.coredownload.pdf
• FATF — Methodology for Assessing Technical Compliance with the FATF Recommendations and the Effectiveness of AML/CFT/CPF Systems: https://www.fatf-gafi.org/content/dam/fatf-gafi/methodology/FATF-Assessment-Methodology-2022.pdf.coredownload.inline.pdf
• Basel Committee on Banking Supervision — Anti-money laundering and counter-terrorist financing consolidated guidance, January 2026: https://www.bis.org/committees/bcbs/basel-consolidated-guidelines/module/afs/10
• Basel Committee on Banking Supervision — Sound management of risks related to money laundering and financing of terrorism: revisions to supervisory cooperation, 2 July 2020: https://www.bis.org/publications/202007-guidelines-sound-management-risks-related-money-laundering-and-financing-terrorism-revisions-supervisory-cooperation

Financial intelligence units and information exchange

• Egmont Group — Financial Intelligence Units: https://egmontgroup.org/about/financial-intelligence-units/
• Egmont Group — About the Egmont Group: https://egmontgroup.org/about/
• Egmont Group — Principles for Information Exchange Between Financial Intelligence Units: https://egmontgroup.org/egmont-resources/egmont-group-of-financial-intelligence-units-principles-for-information-exchange-between-financial-intelligence-units/

European Union

• European Banking Authority — EBA and AMLA complete handover of AML/CFT mandates, 19 January 2026: https://www.eba.europa.eu/publications-and-media/press-releases/eba-and-amla-complete-handover-amlcft-mandates
• Authority for Anti-Money Laundering and Countering the Financing of Terrorism (AMLA) — About AMLA: https://www.amla.europa.eu/about-amla_en
• AMLA — Frequently asked questions, including direct-supervision timing: https://www.amla.europa.eu/faqs_en
• AMLA — Data collection exercise to test risk-assessment models ahead of the 2027 selection process, 16 March 2026: https://www.amla.europa.eu/amla-launches-data-collection-exercise-test-risk-assessment-models_en

United Kingdom

• National Crime Agency — Suspicious Activity Reports and the UK Financial Intelligence Unit: https://www.nationalcrimeagency.gov.uk/what-we-do/crime-threats/money-laundering-and-illicit-finance/suspicious-activity-reports
• Financial Conduct Authority — Money laundering and terrorist financing supervision: https://www.fca.org.uk/firms/financial-crime/money-laundering-terrorist-financing
• Office of Financial Sanctions Implementation — About OFSI: https://www.gov.uk/government/organisations/office-of-financial-sanctions-implementation/about

United States

• Financial Crimes Enforcement Network — What We Do: https://www.fincen.gov/about-fincen/what-we-do
• FinCEN — Support of Law Enforcement and Section 314(a): https://www.fincen.gov/resources/law-enforcement/support-law-enforcement
• FinCEN — Section 314(a): https://www.fincen.gov/resources/section-314a
• FinCEN — Section 314(b) information sharing: https://www.fincen.gov/resources/section-314b
• FinCEN and the federal banking agencies — Joint Statement on Suspicious Activity Report Confidentiality and Customer Communications, 2 September 2026: https://www.fincen.gov/news/news-releases/fincen-agencies-issue-joint-statement-suspicious-activity-report-confidentiality
• Office of Foreign Assets Control — OFAC Reporting System: https://ofac.treasury.gov/ofac-reporting-system
• Office of Foreign Assets Control — FAQ 5 on assessing sanctions matches and applicable outcomes, updated 9 September 2026: https://ofac.treasury.gov/faqs/5

Australia

• AUSTRAC — About AUSTRAC and its regulator/FIU role: https://www.austrac.gov.au/about-us/what-we-do/about-austrac
• AUSTRAC — External audit direction to Airwallex, 22 January 2026: https://www.austrac.gov.au/news-and-media/media-release/austrac-orders-audit-airwallex-suspected-amlctf-compliance-failures
• AUSTRAC — External audit direction to a payment platform, 2 April 2026: https://www.austrac.gov.au/news-and-media/media-release/austrac-directs-audit-payment-platform-over-amlctf-concerns

These sources should be used with the bank's current legal interpretation and local procedures. A public authority's interest in a customer is a risk signal or legal event, not proof of criminal conduct, and the operational response must follow the exact power being exercised.