Fraud-to-AML Handoffs and Scam Proceeds

A scam can begin as a fraud problem and become an anti-money-laundering problem within seconds. A customer is deceived into sending a payment, the receiving account is used as a mule, the funds are split across several accounts, part of the value is converted into virtual assets, and another part is withdrawn or transferred across borders. Fraud operations may see the deception, authentication and customer contact. Payment operations may see the payment status, recall attempts and beneficiary bank. AML teams may see the receiving account, onward movement, customer profile and wider network. None of those views is complete on its own.

That is why a mature bank does not treat fraud and AML as two unrelated factories. They remain different control disciplines with different legal duties, customer outcomes and specialist skills, but they need a governed way to exchange intelligence. The handoff is not simply “fraud found, therefore file a suspicious activity report.” Fraud is a predicate offence in many legal systems and fraud proceeds can be laundered, but a fraud event does not automatically prove money laundering, establish that an account holder knowingly participated, or create the same reporting duty in every jurisdiction. The receiving AML team still has to assess the facts against local law, policy and reporting thresholds.

The global context has become more important. FATF’s February 2026 paper on cyber-enabled fraud describes fraud as a major money-laundering risk across a very large share of assessed jurisdictions and emphasises faster information sharing, international cooperation and asset recovery. Its 2023 work on illicit financial flows from cyber-enabled fraud also highlights how scam proceeds can move rapidly across institutions and borders. Those publications are useful global reference points, but they do not replace domestic suspicious-transaction reporting law, privacy law, payment-scheme rules or customer-redress requirements.

For a bank, the practical objective is therefore precise: preserve the fraud evidence, identify when the activity needs AML assessment, trace the movement of value, protect customers, avoid labelling victims as criminals without evidence, and make sure the relevant team owns each decision at the right time.

Fraud and AML handoff lifecycle showing how a scam event moves from customer harm and payment response into AML assessment, network investigation and prevention feedback.

A simple mental model: event, proceeds, network, decision

The easiest way to understand the topic is to separate four questions.

The first question is what happened to the customer? Fraud teams establish whether there was deception, impersonation, account takeover, social engineering, payment redirection, investment fraud, romance fraud or another scam pattern. They also capture whether the customer authenticated the transaction, whether credentials or devices were compromised, what warnings were shown, what the customer was told by the scammer, and what immediate customer-protection action is needed.

The second question is where did the money go? Payment and investigation teams establish the payment identifiers, beneficiary account, beneficiary payment service provider, timestamps, settlement status, recall or recovery actions, returns and onward movement visible to the bank. This is the bridge between customer harm and proceeds tracing.

The third question is what does the wider activity suggest? AML teams look beyond the original victim payment. They ask whether the receiving customer’s behaviour fits the stated profile, whether funds are rapidly passed onward, whether multiple victims pay the same account, whether several accounts share devices or counterparties, whether funds move through exchanges or other conversion points, and whether the combined facts raise suspicion under the law and policy applicable to that bank entity.

The fourth question is what decision is required now? The answer may be further inquiry, a fraud restriction, an AML case, enhanced monitoring, customer safeguarding, a payment recovery action, account review, suspicious transaction reporting, law-enforcement contact, or no further action. Several decisions can coexist. A customer can be a scam victim and still require an AML review if the account is being used to move other victims’ funds. A beneficiary account can look suspicious without the bank having enough evidence to decide whether its holder is knowingly complicit, recruited, coerced or deceived.

This separation matters because it prevents a common control failure: collapsing every fraud signal into a single “criminal” flag. A well-designed bank system preserves observations, assessments and legal outcomes as separate data objects. The observation may be “three incoming transfers from unrelated senders were forwarded within twenty minutes.” The assessment may be “possible mule or pass-through activity.” The legal or policy outcome may be “escalate for AML investigation.” Those are not the same statement.

Why fraud and AML teams see different evidence

Fraud controls are usually designed around immediacy. They may use session telemetry, device reputation, behavioural biometrics, authentication history, beneficiary novelty, transaction velocity, customer warnings and known scam patterns. Their time horizon can be seconds or minutes because the goal may be to prevent a payment before it becomes irrevocable or to contact a customer quickly after an unusual event.

AML monitoring typically works across a broader relationship and longer history. It can combine KYC data, expected activity, product use, counterparties, geographies, cash activity, account networks, previous alerts and external intelligence. Wolfsberg’s work on effective monitoring for suspicious activity is useful here because it encourages institutions to think more broadly than traditional transaction-monitoring rules. Customer behaviour, attributes and transactions together can reveal risk that no single payment rule can explain.

The difference in evidence creates the need for a handoff. A fraud investigator may know that a victim was coached to ignore a warning and use a particular payment reference. An AML investigator may know that the beneficiary received funds from nine unrelated senders and moved them to two exchanges and three newly opened accounts. If the first team sends only “confirmed scam” and the second team sends only “possible mule,” both lose the context needed for a high-quality decision.

The handoff therefore needs to carry enough evidence to reconstruct the story, not just a disposition code.

Fraud does not automatically equal AML suspicion

This distinction is fundamental. A card purchase made with stolen credentials is fraud, but the legitimate merchant receiving the payment is not thereby a money launderer. A customer tricked into sending money to a scammer is a victim, not automatically a suspicious customer. A person whose account receives scam proceeds may be a knowingly recruited mule, an unwitting intermediary, a coerced person, an identity-theft victim or a legitimate beneficiary incorrectly associated with the fraud.

Banks should therefore use handoff triggers as reasons for AML assessment, not as conclusions. FinCEN’s 2016 US advisory on business and e-mail account compromise makes the same practical point in a jurisdiction-specific way: no single fraud red flag necessarily establishes suspicious activity, and institutions should consider the surrounding facts and expected customer activity. The same advisory also encourages communication among fraud, cybersecurity, business and BSA/AML functions. The US SAR rules described there apply to US-regulated institutions; other jurisdictions use their own STR, SAR or SMR frameworks and thresholds.

For delivery teams, this means the case model should distinguish fraud_confirmed, aml_review_required, suspicion_formed, reporting_decision, customer_restriction and law_enforcement_contact. Treating them as one status creates false certainty and makes audit reconstruction difficult.

What should trigger a fraud-to-AML handoff?

A good trigger framework combines several kinds of evidence. It does not rely on a single amount threshold.

A receiving account may warrant AML assessment when fraud-confirmed funds arrive and then move rapidly onward, especially if the pattern repeats with unrelated senders. Several fraud cases may point to the same beneficiary, device, telephone number, IP range, merchant, wallet address or account cluster. A customer who was initially treated as a scam victim may begin receiving and forwarding third-party funds under instructions from the scammer. An apparently legitimate business may receive a sudden concentration of consumer payments unrelated to its known activity. A fraud investigation may uncover fabricated invoices, shell entities or payment instructions that suggest a broader laundering network.

