Cyber-Enabled Crime, Ransomware and Scam Proceeds

Cyber-enabled crime can generate proceeds at enormous speed. Account takeover, phishing, business email compromise, authorised push-payment scams, investment scams, ransomware, credential theft, merchant abuse and other digital crime can all produce funds that quickly enter payment networks and then move through mule accounts, exchanges, remitters, cash-out points and cross-border chains.

For a bank, the practical challenge is that fraud detection, payment security and AML investigation often see different parts of the same criminal event. The fraud team may see the victim interaction. The payments platform sees the transfer. The receiving bank sees the mule account. AML may later see the laundering network. If those views remain disconnected, criminals can move faster than the control environment.

FATF's February 2026 paper on cyber-enabled fraud reinforces this operating-model point. It describes cyber-enabled fraud as a major source of illicit proceeds and emphasises faster information sharing, payment transparency, asset recovery, virtual-asset controls and domestic and international cooperation. For banks, the practical lesson is not to turn every fraud alert into an AML case. It is to make sure reliable fraud, payment and beneficiary evidence can move quickly enough to support prevention, recovery and later financial-intelligence work.

Cyber-enabled crime lifecycle showing victim compromise, payment initiation, receiving account, onward movement, cash-out and AML/fraud feedback.

Cyber-enabled versus cyber-dependent crime

Some crimes exist because of technology, such as certain forms of malware or network intrusion. Others are traditional offences amplified by digital channels, such as fraud, impersonation or extortion.

For banking controls, the distinction can help understand the predicate offence, but the financial question remains: where do proceeds enter, how do they move, and which controls can disrupt the chain?

Account takeover

Account takeover occurs when an attacker gains unauthorised access to a legitimate customer’s account or credentials. The attacker may add beneficiaries, initiate transfers, change contact details, use cards or move funds through wallets.

A sudden transaction pattern can look like mule activity, but the customer may actually be a victim. Fraud and AML teams should distinguish account compromise from voluntary account use.

Credential theft

Credentials can be stolen through phishing, malware, data breaches, social engineering or device compromise. Authentication success does not always prove genuine customer intent if credentials or devices were compromised.

Banks should combine transaction signals with device, authentication and behavioural evidence where lawful and available.

Authorised push-payment scams

In an authorised push-payment scam, the customer is deceived into authorising the payment. Standard authentication can succeed because the customer genuinely approved the transfer.

The bank therefore needs controls beyond authentication, including beneficiary risk, behavioural analytics, warnings, intervention and receiving-account intelligence.

Impersonation scams

Criminals can impersonate banks, police, government bodies, family members, businesses or investment providers. Payment references may appear ordinary.

Fraud prevention can use customer interaction, device changes, payment novelty, beneficiary information and known scam patterns.

Investment scams

Victims may transfer funds repeatedly over weeks or months. Early payments can be small, followed by larger transfers after trust is established.

The receiving side may show multiple unrelated victims funding common accounts, exchanges or payment intermediaries.

Romance scams

Romance scams can produce long-duration payment patterns and may also recruit victims as mules. Customer vulnerability and financial-crime risk can coexist.

Banks should avoid punitive assumptions about victims while still disrupting criminal flows.

Business email compromise

BEC can involve criminals impersonating executives, suppliers or counterparties to redirect corporate payments. A legitimate payment may be sent to a fraudulent beneficiary because invoice or account details were altered.

Receiving-account analysis and beneficiary-change controls can be critical.

Invoice redirection

A supplier’s email account can be compromised and bank details changed. The payment may otherwise match a real invoice.

Controls should therefore consider beneficiary novelty and verified change processes, not only amount or payment description.

Scam proceeds and mule accounts

Mule accounts receive and move fraud proceeds. Some mules are complicit; others are recruited or deceived. A compromised account should not automatically be labelled a mule.

The receiving bank should focus on account-use behaviour and evidence.

Fraud-to-AML handoff showing victim report, transaction, beneficiary, receiving account, linked network and investigation decisions.

Rapid onward movement

Fraud proceeds often move quickly to reduce recovery chances. Funds may be split, withdrawn in cash, sent to other banks, moved to remitters or converted into virtual assets.

Instant payments increase the importance of real-time controls because a next-day monitoring batch cannot prevent immediate loss.

Beneficiary risk

Receiving accounts can be assessed using account age, prior fraud reports, payer diversity, pass-through speed, beneficiary relationships, device intelligence and network links.

A name match service can reduce some misdirected payments but cannot prove that a beneficiary is safe.

Ransomware

Ransomware involves malicious encryption, data theft or other disruption combined with extortion demands. Payments are often requested in virtual assets, but banking institutions may still see fiat funding, exchange payments, intermediary activity or victim-company transfers.

FATF's 2023 ransomware work focuses on how ransom payments can be moved and laundered and on the need for rapid tracing, recovery and cross-border cooperation. A bank should understand the financial flow it can actually observe rather than assume that a transfer to a virtual-asset service provider proves ransomware activity.

Ransomware and sanctions

A victim may face intense operational pressure to pay, but sanctions analysis is a separate legal question. Whether a payment is prohibited depends on the applicable sanctions regime, jurisdictional nexus, parties, ownership or control, destination and any licence or authorisation. A victim's status does not itself create a universal exemption.

For example, OFAC's September 2021 ransomware advisory addresses sanctions risk under the United States framework. It should not be presented as a global rule for every bank. Legal and sanctions specialists should determine which regime applies to the institution and transaction.

Virtual assets

Cybercrime proceeds can be converted into virtual assets, moved across wallets and later converted back to fiat. Banks may see transfers to exchanges or virtual-asset service providers.

Crypto-related activity is not inherently suspicious. The relevant context includes customer profile, provider, transaction pattern, wallet exposure and known intelligence.

Blockchain analytics

Blockchain analytics can identify wallet exposure, clusters and transaction paths. Labels and risk scores are probabilistic and can be wrong.

Investigators should understand source, confidence and limitations rather than treat vendor output as legal fact.

Mixers and obfuscation

Mixing services and other privacy-enhancing mechanisms can reduce traceability. Some services may be subject to sanctions or law-enforcement action, while privacy technology can also have legitimate uses.

Controls should apply current legal requirements rather than generic assumptions.

Cash-out

Criminals ultimately need ways to use proceeds. Cash-out can occur through ATM withdrawals, purchases, virtual-asset conversion, remitters, cards, goods or transfers to controlled companies.

Monitoring should connect the receiving event with downstream movement.

Fraud rings

Criminal networks can operate many victim campaigns and mule accounts. Graph analytics can connect devices, beneficiaries, addresses, phone numbers and transaction paths.

Association is not proof; relationship confidence matters.

Device and identity signals

Device fingerprints, IP addresses, SIM changes, authentication events and identity signals can add useful context. They require privacy governance and careful interpretation.

Shared devices can be legitimate in families or assisted banking. A device link should be treated according to confidence.

Synthetic identity

Synthetic identities can combine real and fabricated information to create accounts or credit profiles. They can be used for fraud and laundering.

Banks should combine identity verification, device data, behavioural signals and network analysis rather than rely on one document.

Remote onboarding

Digital onboarding can increase speed and access while creating impersonation, document manipulation and deepfake risks. Controls may include document verification, biometrics, liveness, database checks and human review according to risk.

Technology outputs require governance and false-positive management.

Merchant fraud

Fraud proceeds can be processed through sham or complicit merchants. Acquirers may see unusual card-not-present patterns, refunds, chargebacks, rapid turnover growth and settlement destinations.

Merchant monitoring and AML can overlap.

Refund abuse

Refunds to different cards or accounts can move value in ways that complicate tracing. Legitimate refund models also exist, so merchant context matters.

Scam typologies evolve quickly

Fraud patterns can change faster than traditional AML scenarios. Banks need feedback loops from fraud operations, complaints, law enforcement and payment schemes into monitoring design.

The 2026 FATF cyber-enabled fraud paper also highlights the growing role of phishing, AI-enabled deepfakes, messaging applications, instant and cross-border payments and virtual assets in scaling fraud. Those developments strengthen the case for regularly refreshing typologies rather than treating an old fraud rulebook as static.

