Authorised Push Payment Scams: How Money Transfer Operators Protect Customers Before They Pay

In an authorised push payment scam, the customer is not hacked. They make the payment themselves, believing it is genuine, because someone has persuaded them to. For a money transfer business, that is a hard problem: the customer has passed every identity check, the payment is technically valid, and once money has been paid out abroad it is rarely recoverable. The only reliable defence is to slow the right payments down before they leave.

This guide is for compliance and product teams at money transfer businesses.

RemitSo is one way to put these controls in place: scam warnings, safe sign-in and a device list, risk checks that hold transfers for a person, and payouts that are locked once approved and never edited. It does not write your fraud policy, decide which transfers to stop or talk to the customer. Those stay with your team.

An authorised push payment (APP) scam is any fraud in which the victim is tricked into sending money themselves. The common patterns are well known:

• Impersonation. A caller or message claims to be from a bank, the police, a tax authority, a delivery firm or the money transfer operator itself, and asks the customer to move money "to keep it safe" or to pay a fine.
• Payment redirection. The customer is told the payee details have changed, and pays a different account.
• Romance and relationship scams. A contact built up over weeks or months asks for money for an emergency, a visa or a ticket.
• Investment, job and family emergency scams. Promised returns, work abroad, or a "new number" claiming to be a relative in trouble.

Remittance customers are targeted for reasons that have nothing to do with carelessness. Sending money abroad is routine for them, so one more transfer does not feel unusual. Many have family overseas who might plausibly need urgent help. Some are newer to the country and less familiar with how local institutions contact people. And cross-border payments are hard to recover once paid out.

Some jurisdictions, the United Kingdom among them, have introduced reimbursement requirements for certain APP scam losses. Whether they apply to you depends on your licence and the payment systems you use; confirm with your advisers. Either way, prevention is cheaper and kinder than reimbursement.

Each intervention point has a different cost to genuine customers, so map them before choosing controls.

The earlier the intervention, the cheaper it is and the more likely it works.

Generic warnings ("Be careful of fraud") are ignored. Warnings work when they are specific, short and shown at the moment of decision.

Show who to pay, and who never to pay

When the customer pays in by bank transfer, tell them precisely which payee name they should see, and state plainly that you will never ask them to pay anyone else. If the payee shows as your brand, the customer has a checkable rule: anything else is a scam. This counters fraudsters who impersonate the operator or change payment instructions mid-conversation.

Write warnings for the story, not the crime

Customers rarely think "this might be fraud". They think "my nephew needs help" or "the bank told me to move my money". Warnings should name those situations:

• "We, your bank and the police will never ask you to move money to keep it safe."
• "If someone you have only met online is asking for money, stop and talk to someone you trust."
• "A message from a new number claiming to be family? Call them on the number you already have."

Use the customer's language

A warning a customer cannot fully understand does not protect them. Translate warnings with the same care as payment screens.

In RemitSo's customer app, scam warnings show customers exactly who to pay, with the payee shown as your brand, and who never to pay. The app can run in English, French or Spanish from a translation dictionary you provide, and every screen, message and alert switches.

Some scams start with access: a fraudster persuades the customer to share a one-time code or install a lookalike app. Sign-in design closes much of that gap.

• Bind sign-in to the device. After a one-time code on first sign-in, the customer sets a PIN, Face ID or fingerprint. A code read out over the phone is then not enough to send money from another device.
• Only accept genuine apps. App integrity checks mean a cloned or modified app cannot talk to your backend, even with valid credentials.
• Show every signed-in device. Customers should be able to see each device on their account and remove one in a single tap. Removing it should end its sessions and stop its PIN and biometric sign-in working.

RemitSo's customer app works this way: a one-time code, then PIN, Face ID or fingerprint; only genuine apps connect; and removing a device in one tap stops its sessions, PIN and Face ID sign-in.

Warnings do not stop customers under heavy pressure. The next layer is risk checks that hold certain transfers for human review before payout. Patterns worth a closer look include:

• A first transfer to a new recipient that is much larger than the customer's usual amount.
• Several new recipients added in a short period.
• A sudden change in destination country or payout method.
• Transfers that push close to, or try to split around, the customer's limits.
• A recently added device followed quickly by a large transfer.

The goal is to hold the right transfers, not more of them; holding too much trains reviewers to approve on autopilot. Reviews should include open questions to the customer: who is the recipient, how do you know them, did anyone tell you what to say.

RemitSo provides 46 ready-made risk indicators that you combine into your own rules with logical conditions. Several map directly to scam patterns: a new customer baseline, transaction frequency and volume against the customer's history, frequent transfers to the same recipient, payment details or sign-in IP from a high-risk or FATF call-for-action country, IP reputation, and whether the IP and the payment instrument's country match. Two are especially useful once you have seen a scam: watched names, email addresses and email domains for customers, recipients and account holders, and payment details reused across customers. Add a mule recipient's name or a scammer's email domain to the watch list, and the next customer sent to the same place is held for a person. Risky transfers wait for review; everything else flows on its own, and Risk Radar shows which indicators fired and what the outcome was. Scout, in the admin panel, measures every 5 minutes and groups transfers needing action in one place, so held items are not left unseen.