Materiality still matters, but it should be risk-based. A bank may decide that some high-value fraud events always receive an AML review because the potential proceeds and external reporting implications are significant. Lower-value cases may be escalated when network or repeat-activity indicators are present. The threshold logic should be documented, tested and reviewed against actual conversion outcomes rather than inherited indefinitely from an old rulebook.

The trigger should also describe why the case is being transferred. “Fraud case 1234” tells the AML investigator almost nothing. “Confirmed impersonation scam; receiving account has three linked victims, 92% of funds moved onward within 35 minutes, two counterparties overlap with an existing AML case” is actionable.

Fraud-to-AML handoff trigger model separating customer harm, proceeds behaviour, network evidence and contextual risk before an AML assessment decision.

The handoff package: what data must travel with the case

A handoff should be treated as a controlled data product. At minimum, the receiving team needs the source case identifier, customer and account identifiers, payment references, timestamps, amounts, currencies, beneficiary and beneficiary-PSP details, fraud type, customer-contact summary, authentication or device evidence where relevant, recall or recovery status, linked cases and a concise reason for escalation.

The package should preserve provenance. If an IP address came from the digital channel, the case should record the source system and timestamp. If a customer said the scammer contacted them through a messaging application, that is customer-provided information and should not be presented as independently verified. If a beneficiary is linked to another case through an internal entity-resolution engine, the relationship and matching confidence should be visible. Investigators need to know what is fact, what is customer statement, what is model output and what is analyst inference.

Raw evidence and analyst conclusions should remain separable. This is particularly important when the case later supports a regulatory report, a response to an FIU or law-enforcement request, a customer complaint, or internal quality review. An investigator should be able to see the original payment event and the reasoning applied to it rather than only a final label.

Useful technical fields include a common case ID, source-system IDs, event timestamp in a consistent time standard, account and customer keys, payment rail, payment status, end-to-end and scheme identifiers where available, beneficiary identifiers, device/session IDs, channel, authentication outcome, fraud typology, victim status, recovery action, AML reason code, linked-entity IDs, evidence source, evidence timestamp, analyst confidence and data-retention classification.

Tracing scam proceeds without overclaiming certainty

Scam proceeds can disperse rapidly. A victim’s payment may arrive at one account, split into several transfers, move to another institution, be withdrawn as cash, purchase goods, fund a prepaid instrument or be converted into virtual assets. The bank should reconstruct what it can see and clearly mark where visibility ends.

The trace begins with the victim transaction and follows confirmed account movements. Investigators should capture the amount entering each account, the time it remained there, the amount moved onward, destinations, fees or deductions and any value left behind. When multiple victim payments converge on a common account, the pattern can be more informative than any single transfer.

Cross-institution recovery and information sharing require legal and scheme-specific handling. A sending bank may be able to submit a recall, recovery request or scam notification through a payment scheme or bilateral channel, but it should not assume it has a universal right to freeze funds held by another institution. The receiving institution applies its own legal duties, contractual rules and internal controls. Information sharing between institutions also depends on the applicable legal basis, privacy framework, confidentiality rules and any recognised industry or statutory mechanism.

Virtual-asset movements require the same discipline. A transfer to an exchange can indicate a conversion point, but it does not by itself prove laundering. Blockchain analytics may help identify transaction paths or known service exposure, yet attribution can be probabilistic and should be corroborated. FATF’s 2026 work on stablecoins, unhosted wallets and offshore VASPs highlights the growing complexity of virtual-asset-enabled fraud and illicit finance, but a bank still needs evidence appropriate to its own case before making a customer decision.

Scam-proceeds trace from victim payment through receiving account, onward mule layers and conversion points, with clear visibility boundaries and evidence confidence.

Money mules: avoid the victim-or-criminal binary

Mule activity is where fraud and AML most obviously overlap. Some people knowingly allow criminals to use their accounts. Some are recruited with misleading “job” offers. Some are groomed through romance or investment scams. Some are coerced. Some have accounts opened or taken over through identity abuse. The bank’s task is to assess the evidence and manage risk; it should not pretend to determine criminal liability, which belongs to competent authorities under the relevant law.

AUSTRAC’s work on exploitation of international students as money mules is a useful example of this nuance. It describes vulnerable people being recruited to move criminal proceeds and encourages Australian reporting entities to consider suspicious matter reporting when combinations of indicators raise suspicion. That is an Australian example, not a universal reporting rule, but the analytical lesson travels well: vulnerability and suspicious movement can coexist.

A practical mule assessment therefore looks at how the account was opened, who appears to control the device, whether credentials are shared, the source and purpose of incoming funds, the speed and direction of onward transfers, customer explanations, communication evidence, prior warnings, linked accounts, cash withdrawals and whether the customer retains a commission. The conclusion should record uncertainty where uncertainty exists.

For customer treatment, the distinction matters enormously. A person who is clearly being exploited may need safeguarding and tailored communication. A customer who appears to be knowingly facilitating a network may require restrictions, exit review or reporting under local policy. An ambiguous case may need both protective measures and enhanced investigation. The control should allow those paths instead of forcing a binary classification too early.

Joint ownership without losing accountability

“Fraud and AML jointly own the case” can sound collaborative while hiding a practical problem: if everybody owns it, nobody may be accountable for the next action. A better model assigns explicit phase ownership.

Fraud operations can lead the immediate customer-harm response: contacting the customer, securing credentials, stopping or challenging payments where possible, initiating recovery, handling fraud claims and applying customer safeguards. AML can lead the wider financial-crime assessment: reviewing the receiving relationship, mapping related accounts and counterparties, evaluating suspiciousness, deciding on escalation to the MLRO or equivalent function, and supporting any regulatory reporting process required by local law.

Payment investigations may own the payment-chain work, such as recalls, returns, scheme messaging and evidence from correspondent or beneficiary institutions. Financial-crime intelligence teams may own network analytics. Legal, privacy, sanctions, cyber, complaints and vulnerable-customer teams may need to be consulted depending on the case.

The handover point must be explicit. A case may transfer from fraud to AML, or the two teams may work in parallel while retaining distinct decisions. The system should record the accountable owner for each action, due date, escalation path and status. Joint governance is useful; shared ambiguity is not.

Joint ownership model showing which fraud, payments and AML decisions remain separate, which evidence is shared, and where governance resolves overlaps.

Alert, case, investigation and reporting outcomes

A handoff should not create an AML case merely to satisfy a process metric. The receiving team should triage the evidence and decide what is proportionate. Some referrals can be closed quickly because the fraud context fully explains the activity and there is no additional suspicious behaviour. Others require a full investigation because the beneficiary account, network or onward movement raises unresolved concerns.

