Category: Fraud Typologies

Authorized Push Payment (APP) Fraud

Also known as: APP Fraud, Authorised Push Payment Fraud, Push Payment Fraud, APP Scams

Simply put

Authorized Push Payment (APP) fraud happens when a criminal tricks a victim into sending money themselves, often by posing as a genuine person or organization the victim believes they should pay. Because the victim personally authorizes and initiates the transfer, this type of fraud relies on manipulation and social engineering rather than on stealing account credentials or card data. It is commonly associated with real-time or fast payment systems where funds move quickly.

Formal definition

APP fraud is a form of authorized fraud in which a legitimate account holder is deceived or manipulated—typically through social engineering—into initiating a push payment to an account controlled by a fraudster, often while believing they are paying a genuine payee. Unlike account takeover or unauthorized transactions, the payment is initiated and authorized by the genuine payer, which complicates detection and attribution because the transaction may appear valid on standard authentication and authorization checks. APP fraud is particularly prominent in fast or real-time payment systems, where the speed and finality of settlement can reduce opportunities to recall or reverse funds. It is distinct from card-not-present fraud and credential theft; the fraud vector is coercion of the payer rather than compromise of authentication factors. Note that liability, reimbursement, and consumer-protection obligations for APP fraud are governed by regional regulatory regimes and scheme rules, which vary by jurisdiction and change over time; readers should confirm applicable rules against current published requirements.

Why it matters

APP fraud is significant because it exploits the genuine account holder rather than any weakness in authentication or credential security. When a victim is manipulated into initiating and authorizing a payment themselves, the transaction typically passes standard authentication and authorization checks because, from the payment system's perspective, the legitimate payer has approved it. This makes APP fraud harder to detect and attribute than account takeover or credential theft, where an unauthorized party is acting on the account.

The risk is heightened in fast or real-time payment systems, where the speed and finality of settlement can reduce the opportunities to recall, hold, or reverse funds once a payment is sent. Because the fraud vector is social engineering—coercion or deception of the payer—rather than a technical compromise, controls that focus solely on authentication factors may offer limited protection against it.

Liability, reimbursement, and consumer-protection obligations for APP fraud are governed by regional regulatory regimes and scheme rules, which vary by jurisdiction and change over time. Institutions should confirm the applicable rules against current published requirements rather than assuming a uniform standard applies across markets.

Who it's relevant to

Fraud Analysts and Risk Teams

APP fraud is difficult to detect using controls oriented toward unauthorized access, because the genuine account holder authorizes the payment. Analysts may need behavioral, contextual, and payee-related signals to identify potentially manipulated transactions, while accepting the false-positive and false-negative trade-offs inherent in such detection.

Payment Processors and Operators of Fast Payment Systems

Because APP fraud is especially prominent in real-time payment environments where settlement is quick and often final, operators and processors face the challenge of balancing payment speed with opportunities to hold, verify, or recall suspicious transfers.

Compliance and Regulatory Teams

Liability, reimbursement, and consumer-protection obligations for APP fraud are set by regional regulatory regimes and scheme rules that vary by jurisdiction and change over time. Compliance teams should confirm applicable obligations against current published requirements rather than assuming fixed rules.

Consumer-Facing Financial Institutions

Institutions serving payers are positioned to educate customers about social engineering tactics, since the fraud relies on deceiving the genuine payer rather than compromising credentials. Awareness efforts may help reduce susceptibility, though they cannot eliminate the risk of manipulation.

Inside APP Fraud

Authorized Push Payment (APP)

A credit transfer that the legitimate account holder authorizes and initiates, typically via a real-time or account-to-account payment rail rather than a card network. In APP fraud, the payer is deceived into authorizing the payment themselves, which distinguishes it from unauthorized transactions where the account holder did not consent.

Social engineering vector

The deception mechanism through which a fraudster manipulates the victim into sending funds, such as impersonation of a trusted party, invoice or business email compromise, purchase scams, or romance and investment scams. The fraud exploits the payer's decision-making rather than a technical control failure.

Payer authorization

The defining element that separates APP fraud from account takeover and unauthorized card fraud. Because the genuine customer authenticates and approves the transfer, controls that verify identity or authorization at the point of payment may not flag the transaction as anomalous.

Beneficiary or mule account

The receiving account controlled by or on behalf of the fraudster, into which authorized funds are pushed and often rapidly moved onward. Detection frequently depends on receiving-side monitoring and information sharing between sending and receiving institutions.

Reimbursement and liability rules

The framework governing whether and how a defrauded payer is made whole. These rules are set by regional regulators, payment scheme operators, and network rules; they vary by jurisdiction and change over time, so applicability should be confirmed against the current governing rules rather than assumed.

Relationship to other fraud types

