What do banks get wrong about defending against APP scams and social engineering?

Why banks keep underestimating APP scams

APP scams are often mishandled because institutions split the problem across fraud, cyber, and customer support teams, then expect each team’s partial controls to add up. That approach misses the way social engineering turns legitimate payment rails into an abuse path: the customer appears authorised, the device may look normal, and the transaction can arrive with no obvious malware signal. For that reason, the most useful benchmark is whether the bank can detect manipulation before payment execution, not whether it can explain the scam after settlement. See the CISA cyber threat advisories for current social engineering and impersonation patterns that repeatedly show up in real-world abuse. In practice, many banks discover the weakness only after a customer complaint proves the controls were tuned to confirm intent too late.

How APP scam defence works when it is actually layered

Defence has to treat APP fraud as a decision-quality problem, not just a messaging problem. The bank needs to assess whether the payment request, the user behaviour, the channel context, and the destination account collectively make sense. If a transfer is unusual for the customer, inconsistent with their history, or preceded by signs of coercion or remote access, the bank should be able to slow, step up, or interrupt the transaction before money leaves the account.

A practical model usually combines four checks:

• account and device signals that show whether the session fits the customer’s normal pattern
• beneficiary and network checks that identify mule accounts, rapid reuse, or first-time payee risk
• intent verification that tests whether the customer understands the payment purpose and recipient
• intervention workflows that let staff or automation act while the payment is still reversible

This is where banks often over-rely on static warnings. A warning banner can help, but it does not stop a convinced customer from approving a transfer under pressure. The control objective is to combine contextual detection with intervention that is strong enough to matter but fast enough to keep pace with the payment journey. Banks that only review after the transaction are optimising for recovery, not prevention, and recovery is inherently less reliable. Guidance from frameworks such as NIST SP 800-63 Digital Identity Guidelines is useful here because payment defence depends on how confidently the institution can bind a user to a transaction decision, not just to a login.

Where this guidance breaks down is in environments with delayed analytics, weak cross-channel visibility, or manual escalation paths that cannot act before settlement.

Where banks overcorrect, and where the edge cases sit

Tighter intervention often improves scam prevention but increases customer friction, false positives, and the risk of blocking legitimate urgent payments, so banks have to balance prevention against service disruption.

One common edge case is an otherwise legitimate customer who is being coached in real time by an attacker. In that situation, the customer may pass every traditional authentication check while still being under manipulation. Another is a trusted payee that has become a compromise point, where the bank sees nothing unusual in the recipient but the payment is still unsafe. A third is the “clean device, dirty context” problem, where the handset or browser looks normal but the social engineering occurred off-channel, through messaging, email, or voice. Industry consensus is still evolving on how much friction should be added at each point in the journey, but there is broad agreement that one-time warnings are not enough on their own.

For banks, the important question is not whether a control can identify fraud in general, but whether it can discriminate urgent genuine intent from pressured or induced intent well enough to intervene without creating a blanket delay for all high-value transfers. That distinction is what separates an effective APP scam control from a generic fraud screen.

Practitioner Guidance

What to prioritise: Treat APP scam defence as a payment-authorisation integrity problem, not a customer-awareness campaign. The first priority is to find the point in the journey where the bank can still intervene before funds are released.

What to verify: Confirm that fraud, payments, digital channels, and call-centre teams are using the same escalation triggers and the same view of risk. If each function acts on different signals, the attacker only needs the weakest handoff.

Decision rule: If the customer’s intent cannot be reasonably corroborated from context, beneficiary history, and session behaviour, the transaction should be treated as higher risk rather than merely unusual. In practice, the most dangerous failures happen when teams assume authentication alone proves consent.

Practitioner takeaway: Banks usually lose APP cases when they optimise for warning the customer instead of proving the payment is genuinely safe to authorise; the control goal is to interrupt manipulation, not merely document it after the transfer.

Related resources from NHI Mgmt Group

• What do teams get wrong about training users against social engineering?
• What do security teams get wrong about help desk social engineering?
• What do organisations get wrong about social engineering defence?
• What do organisations get wrong about defending against data poisoning?