An AML investigation may include customer-profile review, transaction history, counterparty analysis, linked-account search, prior alert review, KYC refresh, source-of-funds questions, device or channel information, adverse information where appropriate and requests for additional internal evidence. The investigation should preserve the fraud narrative because the original deception method can explain why money entered the network and can identify other likely victims.

If suspicion is formed, reporting follows the institution’s applicable law and policy. FATF Recommendation 20 provides the global standard that financial institutions should report suspicious transactions to the relevant FIU, but the legal threshold, timing, scope, terminology, confidentiality obligations and filing mechanics are jurisdiction-specific. US institutions may file SARs under BSA rules; Australia uses SMRs; many jurisdictions use STR terminology. The chapter therefore does not prescribe one universal filing threshold.

The bank must also manage confidentiality. Information about an internal fraud investigation may be shareable with the customer for fraud-resolution purposes, while information relating to an AML report can be subject to strict confidentiality or tipping-off restrictions. Case design should keep those information domains distinguishable so a service agent does not accidentally expose restricted AML information.

Reimbursement and AML investigation are separate decisions

Customer reimbursement can run in parallel with AML work. The fact that a customer is reimbursed does not decide whether the beneficiary network is suspicious, and an AML investigation should not automatically delay customer redress where the applicable rules require a faster outcome.

The United Kingdom provides a useful jurisdiction-specific example. PSR requirements for in-scope Faster Payments and CHAPS APP scam claims took effect on 7 October 2024, with defined reimbursement rules and a maximum reimbursement level. Those rules create operational timelines and cost-sharing incentives for relevant UK payment service providers. They should not be projected onto countries or payment systems that do not have the same framework.

For architecture, the safest design is to keep fraud_claim_outcome, reimbursement_status, recovery_status, aml_case_status and regulatory_reporting_status as separate but linkable objects. That allows fraud operations to meet customer deadlines while AML continues a network investigation without one workflow overwriting the other.

Confirmation of Payee and beneficiary intelligence

Name-checking services can provide useful fraud context. In the UK, Confirmation of Payee compares the payee name entered by the payer with the name held for the receiving account and can return match, close-match or no-match results. The PSR has directed broad implementation across Faster Payments and CHAPS participants in scope. Other markets use different account-name or beneficiary-verification mechanisms, so “Confirmation of Payee” should not be treated as a universal scheme term.

A mismatch can be useful evidence but is not proof of fraud or money laundering. Legitimate differences can arise from trading names, joint accounts, abbreviations or data quality. The value comes from combining the result with other evidence: a new beneficiary, urgent scam narrative, multiple victim payments to the same account, a sudden change in beneficiary details or known mule-network links.

For a handoff, the bank should preserve the actual name-check result, timestamp, user response and any override or warning shown. That gives AML investigators context without turning a fraud-prevention control into an unsupported suspiciousness conclusion.

Information sharing: powerful, but legally bounded

Fast intelligence sharing can improve recovery and network detection, but banks need to know the legal basis for each exchange. Internal sharing between fraud and AML teams is usually easier than sharing with another institution, but even internal access should follow purpose limitation, role-based access, retention controls and need-to-know principles.

External sharing can occur through scheme processes, FIU or law-enforcement channels, statutory information-sharing arrangements, industry utilities or bilateral mechanisms where permitted. FinCEN’s Section 314(b) framework is a US example; it should not be used as a global model without checking local law. FATF has continued to emphasise effective public-private and cross-border information sharing, including in its 2026 work, while also recognising data-protection considerations.

The practical rule is simple: a case-management screen should never assume that because data is useful, it is legally shareable. Architecture should support jurisdiction, purpose, recipient, legal basis, approval, data category and disclosure timestamp as part of the audit trail.

System architecture for a real handoff

A robust implementation usually connects several platforms rather than replacing them with one giant case system. The digital channel or fraud engine creates the initial event. A fraud case system captures the customer interaction and evidence. The payment hub provides payment status and identifiers. A transaction-monitoring or financial-crime platform provides alerts and network context. A customer master and KYC platform provide profile data. Entity-resolution services connect beneficiaries, devices and accounts. A case-management layer coordinates the handoff. Reporting platforms handle regulatory submissions where required.

The critical architecture issue is correlation. The same event may have a channel transaction ID, payment instruction ID, clearing reference, end-to-end identifier, fraud case ID and AML case ID. Without a correlation model, investigators copy data manually and lose traceability. A canonical handoff object can hold the cross-references without forcing all source systems to adopt one identifier.

The handoff event should be idempotent. If the fraud platform retries a message, the AML system should not create duplicate cases. Versioning matters because new evidence can arrive after the initial referral. A subsequent victim complaint or beneficiary link should enrich the existing referral rather than silently overwrite the earlier evidence. Audit logs should show who changed a conclusion, when and why.

Latency should reflect the use case. A potential live scam where funds are still recoverable may need near-real-time notification. A historical network review may tolerate batch processing. The requirement should state the business outcome and deadline rather than simply demand “real time” everywhere.

Data quality and lineage

Poor data can break the handoff even when the policy is sound. Common failures include missing beneficiary identifiers, truncated names, timestamps in different time zones, inconsistent customer keys, lost payment references, duplicate alerts, stale KYC data and fraud notes stored only as free text.

A BA should trace each critical field from source to destination. Where did the beneficiary account come from? Is it the instructed beneficiary or the final settled beneficiary? Is the device ID stable across channels? Does a “confirmed fraud” flag mean customer-confirmed, analyst-confirmed or chargeback-confirmed? Can the AML investigator see the original fraud reason code or only a transformed category?

Quality controls should reconcile handoff populations. If 1,000 fraud cases met the referral trigger, the downstream system should account for all 1,000 as received, rejected with reason, merged, pending or errored. Silent message loss is a control failure even when individual cases look correct.

Failure modes that banks should test deliberately

The first failure mode is late handoff. Fraud closes the customer claim before AML sees the beneficiary network. By the time the case arrives, funds have dispersed and related accounts have continued operating.

The second is thin handoff. The referral contains only a generic fraud code, forcing AML to reconstruct the customer contact, payment identifiers and device evidence. This increases handling time and encourages inconsistent closure.

The third is over-handoff. Every fraud case is transferred regardless of AML relevance. The queue grows, analysts learn that referrals are low value, and genuinely important network cases compete with noise.

The fourth is victim misclassification. A groomed or coerced person is treated as a knowing mule because the system sees only transaction direction. The opposite can also happen: an apparently vulnerable narrative is accepted without testing evidence that suggests deliberate facilitation.

The fifth is conflicting customer action. Fraud operations unblock or reassure a customer while AML is considering restrictions, or AML action disrupts a fraud-recovery process. Named owners and shared action visibility reduce this risk.

