Home / Insights / Banks & ADIs
Banks & ADIs

APP Scams & Authorised Push Payment Fraud in Australian Banking

A prevention and response playbook: why scams are now the dominant loss vector, and how a bank intervenes across the whole payment journey.

By Financial Crime Advisory · 30 July 2026 · 12 min read

For most Australian banks, the fraud problem has quietly inverted. The classic threat — a criminal stealing credentials and moving money without the customer's knowledge — is now the smaller share of the loss. The larger share comes from customers being manipulated into sending money themselves. That is the world of authorised push payment (APP) fraud, and it breaks most of the controls a bank was built to run.

In this guide

Why scams are now the dominant fraud-loss vector

Two structural shifts put scams at the centre of bank fraud loss. The first is the move to real-time payment rails. Australia's New Payments Platform, and the Osko and PayTo services built on it, clear and settle in seconds. That is excellent for customers and merchants — and equally excellent for criminals, because it removes the batch-processing delay that once gave a bank hours to spot and reverse a suspicious transfer. When money is irrevocable within seconds, the point of control has to move upstream, to before the payment leaves.

The second shift is that fraudsters have followed the path of least resistance. Banks spent a decade hardening authentication — chip and PIN, tokenisation, device binding, strong customer authentication. So attackers stopped trying to beat authentication and started defeating the human instead. Rather than steal a credential, they persuade the account holder to authenticate the payment personally. From the bank's systems, that transaction looks legitimate: right device, right credentials, right customer. The deception happened in a phone call, a text message or a fake investment portal the bank never saw.

The result is a loss vector that is growing in both frequency and average value, that evades credential-based defences by design, and that carries reputational and — increasingly — regulatory weight the moment a customer is left carrying a loss they were talked into.

Authorised push payment fraud vs unauthorised fraud

The distinction sounds academic. It is the single most important idea in modern scam prevention, because it dictates which controls can possibly work.

Unauthorised fraud is when the customer did not consent: a stolen card, an account takeover, a hijacked session. The customer is a victim of access. Detection here is about spotting the imposter — anomalous device, impossible travel, credential-stuffing patterns, a session that does not behave like the real customer.

Authorised push payment fraud is when the genuine customer consents, but only because they have been deceived. They log in themselves, pass every authentication step, and press send. There is no imposter to detect. The signal is not "is this the right person?" — it is "is this the right person doing something that is wrong for them?" That is a fundamentally harder question, and it is why a bank cannot simply extend its unauthorised-fraud model and expect it to catch scams.

The core implication: if your fraud strategy is built around catching an imposter, it is structurally blind to APP fraud. Scam detection has to reason about the customer's own behaviour, the destination of the payment, and the context around it — not just the authenticity of the login.

The main scam typologies

Scams are not one problem. They are a family of social-engineering plays, each with a different emotional lever and a different detectable footprint. A prevention program that treats them as a single category will miss most of them.

Investment scams

The highest average-value category. Victims are led to fake trading platforms, cryptocurrency schemes or "exclusive" opportunities, often over weeks, and make a series of escalating transfers. The footprint is a customer, frequently older or newly interested in investing, making unusually large payments to a newly added payee, sometimes to a digital-currency exchange or a mule account, often after a period of atypical account behaviour.

Romance scams

A relationship is cultivated over time, then monetised through requests for help, emergencies or "investment" the victim is coached into. These are slow-burn and emotionally entrenched, which makes intervention delicate — the customer will often defend the payment and resent the friction.

Invoice and business email compromise (payment redirection)

A criminal intercepts or spoofs legitimate invoicing and changes the payee's bank details. The business believes it is paying a genuine supplier. This is where confirmation of payee earns its keep: the name on the invoice will not match the name on the criminal's account.

Remote-access scams

The victim is persuaded to install remote-access software so a "technician" or "bank officer" can help. The criminal then either operates the account directly or walks the customer through a payment. The detectable signal is often the presence of remote-access tooling on the session and a payment made under it.

Bank and government impersonation

The customer is told their account is compromised and they must "move funds to a safe account" — which belongs to the criminal. Spoofed caller ID and lookalike SMS threads make it convincing. The irony is sharp: the customer is fleeing a fraud that does not exist straight into a real one.

Purchase and marketplace scams

Goods or services that never arrive — concert tickets, puppies, vehicles, rental bonds. Individually lower value, high in volume, and a common entry point for younger customers.

The payment-fraud lifecycle — and every point a bank can intervene