Fraud-to-AML handoff

A confirmed or credible fraud event can be an AML input because the receiving account may be handling criminal proceeds.

The handoff should preserve transaction ID, victim report, beneficiary, timestamps, recovery actions, device evidence and linked accounts.

AML should not need to rediscover the fraud case from screenshots.

AML-to-fraud feedback

AML network analysis can identify additional accounts or beneficiaries before they generate victim complaints. That intelligence can improve real-time fraud controls where legally permitted.

Case objects

Fraud report, transaction, account, customer, device, beneficiary, alert, network case and suspicious report are different objects with different lifecycle states.

A good platform should link them without collapsing them.

Recovery and recall

Recovery depends on payment rail, timing, recipient cooperation and the legal mechanisms available in the relevant jurisdictions. Operations should act quickly and preserve evidence of recall, stop-payment, freeze or restriction requests and responses.

A recall request does not guarantee recovery. Cross-border tools such as INTERPOL's I-GRIP demonstrate why rapid cooperation can matter, but a bank should use the channels and authorities available to it rather than assume a universal recovery mechanism.

Holds and restrictions

A temporary operational hold is not the same as a sanctions freeze or legal restraint. Systems and customer communications should use precise terminology.

Customer protection

Victims can be distressed or vulnerable. Fraud prevention and financial-crime controls should not unnecessarily blame the customer.

Scenario: APP scam

A customer is deceived into sending EUR 20,000 to a new beneficiary. The receiving account is two weeks old, has received several unrelated credits and forwards most funds within minutes.

The sending bank sees deception; the receiving bank sees mule-like behaviour. Connected intelligence can improve both prevention and recovery.

Scenario: account takeover

A long-standing customer’s credentials are compromised. Attackers receive fraud proceeds into the account and forward them to exchanges.

AML may see criminal proceeds, but customer treatment should reflect that the legitimate customer may be a victim rather than a willing mule.

Scenario: ransomware payment

A company seeks to purchase virtual assets after a ransomware incident. The bank should involve fraud/cyber, AML, sanctions and legal specialists and understand the proposed recipient and applicable restrictions.

The operational urgency does not remove legal obligations.

Scenario: investment scam network

Dozens of customers send payments to several companies advertising investments. Funds consolidate into a small number of accounts and then move overseas.

Network analytics can identify common destinations and related ownership.

Monitoring design

Useful signals can include victim-linked beneficiary activity, rapid pass-through, new account age, device changes, unusual beneficiary creation, crypto conversion, cash withdrawal and network links.

Controls should be segmented and tested against legitimate high-velocity businesses.

Real-time versus post-event controls

Real-time controls aim to prevent or interrupt payment. Post-event AML controls can reconstruct wider networks and identify typologies.

They serve different purposes and should share relevant evidence.

Control timing model separating pre-payment fraud prevention, payment decisioning, immediate recovery and post-event AML/network investigation.

Model governance

Machine learning can improve detection but introduces model risk. Banks should manage data quality, bias, drift, explainability, validation and human oversight.

A score should not become an unchallengeable conclusion.

Business analyst view

A BA should map data from channel, authentication, payment engine, fraud platform, core banking, screening, transaction monitoring and case management.

Requirements should define identifier linkage, timing, event sequence and failure handling.

Payment lineage

Investigators need original instruction, beneficiary, payment status, repair events, settlement, return or recall, and downstream case IDs.

ISO 20022 data can improve context if structured fields are preserved.

Evidence provenance

Device matches, vendor risk scores, blockchain labels and external intelligence should record source, timestamp and confidence.

Analysts should distinguish verified fact from model inference.

Quality assurance

QA should test whether analysts incorrectly label victims as mules, whether fraud evidence reaches AML, whether high-risk beneficiaries are escalated consistently, and whether model outputs are challenged appropriately.

Metrics

Useful measures include prevented loss, recovered value, time to receiving-account action, repeat beneficiary risk, network expansion, false positives, victim-linked detection and case quality.

Metrics should not encourage excessive blocking or customer harm.

Common mistakes

Common mistakes include assuming successful authentication proves genuine intent, treating all crypto activity as suspicious, labelling compromised customers as mules, separating fraud and AML evidence, and relying on next-day controls for instant-payment risk.

Another mistake is treating vendor device or blockchain labels as facts rather than intelligence.

Learning checkpoint

A reader should be able to explain how cybercrime proceeds move from victim to laundering network, distinguish authorised scams from account takeover, understand ransomware and sanctions interaction, design fraud-to-AML handoffs and describe why real-time and post-event controls have different roles.

References and further reading

Educational note: fraud liability, reimbursement, ransomware, sanctions, virtual-asset and suspicious-reporting requirements vary by jurisdiction and payment rail. Apply current legal, regulatory and scheme rules.

Deep dive: the end-to-end operating model for cyber-enabled financial crime

Cyber-enabled crime exposes a structural weakness in many banks: customer authentication, fraud detection, payment processing, AML monitoring, cyber incident response and sanctions controls often operate in separate systems with separate queues. Criminals experience none of those organisational boundaries. They move from social engineering to payment, beneficiary account, onward transfer and cash-out as one continuous process.

A mature control model therefore links evidence across those functions while keeping decision rights clear.

Start with the customer event

The first useful timeline can begin before the payment. Did the customer change device, reset a credential, add a beneficiary, receive an unusual call, increase a limit or initiate a transaction outside normal behaviour? These events can explain why a payment that passes authentication still deserves intervention.

The bank should distinguish authentication evidence from evidence of genuine customer intent.

Authorised scam versus unauthorised transaction

In an authorised scam, the genuine customer may initiate or approve the transfer because they have been deceived. In an unauthorised transaction, an attacker may control credentials or device access.

Those situations can produce different fraud, reimbursement and customer-protection outcomes under local rules. AML may still investigate the receiving or downstream accounts in either case.

Business email compromise

BEC can target corporate payment processes by changing beneficiary details or impersonating executives and suppliers. Controls can include verified beneficiary-change procedures, dual approval, behavioural analytics and payment-risk scoring.

A bank should avoid assuming that a payment to a known supplier is safe if the account details were recently changed.

Invoice-redirection chronology

A useful case reconstruction compares previous supplier account details, time of change, approval process, email compromise indicators and final payment beneficiary. The fraud narrative should be available to AML if the receiving account is under investigation.

Beneficiary-side intelligence

Sending-bank controls often know the customer being deceived. Receiving-bank controls may know the beneficiary account's age, prior reports, incoming payer diversity, linked devices and onward movement. Neither side necessarily has the full story.

Where lawful information-sharing mechanisms exist, connecting these perspectives can improve prevention and recovery.

Confirmation or verification of payee

Beneficiary-name checking can reduce some misdirection and impersonation fraud. A correct name match does not prove the receiving account is safe: a genuine account holder can be recruited as a mule or willingly participate.

Name verification is therefore one layer, not a substitute for beneficiary risk assessment.

New-beneficiary risk

A payment to a newly created beneficiary can be higher risk when combined with unusual amount, customer behaviour, scam indicators or beneficiary intelligence. It should not be treated as suspicious merely because it is new.

Payment velocity

Instant-payment rails compress decision time. Real-time controls need features that are available before or during payment. Post-event AML data can be richer but arrives too late to prevent the first loss.

Architecture should clearly identify which data is available at each decision point.

Intervention design

Possible interventions can include warning, step-up authentication, customer confirmation, cooling-off mechanism where permitted, manual review or payment hold. The intervention should be proportionate and tested for customer impact.

Generic warnings can become ineffective if customers see them on every payment.

Customer-contact risk

In some scams, criminals remain on the phone with the victim and coach them through bank questions. Staff should be trained to recognise coercion and scripted explanations without assuming every nervous customer is being scammed.

Receiving-account behaviour

Mule-like receiving behaviour can include many unrelated payers, rapid pass-through, new-account age, concentrated downstream beneficiaries, cash withdrawal, virtual-asset conversion and fraud reports.

These signals need customer context. Marketplaces, payment companies and legitimate sellers can also have many payers and rapid onward flows.

Complicit, recruited and compromised accounts