The sixth is unsafe information sharing. Useful intelligence is emailed or exported without checking purpose, recipient, confidentiality or local law. A technically effective handoff can still fail legally if disclosure controls are weak.

The seventh is model overconfidence. An entity-resolution or blockchain score is treated as fact. Scores should support investigation, not replace it.

Measuring whether the handoff works

The best metrics measure outcomes and control quality rather than the number of referrals. Useful measures include time from confirmed fraud to AML receipt, percentage of referrals containing all mandatory evidence, proportion of referrals converted into substantive AML investigations, duplicate rate, linked-victim discovery, recovery action started within the required window, cases with victim-safeguarding actions, false or unnecessary referral rate, repeat-loss reduction and time to feed newly identified mule infrastructure back into fraud controls.

A high conversion rate is not automatically good if the bank is missing networks outside a narrow trigger. A low conversion rate is not automatically bad if the handoff is intentionally broad for a high-risk typology. Metrics need context, trend analysis and quality sampling.

Governance should review missed handoffs as seriously as bad handoffs. Post-event analysis can ask whether a later-confirmed mule account had earlier fraud evidence that should have triggered AML assessment. That is how the bank finds seams between functions rather than simply optimising each function separately.

BA requirements and acceptance criteria

A BA should be able to describe the handoff without relying on words such as “appropriate” or “timely” unless those terms are made testable. Requirements should define the trigger, evidence package, receiving queue, priority, ownership, SLA, deduplication key, enrichment behaviour, error handling, customer-action visibility and audit evidence.

A strong acceptance criterion might say that when two confirmed scam cases within a defined observation window share the same beneficiary account and the configured network trigger is met, the platform creates or enriches one AML referral, links both fraud cases, preserves both payment references and customer narratives, records the trigger reason and does not create a duplicate on message retry. Another criterion might require that a fraud case marked as possible victim-mule routes to a joint-review queue rather than automatically applying a knowing-mule label.

Negative testing matters. A legitimate business receiving several payments should not be escalated merely because volume is high if the activity is consistent with the customer profile and there is no fraud linkage. A legitimate name mismatch should not become an AML case solely because a name-checking service returned “close match.”

Failure-mode testing should cover unavailable entity-resolution services, delayed payment data, duplicate events, corrected fraud classifications, revoked customer consent where relevant, cross-border privacy restrictions and a case that becomes subject to AML-report confidentiality after the handoff.

Mini case study: the beneficiary that appeared in five scam cases

Consider a fictional retail bank that confirms five impersonation scams over two days. The victims are unrelated. Each sent between modest and mid-sized amounts to the same beneficiary account at the bank’s own institution. Fraud operations focused correctly on the victims, blocked compromised credentials where needed and started recovery activity. The beneficiary account initially looked ordinary because it had been opened six months earlier and had regular salary-like credits.

The handoff trigger fired because the beneficiary was common to multiple confirmed scams. The referral contained all five payment IDs, victim case IDs, customer-contact summaries, the beneficiary account and timestamps. AML enrichment then showed that most incoming scam funds moved onward within forty minutes to two newly added external beneficiaries and one virtual-asset service provider. Device analysis also linked the receiving account to a second internal account opened with different identity details.

That evidence justified a deeper AML investigation, but it still did not prove what the account holder knew. The investigator reviewed onboarding evidence, device history, prior account behaviour and customer explanations. The bank applied customer and transaction controls under its local policy while the MLRO function assessed whether the legal suspicious-reporting threshold was met. Fraud operations continued victim communication and recovery work in parallel.

The important lesson is not the final disposition. It is the control chain. Fraud evidence identified customer harm. The handoff connected separate victim cases. AML analysis identified the network. Payment data preserved the fund trail. The bank kept victim redress, customer restrictions and regulatory reporting as separate decisions, each with its own owner and legal basis.

Composite case timeline showing five scam victims converging on one beneficiary, onward dispersal, AML network discovery and separate customer, recovery and reporting decisions.

What good looks like

A good fraud-to-AML handoff is fast without being careless, rich without being indiscriminate, and evidence-led without pretending uncertainty has disappeared. Fraud teams preserve the deception story. Payment teams preserve the movement of value. AML teams test whether the activity creates wider financial-crime concern. Customer-protection teams keep vulnerability in view. Technology connects the records without erasing their different purposes.

The strongest control is not the one that sends the most cases from fraud to AML. It is the one that sends the right cases with enough evidence, early enough to matter, and then feeds what AML learns back into fraud prevention. That closed loop turns isolated customer incidents into reusable financial intelligence while keeping legal decisions, customer outcomes and investigative conclusions properly separated.

References and further reading

Operational deep dive: from referral trigger to evidence-ready case

The base chapter explains why fraud and AML need a controlled handoff. This deep dive focuses on the operational mechanics that determine whether the handoff works under real bank conditions: trigger calibration, evidence packaging, cross-border boundaries, victim contact and queue management. The objective is not to make every fraud case an AML case. It is to make sure cases with wider proceeds or network risk are transferred early enough, with enough context, for the receiving team to make an independent assessment.

Calibrating handoff triggers

A referral trigger should be built from observed risk, not convenience. Amount can be one component, but scam networks often deliberately use smaller transfers to avoid review. More useful variables include number of unrelated fraud victims paying the same beneficiary, percentage of incoming funds moved onward, dwell time, concentration of newly added beneficiaries, linked devices, common contact details, repeat fraud complaints and overlap with existing financial-crime cases.

Calibration should be segmented. A pattern that is unusual for a personal current account may be routine for a marketplace seller or money-service business. Thresholds therefore need customer, product and channel context. Historic labelled cases can help estimate which combinations generated meaningful AML investigations, but outcome data must be treated carefully because older cases reflect the bank's previous controls and may contain selection bias.

The control owner should monitor both referral yield and missed networks. If a trigger produces thousands of low-value referrals that AML closes immediately, it may be too broad. If post-event reviews repeatedly discover that known mule accounts had earlier fraud cases that never reached AML, it may be too narrow. Changes should be versioned, approved and tested so the bank can explain why a threshold moved and what effect followed.

The evidence package

The most important operational discipline is preserving the evidence as it crosses the organisational boundary. A receiving AML investigator should not have to reconstruct the fraud case from screenshots, email chains and free-text notes.

A practical package contains four layers. The first is identity and relationship context: customer ID, account ID, KYC risk profile, product, opening date and relevant linked parties. The second is the fraud event: fraud typology, customer statement, authentication evidence, device or session data, payment warning outcome and whether the fraud classification is confirmed or provisional. The third is the payment trail: instruction ID, amount, currency, initiation and settlement timestamps, beneficiary account, beneficiary PSP, clearing or scheme reference, recall status and any returned funds. The fourth is the AML reason for referral: network link, rapid onward movement, multiple victims, unexplained third-party funds, linked cases or another documented concern.

