Skip to content
All articles

Your customer just sent their savings to a criminal. How to catch a scam payment before the money leaves.

Charles Archibong

, Co-founder

In an authorised push payment scam, your real customer is tricked into sending their own money to a criminal. Identity checks pass, because nothing is fake. This is what the sending firm can still see at the moment of payment, and how to hold or question it in time.

A customer's phone showing a large transfer to a new recipient, paused with a question before the money leaves the account.

Key takeaways

  • In an APP scam the customer is genuine and the payment is authorised, so identity and login checks pass.
  • The payment still looks unusual: a new recipient, an amount out of character, a rush of transfers, a new device.
  • The useful moment is before the money leaves. After that, recovery depends on the receiving side.
  • Toden returns allow, review or block on each payment. Holding the funds and speaking to the customer are your job.
  • Reimbursement and delay rules differ by country. The UK rules cited here are an example, not your law.

Picture a customer you have known for four years. Salary in on the 25th, rent and school fees out, a few small transfers to the same five people. Nothing about the account has ever needed a second look.

One Thursday afternoon she logs in on her own phone, with her own PIN. She adds a recipient she has never paid. She sends most of her balance. Twenty minutes later she sends the rest, in two more transfers.

Every control you own said yes. It was her face, her device and her instruction. What you could not see was the caller on the other line, calm and helpful, explaining that her account had been compromised and the money had to be moved somewhere safe.

That is an authorised push payment scam, usually shortened to APP scam. The customer is real. The payment is authorised. The money is gone anyway. The account it lands in is usually a money mule account, which we covered separately. This article is about the other end: the customer who sends, and the decision you make in the seconds before the payment goes.

Why identity checks cannot stop it

Most fraud controls ask one question: is this really the customer? In an APP scam the honest answer is yes.

  • Onboarding checks pass. The customer was verified properly, perhaps years ago.

  • Login checks pass. The right person signed in, often on their usual device.

  • A step-up passes too. Ask for a selfie or a one-time code and the customer will give it, because they believe the payment is urgent and legitimate. A scammer on the phone will even coach them through it.

So the question has to change. Not who is making this payment, but whether this payment makes sense for this customer.

What it costs, and who pays

The clearest published figures are British. UK Finance reported (opens in a new tab) £450.7 million lost to APP fraud in 2024 across just under 186,000 cases, with £267.1 million (around 59%) reimbursed to victims by banks. It also reported that 70% of APP cases started online and 16% through telecommunications networks, and that investment scams alone accounted for £144.4 million. We have not found a figure of the same quality for African markets, so we will not offer one.

In the UK the cost no longer stops with the victim. Under the Payment Systems Regulator's reimbursement protections (opens in a new tab), which apply to UK bank transfers over Faster Payments or CHAPS made on or after 7 October 2024, victims can claim up to £85,000 and can expect to be reimbursed within five business days. Firms may apply an optional £100 excess, and a customer who was complicit or grossly negligent is not covered. The regulator says sending and receiving firms split the cost 50:50 (opens in a new tab).

Your country may have no such rule, a different one, or one on the way. Even where nothing forces you to repay, the customer who lost their savings through your app rarely stays a customer, and rarely stays quiet.

What you can see at the moment of payment

You cannot hear the phone call. You can see what it makes the customer do. None of these proves a scam alone, and together they are hard to explain any other way.

  • A first payment to a new recipient. Especially one added minutes earlier.

  • An amount out of character. Far above what this customer normally sends, or most of the balance at once.

  • A rush of transfers. Several payments in a short window, sometimes split to stay under a limit.

  • A new device or location. Less common than in account takeover, but scammers do talk victims into installing an app or using another phone.

  • Changes just before the money moves. A raised limit, a new beneficiary, a password reset.

  • A recipient you have seen before. The same account receiving first payments from several of your customers is a strong sign.