The account-use pattern and customer culpability are separate questions. A person may knowingly provide an account, be deceived into moving funds, or lose control through account takeover.

Customer treatment, fraud remediation and AML decisions should reflect evidence rather than one generic “mule” label.

Network case management

One scam network can include many victims, receiving accounts, consolidation nodes and final destinations. Case platforms should allow network-level analysis while preserving individual customer decisions.

A network case should not automatically close all related customer cases when one account is exited.

Device intelligence

Device identifiers can link accounts but can also produce false associations through shared family devices, reused hardware, public terminals or vendor uncertainty. Controls should store match confidence and signal source.

IP and location signals

Network location can add context but should not be treated as precise physical identity. VPNs, mobile networks and shared connections can create ambiguity.

SIM-swap and telecom signals

Where legally available, SIM change or mobile-number events can support fraud analysis. They should be one feature among several, not automatic proof of takeover.

Synthetic identity

Synthetic identities can use combinations of real and fabricated data. Detection can involve identity consistency, device links, account behaviour and external verification.

Banks should avoid assuming every identity-data inconsistency is deliberate fraud; data-quality errors exist.

Deepfakes and impersonation

Remote onboarding and assisted service increasingly face synthetic media and voice or video impersonation. Controls can use liveness and document checks, but technology performance, accessibility and bias require governance.

Human review should have clear escalation criteria.

Ransomware operating model

A ransomware event can involve the victim company, incident-response specialists, insurer, legal counsel, virtual-asset provider, bank and potentially a sanctioned actor. The bank should understand its role in the requested payment or asset conversion.

The institution is not responsible for incident response outside its role, but it must apply applicable AML, sanctions and payment controls.

Sanctions screening in ransomware

The proposed recipient may be identified through wallet information, threat-actor intelligence or service-provider data. Sanctions specialists should determine whether an applicable legal prohibition or reporting duty exists.

A ransomware victim's urgency does not create an exemption by itself.

Virtual-asset funding

A bank may see a customer sending fiat to an exchange to acquire virtual assets. That transaction can be legitimate. In a ransomware context, the purpose and destination can materially change the risk.

The bank should avoid generic “crypto equals high risk” logic.

Blockchain analytics

Analytics can show direct and indirect wallet exposure, transaction history and clusters. Labels may be vendor-generated, probabilistic or based on incomplete attribution.

The case record should state whether exposure is direct, how many hops are involved, what confidence applies and which data source produced the conclusion.

Mixers and privacy technology

Privacy-enhancing services can complicate tracing. Some services can be sanctioned or associated with criminal activity, while privacy tools can have lawful uses. The legal and factual context should drive the outcome.

Exchange and VASP due diligence

Where a bank serves exchanges or other virtual-asset businesses, it should understand their regulatory status, products, geographies, customer base, controls and settlement model. This is separate from assessing an ordinary retail customer's transfer to an exchange.

Fraud proceeds through merchants

Criminal proceeds can be processed as apparent merchant sales. Acquiring data such as merchant category, terminal or device, refunds, chargebacks and settlement account can reveal patterns not visible in ordinary payment monitoring.

Refund laundering

Refunds to different payment instruments can create value-transfer opportunities. Acquirers should distinguish legitimate refund processes from unexplained redirection.

Card and wallet interaction

Stolen credentials, card fraud and wallets can generate or move proceeds before funds enter bank transfers. Financial-crime programmes should understand cross-product relationships rather than treat each channel as isolated.

Recovery workflow

When a victim reports fraud, the sending bank may initiate recall or recovery actions according to scheme and legal rules. The receiving bank may be able to restrict remaining funds where permitted.

Every action should preserve timestamps, amount, reference, response and remaining balance where available.

Partial recovery

A case can involve partial recovery after some funds move onward. Case systems should not represent recovery as a simple yes/no field.

Returns and reversals

A returned or reversed payment changes the economic exposure but does not erase the underlying fraud event. Monitoring and case logic should preserve the original attempt and outcome.

Duplicate fraud reports

Multiple customers can report the same beneficiary or network. Case-management logic should group intelligence without losing each victim's transaction and rights.

Payment repair

If beneficiary or payment data is repaired during processing, the original and amended values should be preserved. A change can affect screening, fraud scoring and later investigation.

ISO 20022 context

Structured party and remittance data can improve investigations if it survives transformations. The bank should trace which fields are available to real-time fraud controls and which reach post-event AML systems.

UETR and identifiers

Relevant cross-border transactions can use UETR, while domestic and instant rails can have different identifiers. A case platform should link scheme and internal IDs rather than rely on one universal reference assumption.

Fraud-to-AML referral criteria

Not every fraud case requires AML escalation. Referral logic can consider credible criminal proceeds, mule indicators, repeated beneficiaries, network links, customer complicity and policy thresholds.

Criteria should be documented and tested.

AML-to-fraud intelligence

AML may identify suspicious beneficiaries or account clusters. Where permitted, selected intelligence can feed fraud prevention. Governance should define confidence, review period and how stale associations are removed.

Internal watchlists

An internal high-risk beneficiary or device list should store source, reason, confidence, effective date, expiry or review and owner. Weak or stale associations can unfairly block customers.

External information sharing

Industry utilities, schemes and public-private partnerships can improve scam detection. Sharing must follow privacy, secrecy and applicable legal rules.

Data minimisation

Fraud and AML teams can have access to sensitive customer and device data. Access should be role-based and limited to legitimate control purposes.

Machine-learning features

Possible features include account age, payment novelty, beneficiary history, transaction velocity, device events and network relationships. Every feature should have defined meaning, source and quality controls.

Label quality

Training data can be biased by what the bank previously detected. Confirmed fraud, suspected fraud and customer complaint are different labels. Model development should account for that distinction.

Explainability

An investigator should understand the primary reasons a case was prioritised. A black-box score with no usable rationale weakens challenge and customer-impact governance.

Drift

Scam tactics evolve. Model and rule performance should be reviewed for new patterns, customer behaviour change and payment-product change.

Operational capacity

A model that doubles alerts without improving case quality can overwhelm investigators and delay urgent cases. Detection performance and operational capacity should be considered together.

Scenario: legitimate new beneficiary

A customer sends a large payment to a new solicitor for a property purchase. The amount and beneficiary are unusual relative to normal behaviour, but the customer explanation and transaction context are credible.

This negative case is important when testing high-value/new-beneficiary rules.

Scenario: impersonation scam

A customer receives a call from a criminal pretending to be bank security and transfers funds to a “safe account.” Authentication succeeds. The beneficiary has recent scam reports and forwards funds rapidly.

The end-to-end case demonstrates why authentication, customer intent and beneficiary risk are separate concepts.

Scenario: compromised beneficiary account

Fraud proceeds arrive at an old salary account. Device data indicates takeover and the legitimate customer quickly reports loss of access. The account was used in the laundering chain, but the customer may be a victim.

Scenario: scam investment platform

Many customers send funds to several merchant or corporate accounts tied to one online platform. AML network analysis finds common owners and downstream beneficiaries. Fraud complaints and merchant-acquiring information strengthen the picture.

Scenario: ransomware with uncertain attribution

A company needs to transfer funds to a VASP after an attack. Threat-actor attribution is uncertain. The bank should not invent certainty; it should escalate available wallet, service-provider and sanctions information to appropriate specialists.

Customer communication

Fraud warnings and intervention should be understandable. AML or suspicious-reporting rationale may be protected. Systems should support accurate customer-facing status without exposing restricted information.

Vulnerability

Elderly, isolated or financially stressed customers can be targeted, but vulnerability is not limited to any demographic. Controls should use behaviour and customer circumstances carefully rather than stereotypes.

Metrics

Useful measures can include prevented fraud, recovered value, beneficiary detection, time to action, repeat network identification, false-positive rate, customer friction, AML referrals and case quality.

A single loss metric can encourage overblocking if not balanced with customer outcomes.

Quality assurance

QA should review classification of authorised versus unauthorised fraud, mule versus compromised customer, use of vendor intelligence, recovery evidence, fraud-to-AML referral quality and clarity of investigation narratives.

BA architecture map