The package should not convert analyst inference into fact. For example, customer stated scammer instructed transfer is different from scammer controlled customer. Blockchain analytics exposure score is different from funds proven to originate from a criminal wallet. Provenance, source and confidence should travel with the data.

When a case is enriched after referral, the handoff should be versioned. A new victim link, corrected beneficiary identifier or changed fraud classification should create a visible update rather than silently overwrite the original record. This allows investigators, quality reviewers and auditors to reconstruct what the bank knew at each decision point.

Queue design and priority

A handoff queue should reflect urgency. Some cases matter primarily because of investigation quality; others also contain a narrow recovery window. A confirmed scam payment that settled minutes ago to an internal beneficiary is not operationally equivalent to a six-month-old historic alert. Priority should consider recoverability, active customer harm, network size, value, ongoing account activity and whether the receiving account remains open and capable of dispersing funds.

Priority must not be confused with suspiciousness. A case can be urgent because customer funds may still be recoverable even if the AML conclusion is uncertain. Conversely, a case can present serious laundering concern but no immediate recovery opportunity. Separate fields for urgency, fraud severity and AML risk avoid forcing one score to represent three different questions.

Work allocation should also recognise complexity. Cases involving possible victim-mules, cross-border value movement, corporate beneficiaries, virtual assets or several related fraud cases may require specialist review. Routing rules should be transparent and should allow escalation when an apparently simple referral develops into a network case.

Cross-border coordination without inventing powers

Scam proceeds can cross institutions and jurisdictions quickly, but a bank's legal power does not travel automatically with the money. A sending institution may be able to issue a recall, scam notification or recovery request through a payment scheme, correspondent relationship or bilateral process. The receiving institution decides what action it can take under its own law, scheme obligations and account relationship.

International cooperation between FIUs and law-enforcement agencies is separate from ordinary bank-to-bank information sharing. FATF encourages rapid cooperation and information exchange, and national mechanisms can support it, but a commercial bank should not describe itself as directing prosecutions or freezing assets in another jurisdiction unless a specific legal mechanism provides that authority.

Cross-border handoff requirements therefore need a jurisdiction map. It should identify which legal entity holds the customer, where data is stored, which team may access it, whether external sharing is permitted, what payment-recovery mechanism applies, which FIU receives any required report and what confidentiality restrictions follow. The map is especially important in global groups where the fraud platform is centralised but AML reporting duties remain local.

Victim contact and AML confidentiality

A bank can damage both customer trust and investigation quality if fraud and AML teams contact the same person independently without coordination. The fraud team may need to explain reimbursement, secure the account and collect the scam narrative. AML may need additional information about incoming funds or counterparties. The customer should not receive contradictory messages or be exposed to information that is legally restricted.

A practical model designates one customer-contact owner while allowing other teams to request questions through that owner. The case record should distinguish questions that can be discussed openly from information linked to a confidential AML reporting process. Local legal advice and policy are necessary because tipping-off and SAR/STR confidentiality rules differ by jurisdiction.

Victim safeguarding should remain visible after the handoff. Repeated scam victimisation, coercion, cognitive vulnerability or grooming may require specialist support. A case should not lose those indicators simply because the account also shows movement that needs AML assessment.

Controlled testing instead of production theatre

Handoff testing should use synthetic or tightly governed test cases wherever possible. A complete end-to-end test starts with a fraud event, creates the referral, transfers the evidence, deduplicates repeated messages, links related cases, updates the receiving case when new evidence arrives and records every action in the audit trail.

Positive tests should cover multiple confirmed victims paying one beneficiary, a possible victim-mule, rapid onward movement, cross-border beneficiary routing and a virtual-asset conversion point. Negative tests should include a legitimate high-volume merchant, a benign name mismatch and a fraud event with no broader AML indicator. Failure tests should cover unavailable entity-resolution services, delayed payment data, duplicate events and a receiving queue outage.

Acceptance should be based on evidence. The test should prove that the same case is created once, all mandatory identifiers are present, timestamps retain their meaning, source evidence remains attributable, updates are visible and no restricted AML information is exposed to an unauthorised role.

Operational quality review

Quality assurance should sample both accepted and rejected handoffs. Accepted referrals show whether AML reasoning was proportionate and whether useful evidence arrived. Rejected referrals show whether the trigger is producing noise or whether analysts are overlooking network risk. Missed-handoff reviews are equally important because they test what the process never transferred.

Useful quality questions include: Was the customer correctly identified as victim, possible mule or unresolved? Was the fraud narrative preserved? Could the investigator follow the payment trail without re-keying information? Did the referral explain why AML assessment was needed? Were recovery and reporting decisions kept separate? Did any external information sharing have a recorded legal or policy basis? Was the final decision supported by evidence rather than a model score alone?

A strong handoff process improves through this feedback. Fraud teams learn which evidence AML finds useful. AML teams feed newly identified beneficiary and mule patterns back to fraud detection. Product and technology teams fix missing data. The process becomes a closed control loop rather than a one-way referral queue.

Advanced practice: reverse handoffs, network intelligence and governance

The strongest fraud-to-AML design is bilateral. Fraud sends scam and payment intelligence into AML, while AML sends network intelligence back into fraud prevention. Without that reverse path, the institution may investigate the same beneficiary, device or recruitment pattern repeatedly after new victims have already lost money.

Reverse handoffs from AML into fraud prevention

An AML investigation may identify a cluster of receiving accounts, shared devices, common beneficiary details, virtual-asset conversion points or recruitment narratives that were not visible to the fraud engine when the original payments were made. Those findings can become fraud-prevention intelligence, but they should be translated carefully.

A confirmed internal account link may support a beneficiary-risk rule. A recurring recruitment phrase can improve agent guidance. A common device or channel pattern may support additional authentication or onboarding review. A newly identified account should not automatically become a permanent blacklist entry without governance, because account ownership can change, data can be wrong and investigative conclusions can later be revised.

The reverse handoff therefore needs a lifecycle: intelligence proposed, evidence reviewed, scope approved, control implemented, effectiveness measured and intelligence expired or refreshed. Each item should have an owner and an effective period. This prevents temporary investigative clues becoming indefinite customer restrictions with no review mechanism.

Entity resolution and network analytics

Scam networks rarely use one clean identifier. They reuse fragments: telephone numbers, devices, addresses, beneficiary names, corporate officers, IP ranges, wallets, payment references and cash-out destinations. Entity resolution helps investigators connect those fragments, but matching confidence must remain visible.

A deterministic match, such as the same internal account number, is different from a probabilistic match between similar names and addresses. Architecture should store the relationship type, matching method, confidence and source data. Investigators should be able to challenge a link rather than inherit it as fact.

