Financial Crime, AML, CFT, Sanctions and Fraud

Financial crime is easiest to misunderstand when a bank uses one convenient label for several different problems. Money laundering, terrorist financing, sanctions breaches or evasion, proliferation financing, fraud, bribery, corruption, tax crime and cyber-enabled crime can touch the same customer, account, payment or company. They often share data and they often expose the same weaknesses in onboarding, payment processing or case management. Yet they do not have one universal legal definition, one detection method, one reporting route or one operational outcome.

That distinction matters in real banking. A genuine customer can authorise a payment that is not fraudulent but is still prohibited by sanctions. A payment can be permitted under sanctions but still form part of a laundering pattern. Money used for terrorist financing can come from lawful salary or business income. Fraud can create criminal proceeds that later move through mule accounts and become an AML problem. A company can have no sanctions-list match but still create sanctions exposure through ownership, control, geography, goods, services or transaction purpose. The same event can therefore be acceptable through one risk lens and unacceptable through another.

This chapter builds a joined mental model for those disciplines. The objective is not to turn every analyst into a specialist in every legal regime. It is to show how a bank should connect the story without collapsing the decisions. That is useful for compliance professionals and investigators, but it is equally important for operations, business analysts, architects, developers, testers and product owners. Many serious control failures start not with a bad intention but with a vague requirement such as “perform AML screening” or “stop financial-crime payments” when nobody has defined which risk is being controlled, which data is needed, who owns the decision, when the decision must happen, or what the system should do with the payment while the decision is unresolved.

The simplest mental model: one event, several lenses

Think of a bank event as a common fact pattern viewed through several specialist lenses.

A customer instructs a payment. The fraud lens asks whether the customer genuinely authorised it, whether the customer has been manipulated, whether the credentials or device are compromised, and whether immediate intervention could prevent loss. The sanctions lens asks whether an applicable legal restriction affects a party, asset, jurisdiction, sector, service, vessel, good or activity, and what the applicable authority requires the bank to do. The AML lens asks whether the activity, in context, may involve criminal proceeds or another suspicious pattern that requires investigation and possibly reporting. The CFT lens asks whether funds, financial services or a network may support terrorism, remembering that the source of the money can be lawful. The proliferation-financing lens asks whether value or financial services may support proliferation-sensitive activity or the breach, non-implementation or evasion of relevant targeted financial sanctions.

Those questions may be triggered by the same transaction, but they are not interchangeable.

That is the first principle of a sound operating model: share the evidence, preserve the meaning. Customer identity can be reused. Ownership data can be reused. Payment parties and transaction history can be reused. Device intelligence, adverse information and case relationships can be reused where law and policy permit. But the bank should not convert those reusable facts into one generic financialCrimeResult that loses the reason for the decision.

The second principle is that a signal is not the same as a conclusion. A name-screening match is a signal. A transaction-monitoring alert is a signal. A fraud score is a signal. An adverse-media result is a signal. A front-line referral is a signal. The bank still needs context, evidence, the applicable legal or policy standard and an accountable decision.

The third principle is that time matters differently in each discipline. Fraud may need a decision in milliseconds or seconds because customer money can disappear instantly. Sanctions screening may need to resolve before a payment or asset dealing is released. AML monitoring may identify a pattern only after several transactions have occurred. A suspicious-activity reporting clock may start at a defined point under local law. Customer due diligence can operate over months or years, with periodic and event-driven reviews. A joined financial-crime model therefore needs more than one queue and more than one service-level target.

“Financial crime” is an operating umbrella, not one legal offence

Banks commonly use financial crime as an organisational umbrella. It helps group related risks, policies, technology and investigative capabilities. A chief financial crime officer may have responsibility across AML, CFT, sanctions, anti-bribery and corruption, tax crime, fraud or other areas. A common data platform may support several of those controls. A case-management tool may host multiple case types. A financial-crime risk assessment may aggregate exposures across customers, products, countries and delivery channels.

That does not make financial crime a single offence with a single global definition.

The legal foundation comes from specific laws and regulatory frameworks. Money laundering offences are defined in national law. Terrorist-financing offences and terrorism-related targeted financial sanctions are implemented through national or regional frameworks that reflect international obligations. Sanctions authorities issue measures under their own legal mandates. Fraud offences and payment-service protections vary by jurisdiction. Bribery, corruption and tax offences have separate legal elements. The bank therefore needs a taxonomy that is broad enough for governance but precise enough for decisioning.

A useful design pattern is to separate three layers.

The risk-domain layer identifies the broad area: AML, CFT, sanctions, proliferation financing, fraud, bribery and corruption, tax crime, market abuse, cyber-enabled financial crime or another defined domain.

The control layer identifies what the bank is actually doing: customer due diligence, customer screening, payment screening, transaction monitoring, device-risk assessment, adverse-media review, source-of-wealth assessment, trade-document review, fraud authentication, case investigation or regulatory reporting.

The decision layer records the outcome under the relevant law and policy: clear, investigate, escalate, report, restrict, decline, reject, block, freeze, return, recall, reimburse, exit, retain evidence or another explicitly defined result.

When systems merge those layers, errors become likely. A transaction can be “clear” for fraud because the customer confirms it, but unresolved for sanctions because the beneficiary may be a designated person. It can be “clear” for sanctions and still require AML investigation because its commercial purpose and movement pattern are unexplained. A single pass/fail field cannot safely express that.

Anti-money laundering: criminal proceeds, misuse and suspicion

Anti-money laundering is concerned with preventing, detecting and responding to the misuse of the financial system to deal with criminal proceeds and related suspicious activity. FATF’s international standards provide a common architecture, including criminalisation of money laundering, customer due diligence, beneficial ownership, recordkeeping, suspicious transaction reporting, correspondent-banking controls, risk assessment and supervision. The binding implementation, however, comes through local law and regulation.

The bank rarely observes the predicate offence directly. It usually sees financial traces.

A customer may receive funds from many unrelated parties and move them out rapidly. A company may send money through a chain of entities that does not match its stated business. Cash deposits may be inconsistent with the customer’s profile. Trade payments may not fit the goods, invoices or commercial counterparties. Multiple accounts may behave as a coordinated network. A dormant account may suddenly become a pass-through vehicle. A professional intermediary may move client money without a clear reason. None of those facts alone proves money laundering. The AML process combines them with customer knowledge, product context, geography, counterparties, transaction history and other evidence.

That is why AML is strongly contextual. A high-value cross-border payment can be normal for a multinational treasury operation and highly unusual for a newly opened personal account. A cash-intensive business may legitimately deposit significant cash. A charity may send money to difficult regions for lawful humanitarian work. The control objective is not to punish unusual activity. It is to identify activity that cannot be reasonably explained in context and to escalate it under the applicable standard.

A mature AML framework therefore operates across the customer lifecycle. Customer due diligence creates a baseline. Ongoing monitoring tests whether observed activity still fits what the bank understands. Event-driven review updates the profile when ownership, business activity, geography or behaviour changes. Transaction monitoring and other forms of monitoring for suspicious activity generate leads. Investigators gather evidence and form a reasoned view. Where the local legal threshold is met, the bank files the required suspicious activity or suspicious transaction report with the relevant financial intelligence unit or authority.

The reporting language and threshold are jurisdiction-specific. “SAR,” “STR,” “suspicious matter report” and similar terms are not universally interchangeable. Filing deadlines, monetary thresholds where applicable, confidentiality rules and the point at which the reporting clock begins also differ. A global system should therefore not hard-code one country’s reporting rule as if it were a FATF rule.

The role of the financial intelligence unit is also distinct from the role of the bank. Under FATF Recommendation 29 and the Egmont framework, an FIU serves as a national centre for receiving and analysing suspicious transaction reports and other relevant information and for disseminating the results of its analysis. The bank provides financial intelligence; it does not replace the FIU, police, prosecutor or court.

Operationally, AML is often a pattern-and-context discipline. Some decisions are urgent, but many conclusions emerge only after the bank joins customer, account, payment and network information over time.

Counter-terrorist financing: purpose and network can matter more than source

Counter-terrorist financing overlaps with AML but begins from a different conceptual problem. Money laundering typically asks how criminal proceeds are being handled, disguised or integrated. Terrorist financing can involve money that was earned completely lawfully. Salary, business revenue, donations or ordinary savings can be diverted to support terrorist acts, terrorists or terrorist organisations.

That difference changes what analysts should look for.

A source-of-funds review may show nothing criminal. The value may be modest. The customer may not display the classic layering behaviour associated with laundering. The important facts may instead be the beneficiary, network, destination, associated persons, repeated small-value transfers, fundraising method, use of cash or informal transfer channels, digital-platform activity, travel or other contextual intelligence.

FATF Recommendation 5 deals with the terrorist-financing offence, while Recommendation 6 addresses targeted financial sanctions related to terrorism and terrorist financing. Those are connected but separate controls. Behavioural CFT monitoring may identify previously unknown activity that merits investigation. Terrorism-related sanctions screening tests customers and transactions against applicable designations and other legal restrictions. A bank needs both.

This distinction is especially important when people say “CFT is just AML for terrorism.” It is not. Some control components are shared, but the evidential logic can differ. The absence of criminal proceeds does not remove the risk. Low value does not automatically mean low risk. A payment can appear economically ordinary but become significant when linked to a known network or intelligence pattern.

FATF’s 2025 comprehensive update on terrorist-financing risks emphasised the continued use of diverse methods, including cash, money or value transfer services, formal financial services, online payment services, virtual assets, digital platforms and misuse of legal persons. FATF’s June 2026 work also highlighted abuse of social media, instant messaging and streaming platforms for fundraising and movement of value. The lesson for banks is not to build a scenario for every new technology keyword. It is to maintain an adaptable risk model that can combine financial behaviour with lawful intelligence sources, customer context and network relationships.

There is another current nuance. In June 2026 FATF updated Recommendation 6 to align with UN humanitarian exemptions. For banks, that reinforces a broader principle: counter-terrorist financing controls must be effective without being mechanically overbroad. A control that stops legitimate humanitarian activity simply because geography is difficult is not automatically a stronger control. The correct result depends on the applicable legal framework, exemptions, licences, risk assessment and evidence.

Sanctions: legal restrictions with jurisdiction-specific consequences

Sanctions are not simply “high-risk AML.” They are legal restrictions imposed by competent authorities for foreign-policy, national-security or related objectives. Depending on the regime, restrictions may concern designated people or entities, ownership or control, countries or territories, economic sectors, securities, lending, services, vessels, aircraft, goods, technology, trade or specific activities.

The operational consequence can be immediate and legally prescribed.

