Authorized push payment scam detection

Authorized push payment (APP) scam detection only works if the decision lands before the credit leaves the payer's account. Once Faster Payments or equivalent rails have settled, a warning is a customer-service note, not a control. Score the outbound instruction in the same window you already use for real-time transaction fraud scoring: payee novelty, amount versus the customer's own history, timing relative to session and call activity, and device or channel identity.

The unit of work is one payment instruction. Pull the proposed payee (account number and sort code or IBAN), the amount, the customer's recent outbound pattern, the device or channel that originated the instruction, and whether Confirmation of Payee matched. Combine those into a risk score and a reason code before you call the payment engine. If you cannot halt or delay the credit, stop treating this as detection. You are doing after-the-fact typology tagging.

Decision order is pass, warn, then hold. Pass when the payee is known and the amount is in-pattern, even if the device is new. Warn when the payee is new and the amount or device is unusual, and put the cite on screen before the customer can confirm. Hold when those signals stack, or when Confirmation of Payee is a close or no-match, and only then ask the customer to confirm.

Fraud platforms and core banking suites used in this space, including Featurespace, NICE Actimize, and Temenos, sit as a class around scoring, cases, and payment orchestration. Use whichever stack you already run. The quality bar is not the vendor name. It is whether a high score can warn or hold before execution, with a reason a customer can read.

A late warning is a common production failure. The model fires after the payment has gone because scoring was hung off a settlement feed, a batch mule file, or a case queue that opens after the credit. Move the call to the pre-execution path: after payee validation, before the debit is committed.

Do not silently block a known payee. A standing order to a landlord, a regular supplier, or a family member the customer has paid for months is not an APP event because a device changed or the amount ticked up with rent. Silent blocks on known payees create operational noise and teach customers to ignore every subsequent prompt.

Use a two-factor trigger for customer friction: new or first-time payee, plus at least one of unusual amount or unusual device or channel. New payee alone is too blunt; people pay new tradespeople. Unusual amount alone is too blunt; bonuses and tax bills happen. Together, they match the social-engineering pattern: a first-time destination, a larger-than-usual sum, often from a device or browser the customer has not used for payments.

Hold rather than hard-decline when the score is high and the payee is new. A hold buys time for the customer to read the reason, for a callback, or for a cooling-off window. A hard decline on a genuine new payee (a deposit, a solicitor, a car purchase) looks like the bank broke the payment. A silent pass on a new payee with an outlier amount is how APP leaves the book.

Illustrative path, not a measured case: a retail customer who pays the same letting agency every month gets a new phone. The next rent instruction is the usual amount to the usual account. Score it. Device novelty is real, but the payee is known and the amount is in-pattern. Let it through. Do not block the landlord standing order. Contrast that with the same customer instructing a large first-time payment to a personal account they have never used, from that new phone, after a long authenticated session. Warn or hold. Cite the new payee and the amount, not a generic "this looks risky."

The outcome you are buying is a warning or hold the customer can understand, not a black-box stop. The cite should name what changed in language they can verify: this account has not been paid from this profile before; this amount is well above what you usually send; this device has not originated a payment. If Confirmation of Payee returned a close or no-match, say that. Do not dump model features, graph scores, or internal typology names onto the screen.

A readable cite does two jobs. It interrupts the script the scammer is reading to the customer. It also gives your complaints and ombudsman file a factual basis: you did not hide the risk, and you did not invent a scam after the fact. If you cannot explain the hold in one or two sentences a branch colleague could repeat, you are not ready to show it.

Keep the tone factual. You are not accusing the payee. You are stating payment conditions that do not match the customer's own pattern. Accusation language ("this is a scam") is a quality failure. The warning is a hypothesis with evidence, not a finding.

Customer confirmation is an intervention, not evidence that the payment was safe. People under social-engineering pressure will tap through a warning to please the person on the phone. Treat a click-through as "the customer proceeded after being shown the cite," and keep the audit trail. Do not treat it as proof there was no scam, and do not use it to suppress a later mule or recovery investigation.

If the score remains high after confirmation, you can still apply a timed hold, a callback from a known number, or a second-channel confirm. Those are operational choices. What you should not do is log "customer confirmed, therefore not APP" and close the case. That failure mode shows up when the funds later appear in mule account detection at top-up on the receiving side, and the paying bank has already marked the outbound as customer-accepted.

The same caution applies in reverse. A warning that was shown, or a hold that was released, is not proof the payment was a scam. Do not auto-file a fraud case, do not file an APP reimbursement claim, and do not freeze the payee for all other customers on the back of a model score plus a prompt. Quality here means: you interrupted execution with a reason. Disposition still needs investigation.

APP scoring should ingest, not duplicate, adjacent controls. Vulnerable customer detection can raise the prior that a customer is more likely to be coached through a payment. That can lower the threshold for a warning or extend a hold. It should not silently stop every outbound from that customer. Known payees still need to move.

On the receiving side, APP proceeds often fund mule collection. Link outbound APP holds to AML transaction network monitoring so a first-time payee that already sits in a pass-through cluster is more likely to hold. Do not wait for the AML batch to tell you the money has already hopped. The outbound score still has to fire first.

When you tune, watch three failure modes as a set. Blocking the landlord standing order means your known-payee exemption is too weak or your device signal is over-weighted. Warning after the payment has gone means the score is on the wrong feed. Treating a click-through as evidence of no scam means confirmation was wired as a clearance rather than as friction. Fix those before you add more features.