Network visualisation is most useful when it explains direction and timing. A graph that simply shows many connected nodes can look impressive while teaching little. Better analysis identifies who paid whom, when, how quickly funds moved onward, which accounts received multiple victim payments, which entities bridge clusters and where the bank loses visibility.

Monitoring the beneficiary side

Fraud prevention often starts with the payer, but scam-proceeds control also needs beneficiary intelligence. A receiving account that suddenly attracts unrelated consumer payments, followed by rapid dispersal, may deserve attention even when each individual transfer is below a fraud threshold.

Beneficiary monitoring can combine account age, prior activity, incoming payer diversity, payment purpose, fraud-confirmed source events, onward velocity, cash withdrawal, transfer to newly added beneficiaries and links to other investigated accounts. This should be calibrated to the customer's expected business. A legitimate marketplace seller or charity can have many unrelated payers; context prevents the control from confusing business models with mule behaviour.

Receiving-bank intelligence becomes particularly valuable when the bank also holds the beneficiary account. The fraud team can see confirmed victim reports while AML can see the full receiving-account history. A governed internal link between those two views can shorten the time from first victim report to network action.

Governance and decision rights

A joint steering forum can help when fraud and AML priorities compete, but governance should focus on decisions rather than meetings. It should own trigger changes, handoff quality, systemic data gaps, recurring missed networks, customer-treatment conflicts and investment priorities.

The forum should not take over individual suspicious-reporting decisions from the MLRO or other legally designated function. Nor should it decide fraud reimbursement contrary to the applicable scheme or jurisdictional rules. Its purpose is to make the interface work while preserving legal accountabilities.

A useful responsibility model separates: fraud-event classification; immediate customer protection; payment recovery; AML investigation; suspicious-reporting decision; customer restriction or exit; external information sharing; and control tuning. Each can have a different accountable owner even when the same case supplies evidence to all of them.

Privacy and purpose limitation

A shared fraud-AML data platform can improve detection but also creates privacy and access risk. The fact that fraud data might be useful to AML does not justify unrestricted access to every fraud record. Role-based access should reflect purpose, jurisdiction and sensitivity.

Data minimisation is especially important for customer communications, device data and third-party personal information. A handoff should carry the fields needed for the receiving control, not every data element available in the source platform. Retention periods should follow the applicable recordkeeping framework rather than the longest period used by any connected system by default.

Audit logs should record who viewed or changed sensitive information. External disclosure should record recipient, purpose, legal or policy basis, approving authority where required and the information actually shared.

Control change after a new typology

Suppose AML identifies a recurring pattern in which recently opened accounts receive two or three scam-confirmed credits and then send most value to the same group of external beneficiaries. The immediate response may be case investigation. The strategic response is to ask whether fraud or monitoring controls can identify the pattern earlier.

A change team should test whether the pattern is stable, how many legitimate customers would be affected, whether the source labels are reliable, and whether the control can act before settlement or only after it. If implemented, the new rule should include a documented objective, population, data lineage, threshold, expected false-positive range, decision action and review date.

This is where reverse handoffs create measurable value. The institution stops treating AML investigations as endpoints and starts using them as intelligence to prevent the next scam.

Management information that matters

Useful management information links the two functions. It can show the number of fraud cases meeting AML referral criteria, time to referral, completeness of handoff data, percentage converted to substantive AML investigations, number of linked victims discovered, value recovered or protected where attribution is credible, number of missed handoffs found in quality review, and time taken to translate confirmed network intelligence into preventive controls.

The metrics should not reward volume for its own sake. More referrals can mean better coverage or worse calibration. More AML cases can mean stronger detection or unnecessary escalation. Governance should pair volume with quality, outcome and missed-risk analysis.

Architecture principle: share evidence, not conclusions

The most durable design principle is to exchange observations and evidence while keeping the receiving function responsible for its own conclusion. Fraud can say that a customer reported impersonation, the payment was authenticated, a particular beneficiary received the funds and two other victims named the same beneficiary. AML then decides whether those facts create a case and whether suspicion is formed under the applicable rules.

Likewise, AML can tell fraud that an account belongs to a network under investigation, that particular payment patterns recur and that certain beneficiary attributes are high risk. Fraud then decides how to use that intelligence within its own prevention controls and customer-treatment framework.

That separation makes the handoff both more useful and more defensible. It preserves specialist judgement, reduces confirmation bias and gives auditors a clear trail from evidence to decision.

Practice close: requirements, acceptance criteria and testing

This section converts the chapter into delivery artefacts for business analysts, product owners, architects, developers, testers and control owners. The central test is simple: can a fraud case with wider proceeds or network risk reach AML with the right evidence, once, quickly enough to matter, while customer protection and legal decisions remain correctly separated?

BA checklist

Before accepting a handoff design, confirm that the requirement set answers these questions:

  • What precise event or combination of events creates an AML referral?
  • Which evidence fields are mandatory and which are optional?
  • How are fraud case, payment, customer, beneficiary and AML case identifiers correlated?
  • What makes a referral urgent, and is urgency separate from suspiciousness?
  • Who owns customer contact, payment recovery, AML triage, reporting and restriction decisions?
  • How are duplicates prevented when an event is retried?
  • How does new evidence enrich an existing referral?
  • How are possible victim-mules routed without automatically labelling them as knowing participants?
  • Which jurisdictions or entities can receive the data, and what access or disclosure restrictions apply?
  • What happens when a dependency such as entity resolution, device intelligence or payment-status enrichment is unavailable?
  • How is the complete decision trail retained for QA, audit, complaints and regulatory response?

A requirement that says “send relevant fraud cases to AML promptly” is not testable. A requirement that defines trigger logic, payload, queue, SLA, deduplication key, ownership and error handling is.

Example acceptance criteria

Network referral. Given two or more confirmed scam cases that meet the configured shared-beneficiary trigger, when the fraud platform publishes the handoff event, then one AML referral is created or enriched, every source fraud case is linked, all payment references are retained and a retry of the same source event does not create a duplicate.

Evidence provenance. Given a customer statement and a model-derived device link, when both are included in the referral, then the receiving case identifies the customer statement as customer-provided information and the device link as model-derived evidence with source and timestamp. Neither is stored as an unqualified fact.

Victim-mule routing. Given an account showing both vulnerability indicators and receipt or onward movement of third-party scam funds, when the trigger is met, then the case routes to the defined joint-review path and does not automatically apply a knowing-mule classification.

Separate outcomes. Given a fraud claim that is reimbursed while AML investigation remains open, then the reimbursement status can close without closing the AML case or changing the suspicious-reporting status.

Confidentiality. Given an AML case that becomes subject to restricted reporting information, then fraud users can still access the permitted fraud evidence and customer-contact actions but cannot access protected reporting data unless their role is authorised under the applicable framework.

Positive testing

