Why do customer-authorised scams require different controls than phishing?

Why the control objective changes at the payment edge

Customer-authorised scams are not a pure anti-phishing problem because the user often authorises the transfer, even when they have been manipulated. The control objective shifts from blocking an unwanted login or message to interrupting a valid-looking payment before value leaves the institution. That is why destination checks, beneficiary risk signals and payment friction matter more than inbox filtering alone.

Phishing controls are designed to stop deception before credentials, sessions or payment instructions are accepted. Scam controls must work later in the chain, when the transaction itself may be legitimate from a systems perspective but harmful in context. The practical question becomes whether the bank can recognise anomalous payee behaviour, unusual payment intent or scam indicators in time to intervene.

That distinction is why phishing defence and scam prevention use different evidence. Phishing programs lean on sender reputation, link analysis, lookalike domains and account protection. Scam prevention needs transaction analytics, behavioural context, beneficiary verification and step-up intervention that can still fire even when authentication succeeded and the customer appears to have consented.

For a broader control model, this is closer to authorisation models than to simple message filtering, because the real decision is whether a payment should be allowed to proceed under current conditions.

Why sanctions screening and investigation tools are not enough

Sanctions and post-event investigation are important, but they are reactive and narrow. They help identify prohibited counterparties and support case handling after the fact, yet they do not reliably stop a customer who has been coached into sending money to an apparently legitimate but fraudulent destination. By the time a sanctions hit or case review occurs, the transaction may already be complete.

This is why scam defence needs controls at the transaction layer, not just the compliance layer. If the payment rail permits the instruction and the destination is not obviously prohibited, the institution still needs its own risk decisioning. Pre-transaction scoring can combine customer behaviour, device signals, beneficiary history, velocity, account age and other indicators to decide whether to delay, warn, challenge or block.

Those controls also need to be operationally usable. If the friction only appears after settlement, it is too late. If it is so aggressive that it blocks ordinary customer activity, it loses credibility and will be bypassed or poorly tuned. The control has to be both timely and proportionate to the scam pattern being targeted.

That is why lifecycle and governance controls matter alongside screening. The bank needs a managed process for tuning thresholds, reviewing false positives and preserving evidence so investigators can understand why a transaction was stopped or allowed. NHI Lifecycle Management Guide is useful here as a governance analogue because it frames how ongoing control, visibility and revocation decisions need to be managed rather than assumed.

What good scam control looks like in practice

Effective customer-authorised scam controls treat destination risk as first-class. That means the institution looks beyond sender and login security and asks whether the payee, payment pattern and customer context fit known scam behaviour. A transaction may be technically valid, but still unsafe because it matches a high-risk transfer pattern or occurs under pressure, urgency or abnormal beneficiary conditions.

The best controls combine prevention and interruption. That can include pre-transaction risk scoring, confirmation prompts that are meaningful rather than generic, payee verification, cooldown periods for new beneficiaries, and analyst review for high-risk cases. The point is not to prevent every risky transfer, but to create enough time and signal to catch an otherwise authorised scam before the money is irrecoverable.

For institutions operating in payments-heavy environments, the control set should also align with authorised push payment governance. Authorised Push Payment (APP) Fraud Guide gives a useful map of the scam landscape, while the PCI DSS v4.0 document library is a reminder that access control alone is not enough when business process abuse is the real issue.

Risk and Threat Considerations

Customer-authorised scams create a different risk profile because the attacker is not always trying to break authentication. They are trying to steer a legitimate customer into approving the transfer themselves, which makes traditional phishing-style controls blind to the final act of harm.

Failure mechanism: The institution relies on controls built to stop unauthorised access, but the scam succeeds after the customer has authenticated and approved the payment, so the control never evaluates the transaction as risky.

Impact: Funds move to a fraudulent destination, recovery becomes harder once settlement occurs, and the institution can miss the chance to interrupt harm even though the payment looked authorised at the time of processing.

Practitioner Guidance

What to prioritise: Put decisioning as close as possible to the transfer event. If you can only afford one enhancement, make it a pre-transaction control that can delay, challenge or suppress risky payments before settlement rather than a post-event detection workflow.

What to verify: Test whether the control can still act when the customer is authenticated and the payment is otherwise syntactically valid. If it only looks for bad logins or obvious fraud markers, it is probably solving phishing, not scam authorisation abuse.

Practitioner takeaway: The key design change is to control the payment outcome, not just the access event, because customer-authorised scams exploit trust at the point of transfer rather than at the point of login.

Related resources from NHI Mgmt Group

• Guide: Phishing Guide
• Why do strong customer authentication controls still fail against authorised fraud?
• Why do customer identities need different controls from workforce identities?
• Why do real-time payment scams create different controls than card fraud?
• Why do phishing and BEC still require layered controls instead of one AI model?