Map channel, authentication service, customer data, fraud engine, payment hub, scheme, core ledger, sanctions screening, AML monitoring, recovery workflow and case management. For each interface, identify identifiers, timing and failure mode.

Failure scenarios

Test unavailable fraud model, delayed beneficiary intelligence, payment sent while screening service is degraded, duplicate callback, partial settlement, timeout, customer cancellation, list update during processing and case-system outage.

Auditability

For a payment intervention, the bank should be able to reconstruct what data and model version were used, which decision was made, who overrode it if applicable and what happened to the payment.

Final deep-dive exercise

Reconstruct a scam from first customer contact through payment, receiving account, two onward transfers, partial recovery and an AML network case. Identify the controls that could act before payment, immediately after settlement and during post-event investigation. Then identify which evidence belongs to fraud, payments, sanctions and AML. This exercise turns a fragmented set of alerts into one controlled end-to-end operating model.

Advanced practice: cyber-fraud proceeds from victim event to laundering network

Cyber-enabled crime requires investigators to think in sequences rather than isolated alerts. The same economic event can create evidence in authentication systems, payment channels, fraud engines, beneficiary-bank monitoring, transaction-monitoring platforms, virtual-asset analytics and customer case management. The professional skill is reconstructing that sequence without confusing what each control actually proves.

Worked case: authorised push-payment investment scam

A customer at Bank A believes she is investing through an online trading platform. She passes strong authentication and sends three instant payments to Account X at Bank B over two days. Account X is six weeks old, has previously received only small salary payments and begins receiving money from seven unrelated people. Ninety minutes after the first victim payment, most funds are divided between Accounts Y and Z and a virtual-asset service provider.

From Bank A's perspective, the first question is whether the customer's behaviour is unusual and whether scam indicators were present before payment. From Bank B's perspective, the stronger pattern may be receiving-account behaviour: unrelated payers, abrupt activity change, high pass-through and common downstream beneficiaries. Neither bank can assume the exact offence merely from the transactions.

If Bank A later receives a victim report, that confirmed fraud information can materially change Bank B's assessment of Account X if information can be shared through lawful channels. The AML case at Bank B should then examine whether Y and Z show similar behaviour, whether the accounts share devices or contact details, and whether the virtual-asset destination appears across other cases.

The important learning point is that authentication success at Bank A did not validate the investment. It established that the customer authorised the payment through the channel. Fraud controls and customer warnings must therefore consider deception as well as unauthorised access.

Worked case: account takeover followed by laundering

A long-standing customer at Bank C experiences a credential reset and login from a new device. The account receives two transfers from unrelated businesses and sends the combined value to four new beneficiaries within 20 minutes. The legitimate account owner then contacts the bank saying they cannot access online banking.

The primary customer-protection issue is account takeover. The AML issue is that the compromised account has also been used as laundering infrastructure. Fraud operations may lock access, restore credentials and recover funds where possible. AML investigators still need to understand the incoming and outgoing money and whether the account connects to a wider network.

Closing the fraud case after restoring the customer's account should not delete or hide the transaction evidence. The same beneficiaries may appear in other mule cases.

Worked case: business-email compromise

A corporate customer has paid the same supplier monthly for two years. An attacker compromises email and sends a convincing instruction stating that the supplier has changed banks. The corporate user updates the beneficiary and releases a high-value payment using normal entitlements.

The bank may not detect this from authentication because the genuine user performed the actions. More relevant signals can include a material beneficiary change, unusual country or account, a request outside normal supplier-change procedure, or conflict between invoice details and historical beneficiary information.

If the funds reach a mule or front company, the receiving side can see a different risk picture. This is why corporate-fraud controls, beneficiary maintenance, payments and AML investigations need stable identifiers and evidence sharing.

Ransomware and extortion: keep legal questions separate

A corporate customer tells the bank it is responding to a ransomware incident and intends to transfer funds to a virtual-asset exchange. Several control questions arise: Is the customer genuinely the victim? Is the payment permitted under applicable law and sanctions restrictions? Is the exchange a regulated or higher-risk provider? What does the bank know about the ultimate wallet or threat actor? Are law-enforcement or specialist teams involved?

AML, sanctions, cyber incident response and legal advice can all be relevant, but they are not the same decision. A transaction associated with ransomware can create sanctions concerns if designated actors are involved; a lawful customer engaging an incident-response firm can also generate unusual payments without being a money launderer.

The case record should preserve which team decided what and on what basis.

Fraud proceeds through merchant infrastructure

A criminal network can also use sham merchants, compromised merchants or refund mechanisms to convert stolen payment value into settlement funds. The acquiring bank or payment provider may see authorisation and settlement data rather than classic bank transfers.

Useful signals can include rapid merchant-volume growth, unusual card geography, refund or chargeback patterns, activity inconsistent with merchant category, common settlement accounts, device or terminal anomalies and ownership links to other problematic merchants. Again, a high chargeback rate can have innocent explanations; the pattern should be assessed against the merchant's business.

Virtual-asset tracing exercise

Suppose victim-linked funds move from a bank account to Exchange A, then on-chain to several wallets, through a mixer, into another asset and finally to Exchange B. The investigator should separate what is directly known from what is inferred by analytics.

Known bank facts may include the fiat payment to Exchange A and customer ownership of the sending account. Exchange or law-enforcement information may establish wallet attribution. Blockchain analytics may identify exposure to a mixer or likely transaction paths with confidence scores. The bank should not write "funds were laundered through Mixer X" unless the evidence supports that conclusion. A better narrative states the observed transfer, the analytics attribution, its confidence and the reason the pattern raises concern.

Chain hopping and use of multiple assets can increase tracing complexity, but active traders and treasury users may also move between assets for legitimate reasons. Customer purpose remains important.

Offshore VASPs and regulatory perimeter risk

FATF's March 2026 report on offshore VASPs highlights how providers serving customers across borders can exploit regulatory gaps or weak supervision. For a bank, provider risk should be one factor among several. The control can consider whether the provider is licensed or registered where expected, the countries it serves, transparency of ownership, adverse regulatory action and known fraud or laundering exposure.

The existence of an offshore structure does not prove illegality. The bank should use the information to calibrate due diligence, monitoring and escalation.

DeFi exposure: do not oversimplify

DeFi can involve decentralised protocols, smart contracts, bridges, liquidity pools and self-hosted wallets. FATF's July 2026 report emphasises regulatory challenges and continuing ML/TF/PF exposure. Banks may see fiat entry and exit rather than protocol-level activity.

Where analytics identify DeFi exposure, investigators should ask what service or protocol was used, whether an identifiable service provider is involved, how the customer explains the activity, and whether the transaction path is consistent with investment or business purpose. The label "DeFi" should not replace analysis.

Rapid recovery and evidence preservation

When fraud is reported, recovery actions are time-sensitive. Operational playbooks should define how the bank initiates recalls, contacts beneficiary institutions, restricts accounts where permitted, preserves evidence and escalates AML concerns in parallel.

For instant payments, timestamps should be captured to the second where available: victim payment initiated, beneficiary credited, fraud report received, hold applied, onward payment initiated, recall requested and response received. This chronology can reveal whether a control had a realistic opportunity to intervene.

Model feedback and outcome quality

A mature fraud/AML environment feeds high-confidence outcomes back into controls. Confirmed victim-linked beneficiary accounts, known false positives, successful customer explanations and law-enforcement feedback can all improve models.

Outcome labels need governance. If every closed alert is labelled "not suspicious," the bank may train models on poor-quality assumptions. Case closure can mean insufficient evidence, legitimate activity, duplicate alert, already reported, account-takeover victim or several other things. Those outcomes should be distinct.

BA test: can the bank reconstruct one payment end to end?

Select one real or test payment and attempt to move from channel authentication to payment instruction, payment hub, sanctions/fraud decisions, settlement reference, beneficiary account where internal, recall or return, monitoring alert and case. If any step requires screenshots, email or manual guesswork, there is a lineage gap.

For ISO 20022 payments, preserve original party, account, agent and remittance values as received. If enrichment or repair changes them, store the changed value and reason. Investigators need to know what the control actually screened at the time, not only the final cleaned record.

Closing standard

