By NHI Mgmt Group Editorial TeamBased on Chainalysis: “Follow the Fraud: How to Protect Your Customers this Holiday Season” (December 17, 2025)

TL;DR: APP fraud is now a top threat to financial institutions because victims willingly authorise transfers through clean-looking accounts, leaving traditional sender-focused checks blind to recipient risk, according to Chainalysis. The control gap is not better fraud suspicion after the fact, but earlier visibility into who receives the money and whether the destination is already part of a scam network.


At a glance

What this is: Chainalysis argues that APP fraud succeeds because the payment looks legitimate at the sender level while recipient risk remains invisible to standard financial controls.

Why it matters: Banks, RTP networks, and crypto platforms need controls that evaluate where funds are going, not just whether the sender looks authentic, because authorised transfers can still be fraudulent.

By the numbers:

  • Around $442 billion was lost to scammers this year, according to Chainalysis.
  • 67% believe their financial institutions should reimburse them for money lost in a scam even when they personally authorized the transaction, according to Chainalysis.
  • Over $10 billion worth of crypto was lost in 2024 due to reimbursements, operational costs, and more, according to Chainalysis.

Context

APP fraud, or authorised push payment fraud, is a scam pattern in which the victim is manipulated into sending money to an account that appears legitimate. The governance gap is not authentication at the point of transfer, but the lack of effective recipient-risk assessment before funds move.

This matters because many financial controls are still built to evaluate the sender, the device, or the transaction pattern in isolation. In regulated payment environments, that leaves a blind spot for the destination account, the fraud network behind it, and the organisational impact when authorised transfers later turn into disputes.

For identity and fraud teams, the connection is direct: the trust decision is being made on the wrong side of the transaction boundary. A payment can satisfy conventional checks and still be fraudulent if the receiving identity has already been linked to a scam operation.


Key questions

Q: What breaks when fraud controls only assess the sender in APP scams?

A: Sender-only controls miss the core abuse pattern in APP fraud, which is that the victim authorizes a transfer to a recipient that may look legitimate but is actually risky. That means authentication, biometrics, and anomaly detection can all succeed while the payment still goes to a scam destination. Teams need recipient-risk analysis as part of the decision.

Q: Why does authorised payment fraud create such high operational impact for financial institutions?

A: Authorised payment fraud shifts the burden from prevention to recovery. By the time the customer reports the scam, funds are frequently dispersed, so the institution must manage disputes, possible reimbursement, investigation effort, and customer trust damage at the same time. That makes APP fraud a combined fraud, operations, and governance problem.

Q: What are the signs that recipient-risk controls are too weak?

A: A common sign is heavy reliance on customer authentication, device signals, and sender behaviour while destination accounts are barely scored at all. Another indicator is repeated losses to clean-looking accounts that pass verification but later appear in scam or mule patterns. If recipient context is absent from the decision, the control set is incomplete.

Q: Should banks prioritise reimbursement policy or prevention first for APP fraud?

A: Prevention should come first, but reimbursement policy still needs to be defined in parallel. If institutions only debate compensation after losses occur, they miss the real issue, which is whether the payment flow can detect risky recipients before funds move. Mature programmes treat prevention, escalation, and customer remediation as one operating model.


Technical breakdown

Why sender-only fraud checks miss APP risk

APP fraud exploits a control model that assumes transaction legitimacy can be inferred from the payer. Identity checks, behavioural biometrics, and anomaly detection are all useful, but they mostly score the person initiating the transfer. In APP cases, the victim is genuine, the action is intentional, and the fraud resides in the recipient account and the social engineering that drove the payment. That means a bank can clear the sender and still miss the real threat signal. The technical issue is not transaction authentication alone, but where fraud intelligence is applied in the payment flow.

Practical implication: Shift fraud scoring toward recipient intelligence and destination-account risk rather than relying only on sender verification.

How clean-looking accounts conceal scam networks

Fraudsters often route funds through verified or otherwise clean-looking accounts so the payment path appears normal. This creates a false sense of legitimacy because traditional risk engines treat verified identity as low risk, even when the receiving account is part of a larger scam network. In practice, the account can be technically valid, operationally active, and still criminally compromised or controlled. For payment security, the key architectural weakness is treating verified account status as proof of trust instead of one input into a wider network-level risk model.

Practical implication: Correlate verified recipient accounts with network patterns, mule activity, and prior scam exposure before authorising high-risk transfers.

Why reimbursement and disputes become part of the control problem

Once an APP scam is reported, the funds are often already dispersed, which converts fraud detection into loss recovery and customer dispute management. That is why APP fraud is expensive even when the initial transaction was authorised. The operational burden lands across reimbursement decisions, customer support, investigations, and reputational handling, not just fraud losses. This makes APP fraud a governance issue as much as a detection issue, because institutions need to decide where liability, customer protection, and prevention responsibility sit across payment rails and product lines.

Practical implication: Define escalation and reimbursement workflows alongside fraud controls so post-transaction handling is consistent and auditable.


Threat narrative