A bank may be required to freeze assets, block a transaction, reject or refuse activity, stop providing a service, prevent funds or economic resources from being made available, submit a report, obtain or validate a licence, or apply another restriction. The precise action depends on the governing law, the bank legal entity, the transaction nexus, the sanctions programme and the facts. Even within one authority, not all sanctions programmes operate in the same way. OFAC, for example, expressly describes US sanctions programmes as comprehensive or selective and uses different forms of blocking and trade restrictions. That should not be translated into a universal global rule.

Sanctions screening is one control within sanctions compliance, not the entire programme.

Name screening compares customer or payment data with sanctions data. A fuzzy match to a common name does not prove that the person is designated. Analysts may need date of birth, nationality, address, passport or registration number, aliases, ownership information or other identifiers. Entity screening can require beneficial-ownership and control analysis. Payment screening can need debtor, creditor, ultimate-party, agent, address, remittance, vessel or other message data. Trade controls can require information that may never appear in a normal credit-transfer message.

A company may not be named on a list but may still be restricted because of ownership or control under the applicable regime. Conversely, a company sharing a word with a listed entity is not automatically sanctioned. This is why entity resolution and legal applicability must be separate stages.

Sanctions also create a different decision clock from ordinary post-event AML monitoring. Many controls must operate before the bank releases a payment or deals with an asset. If a potential match cannot be resolved automatically, the transaction may need to be held or otherwise controlled while an authorised team investigates. The system must preserve the original instruction, the screening data, the list version, the match details, the analyst decision, the legal basis and the final transaction outcome.

The important global lesson is jurisdiction and nexus. OFAC is highly relevant where US law or a US nexus applies, but it is not the sanctions authority for every bank in the world. EU restrictive measures, UK financial sanctions and other national or supranational regimes can differ in scope, ownership tests, licensing and reporting. A global bank therefore needs a sanctions applicability model rather than one undifferentiated list.

Proliferation financing: related to sanctions, but not reducible to name screening

Proliferation financing concerns financing connected with the proliferation of weapons of mass destruction and related programmes, procurement networks, goods, technology and means of delivery. In practice, banks may encounter the risk through trade finance, correspondent banking, cross-border payments, virtual assets, shipping, corporate structures, front companies, intermediaries, dual-use goods and complex ownership chains.

It is important to be precise about the FATF framework. FATF Recommendation 7 concerns targeted financial sanctions related to proliferation. FATF’s Recommendation 1 framework also requires assessment and mitigation of proliferation-financing risk in relation to potential breaches, non-implementation or evasion of relevant targeted financial sanctions. Domestic sanctions, export-control or criminal-law obligations can be broader and should be identified separately rather than attributed generically to FATF.

The distinction matters for system design. A payment filter may find a designated party, but a proliferation-financing investigation may begin somewhere else: an unusual trading company, a newly inserted intermediary, a shipping route, a controlled or dual-use item, a change in beneficial ownership, inconsistent end-use information, or a cluster of transactions that individually appear ordinary.

FATF’s 2025 report on complex proliferation-financing and sanctions-evasion schemes highlighted the use of intermediaries, obscured beneficial ownership, virtual assets and maritime or shipping techniques. Those are not automatic proofs of proliferation financing. They are risk indicators that become meaningful when combined with the customer, goods, geography, network and transaction context.

For a bank, the correct mental model is therefore sanctions plus context, not sanctions instead of context. Targeted financial sanctions can create immediate legal obligations. Broader PF risk management helps the bank understand whether customers, products and transactions are being used to circumvent those controls or support proliferation-sensitive activity.

Fraud: customer harm, deception and speed

Fraud is often the most time-sensitive financial-crime domain because money can leave the victim’s control immediately. The bank may be dealing with stolen credentials, account takeover, card fraud, identity fraud, loan fraud, merchant fraud, business-email compromise, authorised push-payment scams, social engineering or first-party deception. The taxonomy and legal treatment vary by product and jurisdiction.

Fraud controls therefore use evidence that AML systems may not prioritise. Device identity, session behaviour, authentication events, IP or network signals, behavioural biometrics, beneficiary novelty, transaction velocity, card-present or card-not-present context, historical login patterns and customer confirmation can all be critical.

The decision can be sub-second. A bank may decline a card authorisation, require step-up authentication, hold a transfer for confirmation, disable a digital session, contact the customer, attempt a recall or recovery, or start a reimbursement process under applicable rules.

Fraud and AML nevertheless intersect constantly because fraud creates proceeds.

Consider an authorised push-payment scam. The victim genuinely logs in and authorises the transfer after being deceived. A simple authentication control may conclude that the customer is genuine. The fraud problem is not stolen credentials; it is manipulation. The receiving account may be a mule. Once the funds arrive, AML-relevant patterns can include multiple unrelated credits, rapid onward transfers, cash-out, virtual-asset conversion or distribution across a network. The fraud team is trying to prevent or recover victim loss; the AML team is trying to understand and report the laundering or mule network where required.

The European Banking Authority’s payment-fraud reporting framework is a useful jurisdiction-specific illustration because it distinguishes unauthorised payment transactions from transactions where the payer is manipulated into initiating a payment. That is not a universal global fraud definition, but it demonstrates why fraud systems need more precise classifications than “authorised versus unauthorised.”

Fraud cases can also generate valuable intelligence for AML, sanctions and CFT. A mule account linked to scam proceeds may share devices or beneficiaries with other customers. A fraud investigation may reveal a shell company or false identity. A cyber-enabled theft may fund a sanctioned or proliferation-related network. The right architecture should make relevant intelligence available without assuming that the fraud decision itself answers the AML or sanctions question.

Bribery, corruption, tax crime and other predicate risks

Financial crime programmes often extend beyond AML, CFT, sanctions and fraud because other offences generate proceeds or create separate conduct and legal risks.

Bribery and corruption can appear as consultancy fees, commissions, gifts, hospitality, sponsorships, charitable payments, procurement arrangements, inflated contracts or benefits routed through relatives and intermediaries. Banks may see the resulting money movement rather than the original corrupt agreement. Politically exposed person controls, beneficial-ownership analysis, source-of-wealth review and adverse information can help identify relevant risk, but a PEP is not a finding of corruption. Political exposure is a risk factor that can justify enhanced measures under applicable frameworks.

Tax crime requires equal care with terminology. Tax evasion can constitute a predicate offence to money laundering under applicable law, but lawful tax planning is not the same thing. A complex offshore structure is not automatically criminal. The bank needs evidence of behaviour such as concealment, false documentation, sham arrangements, unexplained ownership or other facts that indicate a legal or AML concern. Separate tax-transparency regimes may create reporting obligations, but those are not interchangeable with suspicious-activity reporting.

Cyber-enabled crime can create both fraud and AML consequences. Ransomware, phishing, account takeover, business-email compromise and theft of virtual assets can produce proceeds that later move through bank accounts, exchanges and intermediaries. Market abuse, trafficking, environmental crime, narcotics, organised crime and other predicate offences can also generate value that enters the financial system.

The practical lesson is that the bank should maintain a clear relationship between predicate or underlying activity and financial-control response. The bank may not know the exact predicate offence at the time of filing a suspicious report. It still needs enough facts to explain why the activity is suspicious and what risk indicators are present.

A comparison that prevents category errors

The following table is not a legal rulebook. It is a practical way to stop teams from collapsing different domains into one vague “financial crime check.”

The table should be implemented conceptually in systems too. A bank needs explicit domain, trigger, owner, status and outcome data so that one control does not silently overwrite another.

Where the risks appear across the customer lifecycle

A joined financial-crime view becomes practical when it is mapped to the lifecycle of a bank relationship.

Before onboarding

Risk can appear before the bank accepts the customer. Identity may be false or stolen. A company may have opaque ownership. A prospective customer may be a sanctioned person or owned or controlled by one under the applicable regime. The business model may involve higher-risk geographies, products or sectors. Adverse information may raise questions about fraud, corruption, organised crime or other predicates.

Different teams can use the same evidence differently. Identity-verification controls may focus on whether the person is real and present. Sanctions screening focuses on whether the verified person or connected party is subject to applicable restrictions. AML/KYC focuses on whether the bank understands the customer, ownership, purpose and expected activity sufficiently to manage the relationship. Fraud prevention may examine synthetic identity, device or application patterns. The onboarding decision should preserve those distinct reasons.

At account and product setup

Product choice changes the risk surface. A basic domestic account, high-value private-banking relationship, correspondent account, merchant-acquiring service, trade-finance product, card programme and virtual-asset-related service do not expose the bank in the same way.

Controls therefore need product context. Expected transaction values, countries, counterparties, cash usage, payment channels and authorities should be captured in reusable data where appropriate. If the customer is approved for a product subject to special restrictions, the downstream payment and monitoring systems need to know. It is not enough for a compliance analyst to record the condition in free text.

At login, authentication and instruction creation

Fraud risk becomes especially visible at the channel. A new device, unusual session, change of contact details, new beneficiary, unusual navigation or repeated failed authentication can indicate account takeover or manipulation. Those signals are usually time-sensitive.

AML may not need to stop the session, but the same event can enrich later investigation. If several accounts that appear unrelated use the same device or network pattern, that may become useful relationship evidence. Data sharing should be controlled and proportionate, but the architecture should not make cross-domain analysis impossible.

At payment initiation

The payment instruction creates another set of control opportunities. The bank can validate customer authority, account status, limits, beneficiary details and payment data. Fraud controls may score the transaction. Sanctions controls may screen relevant parties or attributes. Product or country restrictions may apply. Some banks may perform other pre-transaction risk checks based on risk appetite and legal requirements.

The important design question is not “does the payment pass financial crime?” It is which controls are mandatory before release, which can operate asynchronously, and how unresolved results interact.

If fraud is clear but sanctions is unresolved, the payment should not be treated as fully clear. If sanctions is clear but fraud is high risk, the sanctions result should remain clear while the payment is still held for fraud. If both are clear but an account restriction exists because of an investigation or court order, the orchestration layer must respect that separate control.

During routing and processing

Cross-border payments can pass through multiple banks. Each institution applies its own legal obligations, policies and risk appetite. An intermediary or correspondent may screen data that the originating bank has already screened and can reach a different result because it applies a different jurisdiction, sanctions list, matching rule or customer context.

Message quality matters. Names, addresses, debtor and creditor details, ultimate parties, agents, remittance information and payment identifiers can support screening and investigation. Truncation, poor mapping or unstructured data can weaken controls. ISO 20022 can improve structure, but only if the data remains complete and correctly mapped across channels, hubs, screening engines, gateways, ledgers and investigation platforms.