A high-quality cyber-proceeds investigation explains the predicate-event evidence where known, movement of funds, customer and account role, downstream network, control timing, external intelligence and uncertainty. It avoids both extremes: treating fraud as only a customer-reimbursement matter, or labelling every unusual digital transfer as money laundering.

Practitioner close: cyber-enabled crime, ransomware and scam proceeds

Case lab: fraud event becomes a laundering investigation

A customer receives twelve instant payments from unrelated individuals within twenty minutes. Most incoming funds leave within minutes to newly added beneficiaries and a virtual-asset service provider. The fraud team identifies several senders as victims of impersonation scams.

The AML question is now different from the original fraud question. Fraud operations may be trying to stop or recover victim funds; AML investigators need to determine whether the receiving account is controlled by the fraudster, a recruited money mule, an unwitting intermediary or an account-takeover victim, and how the wider network moves proceeds.

The investigation should preserve the time sequence. Incoming victim payment, login event, device change, beneficiary creation, transfer, cash withdrawal, card spend and virtual-asset purchase can together explain the account’s role. If fraud and AML systems each keep only their own events, the bank can miss the complete pattern.

Ransomware: separate payment legality from laundering analysis

Ransomware cases can involve cybercrime, sanctions, money laundering and virtual assets at the same time. A bank should not assume that every ransomware-related transfer has the same legal outcome. The applicable sanctions regime, parties, virtual-asset exposure and local reporting requirements must be assessed separately.

For AML analysis, useful evidence can include source of funds, beneficiary or VASP, wallet information where available, transaction timing, subsequent movement, customer business purpose and links to known infrastructure. Blockchain analytics can add context but should be treated as analytical evidence rather than automatic proof that a customer committed an offence.

Recovery changes the evidence, not the history

If stolen funds are recovered or returned, the original suspicious movement still matters. Recovery can reveal beneficiary accounts, intermediaries and network links. Case management should therefore connect the original payment, fraud claim, recovery request, return transaction and any AML escalation rather than overwrite the event with “funds recovered.”

Account takeover versus mule behaviour

An account that suddenly sends scam proceeds may be a recruited mule or a legitimate customer whose credentials were compromised. Device intelligence, authentication events, behavioural history, beneficiary changes and customer contact can help distinguish the hypotheses.

This distinction matters for customer treatment and investigation. The bank should avoid labelling a customer a mule solely because their account received criminal proceeds when credible evidence suggests account takeover.

Practitioner checkpoint

A strong cyber-enabled crime investigation reconstructs the sequence across fraud, payments, authentication, devices, AML monitoring and virtual-asset exposure. It separates fraud loss, sanctions questions and AML suspicion, preserves recovery events and avoids turning risk indicators into unsupported conclusions.

Practitioner masterclass: connecting fraud, payments and AML in cyber-enabled crime

Cyber-enabled financial crime is a timing problem as much as an analytical problem. A fraud event can begin with social engineering, move into a payment within minutes, reach a receiving account in seconds and be dispersed before a traditional AML batch has even started. The institution therefore needs controls operating at different speeds for different purposes.

Build one event timeline

Start with customer interaction, authentication, beneficiary creation, payment initiation, approval, settlement, victim report, recall, receiving-account movement and downstream cash-out. Add device changes, credential resets, fraud alerts and AML alerts.

A single timeline helps teams see that fraud and AML are not separate stories.

APP scam exercise

A customer is tricked into transferring EUR 15,000 to a new beneficiary. Authentication succeeded. The sending bank therefore needs to distinguish authentication from genuine informed intent.

The receiving bank should assess the beneficiary account's age, prior reports, inbound payer diversity and onward movement. Connecting both sides can improve recovery and network disruption.

Cybercrime event timeline linking customer compromise, payment, receiving account, recovery and AML network investigation.

Account takeover exercise

A long-standing customer suddenly logs in from a new device, resets credentials and sends payments to new beneficiaries. The primary fraud question is whether the customer lost control of the account.

If the same account also receives and forwards criminal proceeds, AML may investigate the flow, but customer treatment should not assume willing mule participation.

Ransomware decision exercise

A company asks the bank to fund a virtual-asset purchase after a ransomware incident. The bank needs a coordinated response involving cyber/fraud, AML, sanctions and legal specialists. Urgency does not override sanctions law or internal escalation requirements.

Blockchain analytics discipline

A vendor may label a wallet as high risk or connected to an illicit service. Record the source, date and confidence. Understand whether the link is direct, indirect or heuristic.

Do not convert a probabilistic label into a statement of legal fact.

Beneficiary-network expansion

Once one receiving account is linked to confirmed scam payments, search for shared beneficiaries, devices, contact details and rapid onward destinations. Expand carefully: weak associations should not trigger automatic adverse decisions.

Fraud-to-AML handoff specification

At minimum, pass transaction identifier, victim-report reference, beneficiary, amount, timestamp, payment status, recall status, device or authentication evidence and any linked receiving accounts. The AML case should be able to trace back to the original fraud evidence.

AML-to-fraud feedback

AML may identify a beneficiary cluster that has not yet generated formal fraud complaints. That intelligence can improve future real-time scoring, subject to governance and data-sharing rules.

Control-speed map

Pre-payment controls include authentication, behavioural analytics and beneficiary risk. Immediate post-payment controls include recall and receiving-bank contact. Post-event AML controls include network reconstruction, suspicious reporting and typology feedback.

Each layer has a different success measure.

Model-governance exercise

For a mule or scam model, document purpose, population, features, training data, validation, performance, thresholds, override rights and monitoring. Test legitimate high-velocity customers so the model does not equate speed with crime.

Customer vulnerability

Victims of romance, investment or impersonation scams may continue to believe the criminal. Customer communication should be clear and protective without humiliating the customer or revealing protected AML information.

Payment-lineage exercise

Trace a payment from channel instruction through payment engine, screening, settlement, return or recall and case management. Confirm that identifiers allow investigators to join the records without screenshots.

BA acceptance criteria

Include delayed fraud report, reversed payment, repaired beneficiary, duplicate transaction, missing device signal, receiving account closure, partial recovery, multiple victim reports and cross-border onward transfer.

Quality assurance test

Review cases where analysts labelled customers as mules. Check whether the evidence distinguishes complicit use, recruitment/deception and account takeover. Review whether vendor risk labels were independently interpreted and whether fraud evidence was visible in the AML case.

Final practitioner test

A strong learner should be able to reconstruct the full cybercrime money flow, explain why successful authentication does not prove genuine intent, separate victim from mule classifications, understand ransomware-sanctions interaction and design evidence-sharing between fraud, payments and AML without collapsing their decision rights.

60-minute mastery extension: cyber-enabled crime, ransomware and scam proceeds

This extension is designed to make the chapter a minimum 60-minute guided learning experience. Spend around 25 minutes on the core lesson and diagrams, 15 minutes on the scam/ransomware cases, 10 minutes on fraud-to-AML data design and 10 minutes on the final control-speed test.

Cyber-enabled financial crime is a race against time

Digital crime can move from social engineering or account compromise to payment, receiving account, onward transfer and cash-out in minutes. The fraud team may see the customer interaction, the payment platform sees the instruction, the receiving bank sees the beneficiary account and AML may later see the wider network. The control environment is strongest when these views can be connected without collapsing their different decision rights.

Worked case: authorised push-payment scam

A customer receives an impersonation call and is persuaded to send EUR 25,000 to a new beneficiary. Strong customer authentication succeeds because the customer actually authorises the payment. The sending bank's challenge is therefore not authentication alone; it may need behavioural signals, beneficiary risk, warnings and customer intervention.

The receiving account is three weeks old, has received several payments from unrelated senders and forwards most value within minutes. Two prior senders have already complained of scams. The receiving bank has a different but complementary view. Fraud and AML intelligence can connect the victim-side and beneficiary-side evidence.

Account takeover versus authorised scam

In account takeover, the attacker controls credentials or device access and the legitimate customer may not authorise the transaction. In an authorised scam, the customer may approve the payment while being deceived. Both can produce rapid losses, but the authentication, liability, communication and remediation questions differ.

AML should also avoid treating a compromised account holder as a willing mule merely because the account handled criminal proceeds. Account use and customer intent must remain separate concepts.