Positive tests should represent real control stories rather than single-field unit tests. A useful scenario begins with an impersonation scam, creates the payment, confirms the fraud event, links the receiving account to two other victim payments and then verifies that the handoff carries all three victim links into one AML referral. The test should then add new evidence and confirm that the same referral is enriched rather than duplicated.

Another scenario can model a possible victim-mule. The test account receives funds from strangers after a grooming event and forwards them onward. The expected outcome is not “money laundering confirmed.” The expected outcome is that vulnerability evidence and transaction evidence are both preserved and the case reaches the correct review path.

A virtual-asset scenario should prove that an exchange payment is represented as a conversion point or service exposure, not as proof that the assets are criminal. If blockchain analytics is used, the test should retain provider, score or classification, timestamp and confidence so an investigator can judge it in context.

Negative testing

Negative tests protect customers from over-control. A legitimate small business may receive many unrelated credits and pay suppliers quickly; if that behaviour matches the documented business model and there are no fraud-confirmed source events, the handoff should not fire merely because payer diversity is high.

A UK Confirmation of Payee close match can arise from a trading name or formatting variation. It should not create an AML referral on its own. A fraud event involving a stolen card at a legitimate merchant should not cause the merchant to be labelled suspicious without additional evidence.

Negative testing should also include corrected data. If fraud operations later determine that a case was not a scam, the downstream referral should receive that correction while preserving the original history rather than deleting evidence silently.

Failure-mode testing

Test dependency failures deliberately. If the entity-resolution service is unavailable, does the handoff wait, continue with a visible degraded status or route to manual review? If the payment platform sends the same event twice, is the referral idempotent? If the receiving AML queue is unavailable, is the event retried and reconciled? If a timestamp arrives without timezone information, is it rejected or normalised predictably?

Test partial-data scenarios as well. A cross-border payment may not expose the same beneficiary detail as an internal transfer. A device identifier may be absent for a branch-originated payment. The system should distinguish “not available” from “empty” and should not fabricate default values that later look like real evidence.

Synthetic journey testing

Victim-facing journeys can be tested with synthetic personas and controlled scenarios. The purpose is to see whether customers receive contradictory communication when fraud and AML actions overlap, whether vulnerable-customer flags survive the handoff, whether account restrictions are explained appropriately and whether restricted AML information remains protected.

Using fabricated cases in live production queues is not a default testing method. If an institution chooses production-like seeding, it requires strong governance, segregation, privacy controls and operational safeguards. In most situations, a realistic pre-production environment with representative data and controlled operational exercises provides safer evidence.

Quality assurance after go-live

Post-production QA should sample accepted referrals, rejected referrals and cases that later proved to be missed handoffs. Reviewers should assess evidence completeness, timeliness, victim treatment, AML reasoning, use of model outputs, external disclosure controls and whether the final decision is reproducible from the file.

The QA team should also compare referral populations to source populations. If the trigger selected 600 fraud cases but AML received 594, the six missing cases need an explained state. Technical reconciliation is part of financial-crime control effectiveness, not merely an IT support metric.

Definition of done for the capability

The handoff capability is complete only when the business rule, data contract, roles, customer journey, legal boundaries, monitoring, reconciliation, testing evidence and governance are all working together. A screen that allows one team to “send a case” is not the control. The control is the full chain from detection through evidence transfer, independent AML assessment, customer protection and feedback into prevention.

Masterclass: the romance-scam victim who became a conduit

This is a fictional composite case built from publicly described scam and money-mule patterns. It is not based on one identifiable person or enforcement action. The purpose is to show why a bank needs joint fraud and AML reasoning when a customer may be both exploited and involved in moving other victims' money. The case deliberately avoids deciding criminal liability: the bank assesses risk, customer vulnerability, suspiciousness and control action; competent authorities determine criminal responsibility under the applicable law.

Stage 1: clear victim indicators

A recently widowed customer begins an online relationship with a person claiming to work overseas. Over several months the customer sends personal savings for supposed travel, medical and business expenses. The payments are made from the customer's usual device with valid authentication. Fraud controls therefore have little evidence of account takeover.

The first meaningful signal is behavioural. The customer adds new beneficiaries, payment values increase and the payment descriptions do not fit previous activity. When contacted after one unusually large transfer, the customer says the beneficiary is a trusted partner and insists the payment is genuine. The bank gives scam warnings, but the customer has been coached to dismiss them.

At this stage the dominant issue is customer protection. There is no evidence that the customer is laundering money. Fraud operations document the grooming narrative, warnings, beneficiaries, devices and customer responses. Those records later become crucial.

Stage 2: third-party money begins to arrive

Several weeks later the pattern changes. The customer starts receiving transfers from people with no apparent relationship to them. The customer explains that the overseas partner cannot receive money directly and has asked for help collecting business payments. Soon after each incoming transfer, most of the value is sent onward to accounts supplied by the partner.

This is the point where a fraud-only view becomes insufficient. The customer still presents as a likely victim of grooming, but the account is now moving third-party funds. The correct control response is not to decide immediately that the customer is a knowing mule. It is to preserve the vulnerability evidence and trigger an AML assessment of the receiving and onward-payment pattern.

The handoff includes the original romance-scam narrative, dates of warnings, incoming payer details, onward beneficiaries, device history and the customer's explanation. AML can now see something fraud could not: two of the incoming senders have their own fraud cases at the bank and a third payment is linked through a beneficiary to an existing mule investigation.

Stage 3: joint review

Fraud and AML hold a joint case review. Fraud explains the grooming indicators and why the customer may not understand the criminal purpose of the transfers. AML explains the network evidence and why the account's use creates broader financial-crime concern. Payment investigations show that some funds have already moved to another institution and some remain recoverable.

The teams separate their decisions. Fraud continues safeguarding and customer communication. Payment operations pursue available recovery actions. AML investigates the customer's relationship, incoming third parties and onward destinations. The MLRO or locally designated reporting function considers the reporting threshold under the law applicable to the bank entity. No team treats reimbursement, suspicious reporting or customer restriction as an automatic consequence of another team's decision.

This separation is important. A customer can need protection and still present financial-crime risk. Vulnerability does not make transaction evidence disappear; suspicious transaction patterns do not erase vulnerability.

Stage 4: evidence changes the picture

The customer provides message history showing that the supposed partner instructed them exactly when to expect incoming payments and where to send them. The messages contain pressure, emotional manipulation and threats to end the relationship. That evidence strengthens the exploitation assessment.

At the same time, the account history shows that the customer continued to follow instructions after repeated bank interventions. The bank records this as relevant evidence, but does not translate it into a legal conclusion such as “knowing money laundering established.” Human behaviour under grooming and coercion is complex, and criminal mental-state tests belong to the applicable legal process.

The institution may still decide that it cannot safely continue unrestricted account use. Any restriction, monitoring or exit decision should follow local law, contract, vulnerability policy and financial-crime risk governance. Customer communication should be carefully designed so that the bank protects the person without exposing confidential AML information.