After execution

Post-event monitoring becomes important once activity accumulates. A single transaction may look ordinary while the pattern across time is not. Multiple credits from unrelated parties, rapid pass-through behaviour, repeated transfers to common beneficiaries, circular movement, sudden use of new geographies or activity outside the customer’s profile can generate AML or fraud intelligence.

A post-event alert should retain the original transaction data and link to the customer profile that existed at the time. If the current KYC profile has changed, investigators may need both the historic and current versions. That is why effective dating and data lineage matter.

During investigation and reporting

An investigation can join information from onboarding, payments, cards, devices, trade systems, sanctions screening, customer contacts, previous cases and external sources. The investigator should be able to distinguish verified facts from allegations, system-generated scores from human conclusions, and current data from historical data.

If suspicion is reached, the case may proceed to a jurisdiction-specific reporting process. If a sanctions match is confirmed, the sanctions legal and reporting outcome may be separate from any AML report. If fraud is confirmed, customer recovery and reimbursement processes may continue in parallel. One case can therefore produce several linked outcomes without those outcomes being identical.

During restriction, review or exit

A bank may decide to apply enhanced monitoring, product restrictions, account limitations or relationship exit depending on law, policy, risk appetite and evidence. Those decisions can have significant customer impact and should be governed carefully.

Exit is not a substitute for reporting where reporting is required. Reporting is not automatically a legal instruction to close an account. A sanctions freeze is not the same as a discretionary risk-based exit. Fraud channel restrictions may be temporary while the customer is authenticated. The system and operating procedure should preserve those distinctions.

Shared data does not mean shared semantics

Financial-crime controls are data-hungry, and it is tempting to build one enormous data lake and assume integration is solved. Integration is useful only when meaning travels with the data.

A customer name should have an original value, normalised forms where used, source system, effective date and relationship to the customer record. A beneficial owner should have an ownership or control relationship, percentage where relevant, evidence source, verification status and effective dates. A payment should preserve the original instruction, transformed messages, transaction identifiers, parties, agents, values, currencies, timestamps and status history. A sanctions screening result should record which data element was screened, against which data set and version, what matching logic triggered, what identifiers were compared and who resolved the result.

Fraud evidence needs its own semantics. A device identifier is not proof that two customers are the same person. An IP address can be shared. Behavioural scores are probabilistic. Customer confirmation can be useful but can also occur under social engineering. AML investigators should receive the evidence and its limitations rather than a binary “fraud link.”

The same principle applies to adverse media. A search result mentioning a name is not verified identity. A PEP classification is not an allegation of wrongdoing. A sanctions-list match is not a confirmed legal match until entity resolution and applicable legal analysis are complete. Case data should identify the source, confidence, date and decision status.

Data lineage is especially important when controls fail. If a sanctions engine did not receive ultimate-creditor data because an interface dropped the field, the bank needs to know which payments were affected and during what period. If a transaction-monitoring scenario used the wrong customer-risk attribute after a mapping change, the bank may need a lookback. Without lineage, remediation becomes guesswork.

Screening, monitoring and fraud scoring are different detection patterns

A bank should not use the word “screening” for every financial-crime control.

Screening usually compares a party, identifier or data element with a reference data set. Sanctions and PEP screening are common examples. Matching may use exact, fuzzy, phonetic, transliteration or other logic. The output is normally a potential match requiring resolution or a clear result.

Monitoring observes behaviour, events or relationships over time. Traditional transaction monitoring is part of this, but modern monitoring for suspicious activity can combine customer attributes, transactions, network patterns and other risk indicators. The Wolfsberg Group’s 2024 and 2025 work explicitly encourages a broader view than automated transaction monitoring alone.

Fraud scoring or decisioning can combine real-time session and transaction features to predict risk or determine whether additional authentication or intervention is needed. Its performance measures, latency constraints and customer-experience trade-offs can differ materially from AML monitoring.

Rules-based policy controls can enforce known restrictions without generating an investigative alert. A product may prohibit a destination, a sanctioned sector may restrict a particular financing activity, or an account may have a legal hold.

Human referrals remain important. A relationship manager, operations analyst, customer-service agent or investigator may notice something that an automated model does not. A mature programme has a controlled route for those referrals and does not treat them as second-class data.

The output of detection should therefore include enough information for the next stage. “Score 87” is not enough. The investigator needs to know what drove the score, what data was available, which event triggered it and how to reach the underlying evidence.

Alert, case, investigation and report are not synonyms

Financial-crime operations often become confused because teams use workflow words loosely.

An alert is a prompt for review. It may come from a transaction-monitoring scenario, screening engine, fraud model, rule, external intelligence source or internal referral.

A case is a controlled work item used to organise evidence, tasks, decisions and audit history. A case can contain several alerts, or one alert can lead to more than one specialist case.

An investigation is the analytical process. It includes gathering facts, testing explanations, reviewing relationships, documenting reasoning and deciding whether escalation or reporting is required.

A report is a formal output to an authority where the applicable legal or regulatory conditions are met. It is not simply the closing state of every case.

This matters when designing queues. Suppose a payment sanctions filter generates a potential match and a transaction-monitoring system separately generates an AML alert on the same account. The bank may create a sanctions interdiction case and an AML investigation case linked by customer and transaction ID. The sanctions case may need resolution before payment release. The AML case may continue after the payment is resolved. If both are forced into one workflow, either the sanctions decision becomes too slow or the AML investigation becomes too shallow.

Case confidentiality must also be designed by domain. Suspicious-activity reporting information can have strict disclosure restrictions. Law-enforcement requests can carry handling requirements. Fraud customer communication may be necessary immediately. Sanctions reporting may have a different audience. Role-based access should reflect those differences.

The joined operating model

The strongest design is neither a fully siloed model nor a single universal financial-crime engine.

Pure silos lose intelligence. Fraud teams may identify mule networks that AML teams never see. Sanctions investigators may hold useful ownership evidence inside a separate tool. KYC teams may refresh a customer profile without feeding material changes to monitoring. Operations may repair payment data without preserving the original values used for screening.

A single universal engine creates the opposite problem. It may collapse legally different outcomes, use one threshold where several are required, or allow one team’s closure reason to clear another team’s risk.

A joined model places shared evidence and intelligence in the middle while preserving specialist policy, decision rights and outcomes around it.

In practice, that can mean a common party and relationship model, a common transaction store, shared entity-resolution services and linked case identifiers. Around that shared foundation sit specialist services: sanctions list management and screening, fraud decisioning, AML monitoring, KYC/KYB, adverse media, network analytics, investigation and reporting.

The orchestration layer should understand state rather than just pass messages. It should know whether a payment is awaiting sanctions review, fraud confirmation, legal approval or another control. It should also know which outcomes are final, which are temporary, and which controls can proceed in parallel.

Control clocks: the overlooked architecture requirement

Financial-crime requirements often fail because they describe the control but not the time available to perform it.

Fraud decisions for card authorisation or instant payments may need to complete within the end-to-end customer response time. A model that needs thirty seconds can be analytically impressive and operationally useless.

Sanctions screening may need to complete before payment release or asset dealing. Potential matches need a controlled hold state and a queue that can meet relevant cut-offs or service levels without automatically releasing unresolved risk.

AML monitoring often works on a different cadence. Some scenarios run intraday, daily or over longer windows. Network analytics may aggregate weeks or months of behaviour. A case investigation may need time to gather documents or request information.

Customer screening can be event-driven as sanctions or PEP data changes. Periodic KYC reviews can operate on months or years. Event-driven reviews may need to start immediately after a material trigger.

The architecture should make those clocks explicit. Each control needs a maximum technical latency, operational SLA, escalation threshold, stale-work rule and fail-safe behaviour. “Real time” should never be used without a number or a defined business event.

Each control activity needs an explicit operational clock, alongside any applicable legal filing deadline. Fraud prevention, recovery, sanctions interdiction and behavioural investigation cannot safely share one queue and SLA.

Legal outcome and payment outcome are different fields

A subtle but important design principle is to separate the legal or compliance decision from the technical payment state.

A sanctions analyst may determine that a potential match is false. That is a sanctions decision. The payment orchestration layer may then release the payment, unless another control is still holding it.

An AML investigator may decide that activity is suspicious and file a report. That does not automatically mean every future payment should be declined. The account may remain open under enhanced monitoring, or local law and policy may lead to other actions.

A fraud engine may decline a transaction because the customer cannot be authenticated. That does not make the customer a money launderer.

A payment can also fail for reasons unrelated to financial crime: insufficient funds, invalid account, technical error, clearing rejection or beneficiary-bank response. Those states should not be recorded as financial-crime outcomes.

A robust data model therefore separates fields such as controlDomain, controlDecision, legalBasis, decisionAuthority, paymentAction, customerAction, reportingAction and reasonCode. The exact schema will differ by institution, but the conceptual separation prevents later confusion.

Customer communication: one of the clearest differences between domains

The way a bank communicates with a customer can change by risk.

Fraud teams may need to contact the customer immediately to confirm activity, secure credentials or warn about a scam. The customer can be an essential source of evidence.

AML investigations can have confidentiality constraints, especially around suspicious-activity reporting. The bank must avoid tipping off where prohibited and should not expose internal investigative logic unnecessarily.

Sanctions cases can also require carefully controlled communication. A payment may be delayed or rejected, but the detail that can be provided depends on law, policy and the stage of review. A licence may be relevant in some cases.

KYC refresh may require direct customer outreach for documents or explanation. That contact should be designed so it does not accidentally disclose a separate confidential investigation.

Product teams therefore need communication requirements as part of control design. A generic error message such as “payment rejected due to AML” can be legally risky, operationally misleading and harmful to customers. Reason-code translation should distinguish internal detail from what can safely and lawfully be shown externally.

Roles and governance

The organisational chart differs between banks, but accountability should not be ambiguous.

The first line normally owns the risks arising from the business and operates many controls. That can include onboarding teams, payment operations, fraud operations, relationship management and product owners.

Financial-crime compliance or equivalent second-line functions establish policy, provide challenge and oversight, interpret regulatory expectations and may own or approve specialist decisions depending on the bank’s model. Legal teams may be essential for sanctions applicability, licensing, law-enforcement orders and difficult jurisdictional questions.

Specialist AML, sanctions, CFT, fraud and investigations teams need defined decision rights. Technology teams own reliable implementation, but they should not be forced to invent legal rules because requirements are incomplete. Data owners are responsible for source quality and lineage. Model-risk or validation functions may challenge analytical models. Internal audit provides independent assurance.