The most useful way to organise a scam-prevention program is to map the lifecycle of the money and place a control at every stage. A scam is not one event; it is a chain, and a bank sits on both ends of it — as the sending institution and, for the mule, as the receiving one.

  1. Customer onboarding. Strong KYC and identity controls at account opening reduce the supply of mule accounts that receive scam proceeds. This is the cheapest place to stop the chain, because a receiving account that never exists cannot be paid.
  2. Receiving-account (mule) detection. Behavioural and network monitoring on inbound accounts catches the destination side — accounts that suddenly receive and rapidly forward funds, or that link to known mule networks.
  3. Real-time payment interdiction and holds. On the sending side, high-risk payments can be scored in-flight and subjected to a short hold, a step-up check, or a block, before the money settles.
  4. Confirmation of payee / name checking. Before the customer confirms, the bank checks whether the payee name matches the destination account and surfaces a mismatch.
  5. Dynamic warnings and friction. Contextual, scam-specific warnings and deliberate friction — tuned to the payment's risk — give the customer a reason to pause at the exact moment it matters.
  6. Post-event recovery. Rapid detection, recall requests, cross-bank coordination and freezing of downstream accounts to recover what can still be reached.
Design principle: the value of a control rises the earlier it sits in this chain. A prevented onboarding of a mule account, or a payment stopped before settlement, is worth far more than a recall attempted after the funds have been layered and cashed out.

Mule account detection signals

Scam money has to land somewhere, and it almost always lands in a mule account — an account, sometimes opened for the purpose and sometimes belonging to a coerced or complicit customer, used to receive and move on the proceeds. Detecting mules is one of the highest-leverage moves a bank can make, because it attacks the economics of every scam typology at once.

No single signal is decisive; the discipline is scoring them together and escalating on the pattern:

The strongest programs treat mule detection as a network problem, not an account problem. Looking at one account in isolation, a mule can appear ordinary; looking at the graph of accounts, devices and money flows around it, the structure becomes visible.

The controls that matter

The table below maps the core scam controls to what each one actually stops, where it sits in the payment journey, and the maturity a serious program should aim for. No single row is sufficient; the protection comes from the layering.

ControlWhat it stopsWhere it sitsMaturity to aim for
KYC & onboarding controlsSupply of mule and disposable receiving accountsAccount openingRisk-based identity with reuse and synthetic-identity detection
Confirmation of payeeInvoice redirection, impersonation, misdirected paymentsPre-confirmation, sending sideName-match on all fast payments, clear mismatch messaging
Real-time transaction scoringHigh-risk payments across all typologiesIn-flight, before settlementBehavioural, payee-aware model scoring every payment
Risk-based holds & step-upInvestment, impersonation, remote-access paymentsAt the moment of paymentShort, proportionate holds with human review on the riskiest
Dynamic warnings & frictionSocial-engineered payments the customer can still stopPayment screen / channelScam-specific, contextual warnings — not generic pop-ups
Mule / receiving-account detectionThe destination side of every scamInbound monitoringNetwork-based detection with rapid freeze and reporting
Information sharingRepeat mules and cross-bank scam flowsEcosystem-wideStructured, timely sharing of scam and mule intelligence
Recall & recovery workflowResidual loss after a payment is madePost-eventFast, coordinated recall and downstream account freezing

How to build the detection model

A scam-detection model is not a bigger version of a card-fraud model. It answers a different question, so it needs a different design.

Model on the customer's own baseline

Because the customer is genuinely authenticated, the signal lives in the deviation from their own normal behaviour: a first-ever payment of this size, a newly added payee, a payment shortly after a login from a new context, a departure from established payee and timing patterns. The model has to know what normal looks like for each customer, not just for the portfolio.

Make the model payee-aware and network-aware

The destination is at least as informative as the source. Payments to newly created accounts, to accounts with mule-like behaviour, to digital-currency exchanges, or to beneficiaries flagged through information sharing should all lift the score. Bringing receiving-side intelligence into the sending-side decision is where much of the modern edge sits.

Layer, do not stack thresholds

Effective programs combine rules that encode known typologies, behavioural analytics that catch the unusual, and network analysis that exposes structure — then govern them together. Rules give explainability and speed; analytics give coverage of the novel; network analysis catches what neither sees alone.

Design for a decision, not an alert

Because the rail is real-time, the model output has to drive an action inside the payment flow — proceed, warn, add friction, step up, hold, or block — within the settlement window. A score that only produces an after-the-fact alert has already lost the money.