Stage 5: network learning

The investigation identifies several other accounts receiving money from the same victim pool and sending value to a common set of destinations. That intelligence is fed back into fraud prevention. Beneficiary-risk controls are updated, and future fraud cases involving the same network are prioritised earlier.

The institution also changes its handoff rule. A customer already flagged as a likely scam victim who begins receiving and forwarding unrelated third-party funds now enters a joint-review path automatically. The trigger does not say “mule confirmed.” It says “possible victim-mule pattern: fraud and AML assessment required.”

Customer outcome and redress

Customer redress depends on jurisdiction, payment rail and the facts of each payment. In the UK, for example, the PSR's APP reimbursement requirements apply to defined in-scope Faster Payments and CHAPS claims and include specific customer and provider obligations. Other markets have different arrangements. The case design therefore stores reimbursement separately from the AML assessment.

The bank may also offer vulnerability support, safer-account measures, referral to appropriate support organisations or additional payment controls, subject to local policy. It should not provide tax, criminal-law or psychological advice outside its competence. Where specialist help is needed, the customer can be directed to appropriate services.

What the case teaches

The case shows why binary labels fail. The customer can be a fraud victim, a conduit of other victims' funds and a person whose account creates AML concern at the same time. The correct response is evidence-led and phase-sensitive.

It also shows why the handoff package matters. Without the original grooming narrative, AML might see only pass-through activity and miss vulnerability. Without the receiving-account and network analysis, fraud might see only victimisation and miss the movement of criminal proceeds. The combined view is more accurate than either view alone.

Finally, the case demonstrates a governance boundary worth protecting: the bank assesses facts, risk, suspiciousness and customer treatment; it does not declare criminal guilt. That distinction keeps financial-crime controls rigorous while respecting the role of law enforcement, prosecutors and courts.

Knowledge check and glossary

Use these questions to test whether the control logic is understood rather than memorised.

Does a confirmed fraud event automatically require an AML case or suspicious transaction report?

No. Fraud and money laundering can overlap, and fraud proceeds may create AML risk, but the institution still needs to assess the facts under its applicable law and policy. A handoff trigger means “AML assessment required,” not “money laundering proven.”

What is the minimum useful fraud-to-AML handoff?

A case identifier alone is not enough. The receiving team needs customer and account identifiers, payment references and timestamps, beneficiary details, fraud typology and customer narrative, relevant device or authentication evidence, recovery status, linked cases and the reason AML review is needed. Evidence provenance should show what is system data, customer statement, analyst inference or model output.

Why separate victim status from mule assessment?

A person can be exploited, deceived or coerced and still move other victims' funds. Conversely, an account receiving scam proceeds is not automatically controlled by a knowing criminal. The bank should assess vulnerability and transaction risk together without pretending to determine criminal liability.

What makes a strong handoff trigger?

A combination of relevant evidence such as multiple fraud-confirmed source payments, rapid onward movement, common beneficiaries, shared devices, repeat victimisation or links to an existing financial-crime case. Amount can matter, but it should not be the only trigger.

What is a reverse handoff?

It is intelligence flowing from AML back into fraud prevention. A network investigation may identify beneficiary accounts, devices, recruitment methods or payment patterns that can improve fraud detection, onboarding checks or beneficiary-risk controls.

Why must reimbursement and AML investigation remain separate?

They answer different questions and may operate under different legal or scheme timelines. A customer's claim can be resolved while AML investigation of the beneficiary network continues. Reimbursement does not prove or disprove suspiciousness.

How should blockchain analytics be used?

As investigative evidence with source, timestamp, methodology or provider context and confidence. A risk score or service exposure should not be treated as conclusive proof that funds are criminal.

Why is Confirmation of Payee not a universal control term?

Confirmation of Payee is a UK account-name checking service with specific PSR requirements. Other markets may have different beneficiary-verification mechanisms. A CoP mismatch is useful context, not proof of fraud or money laundering.

What is the most important cross-border caution?

Do not assume the sending bank's recovery, freezing or information-sharing rights apply in another institution or jurisdiction. Payment-scheme processes, privacy law, AML confidentiality, statutory sharing gateways and receiving-bank powers must be checked for the relevant legal entity and transaction.

What should quality assurance sample?

Accepted referrals, rejected referrals and missed handoffs discovered later. QA should test evidence completeness, timeliness, victim treatment, reasoning, use of model outputs, external sharing controls, reconciliation and whether the final decision can be reconstructed from the file.

Glossary

Fraud-to-AML handoff: a controlled transfer or sharing of fraud evidence when a case has wider proceeds, network or suspicious-activity relevance requiring AML assessment.

Reverse handoff: financial-crime intelligence sent from AML back into fraud prevention or customer-protection controls.

Victim-mule: an operational term for a person who may have been exploited or deceived while their account is used to receive or move other people's funds. It is not a legal finding of guilt or innocence.

Handoff trigger: a documented condition or combination of conditions that creates a referral for AML assessment.

Evidence provenance: information showing where evidence came from, when it was captured, how it was derived and whether it is observation, statement, model output or analyst inference.

Dwell time: the period value remains in an account before being moved onward. Short dwell time can be relevant in pass-through activity but must be interpreted in customer and product context.

Dispersal velocity: how quickly received value is split or transferred onward across accounts, institutions, cash, goods or virtual assets.

Entity resolution: the process of identifying whether apparently separate records refer to the same person, account, device, organisation or other entity, using deterministic or probabilistic matching.

Case correlation: linking fraud cases, payment events and AML cases through stable identifiers so investigators can reconstruct the complete chain without duplicate records.

Suspicion formed: an internal conclusion that the facts meet the institution's applicable suspicious-reporting threshold. The legal threshold and filing mechanics vary by jurisdiction.

Recovery action: a recall, return request, hold request or other permitted payment-recovery step. The available action depends on the payment rail, institution, scheme and law.

Customer safeguarding: measures designed to protect a vulnerable or deceived customer, which can continue alongside AML investigation.

Purpose limitation: using and sharing personal data only for legitimate, defined purposes permitted by the relevant legal and governance framework.

Idempotency: a system property ensuring that retrying the same handoff event does not create duplicate referrals or conflicting outcomes.

References and further reading

Global standards and current fraud-to-AML risk

Monitoring effectiveness and bank control design

Jurisdiction-specific operational examples

Use of these sources

FATF sources provide the global risk and standards context. Wolfsberg publications are industry guidance on monitoring effectiveness rather than law. FinCEN, AUSTRAC and PSR material is used only for clearly identified US, Australian and UK examples. Institutions must apply the law, FIU reporting rules, payment-scheme requirements, privacy framework and customer-protection obligations relevant to their own legal entity and transaction.