Senior management and boards need information about risk and control effectiveness, not merely activity volumes. Ten thousand closed alerts can indicate a busy team or a badly tuned system. Governance should ask whether priority risks are covered, whether decisions are timely and defensible, whether significant issues are escalating, whether backlogs create exposure, and whether control changes are working.

The three-lines model does not mean that intelligence should stop at organisational boundaries. Ownership can remain separate while evidence flows under controlled rules.

Practical system touchpoints

A realistic financial-crime architecture touches many systems.

The customer master or CRM holds identity and relationship information. KYC/KYB platforms hold due-diligence evidence, ownership and risk assessment. Screening services compare customers and transactions against sanctions, PEP and other data. Payment hubs and gateways hold instructions, status and routing. Fraud engines consume channel, device and transaction features. Transaction-monitoring or suspicious-activity-monitoring platforms analyse behaviour. Case-management tools organise investigations. Data platforms support network analytics and historical review. Reporting services submit required information to authorities. Document stores preserve evidence.

The difficult work lies in the interfaces.

Does the sanctions engine receive ultimate debtor and ultimate creditor when present? Does it receive original script and transliterated name where available? Does the fraud engine know whether a beneficiary is new to this customer or new to the entire bank? Can the AML platform connect card, account, wire and instant-payment activity to one customer? Can investigators see payment rejects and returns? Can they trace a transformed ISO 20022 message back to the customer instruction? Can screening decisions be reconstructed using the list version that existed on the original date?

Those are financial-crime requirements even though they look technical.

A bank should also define failure behaviour. If the sanctions service is unavailable, does the payment stop, queue or route to a contingency process? If a fraud feature is missing, does the model degrade safely or silently score using incomplete data? If the AML feed is late, who knows which population was not monitored? If list updates fail, what prevents the bank from assuming screening is current?

Resilience and observability are therefore part of financial-crime control design.

Business analysis: turning policy into testable requirements

A business analyst should be able to trace every requirement through five questions: what risk, what trigger, what data, what decision, what evidence.

A vague statement such as “screen all international payments for AML” fails several tests. Is the requirement sanctions screening or AML monitoring? Which payment types and legal entities are in scope? Which parties and fields must be screened? At what point in the payment lifecycle? Against which data sets? What happens to an unresolved potential match? Who may release it? What evidence must be stored? What happens during an outage?

A stronger sanctions requirement might say that, before release of an in-scope outbound payment, specified party and agent fields must be screened against the sanctions data applicable to the processing legal entity; unresolved potential matches must place the payment in a controlled hold state; the case must preserve the original field value, normalised value, list and version, matched record, score, analyst evidence, decision, approver where required, timestamps and final payment action.

An AML monitoring requirement will look different. It may specify transaction populations, historical window, customer attributes, scenario logic, suppression rules, alert creation, case linkage and quality controls. It should not promise that the system “detects money laundering.” The system detects defined indicators or patterns for investigation.

A fraud requirement may specify maximum response time, decision features, step-up authentication, customer contact, liability-relevant events, recovery attempts and fallback behaviour.

The BA should also distinguish functional from non-functional requirements. Data completeness, latency, availability, auditability, explainability, access control, retention, recoverability and throughput can determine whether the legal control works in practice.

Architecture: preserve domain boundaries without duplicating the bank

Architects face a difficult balance. If every financial-crime team builds its own customer, payment and relationship database, the bank creates inconsistency. If everything is centralised into one giant control service, the bank can lose domain-specific meaning and create a critical concentration point.

A sensible pattern is reusable foundational services with specialist decision services.

Foundational capabilities can include canonical party identifiers, account and product relationships, payment event history, beneficial-ownership graphs, reference-data services, audit logging, entity resolution and secure evidence access. Specialist services can then consume those facts according to their own rules.

This design also supports change. A sanctions list update should not require rewriting the customer master. A new fraud model should not change the meaning of an AML case. A KYC ownership refresh should publish a governed event that can trigger rescreening and risk review. A payment-message migration should preserve the data contracts used by screening and monitoring.

Event-driven integration can help, but events must be semantically clear. CustomerUpdated is often too vague. Was the address corrected, beneficial ownership changed, risk rating increased, legal name changed or relationship closed? Different events trigger different financial-crime controls.

The architecture should also support historical reconstruction. Investigators and auditors may need to know what the bank knew at the time, not only what it knows now.

Testing: prove the control, not just the screen

Financial-crime testing should go beyond checking that an alert appears.

For sanctions screening, testing should cover exact and fuzzy matches, aliases, transliteration where relevant, missing identifiers, false-positive resolution, ownership links, list updates, re-screening, payment holds, release authority, duplicate messages, retries, timeouts and audit evidence.

For AML monitoring, testing should cover scenario population, thresholds, lookback windows, data aggregation, customer segmentation, suppression, case creation, duplicate detection, historical corrections and late-arriving data. Boundary tests are essential because an incorrect greater-than versus greater-than-or-equal rule can change the population materially.

For fraud, testing should include authorised and unauthorised scenarios, manipulation patterns where supported, device changes, beneficiary novelty, authentication outcomes, performance under latency targets, degraded mode and customer communication.

For joined workflows, testers should deliberately create conflicting outcomes. A payment should be fraud-clear and sanctions-held. Another should be sanctions-clear and fraud-declined. An AML case should be created after a payment settles while a separate fraud recovery continues. These tests prove that the orchestration layer respects domain boundaries.

Negative testing is especially important. The absence of an alert can be the defect. Testers need expected populations and reconciliation controls so they can prove that every in-scope event reached the control.

Common failure modes

Several failure patterns recur across institutions.

Everything is called AML. Fraud, sanctions, KYC and transaction monitoring become one vocabulary. Requirements lose precision and teams do not know which legal owner should decide.

A clear result in one system clears the whole transaction. The orchestration layer receives PASS from fraud or sanctions and releases the payment without checking other unresolved controls.

Screening is treated as sanctions compliance. The bank screens names but misses ownership, sectoral restrictions, goods, services, licences or jurisdictional nexus.

An alert is treated as suspicion. Operational teams assume a scenario hit proves criminality, creating poor customer outcomes and weak case reasoning.

A suspicious report is treated as a conviction. The fact that the bank reported activity is used elsewhere as if it proves wrongdoing.

A PEP match is treated as a prohibition. Political exposure is confused with sanctions or corruption.

Fraud intelligence never reaches AML. Mule accounts are closed after customer-protection action without the wider network being analysed.

Case data becomes a dead end. Investigators write useful information in free text that never feeds customer risk, monitoring or entity-resolution capabilities.

One country’s rule becomes global configuration. A US SAR timing rule, OFAC outcome or local fraud reimbursement rule is hard-coded for all legal entities.

Data transformations are invisible. The value screened is not the value the customer entered, but the bank cannot reconstruct the mapping.

Control outages are treated as IT incidents only. Nobody identifies the unprocessed population or assesses whether retrospective screening or monitoring is required.

Each failure is preventable when ownership, data lineage, control state and evidence are designed explicitly.

Mini case study: one corporate payment, five different questions

Consider a fictional mid-sized engineering company, Northbridge Components Ltd. It has banked with the institution for four years. Its KYC profile says it manufactures industrial components and usually pays established suppliers in Europe and Asia. Its expected monthly cross-border volume is material but stable.

At 10:14 on a Tuesday, Northbridge instructs a USD 420,000 payment to a consultancy incorporated in another jurisdiction. The payment narrative states “technical advisory services — project Delta.” The instruction is created by an authorised finance user from the company’s normal device and approved through the expected dual-authorisation process.

The fraud engine sees normal credentials, normal device history, normal location and normal approval behaviour. The amount is higher than the company’s recent average, but not outside its historical capacity. Fraud therefore produces a low-risk result. That means the instruction appears genuine. It does not mean the payment is free of other financial-crime risk.

The sanctions engine screens the beneficiary name, bank, address and relevant payment parties. It generates a potential match because the consultancy’s name resembles a designated entity. Entity-resolution checks registration number, address and country and determines that the beneficiary is a different company. The name match is closed as false positive.

During that review, however, the analyst notices that a recently added minority shareholder of the beneficiary has a corporate connection to another entity subject to restrictions. Whether that relationship creates a legal sanctions issue depends on the applicable regime, ownership or control rules and facts. The sanctions case is escalated for legal analysis rather than automatically cleared or blocked.

Separately, the AML monitoring platform notes that Northbridge has never paid this consultancy before and that the stated service does not obviously fit the historical supplier pattern. One unusual transaction is not enough to conclude money laundering. The case analyst reviews KYC, invoices, contract information, previous payments and the commercial relationship.

The analyst finds that Northbridge won a large public-sector contract three months earlier. Adverse information links one of the consultancy’s principals to a senior official involved in the procurement process. The consultancy was formed recently, has limited public operating history and receives a fee equal to a percentage of the contract value.

Now the bribery and corruption dimension matters. None of those facts proves a bribe. Together they create a reason to understand what services were provided, who owns and controls the consultancy, whether the fee is commercially plausible and whether the official or close associates benefit.

The CFT lens finds no relevant indicators from the available information. That is a legitimate conclusion; not every financial-crime case must become every risk domain.

Suppose legal review then confirms that the shareholder connection does not make the beneficiary restricted under the applicable sanctions regime. The sanctions case can be cleared. The AML/ABC investigation can still continue because its question is different.

Northbridge provides a consulting agreement, work product and evidence of services, but the documents contain inconsistencies and the relationship manager cannot explain why procurement success fees were paid through this entity. The investigator reaches the applicable internal threshold for escalation. The bank’s designated reporting function assesses whether the local legal threshold for a suspicious transaction report is met and handles any required filing confidentially.

The payment outcome and relationship outcome then need separate decisions. Depending on applicable law, policy and timing, the bank may have already held or processed the payment, may impose enhanced monitoring, may request additional due diligence or may consider relationship restrictions. None of those actions should be inferred automatically from the fact of a report.

The case demonstrates the central principle of this chapter. Fraud answered “does the instruction appear genuine?” Sanctions answered “does a legal restriction apply?” AML/ABC answered “does the activity create suspicion of criminal proceeds or corruption-related activity?” CFT answered “is there evidence of terrorism-related financing?” The evidence overlapped, but the decisions remained distinct.

What should feed back after a case closes

A case should improve the control environment.

If a sanctions false positive was caused by a recurring naming pattern, the bank may tune matching or add a well-governed false-positive suppression mechanism where permitted. If ownership data was missing, the KYC process or data feed may need repair. If AML investigators repeatedly identify a new typology, monitoring or network analytics may need enhancement. If fraud cases reveal a new social-engineering pattern, customer warnings and transaction controls may need change.