Ransomware

Ransomware can involve system encryption, data theft and extortion. Payments are often requested in virtual assets, but banks can see fiat transfers to exchanges, brokers, intermediaries or specialist responders. A victim organisation's urgency does not remove legal obligations. If a payment creates sanctions exposure, legal and sanctions specialists need to assess the applicable regime and any licence or authorisation.

The bank should not assume that every ransomware-related payment is prohibited or that victim status authorises any payment. The legal outcome depends on the facts and applicable rules.

Blockchain analytics

Blockchain analytics can provide wallet labels, clustering, direct and indirect exposure and transaction paths. These outputs are intelligence, not legal fact. Analysts should know the source, date, methodology and confidence of a label. A risk score can be useful for prioritisation but should not become an unchallengeable conclusion.

The same principle applies to device intelligence, IP geolocation and synthetic-identity scores. Vendor inference should be clearly distinguished from verified bank facts.

Fraud-to-AML handoff exercise

Define the minimum data package that should move from a fraud case into AML: transaction ID, victim-report reference, customer and beneficiary identifiers, amount, timestamp, payment status, recall/recovery status, authentication/device evidence, known receiving accounts and source/confidence of external intelligence.

Then define the reverse flow from AML to fraud: network beneficiaries, linked accounts, high-confidence device clusters and emerging typologies. Add access controls so protected SAR/STR information is not exposed beyond authorised roles.

Real-time versus post-event controls

Real-time controls can stop or interrupt a payment but have very little time and can cause customer friction. Post-event AML controls can examine broader networks and longer patterns but may be too late to recover funds. The two layers have different success measures and should not be judged by the same KPI.

A mature model measures prevented loss, recovered value, time to receiving-bank action, network expansion, false positives, customer friction and investigation quality.

Merchant and refund abuse

Fraud proceeds can also enter through merchant accounts. Sham or complicit merchants can process fabricated sales, while refund flows to different cards or accounts can move value. Acquirers should consider merchant category, website, transaction geography, chargebacks, refunds, turnover growth, beneficial ownership and settlement destinations.

A sudden turnover increase can be legitimate. The risk comes from how multiple signals fit together.

Synthetic identity and remote onboarding

Synthetic identities can combine real and fabricated data. Remote onboarding can also face document manipulation, deepfakes, stolen identities and compromised devices. Controls may use document verification, biometrics, liveness, database checks and manual review according to risk.

No biometric or vendor score should be treated as infallible. Model governance, bias, error handling and human escalation matter.

BA control-speed exercise

Map a scam event from login to beneficiary creation, payment initiation, authentication, fraud score, payment execution, settlement, victim report, recall, receiving-bank action and AML case. Record which systems own each timestamp and identifier. Then ask whether the architecture can reconstruct the event without screenshots.

Add failure cases: delayed fraud report, missing device signal, payment already returned, partial recovery, beneficiary account closed, cross-border onward transfer and vendor service outage.

Final control-speed test

For each control—authentication, beneficiary risk, sanctions screening, payment hold, fraud recall, AML transaction monitoring, network analysis and suspicious reporting—state whether it is primarily preventive, immediate response, detective or post-event intelligence. Then state the evidence it needs and the harm caused if it runs too slowly.

A strong learner should finish able to connect cybercrime, payments, fraud and AML as one financial event while keeping customer intent, legal sanctions analysis and model inference precise.

Worked case: invoice redirection from compromise to cash-out

A mid-sized manufacturing customer, a twelve-year banking relationship with no prior incidents, instructs an illustrative 780,000 payment to a new beneficiary for what its finance officer describes as a supplier invoice settled under changed bank details. The payment executes through the corporate channel with valid credentials and dual authorisation. Four days later the customer reports the fraud: its email was compromised, the invoice and the bank-detail-change notice were fabricated, and the genuine supplier remains unpaid. The funds have already left the beneficiary account in three onward transfers to accounts at two other institutions, with one tranche converted through a virtual-asset provider.

The case exercises the full fraud-to-AML chain under time pressure, and sequencing determines how much is recovered. The first hour belongs to containment: recall requests on all three onward transfers with precise payment identifiers, engagement with the receiving institutions' fraud teams through established channels, hold requests on the virtual-asset conversion where the provider relationship permits, and preservation of the customer's own device and log evidence. Every action is timestamped, because recovery disputes and potential liability assessments will reconstruct the timeline to the minute.

The second phase reconstructs the compromise to distinguish external fraud from insider involvement or customer negligence affecting liability. Email-header analysis, login records, authorisation-device history and the behavioural plausibility of the finance officer's actions each contribute. The dual authorisation, initially reassuring, is examined rather than accepted: who authorised, from which devices, with what timing, and whether the authorisers verified the change through an independent channel. Many business-email-compromise losses survive dual authorisation because both authorisers act on the same poisoned information; the control failure is verification, not authorisation count.

The third phase follows the proceeds as a money-laundering investigation regardless of recovery success. The beneficiary account's history is examined for mule-network markers: account age, prior activity, the relationship between stated business and received funds, device links to other accounts, and the velocity of onward movement. The receiving institutions are engaged not only for recovery but for intelligence, since the same beneficiary infrastructure typically serves multiple victims. The virtual-asset tranche triggers blockchain tracing with confidence labelling, aimed at identifying the off-ramp or service where value re-enters the observable financial system.

Liability and customer-treatment questions run alongside the investigation. Authorised-push-payment reimbursement frameworks differ by jurisdiction, with the United Kingdom's regime being notably more prescriptive than most, and the bank must apply its own jurisdiction's rules rather than improvising fairness. The genuine supplier relationship needs active management: the customer owes a real debt it has already paid once to criminals, and the bank's communication should support the customer's recovery position without admitting liabilities prematurely. Lessons feed control improvement: verification-of-change procedures for bank-detail amendments, cooling-period or call-back requirements above thresholds, beneficiary-risk scoring for first-time corporate payees, and customer education targeted at finance-team compromise rather than generic phishing awareness.

Refund abuse and merchant-infrastructure laundering

Refund and return mechanisms create laundering pathways that transaction monitoring tuned for payments often misses. The basic pattern uses compromised payment instruments for purchases followed by refunds to different instruments or accounts, converting stolen value into merchant credits and onward funds that appear legitimate without removing their criminal origin. More elaborate variants exploit marketplace and platform refund policies at scale, operate collusive merchant-refund rings, or abuse airline, travel and hospitality refund processes where high values and complex itineraries obscure the pattern.

Detection requires joining data the bank often holds separately: acquiring-side merchant records showing refund ratios, refund destinations and velocity, and issuing-side cardholder records showing purchase-and-refund patterns across merchants. Refund-ratio analytics benchmarked by merchant category identify outliers; destination analysis catches refunds routed away from the original payment instrument; and network analysis connects collusive merchants with shared devices, settlement accounts or refund recipients. Platform-economy refund abuse adds the dimension of policy arbitrage across jurisdictions and entities, requiring case coordination beyond single-merchant review.

Response must distinguish merchant fraud, cardholder fraud and laundering, since the same pattern can represent any of the three and the appropriate action differs. Collusive merchants face acquiring-relationship action and potential network reporting; victimised merchants need vulnerability remediation rather than punishment; and laundering patterns trigger the standard financial-crime response regardless of the merchant channel. Refund-policy design itself is a control decision: instant refunds to alternate instruments, refund values exceeding purchase values through stacked promotions, and weak refund-identity verification each create structural capacity that monitoring can only partially offset.

Device and identity graphs: signals with limits

Device fingerprints, IP and network signals, behavioural biometrics and identity-graph analytics contribute powerful fraud and mule-detection signals, but each carries limitations that investigations must respect. Device signals degrade through shared devices in families and communities, device farms that rotate identifiers systematically, and legitimate device changes that mimic evasion. Network signals confuse carrier-grade address sharing, VPN and corporate-egress concentration with criminal infrastructure. Behavioural signals vary with age, disability, stress and unfamiliarity, creating discrimination risk where models penalise atypical interaction patterns.