How to hold or question the payment

  1. Score before you release. Send the payment for a decision while it is still pending, not in a batch that night. A decision that arrives after settlement is a report.

  2. Give review a real meaning. Decide in advance what your app does on a review: pause the transfer, show a warning written for this exact pattern, or route it to a person.

  3. Ask a question a scammer has not rehearsed. "Did someone ask you to move this money?" works better than "Are you sure?". A generic warning is clicked through.

  4. Check what the law lets you hold. In the UK, the Payment Services (Amendment) Regulations 2024 (opens in a new tab) allow a payer's provider to delay a sterling payment within the UK, no later than the end of the fourth business day after receipt, where it has reasonable grounds to suspect fraud or dishonesty by someone other than the payer. It must tell the customer about the delay and why. Other countries set different limits, and some set none.

  5. Record what happened. When a customer later reports a scam, mark that payment as fraud. It is the only way to learn whether your rules would have caught it.

What Toden does, and what it does not

Toden's part is the decision.

  • You send each payment to the transactions API with the customer, the recipient, the amount and, if you have them, the device and IP address. The response carries allow, review or block, with a reason in plain language, on the same request.

  • Built-in rules cover a first sizeable payment to a recipient the customer has never paid, an amount that deviates sharply from that customer's own baseline, too many payments or too much value in a rolling window, and your own lists of high-risk and blocked recipients.

  • A device reference on payments and logins builds new-device evidence. Logins, password resets, device changes and new beneficiaries can be sent as activities and scored by the same engine.

  • A review opens an alert that lists the rules behind it, and your team can take it into an investigation. Our guide to tuning monitoring rules covers thresholds, and you can test a rule change against recent activity before it goes live.

  • When a scam is confirmed, you can record the outcome against the transaction so rule performance is measured on real cases.

Now the limits, which matter more.

  • Toden returns a decision. It does not hold, reverse or recover funds. Pausing the payment is something your system does with the answer.

  • It does not contact the customer. The warning, the call and the wording are yours.

  • It does not know what the customer was told. Nothing in a payment shows the phone call behind it.

  • A step-up confirms who is paying, not why. It helps against account takeover and does little here, because the genuine customer passes.

  • Recipient screening checks the name against sanctions, PEP and adverse media lists. A scammer's mule is rarely on any of them.

  • It sees your customers only. It cannot tell you that the recipient account was reported at another institution an hour ago.

  • The rules need data. Each recipient needs a stable reference across payments, or "never paid before" means nothing.

  • Review will sometimes stop a genuine payment. Where you set that threshold is your decision and your trade-off.

What you may hold, for how long, what you must tell the customer and who repays a loss all differ by country. We have cited UK rules and UK figures because we opened them, not because they apply to you. This is not legal advice for your situation.

Want to see how your own payments would score? Open a Toden workspace (opens in a new tab) or read how transaction monitoring works.

Sources

Charles Archibong

About the author

Charles Archibong

Co-founder

Charles Archibong co-founded Toden. He writes about identity verification, financial technology, and the practical work of building trusted digital services.

  • Risk & Compliance

    Transaction monitoring rules that find risk instead of noise

    A monitoring rule earns its place when it maps to a risk you actually carry, fires on data you actually send, and produces alerts an analyst can close with a reason. Tune rules against labelled outcomes, never against alert counts alone.

  • Developers

    Sending events for real-time risk scoring: an integration guide

    Call the transactions endpoint for money movement and the activities endpoint for logins and account changes, from your backend, before you act. Send complete parties and stable IDs, then route on the summary outcome: allow, review or block.

  • Product Updates

    Account takeover: step up the challenge instead of blocking the customer

    When a login looks like account takeover, do not guess. Let the session continue with limited rights, and ask for proof that only the verified person can give, such as a fresh selfie matched to their enrolment, before any payout, beneficiary change or password reset goes through.

Build your product.We'll handle the rest.

Identity and compliance, end to end, built to global standards, priced for founders.

Authorised push payment scams: catch them before they leave · Toden