Feedback should be governed. A single case should not create an untested global rule. Changes need evidence, impact analysis, approval, testing and monitoring.

Closed cases can also change customer risk. A case closure of “explained and reasonable” is different from “insufficient evidence but residual concern remains.” Case outcomes need structured reason codes if they are to be reused safely.

The goal is a learning system in which investigation improves prevention and detection rather than a factory that closes alerts and forgets them.

Measuring effectiveness without confusing volume with quality

Financial-crime metrics should reflect the purpose of the control.

For fraud, useful measures can include prevented loss, customer harm, false declines, recovery, authentication success, latency and emerging attack patterns.

For sanctions, measures can include screening coverage, list-update timeliness, unresolved-match ageing, decision quality, false-positive rates, data completeness, control outages and legal-reporting timeliness.

For AML/CFT, measures can include risk coverage, alert quality, investigation quality, backlog ageing, data completeness, reporting timeliness, useful intelligence, scenario performance and remediation progress. The Wolfsberg Group’s monitoring-for-suspicious-activity work encourages institutions to think beyond raw alert or filing volume toward effective outcomes.

Metrics should not create perverse incentives. If analysts are rewarded only for closing more alerts, quality can fall. If a sanctions team is measured only on low false positives, matching can become too weak. If fraud teams minimise loss by declining too many genuine payments, customer harm rises.

Effectiveness is therefore a balance of risk coverage, quality, timeliness, explainability, operational resilience and customer impact.

Information sharing, privacy and confidentiality

Joined financial-crime operations need information sharing, but not unlimited access.

Customer data, transaction information, device evidence, adverse information, suspicious-activity reports and law-enforcement material can have different legal and confidentiality constraints. Cross-border groups may face banking secrecy, privacy, data-localisation or employment-law restrictions. The correct solution is not to prevent all sharing; it is to define lawful purpose, access, minimisation, retention, security and governance.

The Egmont framework illustrates the public-sector side of this balance. FIUs are national centres for receiving and analysing suspicious reports and can exchange financial intelligence through controlled mechanisms. Banks likewise need controlled internal sharing so that material intelligence can move without exposing sensitive information to people who do not need it.

For architects, that means domain-aware access control, audit logging and data classification. For investigators, it means understanding that “available somewhere in the group” does not always mean “lawfully accessible for this case.” For BAs, it means data-sharing constraints belong in requirements, not in a late privacy review.

A practical decision framework for any financial-crime event

When a new event appears, teams can work through a consistent sequence without pretending every risk is the same.

First, identify the event. Is it onboarding, customer change, login, payment, trade document, card transaction, screening update, adverse-media result, law-enforcement request or monitoring alert?

Second, identify the risk domains that may be relevant. Do not select every domain by default. Select the ones supported by the event and evidence.

Third, identify the applicable legal entities and jurisdictions. The customer’s residence alone is not enough. Booking entity, processing entity, currency, payment route, location of services, sanctions nexus and other facts can matter.

Fourth, identify the control clock. Must something happen before release, within seconds, before a cut-off, after aggregation, within a reporting deadline or during periodic review?

Fifth, identify the minimum evidence required for a defensible decision. That can include identity, ownership, transaction history, authentication, payment parties, list identifiers, customer explanation, trade documents or external intelligence.

Sixth, record the specialist decision and its basis. Avoid generic clear/fail language where a more precise outcome exists.

Seventh, determine the technical action, customer action and reporting action separately.

Finally, decide what intelligence should feed back into KYC, monitoring, fraud controls, screening, network analytics or training.

That sequence allows teams to work together without inventing one fictional “financial crime algorithm.”

Takeaway

Financial crime is a useful umbrella, but AML, CFT, sanctions, proliferation financing and fraud remain distinct disciplines.

AML is primarily concerned with criminal proceeds, suspicious patterns and the misuse of financial services. CFT focuses on the financing of terrorism and must account for funds that can be lawful in origin. Sanctions apply legally defined restrictions whose scope and outcome depend on the relevant authority, jurisdiction and nexus. Proliferation financing connects targeted financial sanctions with wider procurement, trade, ownership and evasion risk. Fraud focuses on deception, unauthorised or manipulated activity and immediate customer or institutional loss.

The strongest bank model connects those disciplines through common evidence, identifiers and intelligence while preserving specialist legal tests, control clocks, decision owners and outcomes. That principle should be visible in policy, data, architecture, workflow, testing and customer communication.

When teams can explain not only that “financial crime has triggered” but which risk, which evidence, which law or policy, which decision and which action, the control environment becomes clearer, faster to operate and much easier to test and defend.

The next chapter moves deeper into AML by examining criminal proceeds and predicate offences: the underlying crimes that create value which may later be concealed, moved or integrated through the financial system.

Deep practitioner expansion: how the disciplines work together inside a real bank

The distinction between AML, CFT, sanctions and fraud becomes much more important once a bank tries to build an operating model around them. On an organisation chart they may appear as neighbouring functions. In a real payment or customer journey they can all touch the same event within seconds, but they are asking different questions and may have different legal consequences.

A useful way to see the difference is to follow one instruction through a bank. A corporate customer asks to send a cross-border payment to a new supplier. Fraud controls ask whether the instruction was genuinely initiated by an authorised user and whether the behaviour is consistent with the user, device, account and beneficiary history. Sanctions controls ask whether any relevant party, bank, vessel, location or other data element creates exposure under an applicable sanctions regime. AML controls ask whether the activity is consistent with what the bank knows about the customer and whether the transaction forms part of a suspicious pattern. CFT controls ask whether the destination, network, parties or purpose create concern relating to terrorist financing, including cases where the source of funds may itself be legitimate.

These questions can produce different answers. The fraud engine may conclude that the customer really did initiate the payment. The sanctions filter may identify no prohibited party. Transaction monitoring may nevertheless identify a pattern that is inconsistent with the customer’s known business and escalate it for investigation. Alternatively, the transaction may look completely normal from an AML perspective but produce a sanctions match that requires immediate legal analysis. A mature financial-crime design preserves all of those outcomes rather than forcing them into one generic status such as “AML passed.”

That phrase — “AML passed” — is one of the most misleading phrases in banking. AML is not a single gate. Customer due diligence may have been completed; sanctions screening may have returned no unresolved match; fraud controls may have allowed the payment; transaction monitoring may run later; and a future investigation may still identify suspicion. The correct architecture records which control ran, what data it used, what result it produced, who owned any exception and what happened next.

A practical control clock

The four disciplines also operate on different clocks.

Fraud prevention often operates before or during execution. A card authorisation, instant payment or online transfer may need a decision within milliseconds or seconds. The decision may use device reputation, behavioural signals, beneficiary history, velocity, authentication strength, session risk and known scam indicators. If the bank waits an hour, the money may already be gone.

Sanctions screening can also be time-critical. A payment may need to be screened before release because the bank must not make funds or economic resources available where a prohibition applies. The time available depends on the payment rail, cut-off and operating model, but the legal decision cannot be replaced by a generic risk score. An unresolved potential match needs a controlled disposition.

AML transaction monitoring frequently works over a longer horizon. Some scenarios are near-real-time, but many patterns only become meaningful across days, weeks or months. Rapid pass-through of funds, structuring, circular movement, changes in counterparties and unusual use of products may not be visible from a single payment. The objective is therefore not simply to stop a transaction; it is to detect behaviour that may indicate laundering or another financial crime.

CFT can use both types of clock. Terrorism-related sanctions may require immediate screening and freezing controls, while behavioural CFT investigation may depend on network, destination, cash, remittance or small-value patterns accumulated over time.

The architecture should therefore support several simultaneous states. A payment can be authorised, screened, released and later included in an AML investigation without any contradiction. A customer can remain active while a case is under investigation, unless law or bank policy requires restriction. A fraud block can happen before any AML conclusion exists. Keeping these states separate is one of the foundations of good financial-crime technology.

Legal obligation, risk decision and customer outcome are three different layers

A practical bank needs to distinguish what is legally required, what is decided under risk appetite and what is communicated to the customer.

A sanctions law may require an asset freeze. That is not a discretionary customer-risk decision. An AML policy may require enhanced due diligence before continuing a high-risk relationship. That can involve judgement within a framework. A fraud engine may temporarily hold a payment while the customer confirms it. That is a customer-protection intervention. All three may result in a transaction not moving, but the reason, governance and evidence are different.

The distinction matters in requirements. “Stop the payment” is not enough. The requirement needs to answer why the payment is stopped, who may release it, whether time limits apply, whether funds are booked or merely reserved, whether customer communication is permitted, what accounting treatment applies, what data must be retained and whether reporting to an authority is required.

For example, a sanctions freeze may create a legally restricted asset position that must remain blocked until legal authority changes. A fraud hold may be releasable after customer verification. An AML investigation may not itself provide legal authority to hold a payment indefinitely. The bank must know which control creates which power.

Decision rights inside the bank

A mature operating model assigns decision rights explicitly.

Fraud operations may have authority to decline a card transaction, suspend digital access or contact the customer. Sanctions operations may resolve false positives under approved procedures but escalate possible true matches to sanctions compliance or legal. AML investigators may decide whether activity should be escalated for suspicious reporting, subject to the bank’s local governance. Relationship management may own the commercial relationship but should not be able to override a legally mandatory financial-crime outcome.

This separation is not bureaucracy for its own sake. It prevents conflicts of interest and makes accountability reconstructable. If a high-value customer is under investigation, the relationship manager may provide business context, but the decision on whether suspicion exists should not be controlled by the commercial owner of the relationship.

The same principle applies to automated systems. A machine-learning fraud model can recommend an action, but governance must define which decisions it may execute automatically and which require human review. A sanctions-screening engine can rank match confidence, but a low model score cannot override a legal requirement to assess a plausible match if the bank’s policy says it must be reviewed.

Why fraud intelligence is valuable to AML

Fraud and AML teams historically developed different systems because they solved different operational problems. Fraud focused on immediate loss prevention and customer reimbursement. AML focused on suspicious activity, customer risk and regulatory reporting. That separation made sense at one level, but criminals exploit the gap.

Consider a scam network. The victim’s bank sees a customer being manipulated into sending an authorised payment. The receiving bank sees a mule account. The mule may then distribute the proceeds to several accounts, cash out or purchase virtual assets. Fraud systems may identify the victim side quickly, while AML systems may be better placed to understand the receiving network and repeated movement of criminal proceeds.