When a customer reports a scam, speed and accuracy matter most.

1. Establish the state of the transfer. Is it still held, approved but not paid out, or already paid out? The options differ for each.
2. If it has not been paid out, stop it. Holding or cancelling a transfer that has not left is the most effective step available.
3. If it has been sent to the partner, ask the partner to stop or return it. Whether that succeeds depends on the partner and on whether the recipient has collected the funds, so tell the customer honestly that it is not guaranteed.
4. Never edit a payout to "fix" it. Changing the recipient or amount on an approved payout breaks the link between what was approved and what was sent. Ask the partner to stop or return it and, once it is cancelled or returned, create a new transfer if appropriate.
5. Secure the account. Review the device list with the customer, remove anything unfamiliar, check recent sign-ins for unfamiliar locations, and check for other recent transfers.
6. Record everything. Who did what, when, and why, including any refund and its reason.
7. Feed it back into your rules. Could a warning or risk check have caught it earlier? Add the recipient's name, the scammer's email or domain to your watch lists so the same story is caught next time.

In RemitSo, payouts are locked once approved: what goes out is exactly what was approved, and approved payouts are never edited. A hold or stop agreed with the partner directly is recorded with a required reason that is kept. Refunds are recorded with a reason, every customer sign-in is logged with time, IP address, city, country and device details, and if the case points to money laundering a Suspicious Activity Report can be generated and submitted from the console: the records you need for complaints and regulatory review.

The figures below are illustrative only.

A customer has used the app for a year, typically sending about GBP 200 a month to the same two family members. One evening he receives a call from someone claiming to be from his bank's fraud team. The caller says his account is compromised and he must move GBP 3,000 "to a safe account" overseas, using his remittance app because it is "faster".

1. Adding the recipient. He adds a new recipient. The app shows a warning: no bank, police force or money transfer company will ever ask you to move money to keep it safe. He hesitates, but the caller tells him to continue.
2. Paying in. The app tells him to pay only the payee shown under the operator's brand. The caller had given him a different account name for the pay-in, which gives him a second reason for doubt. He uses the operator's details anyway.
3. Risk checks. The transfer combines several signals the operator's rules look for: a new recipient, a new destination country, and an amount fifteen times his usual. It is held for review rather than paid out.
4. Review. Within the operator's target time for held transfers, an analyst calls him and asks how he knows the recipient. He says the bank told him to send it. The analyst explains that this is a known scam.
5. Outcome. The transfer is cancelled before payout and the refund is recorded with its reason. The analyst reviews the device list and recent sign-ins with him; there is nothing unfamiliar. The hold, the refund and its reason are recorded against the transfer, and the new recipient's name goes on the operator's watched names list.

The operator then reviews the case and adds a phrase about "safe accounts" to the warning shown when a new recipient is added in a new country.

Customer journey

• The pay-in screen states exactly which payee name to expect and that you will never ask the customer to pay anyone else.
• Warnings name specific scam stories and appear when a recipient is added and before payment.
• Warnings are translated into every language the app supports.
• Customers see the rate, fee and amount received before paying.

Account security

• Sign-in is bound to the device with a PIN or biometrics after the first one-time code.
• Only genuine apps can connect to your backend.
• Customers can see and remove signed-in devices themselves.
• Every channel repeats that staff will never ask for codes or PINs.

Operations

• Risk rules target new recipients, unusual amounts, new destinations and new devices, and are reviewed regularly.
• Held transfers have an owner, a target review time and a script for calling the customer.
• A written procedure for reported scams covers stopping the transfer, asking the partner to stop or return a sent payout, account security, refunds and records.
• Approved payouts are locked and never edited.
• Every hold, decision and refund is recorded with a reason you can show to a regulator or an ombudsman.
• Names, email addresses and domains from confirmed scams go onto watch lists.
• Your position on any reimbursement rules in your jurisdiction is documented.

RemitSo provides the controls below. Your team still sets the rules, reviews held transfers, talks to customers and owns the fraud policy.

• Scam warnings with a clear pay-in rule. Customers see who to pay, with the payee shown as your brand, and who never to pay, giving them a concrete check against impersonation. See the customer app features.
• Safe sign-in. A one-time code, then PIN, Face ID or fingerprint, and only genuine apps can connect, which makes stolen codes and fake apps far less useful.
• Device list. Customers remove a lost or unfamiliar device in one tap, ending its sessions and biometric sign-in.
• 46 ready-made risk indicators. Including watched names, emails and domains, high-risk-country checks on payment details and sign-in IP, and frequent transfers to the same recipient; combine them into your own rules so risky transfers wait for a person and everything else flows. See the admin features.
• Scout. Measures every 5 minutes and groups what needs an operator in one place, so held transfers are not missed.
• Payouts locked once approved, never edited. What goes out is exactly what was approved, protecting the integrity of every case record.
• Login sessions, reasoned refunds and SARs from the console. Evidence for complaints, reimbursement decisions and regulators. To see the flow end to end, book a demo, or read the getting-started guide.