Scams, money mules, and social engineering
Recognize deception across both the sender and receiver journeys.
The customer completed the authentication challenge correctly. They also sent their savings to an impersonator. The system verified the button press and missed the story behind it. Scam controls need to consider intent, destination, and the receiving network.
Separate unauthorized access from deception
In unauthorized access, another actor uses the account without permission. In a scam, the customer may perform the action after being deceived. These categories can overlap, but they suggest different interventions. A stronger login does not by itself test whether an invoice is genuine.
Use neutral language when collecting the report. Ask what happened, who initiated each action, what instructions were received, and how the destination was selected. Do not infer legal reimbursement rights from the internal fraud category. The relevant law, rail, account type, and facts determine the applicable process.
The familiar security story has an intruder stealing access. In an authorized scam, the person at the keyboard may be the real customer, using the real device, with the correct password. The attack changes the customer’s belief about why the money must move. Strong login controls can therefore coexist with severe scam losses.
Product design can make the intended payment easier to inspect. Show the actual recipient, distinguish a new destination from a familiar contact label, and explain an unusual instruction in language tied to the action. Generic warning walls lose value when customers learn to dismiss them. A warning needs a specific reason, a practical next step, and a path for customers who need help before the funds leave.
Inside the mechanism. Unauthorized access and deception of an authorized customer can require different evidence and intervention points. Record who initiated the operation, what authority was used, and what the customer reports being told. Do not convert a successful authentication result into a conclusion that no harm occurred. The legal treatment depends on the product and facts; the engineering model should preserve those facts so the appropriate process can evaluate them.
A concrete example. The real customer can use the real device and still send money because an attacker supplied a false story. Login success does not settle the payment’s intent. The rule flags 574 of 28,000 authorized transfer attempts. Of those flags, 157 meet the synthetic target, giving 27.35% precision. It misses 39 target events. Under the stated cost assumptions, residual loss and operating friction total $112,458. The important result is the connection between the population, action, capacity, and outcome—not one isolated score.
When the assumption fails. The system treats successful authentication as evidence against every scam path. Evaluate recipient context, behavioral changes, and the timing of a useful intervention. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.
The real customer can use the real device and still send money because an attacker supplied a false story. Login success does not settle the payment’s intent.
- ActorIdentify who performed the action
- InfluenceRecord the claimed reason
- DestinationTrace where value was sent
- Unauthorized use
- Account action lacked permission
- Deceived authorization
- Customer acted on a false story
Impersonation report
Illustrative data; not a real customer record or a prescribed policy.
- Actorcustomer
They pressed send
- Claimurgent bank transfer
Reported false story
- Destinationnew external account
Needs investigation
Authentication and intent answer different questions
Collect actor and deception facts separately. Authentication and intent answer different questions.
- Failure mode 1avoid
- Deny every claim after strong login. Login does not resolve all legal or factual issues.
- Failure mode 2avoid
- Call every scam account takeover. That can misdirect controls.
- Failure mode 3avoid
- Promise reimbursement from a label. Rights require the applicable rules and facts.
Interrupt the story at the right moment
A warning works best when it addresses the action in progress. A generic fraud paragraph becomes background noise. A destination-change warning can explain that a real bank will not need a transfer to a supposed safe account. Keep messages clear and test comprehension.
Avoid revealing exact detection thresholds or implying that the customer caused the problem. Offer a safe pause and a verified support route. Measure completed safe resolutions, not only how many warnings were displayed. A customer who clicks through a warning may be confused, rushed, or under pressure; clicks alone do not prove informed understanding.
Inside the mechanism. A useful interruption addresses the mechanism of the suspected deception at the moment the customer can still change course. A generic warning repeated on every transfer can become background noise. The message should be clear about the action and avoid claiming certainty the system lacks. Measure comprehension and subsequent behavior where possible. A warning display event is not evidence that the customer understood it or that the payment became safe.
A concrete example. A warning is part of the product intervention, not just a paragraph shown before payment. Its value depends on what customers understand and do next. The comparison arm has 144/6000 adverse outcomes (2.40%) and the treatment arm has 132/6000 (2.20%). The absolute difference is -0.20 percentage points, with an illustrative large-sample 95% interval from -0.74 to 0.34. Interpretation depends on assignment integrity, outcome maturity, independence, and the actual decision being evaluated.
When the assumption fails. A generic warning is dismissed without changing the risky action. Evaluate an approved, specific warning with completion, harm, and help-seeking outcomes. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.
A warning is part of the product intervention, not just a paragraph shown before payment. Its value depends on what customers understand and do next.
- Detect contextRecognize a relevant payment pattern
- Warn clearlyExplain the specific concern
- Provide exitOffer verified help and a pause
- Impressions
- Warnings shown
- Comprehension
- Users understand and can act safely
Warning evaluation
Illustrative data; not a real customer record or a prescribed policy.
- Shown1000
Exposure to the message
- Help used80
Possible safe intervention
- Confirmed understandingsampled
Separate evaluation measure
A visible message may still be ineffective
Test warning comprehension and safe exits. A visible message may still be ineffective.
- Failure mode 1avoid
- Count display volume as prevented fraud. Exposure is not an outcome.
- Failure mode 2avoid
- Expose exact rule thresholds. That needlessly reveals control boundaries.
- Failure mode 3avoid
- Use accusatory language. It can reduce cooperation and useful reporting.
Investigate receiver behavior
A receiving account can be used to move proceeds onward. Look at the relation between incoming funds, account history, outgoing destinations, and the stated purpose. A sudden rise in activity can have an honest explanation, such as a successful fundraiser.
Use the pattern to select a review, not to declare a person guilty. Preserve the transaction chain and seek relevant context through approved channels. Restrictions should have a legal and policy basis, a scope, and an owner. Do not assume all incoming funds have the same origin merely because one payment is disputed.
Receiver analysis requires care because a fast movement of money can serve many purposes. A marketplace seller, a payroll business, and a suspected mule account can all receive and forward funds. Compare the activity with the declared business, connected accounts, timing, and other reliable evidence. Do not turn one shared device or one unusual transfer into a conclusion about criminal intent. The investigation should preserve alternative explanations and identify the facts that would distinguish them.
Inside the mechanism. Receiver analysis can connect inflows, rapid outflows, destination reuse, account age, and the stated business purpose. A shared receiver is an investigative lead, not proof that every sender or account is complicit. Keep transfers directed and time-bounded so a pass-through pattern is not confused with unrelated historical activity. Consider the receiver’s legitimate operating model and preserve explanations that contradict the initial hypothesis.
A concrete example. A receiving account can collect and forward money for legitimate reasons or as part of a harmful network. The business explanation determines which facts matter. The daily source population is 7,600 items, but 152 are outside the completed monitoring run. The included population creates 410 hits and 336 unique cases. With 70 cases already open and capacity for 310, the queue closes at 96. Coverage, duplicate work, and staffing are separate causes; reducing one number does not prove that the overall control improved.
When the assumption fails. Fast onward transfers are treated as conclusive proof without counterparty or business context. Review typed relationships, source records, timing, and alternative explanations. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.
A receiving account can collect and forward money for legitimate reasons or as part of a harmful network. The business explanation determines which facts matter.
- InflowObserve source and timing
- ContextCompare with account purpose
- OutflowTrace linked movement and evidence
- Rapid turnover
- Potential investigation signal
- Illicit proceeds
- Conclusion requiring supporting evidence
Receiver review
Illustrative data; not a real customer record or a prescribed policy.
- Prior activitylow volume
Baseline
- New creditsseveral unrelated senders
Pattern change
- Explanationunverified fundraiser
Plausible claim to test
Unusual movement is a lead rather than proof
Review the pattern with customer context. Unusual movement is a lead rather than proof.
- Failure mode 1avoid
- Label every fast transfer laundering. Speed alone is insufficient.
- Failure mode 2avoid
- Ignore the stated purpose. Context can distinguish legitimate activity.
- Failure mode 3avoid
- Assume all funds are tainted. Different inflows may have different evidence.
Connect fraud and AML without collapsing them
Fraud teams often focus on immediate loss and customer protection. AML teams examine suspicious activity and applicable reporting duties. Shared evidence can help both, but their decisions and access rules differ. A fraud refund does not automatically close an AML concern.
Create a controlled referral that carries transaction references, observed facts, and confidence levels. Keep protected reporting information out of general support tools. Track acknowledgment and ownership so the referral is not lost between queues. Each team should record its own conclusion under the relevant policy rather than inherit another team’s label as a legal determination.
Inside the mechanism. Fraud operations may focus on a victim and immediate loss, while AML work evaluates activity and reporting obligations in its institutional scope. The same facts can be relevant to both teams without making the decisions identical. Use a controlled handoff that preserves the source evidence, confidentiality boundaries, and each team’s authority. A fraud label should not automatically become a legal reporting conclusion or a universal account disposition.
A concrete example. The fraud team may need to protect a customer while the AML team separately evaluates activity and reporting duties. A shared event does not create one shared legal decision. The case identifies 644 eligible records from a source population of 920. The required workflow completes for 625, but 9 completed records miss the illustrative internal target. Another 19 remain incomplete. Communication evidence covers 619 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.
When the assumption fails. A customer refund closes every related concern automatically. Share permitted factual evidence while retaining distinct decision owners and confidentiality boundaries. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.
The fraud team may need to protect a customer while the AML team separately evaluates activity and reporting duties. A shared event does not create one shared legal decision.
- Fraud caseCollect loss and deception facts
- ReferralShare permitted evidence
- AML reviewApply the separate investigative duty
- Customer remediation
- Addresses the customer impact
- AML disposition
- Addresses suspicious-activity obligations
Cross-team referral
Illustrative data; not a real customer record or a prescribed policy.
- Factslinked transactions
Shared evidence
- Refundcompleted
Customer remedy only
- AML statusrestricted
Separate controlled record
The objectives and confidentiality rules differ
Keep distinct decisions with a controlled referral. The objectives and confidentiality rules differ.
- Failure mode 1avoid
- Close AML automatically after refund. Remediation does not resolve every suspicion.
- Failure mode 2avoid
- Copy protected reporting status into support. Access must respect confidentiality.
- Failure mode 3avoid
- Send an unowned email. The handoff needs acknowledgment and responsibility.
Build a compassionate incident intake
Scam victims may feel fear or shame. A clear intake helps gather better evidence and reduces repeated explanations. Record the timeline, destination, communications, and remaining account access. Separate immediate containment from later investigation.
Support should know how to protect credentials, escalate a recovery request, and preserve evidence without promising outcomes it cannot control. Use a single case reference across teams. Measure time to a useful first action and the quality of updates. A fast automated acknowledgment is not the same as contacting the right payment partner.
Inside the mechanism. Intake should capture the customer’s account of events without requiring the customer to use the correct technical label. Preserve amount, destination, timing, contact method, and any ongoing access risk. Avoid repeated requests for the same painful narrative when evidence can be shared appropriately. Separate immediate containment, payment recovery, and the applicable complaint or error-resolution process so one workstream does not silently delay another.
A concrete example. A customer reporting a scam may be distressed and uncertain about the sequence. Intake must preserve facts and act on time-sensitive recovery opportunities. The case identifies 532 eligible records from a source population of 560. The required workflow completes for 516, but 8 completed records miss the illustrative internal target. Another 16 remain incomplete. Communication evidence covers 511 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.
When the assumption fails. The customer must supply a perfect legal or fraud label before the case is accepted. Capture the original statement, transfer identifiers, timing, and urgent actions without blaming the customer. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.
A customer reporting a scam may be distressed and uncertain about the sequence. Intake must preserve facts and act on time-sensitive recovery opportunities.
- ListenCapture the event without blame
- ContainAddress ongoing access and transfers
- CoordinateUse one case and clear updates
- Acknowledgment
- Confirms receipt of a report
- Useful action
- Changes exposure or starts the right process
Incident intake
Illustrative data; not a real customer record or a prescribed policy.
- Casescam-42
Shared reference
- Accessstill active
Containment concern
- Partner escalationpending
Needs an accountable owner
Each has a different immediate purpose
Separate containment recovery and investigation. Each has a different immediate purpose.
- Failure mode 1avoid
- Promise all funds will return. Recovery may be uncertain.
- Failure mode 2avoid
- Make the customer retell the story to each team. That adds friction and inconsistent records.
- Failure mode 3avoid
- Close after an automated acknowledgment. The substantive work remains.
Chapter connections
This chapter builds on Transaction risk and decision economics. Continue with First-party misuse, merchant abuse, and feedback to follow the next part of the system. Use the glossary for terminology and risk mathematics for formulas and worked calculations.