If fraud intelligence never reaches AML, the receiving bank may close each fraud complaint as an isolated event and miss a laundering network. If AML intelligence never reaches fraud, fraud controls may continue allowing payments to beneficiaries already associated with suspicious receiving behaviour.

The ideal model does not merge the two disciplines into one indistinguishable queue. It creates controlled information exchange. Known scam beneficiaries, mule indicators, compromised devices, account takeover signals and confirmed fraud cases can enrich AML analysis. AML network findings can in turn improve beneficiary-risk models and fraud prevention.

Mule-account analysis as the bridge

Mule accounts illustrate the overlap particularly well. A mule may be knowingly complicit, recruited with partial knowledge or deceived. The account may receive victim payments, transfer funds onward, withdraw cash or convert value. Fraud teams care because the account receives stolen or manipulated payments. AML teams care because the account is handling criminal proceeds and can reveal a wider network.

A useful mule investigation looks beyond one incoming payment. It asks how many unrelated senders exist, how quickly funds leave, whether the customer retains a percentage, whether devices or contact information overlap with other accounts, whether beneficiaries recur across the network, whether cash withdrawals cluster geographically, whether the account behaviour changed suddenly and whether the customer’s known profile can plausibly explain the activity.

The strongest evidence is often relational rather than transactional. Ten customers sending money to the same beneficiary after similar device changes may be more meaningful than one customer sending a large amount.

Sanctions is not only name screening

Another common weakness is to reduce sanctions compliance to fuzzy name matching. Names matter, but sanctions regimes can restrict much more than listed names.

Restrictions may be based on ownership or control, geographic location, sector, debt or equity instruments, goods, services, vessels, aircraft, technology, financing activity or dealings with specified authorities. A payment can therefore create sanctions risk even when neither the payer nor beneficiary name appears directly on a list.

For example, an unlisted company may be owned by one or more sanctioned persons to a degree that makes it subject to restrictions under an applicable regime. The exact legal test differs between regimes. This means the bank needs beneficial-ownership data, legal interpretation and escalation — not only a screening engine.

A transaction may also involve a restricted port, vessel or trade route. Trade-finance controls may need to consider bills of lading, vessel identifiers, ports, goods descriptions and end-use information. The payment message alone may not provide the full sanctions picture.

Sanctions nexus

A critical concept is nexus: why a particular sanctions regime applies to this bank, legal entity, payment or activity.

Potential nexus can arise through the bank’s legal entity, location, employees, currency, clearing route, correspondent bank, customer, counterparty, goods, service or other legally relevant connection. The rules are jurisdiction-specific, and extraterritorial or secondary-sanctions exposure can further complicate analysis.

For business analysis, this means a single global boolean field called sanctionsPassed is rarely sufficient. The system may need to know which regimes were screened, which list versions were used, which parties were evaluated, whether ownership analysis was performed, what match disposition occurred, whether a licence or exemption applied, which legal entity made the decision and what evidence supports release or restriction.

AML is not only transaction monitoring

Many people meet AML through transaction-monitoring alerts and therefore assume monitoring is the centre of AML. It is important, but the programme begins much earlier.

Customer due diligence establishes identity, ownership, purpose and expected activity. Risk assessment determines the intensity of controls. Screening identifies certain external-risk relationships. Ongoing monitoring compares actual behaviour with expectations. Investigations assemble evidence. Suspicious reporting communicates relevant intelligence to public authorities. Governance, training, quality assurance, model validation, data controls and audit support the entire chain.

If KYC is weak, monitoring becomes noisy because the bank does not know what “normal” means. If payment data is incomplete, investigators cannot reconstruct flows. If case decisions are not fed back into monitoring, the same ineffective scenarios continue. If suspicious reports are low quality, the public-private system receives poor intelligence even if the bank technically meets filing volumes.

A good AML programme therefore behaves like a learning system.

Terrorist financing: why size can mislead

Terrorist financing challenges some intuitive assumptions in financial-crime detection. Large, complex transactions are not required. Funds may be lawful in origin and small in amount. A salary payment can become relevant if part of it is intentionally directed toward terrorist activity. Charitable or nonprofit channels can be abused, although the overwhelming majority of such activity is legitimate and controls must remain proportionate.

This means a simple “large amount equals risk” approach is particularly weak for CFT. Investigators may need to consider destinations, known networks, associated persons, cash behaviour, remittance patterns, travel indicators, sanctions designations and external intelligence. The 2026 Basel consolidated AML/CFT guidance explicitly notes that terrorist-financing transactions may involve very small amounts and that funds can originate from legal sources.

The 2026 FATF update to Recommendation 6 is also important because it reinforces humanitarian exemptions aligned with relevant UN Security Council resolutions. That change is a useful reminder that counter-terrorist-financing controls must be effective without unnecessarily blocking legitimate humanitarian assistance. A bank needs processes capable of distinguishing prohibited activity from permitted or exempt humanitarian flows where the legal framework provides for them.

Proliferation financing: where payments meet trade and technology

Proliferation financing is often difficult because the underlying transaction may look like ordinary trade. A manufacturer buys industrial equipment. A distributor ships components through an intermediary. A bank finances a letter of credit. The risk may sit in the end user, ownership chain, dual-use nature of goods, shipping route, transshipment pattern or relationship to a sanctioned programme.

Financial institutions are not customs agencies and cannot classify every product independently. But they do need risk-sensitive processes where trade data, customer profile and sanctions information indicate concern.

A practical control model can involve customer due diligence on trading businesses, identification of high-risk sectors or jurisdictions, screening of relevant parties and vessels, trade-document review for selected risk segments, escalation where goods descriptions are vague or inconsistent, and specialist review where dual-use or end-use concerns arise.

The key design lesson is that financial crime cannot always be solved from the payment message alone. Context from trade systems, customer files and external data may be necessary.

Bribery and corruption: from public office to payment behaviour

Banks do not investigate corruption in the same way as anti-corruption prosecutors, but they frequently see financial indicators around corruption risk.

A customer connected to a public contract may pay an intermediary with no obvious capability. A consulting firm may receive unusually large fees relative to its size. A politically exposed person or close associate may experience a sudden increase in wealth. A company may send funds to an offshore entity controlled by a relative of a decision-maker. None of these facts proves bribery. Together, and in context, they can justify deeper review.

The role of PEP controls is therefore often misunderstood. PEP status is not a blacklist. It is a risk factor associated with the possibility of abuse of public functions, requiring risk-sensitive enhanced measures under applicable frameworks. A bank should avoid both extremes: treating every PEP as criminal or treating PEP status as a purely administrative label with no effect on due diligence.

Source-of-wealth analysis becomes particularly important in higher-risk private banking and PEP relationships. The question is not simply whether the customer has money, but whether the origin of the customer’s overall wealth is credible and supported by evidence. Source of funds, by contrast, relates to the specific money used in a transaction or relationship. Mixing those concepts leads to weak investigations.

Tax crime: avoid simplistic conclusions

Tax-related activity is another area where bank language must remain disciplined. Offshore structures are not inherently illegal. Trusts are not inherently suspicious. Cross-border tax planning can be lawful. The concern arises where facts indicate criminal tax evasion, concealment, false documentation, sham entities or laundering of proceeds arising from tax crime under applicable law.

A bank may also have obligations under tax-transparency regimes such as CRS or FATCA, but those are not the same as AML suspicious-reporting obligations. The same customer can trigger both types of compliance activity for different legal reasons.

For an investigator, useful questions include whether the economic activity is real, whether invoices and contracts make sense, whether ownership is transparent, whether funds move through entities without commercial purpose, whether the customer’s explanation is consistent with available evidence and whether the jurisdiction treats the underlying conduct as a relevant criminal offence.

Cyber-enabled crime and financial crime convergence

Modern financial crime increasingly begins in a digital channel. Business-email compromise can redirect legitimate invoice payments. Account takeover can move balances through new beneficiaries. Ransomware can create extortion proceeds. Investment scams can use social media, payment accounts and virtual assets. Synthetic identities can open accounts that later become mule infrastructure.

These crimes create a strong case for linking cybersecurity, fraud and AML intelligence. Cybersecurity may identify compromised credentials or malware. Fraud may identify the unauthorised or manipulated transaction. AML may identify the receiving network and onward laundering. Each team sees a different part of the chain.

The bank does not need to merge all functions organisationally. It does need a mechanism to join relevant evidence under controlled access.

Data architecture: what one payment should carry into a case

For practitioners, the most useful way to test a financial-crime architecture is to choose one payment and ask what survives into investigation.

At minimum, the case should be able to reference the original instruction, customer and account identifiers, debtor and creditor information, amounts and currencies, timestamps, agents and intermediaries, payment status, authentication information where relevant, screening results, fraud scores or reason codes where policy permits, customer-risk information, previous alerts and connected parties.

The exact data set varies by payment type, legal regime and privacy constraints. The principle is traceability.

A transformed or repaired payment should not lose the original value that triggered a screening match. A name normalised for matching should not overwrite the original customer-supplied name. A payment reference used in the rail should be joinable to the internal instruction ID and the booking entry. A case should preserve which version of a sanctions list or monitoring model was used at the time of decision.

This is what turns an operational decision into defensible evidence.

ISO 20022 and richer data

ISO 20022 can provide richer structured party and payment information than older free-text formats, but the standard does not automatically create better financial-crime control. Better outcomes depend on data quality, population, transport, mapping and use.

If a sending bank populates structured party data and an intermediary converts it into a truncated legacy field, the receiving institution loses value. If screening uses only one flattened name even though the message contains separate name and address components, the potential benefit is not realised. If investigators receive only the final transformed message and cannot view the original instruction, data lineage is weakened.

For BAs and architects, the requirement should therefore be “preserve and expose the data needed for the control,” not merely “support ISO 20022.”

Case management: one customer, many control types

Financial-crime case management should support shared context without forcing shared decisions.

A single customer may have a fraud case, sanctions case and AML investigation at the same time. The case platform should allow authorised users to see relevant cross-links while respecting confidentiality restrictions. It should not automatically merge all evidence into one universally visible record.

Sensitive suspicious-reporting decisions, law-enforcement requests and certain sanctions legal opinions may require tighter access than ordinary operational fraud cases. Role-based access, need-to-know controls and detailed audit logs therefore matter.

A good case system records at least the trigger, owner, risk type, relevant entities and transactions, evidence, chronology, decision, approval, action, external reporting where applicable, customer communication constraints, closure reason and follow-up actions.

Why closure reasons matter

A false-positive sanctions match, a legitimate fraud alert and an AML alert closed after investigation are all “closed,” but their closure meanings differ.

