What sets Authorized Push Payment (APP) fraud apart from other payment crimes is a particular kind of helplessness. Nothing is hacked and no card is stolen. The victim logs into their own account and sends the money themselves, believing it is going to a lawyer, a romantic partner, an investment manager, or even a safe account in their own name. By the time the fraud is discovered the funds are usually long gone, and the controls built to catch unauthorized transactions never fired, because the victim authorized this one.
That is what makes APP fraud, also called authorized push payment fraud, so hard to stop: the payment looks completely legitimate. This article breaks down how APP fraud works, how it differs from traditional unauthorized fraud, the scam types behind it, and the detection signals that can catch it before the money disappears.
The core challenge of modern payments fraud is explained below in more detail. We examine APP fraud in more detail, compare it to traditional types of payment fraud and discuss current types of scams as well as the kinds of detection that are required to identify fraud that looks perfectly legitimate.
The following topics are going to be covered in this article;
- What Is APP Fraud?
- APP vs Unauthorized Fraud
- Common APP Scam Types
- Why Real-Time Rails Make It Worse
- How to Detect APP Fraud
- The Reimbursement Landscape
- How Sanction Scanner Helps
1. What Is APP Fraud?
Authorized Push Payment (APP) fraud occurs when a person is deceived and makes a payment to another account, which is controlled by a fraudster. The victim believes they are paying a genuine person or organization. APP fraud is often referred to as scams where the victim has been duped into paying and therefore it is classed as a ‘push’ payment. This type of fraud is different from card fraud where an unauthorized payment is made by another person and is a ‘pull’ payment. It is difficult to detect and even harder to retrieve from the recipient’s account as the payment was made by the victim themselves.
2. APP vs Unauthorized Fraud
This distinction between APP and unauthorized fraud is more important than it initially appears. In unauthorized fraud cases, criminals are accessing accounts or using payment cards without the owner’s knowledge and then they move the money themselves. In APP scams, the victim is moving the money. They entered the amount, chose the recipient and confirmed the payment. The whole time they thought they were doing something legitimate.
Most of the key differences between the two types of fraud therefore, stem from this simple fact: In cases of unauthorized payment fraud the criminal does something with the account or card of the owner of the account or card without the owner having known or approved it. In cases of APP fraud, the owner of the account or card is used by the fraudster and the owner believes he or she is conducting a legitimate transaction. Consequently, the types of things that fraud detection systems detect (as being anomalous) are transactions that are conducted in a way that is different from what would be normal for that customer. That could be because the login location for the transaction is different from normal, or because the device used to conduct the transaction is different than usual, or because the transaction is conducted at a rate of transactions per time period that is way above the previous ones. But the fraud detection system is unable to detect anything because the customer thinks that the transaction is legitimate.
Recovering payments that have been made as a result of APP fraud is very difficult. Such payments are made as a result of a push payment (i.e. the payment is made by the customer pressing a button to make the payment). Once such a payment has landed in the account of the payee and has been disbursed from that account (e.g. into other accounts), recovering the payment is a matter for the payee to recover from the person to whom he or she made the payment as quickly as possible. This is not a simple reversal of a payment (as is the case with certain other types of payment errors) and depends on a variety of factors, including the speed of the payee in recovering the payment and the rules of the banks involved. Last but not least, the liability for losses resulting from APP fraud differs from jurisdiction to jurisdiction and is being defined in real time while at the same time large amounts of money are being lost by customers in repeated instances of fraud. In contrast, the liability for losses resulting from card fraud has been defined by liability frameworks for decades.
There’s also a reason why APP fraud resists the usual fraud-scoring models that have been put in place for card and account-takeover fraud by banks over the years. These models detect criminals by how they behave differently from genuine customers. Yet in APP fraud, the genuine customer is performing the entire crime under the influence of someone they trust, i.e. the criminal. So the fraud is in the social engineering that occurred before the transaction. Consequently, the fraud is difficult to identify by means of the technical characteristics of a transaction (fingerprint) and banks are effectively trying to recognize a state of mind as opposed to an abnormality in the behavior of a customer’s accounts.
|
|
APP Fraud |
Unauthorized Fraud |
|
Who initiates the payment |
The genuine account holder |
A criminal acting without the owner's knowledge |
|
Detection challenge |
Transaction looks legitimate; behavior-based and beneficiary-side signals required |
Anomaly-based: device, location, and velocity signals typically flag it |
|
Recovery |
Depends on speed and inter-bank cooperation after funds disperse |
Often reversible through chargeback or transaction reversal mechanisms |
|
Liability (UK)
|
Shared 50/50 between sending and receiving firm under mandatory reimbursement |
Generally borne by the card issuer or sending institution |
|
Liability (US)
|
No federal mandate; largely case-by-case or absorbed by the victim |
Regulation E / Reg Z provide stronger statutory consumer protection |
3. Common APP Scam Types
There are several different APP fraud scams depending on different social engineering playbooks which can be all categorized under the APP fraud umbrella, each targeting different types of trust.
Purchase scams: Scams to purchase goods or services that are never received by the buyer. These can be fake websites selling items such as clothing, electronic goods or travel tickets and tickets to events. Also, counterfeit or fraudulent listings on marketplaces by other individuals.
Romance scams: These scams begin with a false romance relationship that takes weeks to months to culminate with the money request (i.e. “emergency”).
Investment and pig-butchering scams: These are actually a combination of the patience required to pull off a romance scam and the legitimacy of making investments. Fraudsters lead the victim through an increasing amount of investments, which show artificial returns until they are completely spent.
Impersonation scams: These are where the APP fraudster pretends to be someone that the victim trusts such as a bank, police, government agency, or even a family member. These scams often involve spoofed numbers and create a sense of urgency in order to circumvent normal skepticism.
Invoice and CEO scams: This form of APP fraud targets businesses rather than individual consumers. Finance employees are tricked into paying what appears to be a genuine invoice from a known executive or supplier, with the funds paid into a bogus account instead.
These categories aren’t fixed and can be even used as part of a longer-running scam. For example, a pig-butchering scam may start off as a romance scam before transitioning into a fake investment opportunity. Similarly, an impersonation scam where the fraudster claims to be the bank’s fraud department can often follow on from a purchase scam and be used to take advantage of the victim who is worried about a recent transaction that they believe to be a fraud. While scam typologies can provide insight into a scammer’s intentions, as well as the messaging they use to defraud their victims, the underlying behavioral and transaction signals (such as urgency, new payee, increasing transaction amounts) are more likely to be consistent across different scam categories than the scam itself.
4. Why Real-Time Rails Make It Worse
Fast payments were supposed to remove a lot of friction from payments. For good and ill they have certainly done that. APP scams have a lot to thank fast payments for, as they are reliant on victims being put under huge pressure to complete a payment in an instant. The victim has no time to verify any of the information being presented to them. All the fast payment schemes instantly credit the payment. This is the payment characteristic that makes real-time payments so valuable to consumers. Unfortunately, it is also the characteristic that fraudsters have been counting on.
But when a real-time payment is settled, it is effectively irrevocable. No waiting around for a batch to be processed, no holding on to the money overnight, and no chance to change your mind. This is the defining feature of real-time payments (and thus of ACH-based fraud in the US) the very same that defined instant systems globally. It is the key product feature that makes real-time payments so valuable to consumers. It is the feature that the fraudster is relying on.
This leaves a tiny window for fraud prevention to take place in real-time rails vs. legacy batch settlement. Previously, banks could afford the luxury of overnight batch settlement. They could simply let a questionable transfer sit until the following morning. This would give the individual time to review the transaction, call the bank, or quietly place a hold on it. Today that extra time is gone, and it's a lot tougher to catch fraud before it's too late. In real-time however, any intervention will be after the payment has been authorized and funds have moved. A few jurisdictions around the world have created a short payment hold period (e.g. 72 hours in the UK, suspension power) but these are not widespread and would only work if the system had flagged the payment suspicious in the first place.
This is not a case against real-time rails, where the benefits to consumers and businesses of instant payments are significant and no one is suggesting a reversion to multi-day settlement. The more realistic view is that fraud prevention costs have just moved earlier in the transaction lifecycle because of faster payments. Previously banks could investigate after the event. Now they need the confidence to intervene in pre-authorisation. This requires that the underlying risk model is accurate enough to act on in real time and with a low enough number of false positives to prevent genuine customers being routinely stopped from sending their own money.
5. How to Detect APP Fraud
Since the transaction appears legitimate in the APP fraud, detection must shift from validating the transaction to analyzing whether the customer is being manipulated by the payment request.
Payer behavioral signals indicative of manipulation typically surface early in the APP payment process. A customer that has never made a large value payment to a new payee prior to the event, combined with other account activity indicators of suspicious behavior in the period leading up to the scam, APP usage behavior that indicates the customer has been coached to complete the payment, and other indicators that the customer has ignored fraud warnings issued by the bank, all indicate early detection opportunities for APP scams.
Beneficiary risk is as important to monitor as the payer’s behavior. Receiver accounts that have been used in other scams, recently opened accounts that receive large incoming payments, or even accounts with profile information that does not match reality are indicators of fraud on the receiving end of the transactions.
Confirmation-of-payee checks help close the well-known gap fraudsters use to rob victims who pay to accounts they trust (i.e. names) but are controlled by others.
Mule detection is the ultimate connection point for APP fraud to be brought to a halt. Proceeds from APP scams very rarely stay in the first account that received them. They are quickly moved to other accounts in the mule layer’s money mule network. Detecting the mule layer is the last chance to stop the victim from being scammed.
None of these signals on their own are reliable as they all generate false positives. Legitimate customers can make unusual payments to new payees for all sorts of reasons. What holds is the combination: A customer with payer-side risk indicators paying a payee with their own risk indicators on an account that does not pass the confirmation-of-payee check. It is these types of multi-signal correlations that are difficult for static rule-based systems to scale, and that by layering these signals together, an institution can dramatically lower its false positives without missing any cases that matter.
6. The Reimbursement Landscape
Across geographies, regulators have taken different approaches to deal with APP fraud. In the UK, on 7 October 2024, the world’s first regulation to mandate reimbursement for APP fraud was introduced. Essentially, payment service providers are required to reimburse all losses (except where the account holder has not followed reasonable security practices), up to £85,000 (≈ $110,000). Reimbursement is shared 50/50 by the account holder’s sending bank and receiving bank. This major change in regulation has already had an impact across the industry, driving change to ensure that both the sender and receiver are doing all they can to detect and prevent loss of funds due to fraud.
In contrast to the UK, there is no federal policy to require the reimbursement of victims of APP fraud in the US. Liability for such fraud is typically left to the victim. When attempted to be prosecuted as a criminal offense, APP fraud is sometimes pursued under the wire fraud statutes after the fact. Otherwise, APP fraud is handled on a case-by-case basis by individual banks, within the parameters of individual bank policy, and there is no federal regulation to require the reimbursement of any portion of losses incurred as a result of APP fraud. As a result, the entire burden of APP detection in the US rests with the financial institutions. There is no shared-cost mechanism to compel the receiving bank(s) to invest in the fraud detection technologies and processes to identify and block APP before it results in a loss. Thus, in the US, APP detection, as opposed to post-loss APP-reimbursement, is the primary focus of financial institutions.
Some effort has been put within the EU’s PSD3 revisions to also impose reimbursement obligations. In Australia, the emerging framework for preventing scams is increasingly characterized by a shared liability approach among banks, telcos and other digital platforms. Importantly, there is a growing recognition across these emerging market frameworks that APP fraud is not solely a problem for the sending banks to solve alone. Other institutions, carriers and even social media platforms where many scams originate are part of the chain of opportunity to prevent such scams and it is slowly but surely being recognized by regulation.
In addition, the first data from the UK offer an insight into the real-world implications of obligatory reimbursement. With receiving firms now liable for half the damages, banks now have a direct financial interest in looking at the accounts into which money flows, not just those from which it flows. This change has led to the detection of mule-accounts and receiving-side fraud being greatly prioritized. Although it is unlikely that other regulators will follow the UK’s model, this incentive that both parties to a transaction share a financial responsibility for detecting it – is likely to influence the development of APP fraud regulation in other jurisdictions.
7. How Sanction Scanner Helps
At the core of APP fraud is a transaction that looks legitimate on the surface yet contains an illicit intention. Transaction monitoring that is based on a set of rules and is limited to tracking transactions is therefore unable to alleviate this blind spot. The real-time transaction monitoring that is combined with behavioral risk scoring by Sanction Scanner FUSION's fraud detection solution is able to detect the relevant payer- and beneficiary-side indicators of manipulated customers versus regular customers. This is before the payment is even settled, as opposed to after the payment has already been lost.
Sources:
[1] Payment Systems Regulator. PS24/7 Faster Payments APP scams reimbursement requirement: Confirming the maximum level of reimbursement. 2024.
[2] UK Government, legislation.gov.uk. The Payment Services (Amendment) Regulations 2024. 2024.
[3] European Parliament. Payment services deal: More protection from online fraud and hidden fees. 2025.
[4] Australian Government, The Treasury. Scams Prevention Framework: Protecting Australians from scams. 2025.
FAQ's Blog Post
Confirmation of payee helps but does not stop APP fraud on its own. It closes the gap where a victim trusts an account name that is actually controlled by someone else, by checking the name against the account before the transfer. It works best combined with payer behavior, beneficiary risk, and mule detection.
The UK APP fraud reimbursement rule, live since 7 October 2024, requires payment firms to reimburse victims up to £85,000, with the cost split 50/50 between the sending and receiving firm. It was the first regulation of its kind and gave receiving banks a direct financial reason to monitor incoming funds.
Recovering money after APP fraud is difficult because the victim authorized the payment, so it is not a simple reversal. Once funds land and disperse through mule accounts, recovery depends on how fast the receiving bank acts and on inter-bank cooperation. Speed is decisive, which is why stopping the next payment matters more.
APP fraud liability varies by jurisdiction. In the UK, losses are shared 50/50 between the sending and receiving firm under mandatory reimbursement, capped at £85,000. In the US there is no federal mandate, so liability is largely case-by-case or absorbed by the victim, which puts the full burden of detection on institutions.
Banks detect APP fraud by combining signals rather than trusting any one. Payer behavior shows manipulation, such as a first-time large payment to a new payee or signs of coaching. Beneficiary risk, confirmation of payee checks, and mule detection cover the receiving side. The correlation across all of them is what holds.
Real-time rails make APP fraud worse because payments settle in seconds and are effectively irrevocable. Fraudsters rely on the pressure to pay instantly, leaving victims no time to verify. Once the money moves there is no overnight window to place a hold, so intervention has to happen before the payment is authorized.
APP fraud is hard to detect because the fraud happens in the social engineering before the payment, not in the transaction itself. Traditional fraud models spot criminals behaving differently from genuine customers, but here the genuine customer performs the whole transaction. The bank is effectively trying to recognize a manipulated state of mind, not an anomaly.
The main APP scam types are purchase scams for goods never delivered, romance scams, investment and pig butchering scams, impersonation scams posing as a bank or authority, and invoice or CEO scams targeting businesses. The scam categories often blend, but the underlying signals of urgency, new payee, and rising amounts stay consistent.
The difference is who moves the money. In unauthorized fraud, a criminal accesses the account or card without the owner's knowledge and transfers the funds. In APP fraud, the genuine account holder enters the amount, picks the recipient, and confirms the payment, believing it is legitimate. That is why anomaly-based detection struggles with APP fraud.
APP fraud, or authorized push payment fraud, happens when someone is deceived into sending a payment to an account controlled by a fraudster, believing it is going to a genuine person or organization. Because the victim authorizes the payment themselves, it looks legitimate, and the controls built to catch unauthorized transactions never fire.