Attacker objective: Obtain authorised payments into scam-controlled accounts while appearing legitimate to standard fraud controls.

  1. Entry occurs through holiday-season social engineering that pressures the victim into authorising a transfer to a convincing recipient account.
  2. Credential or identity checks confirm the sender but do not expose that the destination is part of a scam network, allowing the payment to clear.
  3. The funds are moved onward before the victim reports the fraud, which leaves limited recovery opportunity and turns the incident into reimbursement and dispute handling.
  4. The attacker objective is to receive authorised funds while avoiding the recipient-side detection that traditional financial controls do not perform.
  • Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
  • CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Recipient-risk blindness is the core control failure in APP fraud. Financial institutions have built mature checks around who sends money, but APP scams exploit the fact that the legitimate customer can still be manipulated into sending funds to a fraudulent destination. The governance gap is not weak authentication alone, but the absence of recipient-side trust decisions. Practitioners should treat destination-account intelligence as a primary fraud control, not a secondary investigation input.

Clean account status is not the same as trustworthy recipient identity. Verified or normal-looking accounts can still sit inside scam infrastructure, mule chains, or recycled fraud operations. That means institutions need network-level context, not just account-level assurance, before release of funds. The practitioner lesson is to stop equating verification with safety when the receiving identity is the actual attack surface.

APP fraud is a payments governance problem, not only a fraud operations problem. The article shows how reimbursement expectations, customer disputes, and operational losses follow the same underlying blind spot. That makes cross-functional ownership essential across fraud, payments, customer protection, and compliance. The field should move toward a control model where recipient-risk evaluation is embedded before settlement, not reconstructed after loss.

From our research library:

What this signals

Recipient-risk blindness: APP fraud shows what happens when a control model assumes the sender is the best source of truth. Financial crime teams need to widen the decision boundary to include the receiving identity, not just the authorising customer.

The practical pressure point is settlement time, because once funds disperse, recovery becomes harder and the institution inherits dispute, reimbursement, and trust-management costs. That is why fraud prevention and payments governance now have to converge around destination intelligence.

For identity and fraud practitioners, the strategic lesson is simple: verification is not the same as trust. Clean-looking accounts can still be part of a scam chain, so recipient risk has to be evaluated as a first-class control signal.


For practitioners

  • Implement recipient-risk scoring before settlement Evaluate destination accounts for scam indicators, mule behaviour, and network exposure before approving authorised transfers, especially for high-urgency consumer payments.
  • Correlate verified accounts with fraud-network signals Treat account verification as one signal only, then combine it with destination reputation, link analysis, and prior scam reports to reduce false trust in clean-looking recipients.
  • Align reimbursement and dispute workflows Define who owns APP fraud escalation, evidence capture, and reimbursement decisions so customer-impact handling is consistent when funds have already moved.

Key takeaways

  • APP fraud succeeds because the customer authorises the transfer, which leaves conventional sender-focused controls blind to the real threat.
  • The article points to substantial financial and operational fallout, including major scam losses, reimbursement pressure, and reputational damage for financial institutions and crypto platforms.
  • Institutions need recipient-risk assessment before funds move, not just better investigation after the loss has already occurred.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and NIST SP 800-63 set the technical controls, while GDPR defines the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsRecipient-risk evaluation is an authorization problem in the payment decision path.
DE.AE-02 — Anomalous Events are DetectedAPP fraud relies on clean-looking transactions that evade ordinary anomaly cues.
RS.CO-02 — Incidents are ReportedAPP fraud losses often surface after settlement and need clear escalation paths.
Recommendation — Apply PR.AA-05 thinking to validate whether the receiving identity should be trusted before release. Tune anomaly detection to include destination-account reputation and scam-network context. Define reporting and escalation paths for scam transfers so response is consistent across channels.
NIST SP 800-63SP 800-63B — Authentication and LifecycleThe article shows that authenticating the sender does not prove the recipient is trustworthy.
Recommendation — Use SP 800-63B to separate authentication assurance from recipient trust decisions.
GDPRArt.32 — Security of ProcessingFraud controls around payment data and customer identity require proportionate security of processing.
Recommendation — Assess whether payment workflows provide security of processing proportional to the fraud risk.

Key terms

  • Authorised Push Payment Fraud: A payment scam in which the victim is persuaded to authorise the transfer themselves. The transfer is technically authorised, but the decision is corrupted by deception, which makes liability, evidence, and prevention harder to separate from standard transaction controls.
  • Recipient Risk: The likelihood that the account receiving a payment is linked to fraud, mule activity, or a scam network. In APP fraud, recipient risk matters as much as sender risk because a legitimate sender can still move funds into a hostile destination.
  • Payment Settlement: The point at which a payment becomes final and funds move beyond easy recall. Once settlement occurs, detection often becomes recovery and dispute management rather than prevention, which is why pre-settlement controls are so important in APP fraud.
  • Fraud Network Detection: Fraud network detection is the process of identifying connected suspicious users rather than reviewing each account in isolation. It looks for shared signals such as identity reuse, device overlap, behavioural similarity, and linked infrastructure. This helps teams stop serial fraud that would otherwise appear as separate incidents.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It helps security, IAM, and fraud practitioners connect identity governance to the controls that matter across modern programmes.
NHIMG Editorial Note
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org