Responsible use therefore embeds signal limitations into control design. No single signal should determine suspicion; signals contribute to risk assessment with documented weights and known failure modes. Model validation must include legitimate high-sharing populations, accessibility-affected users and regional infrastructure patterns to prevent systematic disadvantage. Investigators need signal literacy sufficient to challenge model outputs: understanding what a device match proves, what an IP mismatch does not prove, and when to seek corroboration before acting. Data-protection obligations govern collection, retention and use, with particular attention to biometric and behavioural data; the legal basis, necessity and proportionality of each signal should be documented rather than assumed under blanket fraud-prevention justifications.

Signal sharing across institutions multiplies effectiveness against networks that distribute activity deliberately, and privacy-preserving sharing techniques continue to mature. Participation decisions should weigh the intelligence value against data-protection and competition-law constraints in the relevant jurisdictions, with legal advice shaping the mechanism rather than blocking the objective. The direction of travel favours more sharing under stronger governance, and banks should build the governance foundations that make participation possible.

Worked case: the investment-scam network behind retail accounts

A retail fraud team notices forty-seven customers across different branches reporting investment-scam losses over two months, with individual losses ranging from an illustrative 5,000 to 200,000. Victim interviews reveal a consistent methodology: contact through social media or messaging applications, relationship development over weeks, introduction to a professional-looking trading platform showing growing balances, small initial withdrawals permitted to build trust, then escalating deposit demands followed by withdrawal blocks with fee pretexts. The platform domains differ per victim cohort but share registration patterns, and the beneficiary accounts receiving victim funds show no two victims paying the same account twice.

The investigation treats the victim reports as intelligence illuminating an organised network rather than as isolated complaints. Payment analysis maps victim transfers to beneficiary accounts, revealing a three-layer structure: collection accounts receiving direct victim funds, consolidation accounts aggregating from multiple collection points, and extraction accounts forwarding to virtual-asset providers and overseas entities. Device and infrastructure analysis connects the collection accounts through shared onboarding devices, IP ranges and identification-document anomalies suggesting synthetic or manipulated identities. Platform analysis, supported by open-source investigation and law-enforcement liaison, shows the trading platforms are fabricated interfaces with no market connectivity, and the small permitted withdrawals are funded from other victims' deposits in classic Ponzi mechanics.

Victim handling runs parallel to network investigation with equal priority. Each victim receives a dedicated case handler coordinating recall and recovery attempts, reporting guidance, emotional-support referrals recognising the profound shame and distress investment-scam victims experience, and protection against re-victimisation through recovery-fraud approaches that predictably follow. Vulnerable-victim identification triggers enhanced safeguarding: elderly victims, those showing signs of coercion or cognitive decline, and victims continuing to send funds despite warnings each need tailored intervention rather than standard process. The bank records victim cooperation carefully, since victim testimony often provides the only evidence of the deception methodology supporting later prosecution.

The network response combines defensive and offensive measures. Defensively, the identified beneficiary infrastructure is restricted and reported, platform domains and payment details feed pre-payment warning systems so that future victims encounter friction before transferring, and the scam methodology informs customer-education content that describes the specific grooming pattern rather than generic investment warnings. Offensively, the consolidated intelligence package, victim statements, payment mapping, device infrastructure, platform analysis and virtual-asset tracing, is provided to law enforcement through proper channels, and receiving institutions are engaged for both recovery and their own investigation. The control lesson is that scam response must be organised around networks and victim cohorts rather than individual disputes: the forty-eighth victim is preventable only where the first forty-seven reports were joined into actionable intelligence fast enough.

Synthetic identity: detection at the seams

Synthetic identities, combining real and fabricated personal elements into fictitious persons that pass verification, create accounts specifically designed for fraud and laundering use. Detection focuses on the seams where fabrication meets verification: identity elements that fail cross-consistency, such as credit histories inconsistent with claimed age, addresses with no residential footprint, or employment records that cannot be corroborated. No single check catches synthetics reliably; the defence layers document examination, data-consortium signals, behavioural analysis and portfolio-level pattern detection.

Document and data examination tests each identity element against independent sources: government identity validation where available, credit-bureau file depth and coherence, address and phone-tenure records, and employer existence verification independent of applicant-provided contacts. Behavioural analysis watches for the characteristic synthetic lifecycle: careful account nurturing with small legitimate-seeming activity building history and limits, followed by bust-out exploitation through maxed credit, received fraud proceeds or rapid extraction. Portfolio analysis detects the manufacturing signatures: batches of applications sharing mutated identity elements, sequential document numbers, common devices or addresses with minor variations, and coordinated activity onset across supposedly unrelated accounts.

Response to confirmed synthetic portfolios requires network treatment with organiser identification, since manufacturing infrastructure serves multiple fraud campaigns. Confirmed synthetic accounts are restricted and reported, with intelligence shared through lawful channels given the infrastructure's reuse across institutions. The onboarding lessons feed back into verification design: checks that synthetics routinely defeat need strengthening or supplementation, while verification friction must remain proportionate for genuine customers including young, migrant and thin-file applicants whose legitimate profiles share surface features with synthetics. Fairness monitoring of verification outcomes by demographic segment guards against controls that exclude the legitimate alongside the fabricated.

Industrialised scam operations: call centres and trafficking

Some large investment and romance scam operations use industrialised compounds where trafficked workers conduct fraud under coercion, combining cyber-enabled crime with human trafficking and organised criminality at scale. INTERPOL's June 2025 crime-trend update documents the expanding international footprint of human-trafficking-fuelled scam centres; it does not establish that every major scam originates in such a compound. The banking implications extend beyond victim payments to the operational infrastructure: facility-related payments, worker-recruitment flows, equipment procurement, cryptocurrency consolidation and the lifestyle expenditure of organisers. A bank can encounter victim proceeds in domestic accounts even when the compound and its other financial infrastructure are elsewhere, and the mule and consolidation infrastructure serving industrialised scams shows distinctive scale signatures: high victim counts per beneficiary cluster, scripted victim communication producing recognisable narrative patterns across reports, and rapid professionalised onward movement.

Victim handling for industrialised-scam victims requires awareness of the operation's sophistication: victims groomed over months by professional teams using psychological playbooks experience profound shame and often resist accepting the fraud even after bank intervention. Intervention design must account for groomed resistance: warnings from the bank compete with trusted fraudster relationships, and effective approaches involve family or law-enforcement participation, concrete evidence presentation and patient repeated contact rather than single generic alerts. Recovery prospects are typically poor given professionalised dissipation, making prevention through pre-payment intelligence the highest-value control: shared beneficiary intelligence, platform-domain feeds and methodology-specific warnings that intercept victims before first transfer.

The human-trafficking dimension creates additional reporting and response obligations where the bank encounters related flows: recruitment-fee payments, worker-movement financing or organiser expenditure within its visibility should be assessed for trafficking indicators alongside fraud, with reporting capturing both dimensions and victim-support considerations reflected in handling. Staff training should connect scam typologies with trafficking awareness so that cases are recognised in their full criminality rather than processed as isolated fraud disputes. Industry cooperation against industrialised scams, through shared intelligence, coordinated platform engagement and joint law-enforcement support, reflects the reality that no single institution sees enough of these networks to disrupt them alone.

QR-code phishing and the payment-redirection threat

QR codes collapse the verification gap between physical and digital contexts: victims scanning malicious codes are directed to phishing sites, mule-payment destinations or malware downloads without the URL examination that might protect them in browsers. Criminal applications include fake parking and toll payments, fraudulent restaurant and retail codes overlaying legitimate ones, investment-scam onboarding through malicious codes, and business-invoice QR codes substituting mule-account details for genuine beneficiary information. The banking-visible consequences are authorised push payments to mule accounts initiated through channels the bank's existing scam warnings do not cover.

Controls adapt existing APP-scam defences to the QR vector rather than inventing parallel systems. Beneficiary-risk assessment applies identically regardless of how the victim obtained the payment details: first-time beneficiaries, mule-network markers and profile-inconsistent destinations attract the same friction whether reached by QR scan, link or manual entry. Payee-verification mechanisms expose name mismatches in QR-initiated payments where implemented. Customer education addresses QR-specific verification habits: previewing destinations before confirming, verifying physical codes against tampering, and treating unsolicited payment QR codes with the suspicion applied to unsolicited links. Corporate-customer controls address invoice-QR substitution through the same bank-detail-change verification procedures as text-based redirection: independent-channel confirmation of payment-detail changes above thresholds, with QR-provided details explicitly in scope rather than assumed trustworthy because machine-readable.