A caution on friction: every warning and hold has a cost in customer experience and in false positives that punish legitimate payments. The goal is not maximum friction; it is proportionate friction, concentrated on the payments most likely to be scams and lightened everywhere else. Tuning that balance is continuous work, not a one-time setting.

Building the operating model around the technology

Detection is necessary and nowhere near sufficient. A scam stopped by a model still requires a human process to handle the hold, talk to the customer, and act on the mule at the other end. The operating model is where programs succeed or fail.

The Australian direction on scam liability and the Scam-Safe Accord

The policy environment in Australia has moved decisively toward the position that scams are a shared responsibility, not solely the customer's mistake. The Scam-Safe Accord is the banking industry's coordinated commitment to lift anti-scam defences — including account-name checking, stronger warnings and friction at the point of payment, better information sharing, and investment in detection and customer protection. Alongside it sits a broader public-policy direction toward obligations across the ecosystem — banks, telecommunications providers and digital platforms — to prevent, detect and disrupt scams, with consequences where reasonable steps are not taken.

The practical message for a bank is straightforward. The expectation is now that you act across the entire payment journey and can demonstrate it. A defensible program is one that has controls at every stage of the lifecycle, evidence that they are tuned and effective, and a response capability that engages before the money is gone. Waiting to reimburse after the fact is neither good economics nor, increasingly, an adequate answer to the regulator or the public.

On specifics: the exact scope, thresholds and obligations in this area continue to evolve. Treat the direction of travel as settled — coordinated, ecosystem-wide, act-across-the-journey — and confirm the current detail against the primary sources before you rely on any particular requirement.

The metrics that matter

Scam programs are often measured by the wrong number. Gross scam loss is a weak headline metric because it is driven as much by the external threat environment as by the quality of the bank's defences. Better programs watch a richer set, described here qualitatively rather than with invented targets:

Read together, these tell you whether a program is genuinely moving the money earlier in the chain, or simply reimbursing more efficiently after the loss. The whole thrust of modern scam prevention — and of the direction Australian policy is taking — is to push the point of control upstream: onto onboarding, mule detection, real-time interdiction and confirmation of payee, and away from the recall that happens once the money is already gone.

Common questions

Questions we get asked

What is an APP scam and how is it different from card fraud?

An authorised push payment (APP) scam is one where the genuine customer is deceived into authorising a payment to a criminal — so the transaction carries valid credentials and passes authentication. Card fraud and account takeover are usually unauthorised: the customer did not consent. That difference matters because most legacy fraud controls are built to detect unauthorised access, not a real customer being manipulated into paying, which is why scams now dominate loss and demand a different detection and response model.

What is confirmation of payee and why does it help?

Confirmation of payee — also called account-name checking — checks whether the account name a customer types matches the name registered on the destination account before the payment is sent. It disrupts scams that rely on the customer believing they are paying a trusted party, particularly invoice redirection and impersonation, by surfacing a name mismatch at the moment of payment so the customer can stop and reconsider.

How do banks detect mule accounts?

Mule accounts are detected by combining onboarding signals, behavioural analytics and network analysis on the receiving side. Indicators include accounts that sit dormant then suddenly receive and rapidly forward funds, mismatches between stated purpose and actual flow, shared devices or identity attributes across supposedly unrelated accounts, and inbound credits that fan out to many onward beneficiaries. No single signal is conclusive; effective detection scores them together and layers human review.

What is the Scam-Safe Accord?

The Scam-Safe Accord is an industry commitment by Australian banks to lift anti-scam defences in a coordinated way — including account-name checking, better warnings and friction at the point of payment, stronger information sharing, and investment in detection and customer protection. Alongside broader policy direction on scam prevention and liability, it signals an expectation that banks act across the whole payment journey rather than treating scams as solely the customer's problem.

Can a bank stop a real-time payment once it has been sent?

Real-time rails settle in seconds, so the practical window to intervene is before or at the moment of payment — through holds, step-up verification, dynamic warnings and interdiction on high-risk transactions. Once funds have landed and been forwarded from a mule account, recovery becomes much harder. That is why leading programs push detection upstream and use short, risk-based holds and receiving-side controls rather than relying on after-the-fact clawback.

FCA
Financial Crime Advisory
Australia's fraud, AML & loss-prevention specialists

Scams outrunning your controls?

Whether you're building real-time interdiction, tuning mule detection or standing up confirmation of payee, we'll tell you where you stand and what to do next.