APP fraud is distinct from card-not-present fraud, account takeover (where credentials are compromised without the account holder's consent), and first-party or friendly fraud (where the account holder disputes a legitimate payment). Precise classification affects investigation, reporting, and any reimbursement determination.

Common questions

Answers to the questions practitioners most commonly ask about APP Fraud.

Is APP fraud the same as unauthorized card fraud or account takeover?

No. In authorized push payment (APP) fraud, the legitimate account holder is deceived into authorizing and initiating a payment themselves, typically a bank-to-bank credit transfer, to an account controlled by the fraudster. This differs from unauthorized card fraud or account takeover, where a criminal initiates a transaction or gains control of an account without the genuine customer's knowing authorization. Because the payment is technically authorized by the victim, APP fraud is not addressed by controls designed around unauthorized transaction detection, and it falls outside the cardholder data protection model of PCI DSS, which governs the storage, processing, and transmission of payment card data rather than push credit transfers.

Does 3-D Secure or strong customer authentication stop APP fraud?

Not on its own. 3-D Secure and strong customer authentication are intended to confirm that the person authorizing a payment is the legitimate account holder. In APP fraud, the legitimate account holder is the person authorizing the payment, so successfully passing an authentication challenge does not indicate the payment is genuine. These controls address impersonation and unauthorized use, not social engineering that persuades a genuine customer to send funds voluntarily. They may reduce certain related risks but should not be treated as a defense against APP fraud specifically. Also note that 3-D Secure is governed by the PCI 3DS standard and card-network rules, which are separate from the payment-scheme rules that may apply to push credit transfers.

What data signals can be used to help detect APP fraud during a transfer?

Detection approaches may include behavioral analytics on the payer's activity, deviations from established payee and payment patterns, new-payee risk indicators, transaction velocity and value anomalies, and payee account verification services where available. These signals are intended to flag payments that may result from deception, but they carry false-positive and false-negative trade-offs: legitimate but unusual payments may be flagged, while well-established fraudulent payee relationships may not be. No single signal is definitive, and effectiveness depends on data quality, coverage, and tuning.

How should a firm handle a customer who insists on completing a payment that risk indicators flag as suspicious?

Common practices include presenting targeted warnings, introducing friction such as confirmation steps or cooling-off delays for higher-risk payments, and offering channels for the customer to pause and verify the payee independently. These measures are intended to give a potentially deceived customer an opportunity to reconsider without blocking legitimate payments outright. The appropriate balance depends on applicable regulatory obligations, scheme rules, and firm risk appetite, which vary by region and change over time; confirm current requirements against the governing authority rather than assuming a fixed approach.

What role does payee account verification play in an APP fraud control set?

Payee account verification, such as confirming that the name supplied by the payer matches the name registered to the destination account, is intended to help the payer detect when they are about to send funds to an unexpected or mismatched recipient. It may reduce certain misdirection and impersonation scenarios, but it does not confirm the payee's legitimacy or the payer's intent, and its availability and format depend on the payment scheme and region. It is one input among several and should be combined with other detection and customer-warning measures rather than relied on alone.

How do liability and reimbursement outcomes for APP fraud get determined?

Liability, reimbursement, and reporting obligations for APP fraud are governed by applicable regulations, payment-scheme rules, and regional frameworks rather than by PCI DSS, which addresses cardholder data protection. These rules differ by jurisdiction and payment type and change over time, so allocation of loss between payer, payer's institution, and receiving institution should be determined against the current governing rules for the relevant region and scheme rather than assumed.

Common misconceptions

APP fraud is a form of unauthorized transaction, so standard fraud controls and chargeback rights apply.

In APP fraud the genuine account holder authorizes the payment, so it is not an unauthorized transaction. Account-to-account credit transfers generally do not carry the card-network chargeback mechanisms associated with card payments, and recourse depends on separate reimbursement rules that vary by region and scheme.

Strong customer authentication or multi-factor authentication prevents APP fraud.

Authentication controls confirm that the legitimate customer is initiating the payment, which is precisely what happens in APP fraud. Because the victim is deceived into authorizing a genuine session, authentication may pass successfully; these controls are intended to address different risks and may not detect a socially engineered transfer.

Encryption or tokenization of payment data mitigates APP fraud.

APP fraud does not typically involve compromise of stored or transmitted account data, so data-protection techniques such as encryption, tokenization, or truncation do not address it. The relevant controls focus on transaction risk scoring, payee verification, victim intervention, and receiving-side monitoring.

Best practices

Implement behavioral and transaction risk scoring that considers payee novelty, payment velocity, and deviations from the customer's normal patterns, while accounting for false-positive and false-negative trade-offs that can delay legitimate transfers.

Deploy payee or beneficiary verification mechanisms (for example, confirmation-of-payee style name-matching where available in the region) to help the payer detect misdirected or impersonation-driven transfers before authorizing.

Introduce contextual warnings, transaction friction, or cooling-off steps for higher-risk transfers, recognizing these measures are intended to prompt reconsideration and may reduce, but not eliminate, socially engineered payments.

Strengthen receiving-side controls and mule-account detection, and participate in inter-institution information sharing where permitted, since sending-side controls alone may not identify a socially engineered but genuinely authorized payment.

Confirm the applicable reimbursement, liability, and reporting obligations against the current rules of the relevant regulator and payment scheme, as these vary by jurisdiction and change over time.

Classify and record suspected APP fraud distinctly from account takeover, card-not-present fraud, and first-party or friendly fraud, so investigation, metrics, and any reimbursement decisions reflect the correct fraud type.