Structured closure reasons support tuning, quality assurance and governance. If thousands of sanctions alerts are repeatedly closed because of the same transliteration pattern, screening can be improved. If a monitoring scenario generates alerts that investigators close because the activity is expected for a customer segment, segmentation may need refinement. If fraud cases repeatedly reveal mule beneficiaries, beneficiary-risk controls can be strengthened.

Closure data is therefore an input to control improvement, not only a productivity statistic.

Scenario: the same customer triggers four disciplines

Consider a medium-sized engineering company that has banked with the institution for eight years. It normally pays domestic suppliers and receives revenue from a small number of commercial customers. Over two weeks several changes occur.

First, a new online-banking administrator is added. The device is new and the login originates from a location not previously associated with the company. Fraud monitoring increases the session risk but does not block access because strong authentication succeeds.

Second, the company adds a new beneficiary described as an overseas logistics consultant. The first payment is modest. The second is much larger and urgent.

Third, sanctions screening identifies a partial name match involving a shareholder of the beneficiary. The name is common, so the alert cannot be resolved from name alone. Analysts obtain corporate ownership information and determine that the listed person is not the same individual. The sanctions case is closed as a false positive with evidence.

Fourth, AML monitoring identifies that the payments are inconsistent with the company’s historical activity and stated business. An investigator finds that the beneficiary was incorporated recently, has minimal online presence and shares an address with several unrelated entities. The customer provides an agreement, but the description of services is vague.

Fifth, external fraud intelligence identifies the new administrator’s email account as compromised in a business-email-compromise campaign. The fraud team contacts the customer and confirms that the administrator was not legitimately added.

The payment is now clearly a fraud issue, but the receiving entity may also form part of a laundering network. Fraud prevention addresses the immediate loss. AML investigation assesses the beneficiary and onward movement. Sanctions remains a separate closed false positive. If terrorist-financing or proliferation indicators later emerge, those disciplines may also become relevant.

The lesson is that the correct answer is not “which team owns the customer?” The answer is “which team owns each decision, and how does relevant intelligence move between them?”

Scenario: genuine customer, unacceptable payment

A private-banking customer instructs a payment personally through an authenticated channel. Fraud controls confirm that the customer initiated it. The payment is to an art dealer in another country for a high-value purchase.

The transaction can still create financial-crime risk. Sanctions screening may identify the dealer’s beneficial owner as restricted under an applicable regime. AML controls may identify an unexplained source of funds or a pattern inconsistent with the customer’s known wealth. The fact that the customer genuinely authorised the payment does not make the payment acceptable.

This is a key educational distinction: authentication proves who requested the instruction; it does not prove the instruction is lawful.

Scenario: lawful funds, prohibited destination

A charity receives legitimate donations and attempts to transfer funds for humanitarian relief. The source of funds is lawful. The transaction nevertheless touches a region subject to terrorism-related sanctions controls.

The bank must apply the relevant sanctions and CFT framework, but it must also recognise applicable humanitarian exemptions or licences where they exist. FATF’s June 2026 amendment to Recommendation 6 explicitly strengthens alignment with UN humanitarian exemptions. A poorly designed system that simply blocks every transaction associated with a high-risk region can create unnecessary harm and may not reflect the legal framework.

This scenario demonstrates why proportionality, legal interpretation and operational capability matter together.

Monitoring and analytics: rules, models and networks

Traditional transaction monitoring often uses scenarios such as rapid movement of funds, high cash activity, structuring, unusual international transfers or dormant-account reactivation. Those scenarios remain useful, but modern programmes increasingly add behavioural and network analytics.

Behavioural models ask whether a customer’s activity has changed relative to its own history or peer group. Network analytics asks whether parties, devices, accounts, addresses or beneficiaries connect in ways that reveal a broader pattern. Machine learning can support prioritisation or anomaly detection, but it must be governed like any other material model: data quality, explainability, validation, performance monitoring, bias and change control matter.

The objective is not to replace investigators with an algorithm. It is to use technology to present better hypotheses and evidence.

Precision, recall and operational capacity

Financial-crime detection is a practical optimisation problem. If a scenario is too broad, it overwhelms operations with false positives. If it is too narrow, it misses risk. Precision measures how many detected items are useful; recall concerns how much relevant activity is captured. In financial crime, the true population of suspicious activity is not fully observable, so those metrics require care.

The operational layer matters as much as model performance. A theoretically excellent model that produces 50,000 high-priority alerts when the bank can investigate only 5,000 has created unmanaged risk. Capacity planning, prioritisation and service levels must therefore be part of control design.

Quality assurance and quality control

Quality control generally checks case work close to operations: whether required steps were completed, evidence supports the decision, documentation is clear and procedures were followed. Quality assurance usually takes a broader view across samples, themes, teams and control outcomes.

Both should focus on decision quality rather than formatting alone. A beautifully written case can still be wrong if material evidence was ignored. A short case can be strong if the facts are simple and the reasoning is clear.

Useful QA questions include whether the investigator considered relevant customer history, whether connected parties were reviewed, whether contradictory evidence was addressed, whether the correct legal framework was applied, whether escalation was timely and whether closure rationale would make sense to an independent reviewer.

Metrics that can mislead

Financial-crime teams need metrics, but some common measures become dangerous when treated as targets.

Alert closure volume rewards speed but can punish careful investigation. Low false-positive rates may look efficient but can also indicate that thresholds are too narrow. High suspicious-report conversion rates may indicate good prioritisation or excessive escalation. Low customer offboarding may indicate proportionality or weak action. Metrics require interpretation.

A stronger management-information pack combines volume, ageing, quality, risk concentration, conversion, control effectiveness, customer impact and remediation status.

For fraud, loss prevented and customer reimbursement matter. For sanctions, unresolved-match ageing and list-update control matter. For AML, detection quality, investigation quality, reporting usefulness and overdue high-risk reviews matter. For CFT, outcome measures may rely more heavily on intelligence and network relevance than on transaction size.

Governance across the three lines

The first line operates products, customer relationships and many controls. It owns the risk created by the business. The second line provides independent financial-crime policy, oversight and challenge. Internal audit provides independent third-line assurance.

Real banks often have more complex structures, but the accountability principle remains. A control cannot become “compliance’s problem” simply because it relates to financial crime. If a payments platform drops beneficiary-address information before screening, that is a first-line technology and product control failure with compliance implications. If compliance writes an unimplementable policy, that is a second-line design problem. If audit never tests the actual data flow, assurance is incomplete.

Effective financial-crime management is therefore cross-functional by design.

What a business analyst should capture in requirements

For each financial-crime control, the BA should be able to document the trigger, scope, input data, source system, timing, decision logic, exception path, owner, evidence, audit trail, customer impact, regulatory dependency and downstream use.

For sanctions screening, specify which parties and fields are screened, when screening occurs, how list updates are controlled, what happens to potential matches, who can release, how ownership/control concerns are handled and what evidence is stored.

For transaction monitoring, specify the population, scenario objective, data inputs, frequency, segmentation, alert prioritisation, case creation, linkage to customer risk and tuning governance.

For fraud, specify the decision point, latency requirement, authentication context, device and behavioural signals, decline or step-up options, customer notification, recovery workflow and data sharing with AML where relevant.

For suspicious reporting, specify legal-entity determination, jurisdiction, case threshold, approval, submission format, deadline, confidentiality, acknowledgements, supplemental filings and retention.

The BA should never accept “financial crime check” as a complete requirement.

What developers and architects should challenge

Architects should challenge duplication of party data, loss of original values, inconsistent identifiers, asynchronous controls inserted into real-time flows without a safe state model, and case platforms that cannot reconstruct what happened.

Developers should challenge unclear field definitions. customerName may mean legal name, display name, payment-entered name or screened normalised name. country may mean residence, incorporation, transaction origin, beneficiary bank country or IP geolocation. riskScore is meaningless unless the model, version and scale are known.

Financial-crime systems are particularly sensitive to semantic ambiguity because apparently small mapping choices can change screening or investigative outcomes.

What testers should prove

Testing should cover more than happy-path matching.

A sanctions test should include aliases, transliterations, missing identifiers, ownership scenarios, false positives, list updates, retroactive rescreening where required, release authority and audit evidence.

An AML test should prove scenario population, thresholds, segmentation, historical lookback, duplicate suppression, case creation, customer linkage, data completeness and tuning controls.

A fraud test should include compromised device patterns, genuine unusual behaviour, new beneficiaries, step-up authentication, concurrent sessions, retries and failure modes.

End-to-end tests should prove that a payment held by one control is not accidentally released by another component that sees only a generic status.

Customer impact and proportionality

Financial-crime controls can protect customers, but they can also harm customers when poorly designed. False fraud blocks can prevent urgent payments. Excessive KYC requests can exclude legitimate customers. Sanctions false positives can delay salaries or humanitarian transfers. AML de-risking can remove access for whole categories of customers rather than manage risk proportionately.

The 2025 and 2026 evolution of FATF and Wolfsberg guidance places stronger emphasis on proportionality, prioritisation and effectiveness. That direction matters. The objective is not maximum friction or maximum alert volume. The objective is a system that applies the strongest attention where risk is greatest while maintaining legitimate access to financial services.

Customer outcome therefore belongs in financial-crime design. Teams should know how long a hold can last, what customers can be told, how urgent or vulnerable cases are escalated, how complaints are handled and how systemic false positives are corrected.

The evidence chain for regulatory defensibility

When a supervisor reviews a financial-crime decision months later, the bank should be able to reconstruct the full chain.

What was known about the customer at the time? Which control fired? Which data was used? Which model or list version was active? What did the analyst see? What additional information was obtained? Which policy and legal entity applied? Who made the decision? Was it approved? What action followed? Was external reporting required? Was the control later changed because of the case?

This is why auditability is not a reporting feature added at the end. It is part of the transaction and case design from the beginning.

A compact operating model to remember

When a financial event occurs, think in this sequence:

Identity — who is acting and who ultimately owns or benefits?

Authority — is the instruction genuinely authorised?

Restriction — is any party, asset, geography or activity prohibited or restricted?

Behaviour — does the activity make sense for the customer and product?

Network — what connected parties, devices, accounts or counterparties change the interpretation?

Evidence — what supports or contradicts the concern?

Decision — which discipline owns the outcome and what rule applies?

Action — release, decline, block, freeze, investigate, restrict, report, exit or another defined response.

Learning — what should improve in KYC, screening, monitoring, fraud models or training because of this event?

That sequence prevents the common mistake of treating “financial crime” as one black box.

Practitioner review questions

Before considering this chapter complete, a reader should be able to answer the following without confusing the disciplines.