SIM-swap, OTP interception and authentication-fraud laundering

Account-takeover methodology increasingly targets the authentication layer itself: SIM-swap fraud transferring victims' phone numbers to attacker-controlled SIMs, SS7 and messaging-interception techniques capturing one-time passcodes, and notification-suppression preventing victims from seeing takeover in progress. The banking implications span fraud prevention, mule-network enablement and laundering velocity: compromised authentication lets criminals operate victim accounts directly, open new accounts in victim names, and defeat the step-up challenges meant to protect high-risk actions.

Control design must assume authentication compromise as a routine scenario rather than an exotic attack. Transaction-risk analysis should weigh authentication strength explicitly: actions authenticated through potentially compromised channels attract enhanced scrutiny, and high-risk actions following recent SIM, device or credential changes warrant verification through independent channels. Telecom-data signals, where lawfully available, identify SIM-swap events and high-risk number-porting patterns; device and behavioural analytics detect the usage discontinuity characteristic of takeover operation. Customer-notification design should use channels independent of the potentially compromised factor and provide clear compromise-reporting paths that assume the customer's primary channel may be controlled by attackers.

The laundering dimension arises as compromised accounts and newly opened fraudulent accounts serve mule and layering functions at machine speed: takeover-to-extraction cycles completing within hours, before victims or banks respond. Rapid holds or account restrictions where legally permitted, approved intervention triggers for compromise indicators, and receiving-institution cooperation for recall can help preserve funds. An operational hold is not a sanctions freeze or a court-ordered restraint; the legal basis and decision owner must remain clear. Post-incident analysis should feed authentication-design improvements: each compromise method that succeeds reveals a trust assumption requiring revision, and the authentication architecture should evolve faster than attacker methods through continuous adversarial review rather than periodic overhaul.

Authoritative anchors

FATF Countering Ransomware Financing, 14 March 2023: https://www.fatf-gafi.org/en/publications/Methodsandtrends/countering-ransomware-financing.html

FATF virtual assets: https://www.fatf-gafi.org/en/topics/virtual-assets.html

Europol cybercrime: https://www.europol.europa.eu/crime-areas/cybercrime

INTERPOL — Human trafficking-fuelled scam centres, crime-trend update, 30 June 2025: https://www.interpol.int/en/News-and-Events/News/2025/INTERPOL-releases-new-information-on-globalization-of-scam-centres

2026 practitioner enhancement: cyber-enabled crime, scams and the laundering chain

Cyber-enabled fraud can create criminal proceeds directly inside regulated payment systems. The financial-crime challenge begins before, during and after the payment: deception or account takeover creates the loss; the beneficiary account receives the proceeds; mule and consolidation accounts move the value; cash, virtual assets or cross-border transfers can then make recovery harder. Treating fraud and AML as unrelated control worlds leaves gaps between those stages.

Authorised and unauthorised fraud create different evidence

In account takeover or other unauthorised fraud, authentication, device, credential-reset and session evidence can be central. In authorised push-payment scams, the victim may pass normal authentication because they were deceived into making the payment. A successful authentication event shows that the configured authentication checks passed. It does not by itself establish who consented to the payment or that its economic purpose was genuine. For a specific legal example, UK Payment Services Regulations 2017 regulation 75(3) states that recorded use of a payment instrument is not necessarily sufficient by itself to prove payer authorisation when the user denies authorising the payment. Apply the evidential and consent rules of the relevant jurisdiction.

Investigators should preserve the distinction. It affects customer protection, fraud reimbursement, recovery activity and the evidence available to AML teams.

Scam typologies and the beneficiary side

Impersonation, investment, romance, purchase, job and business-email-compromise scams can produce very different narratives at the sending side but converge on similar beneficiary behaviour: unrelated inbound payments, rapid onward movement, conversion to virtual assets, cash withdrawal or transfers to consolidation accounts.

Receiving-bank controls can therefore be typology-agnostic in part. Beneficiary risk, payer diversity, pass-through ratio, account age, network links and previous confirmed fraud reports can be useful even when the receiving bank does not know the exact scam used against each victim.

Business email compromise and corporate payments

Business-email compromise can redirect genuine invoices or payment instructions to criminal-controlled accounts. Corporate payment files and high-value transfers can therefore be affected even when the underlying commercial relationship is real.

Controls can combine beneficiary-change detection, out-of-band verification for sensitive changes, user and device behaviour, payment history and fraud intelligence. AML investigation becomes relevant when recipient accounts or downstream networks are handling the stolen funds.

Ransomware and extortion proceeds

Ransomware and cyber extortion may involve virtual assets, but not every virtual-asset payment is ransomware related. Banks can encounter fiat payments to exchanges, funds returning from exchanges, payments to incident-response providers or later laundering of proceeds.

The institution should use credible intelligence, customer purpose, provider risk and transaction history rather than infer ransomware from a crypto counterparty alone. Where law-enforcement or sanctions information applies, specialist escalation can change the legal response.

Virtual assets, offshore VASPs and DeFi

FATF's 2026 work on offshore VASPs highlights how providers operating across jurisdictions or outside effective supervision can be exploited for fraud, laundering and terrorist financing. Its July 2026 work on DeFi similarly reinforces that the absence of a traditional intermediary does not remove financial-crime risk.

For banks, useful indicators can include rapid conversion immediately after unrelated inbound payments, use of multiple providers without an apparent investment rationale, exposure to anonymity-enhancing services, chain hopping, peer-to-peer settlement and inconsistencies between customer profile and transaction purpose. Blockchain-analytics scores can inform investigation but should not be treated as legal findings.

Fraud recovery and AML preservation

The urgency of victim recovery can coexist with AML obligations. A bank may need to act quickly on a recall, freeze or account restriction where legally permitted while also preserving the evidence needed for AML investigation. Case systems should link the original victim payment, recall request, beneficiary account, subsequent transactions, customer contact and any external report.

An operational failure occurs when money is recovered but the network evidence disappears into a closed fraud case. Another failure occurs when AML review delays an urgent fraud-recovery step that could have protected the victim. Clear decision rights and parallel workflows are needed.

Real-time payments and decision latency

Instant payments reduce the time between fraud and laundering. Real-time controls can use payer behaviour, beneficiary intelligence, device data, limits and network risk. Post-transaction controls can continue graph expansion and identify downstream accounts even after the original payment has settled.

The architecture should support low-latency signals without making every AML model a synchronous payment blocker. Some risks are suitable for real-time intervention; others are better handled through near-real-time or post-transaction investigation. The legal ability to delay or reject payments depends on scheme and jurisdiction.

Cyber proceeds and traditional laundering channels

Digital crime does not remain digital. Proceeds can be withdrawn as cash, moved through companies, used in trade, transferred by remitters, converted into property or luxury goods, or settled through underground networks. Investigators should follow the value across channel boundaries rather than stop at the first exchange, wallet or beneficiary bank.

Customer and network evidence

A mature investigation combines customer profile, transaction chronology, device and authentication history, payers, beneficiaries, fraud complaints, previous alerts, virtual-asset exposure, beneficial ownership and external intelligence. Shared phone numbers, devices or addresses can reveal networks but need context and confidence scoring.

A factual narrative is crucial. "Customer received five victim-linked credits and transferred 92% to two exchanges within 18 minutes" is stronger than "customer is a crypto fraudster." The first statement is observable; the second overstates what the bank knows.

BA and architecture view

Systems should maintain links among fraud event, payment instruction, authentication event, beneficiary account, recall, return, AML alert, network case and SAR/STR. Payment references and timestamps should remain stable across channel, hub, screening, booking and investigation systems. If a payment is repaired, original and corrected data should be retained.

The objective is a joined evidence model, not one giant decision engine. Fraud, AML, sanctions and customer-protection decisions can remain separate while sharing reliable facts.

References and further reading