Why can a payment be genuine from a fraud perspective but unacceptable from a sanctions perspective? Why can terrorist financing involve legally sourced funds? Why is a PEP not a prohibited person? Why does a sanctions potential match require different handling from an AML monitoring alert? How can fraud intelligence improve AML detection? Why is ISO 20022 data richness useful only when lineage and consumption are preserved? Why should closure reasons feed back into tuning? Why can customer communication differ from internal case rationale? Why can one customer legitimately have several simultaneous financial-crime cases? Why is “AML passed” an unsafe system status?

If those answers are clear, the reader has moved from terminology into operating-model understanding.

Applied practice: one payment, four control clocks

A useful way to test whether the distinctions in this chapter are understood is to take one payment and refuse to let a single label explain it.

Assume a long-standing manufacturing customer initiates a EUR 250,000 cross-border payment to a newly added overseas supplier. The instruction is entered by a genuine authorised user and strong customer authentication succeeds. The beneficiary account details, however, were changed two days earlier after an email exchange. The beneficiary name also resembles a designated entity, while the customer’s account has recently received several third-party credits that do not fit its normal trading pattern.

Fraud asks first whether the instruction is trustworthy. Successful authentication is relevant evidence, but it does not prove that the user was not deceived. A business-email-compromise scam can cause a genuine employee to authorise the wrong beneficiary. Fraud controls may therefore examine beneficiary novelty, device and session history, changes to payment templates, communication or confirmation steps, known scam intelligence and whether the customer can independently verify the supplier’s bank details.

Sanctions asks a different question. The issue is not whether the customer was deceived but whether an applicable restriction affects a party, owner, controller, bank, geography, vessel, goods, service or other relevant element. A name similarity is a potential match, not a legal conclusion. The bank needs sufficient identifiers and the correct sanctions regime to resolve the alert. If a prohibition may apply, the payment state must prevent release while the appropriate sanctions decision is made.

AML asks whether the transaction and the wider account behaviour make economic sense. The new supplier, unexplained third-party credits, changed transaction pattern and any rapid onward movement may justify investigation even if the fraud concern is resolved and the sanctions match proves false. The AML investigator may need customer profile information, source-of-funds context, historical payments, connected counterparties, ownership information and evidence supporting the commercial purpose.

CFT can overlap with AML and sanctions without becoming identical to either. If parties, destinations, networks or intelligence create terrorist-financing concern, analysts must consider that purpose and network dimension. The funds do not have to originate from crime. Where terrorism-related targeted financial sanctions apply, the sanctions control may create an immediate legal consequence; behavioural CFT analysis can continue on a different investigative clock.

The result is a set of parallel facts rather than one “financial-crime result.” The payment can be genuinely authorised, temporarily fraud-held, sanctions-cleared after identity resolution, and still escalated for AML investigation. A system design that forces these into one pass/fail field destroys information the bank may later need.

Decision rights: who may do what

The same scenario should be mapped to decision rights before technology is designed. Fraud operations may be permitted to decline, step up verification, suspend a digital channel or contact the customer under defined procedures. Sanctions operations may resolve documented false positives and escalate plausible true matches, while sanctions compliance or legal may own interpretation of difficult restrictions, licences, ownership or control questions. AML investigators may determine whether activity warrants escalation, while a nominated officer, MLRO or equivalent role may own suspicious-reporting decisions according to local law and governance.

Payment operations can execute a hold, release, return or other technical action, but should not invent the legal reason for that action. Relationship managers can provide commercial context but should not override a mandatory sanctions outcome or a protected suspicious-reporting decision. Senior management may approve risk acceptance or relationship decisions where policy permits, but it cannot authorise conduct prohibited by law.

For a business analyst, these distinctions should become explicit requirements. Every controlled payment state needs an owner, permitted transitions, evidence requirements, release authority and audit trail. “Manual review required” is incomplete unless the requirement identifies who reviews, what information is available, what decision can be made and how the decision changes the payment or customer state.

Shared intelligence without collapsed decisions

Financial-crime controls become stronger when relevant intelligence can be reused. A confirmed scam beneficiary can become an AML intelligence signal. An AML investigation may identify connected accounts that improve fraud beneficiary-risk models. KYC ownership data can help sanctions analysts investigate an unlisted company. Device intelligence can help investigators connect accounts that appear unrelated from transaction data alone.

That does not mean every user should see every record. Suspicious-reporting information, law-enforcement material, sanctions legal analysis, customer authentication evidence and fraud-victim information can be subject to different access restrictions. A good platform therefore shares identifiers and risk-relevant signals through controlled interfaces while preserving purpose limitation, role-based access, provenance and confidentiality.

A reusable signal should carry enough metadata to remain meaningful: source, date, linked customer or transaction identifiers, confidence or disposition where appropriate, expiry or review logic, and restrictions on onward use. A field such as riskyBeneficiary=true is weak because future users cannot tell why the flag exists, how old it is or whether the underlying concern was confirmed.

What an end-to-end test should prove

Testing should reproduce the collision between controls rather than testing each engine only in isolation.

Start with the payment above. Confirm that the fraud engine can request step-up action without overwriting the sanctions state. Confirm that a sanctions potential match prevents release until disposition and that the false-positive decision records the list version, matched data, identifiers considered, analyst and timestamp. Confirm that clearing the sanctions alert does not automatically clear an AML case created from wider behaviour. Confirm that the original beneficiary details remain available even if data is normalised or repaired.

Then change one fact at a time. Make the sanctions match a confirmed restricted party and verify that the applicable legal workflow takes precedence over an ordinary fraud release. Make the beneficiary legitimate but confirm a scam and verify that customer-protection actions and intelligence hand-offs occur. Remove both concerns but retain unexplained third-party credits and verify that AML monitoring can still create a case. Add a terrorism-related designation and verify that the correct targeted-financial-sanctions process is invoked rather than merely increasing an AML risk score.

Failure-path testing matters equally. What happens if the sanctions service is unavailable? Can an instant-payment path fail open? What happens if fraud times out after sanctions has placed a hold? Can a retry create duplicate cases? Can a repaired payment lose the name that originally matched? Can one operational user accidentally release a payment held by another control domain? These are architecture questions with compliance consequences.

Practical close

The professional habit to build is simple: separate identity, authority, restriction, behaviour, network, evidence, decision and action.

Identity asks who the parties really are. Authority asks whether the instruction is genuine. Restriction asks what law or sanctions measure applies. Behaviour asks whether the activity fits the customer and product. Network asks what connected parties change the interpretation. Evidence tests the concern. Decision assigns accountable judgement to the correct discipline. Action translates that decision into a controlled payment, customer, case or reporting outcome.

When those layers remain distinct, teams can collaborate without confusing responsibilities. When they collapse into one generic “AML check,” the bank loses legal precision, operational clarity, testability and auditability.

References and further reading

The chapter uses the following public sources as its main reference base. Global standards are separated from jurisdiction-specific examples because money-laundering offences, suspicious-reporting thresholds, sanctions prohibitions, fraud liability, reimbursement, customer communication and reporting deadlines depend on the law applicable to the bank legal entity, product and transaction.

Global AML, CFT and proliferation-financing standards

• Financial Action Task Force (FATF) — The FATF Recommendations, current version updated June 2026: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html

• FATF — The FATF strengthens its standards to help ensure access to financial services for humanitarian assistance, 23 June 2026. This explains the June 2026 update to Recommendation 6 and its alignment with relevant UN humanitarian exemptions: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/update-recommendation-6-june-2026.html

• FATF — Comprehensive Update on Terrorist Financing Risks, 8 July 2025: https://www.fatf-gafi.org/en/publications/Methodsandtrends/comprehensive-update-terrorist-financing-risks-2025.html

• FATF — Detecting and Disrupting Terrorist Financing Activity through Social Media, Instant Messaging Applications and Streaming Platforms, 26 June 2026: https://www.fatf-gafi.org/en/publications/Methodsandtrends/detecting-and-disrupting-tf-through-smsps.html

• FATF — Complex Proliferation Financing and Sanctions Evasion Schemes, 20 June 2025: https://www.fatf-gafi.org/en/publications/Financingofproliferation/complex-proliferation-financing-sanction-evasion-schemes.html

• FATF — Proliferation Financing topic hub, including Recommendation 7 and proliferation-financing risk material: https://www.fatf-gafi.org/en/topics/proliferation-financing.html

• Basel Committee on Banking Supervision — Anti-money laundering and counter-terrorist financing, Basel Consolidated Guidelines module AFS10, published 1 January 2026: https://www.bis.org/committees/bcbs/basel-consolidated-guidelines/module/afs/10

• Egmont Group of Financial Intelligence Units — Financial Intelligence Units. This describes the FIU role as a national centre for receiving and analysing suspicious transaction reports and disseminating analysis: https://egmontgroup.org/about/financial-intelligence-units/

Bank risk-based controls and suspicious-activity monitoring

• Wolfsberg Group — Guidance on the Risk-Based Approach, 23 June 2026: https://wolfsberg-group.org/news/guidance-on-the-risk-based-approach

• Wolfsberg Group — Statement on Effective Monitoring for Suspicious Activity, Part II: Transitioning to Innovation: https://wolfsberg-group.org/resources/195/202

Jurisdiction-specific examples used in the chapter

• U.S. Treasury Financial Crimes Enforcement Network (FinCEN) — Frequently Asked Questions Regarding Suspicious Activity Reporting Requirements, issued 9 October 2025. This is a United States source and should not be treated as a global SAR/STR rule: https://www.fincen.gov/resources/statutes-regulations/guidance/frequently-asked-questions-regarding-suspicious-activity

• U.S. Treasury Office of Foreign Assets Control (OFAC) — Sanctions Programs and Country Information. OFAC rules apply within their U.S. legal scope and nexus; they are not a universal sanctions code: https://ofac.treasury.gov/sanctions-programs-and-country-information

• OFAC — A Framework for OFAC Compliance Commitments, published 2 May 2019, for U.S.-specific sanctions-compliance programme expectations: https://ofac.treasury.gov/recent-actions/20190502_33

• European Banking Authority and European Central Bank — Joint EBA-ECB report on payment fraud: strong authentication remains effective but fraudsters are adapting, 15 December 2025. This is EEA payment-fraud evidence, not a global fraud-liability rule: https://www.eba.europa.eu/publications-and-media/press-releases/joint-eba-ecb-report-payment-fraud-strong-authentication-remains-effective-fraudsters-are-adapting

Educational note: the chapter explains global control concepts and a bank operating model. Operational decisions must use current local law, competent-authority guidance and the bank's approved policy for the relevant legal entity and transaction.