Scam detection software: seven agents and what none may do

Scam detection software for banks finds the payments a customer is being talked into sending and explains, in words a fraud colleague can act on, which scam is probably behind each one. It sits after the fraud detection engine that scores and holds a payment, and before the person who must call the customer and decide. That position is the hard part: the customer has passed every login and device check, the score says only that something is unusual, and a UK bank that delays the payment has until the end of the next business day to show reasonable grounds. Botminds' APP Fraud Detection is software for this step. Seven agents gather the signals, name the likely scam, write the questions, listen to the call, spot vulnerability, draft the notice and keep the file; none of them can hold a payment, release it or contact the customer.

This guide is written for the head of fraud strategy who has to choose, fund and defend such a tool. The examples come from the solution's fictional sample bank, Corvane Bank UK; its customers and colleagues are invented and every figure about them is sample data, not a customer's result.

How does scam detection software work? Three layers on one payment

Scam detection works in three layers: a score that decides which payments to hold, an explanation that names the likely scam and the evidence for it, and an intervention that tests the explanation with the customer. The first layer is the bank's existing fraud detection engine: it scores each outbound Faster Payment, and anything above the bank's threshold is held. That is necessary and, on its own, close to useless to the person who has to make the call, because a number cannot tell a colleague which questions to ask.

The second layer is where scam detection software earns its name. It reads the held payment against everything the bank knows that the engine does not weigh: what the customer said to the contact centre that morning, whether the bank has actually called them, how the receiving account has behaved, what the customer moved between their own accounts first. The third layer is the call, and the software's job there is to write the questions for the scam it has named and to hear when the answers come from a script. The way the three layers hand over is the whole design.

What is a scam typology, and why the name matters more than the score?

A scam typology is a named pattern of deception, such as an impostor posing as the bank, a romance, a fake investment or a redirected invoice, and naming it is what turns a held payment into a conversation. The UK regulator's own data uses seven: in the Payment Systems Regulator's 2024 performance report, an impersonation scam is one where "a scammer pretends to be the police, bank staff or a friend or family member to convince the victim to make a payment", and a purchase scam is one where "a victim pays in advance for a good or service that they don’t receive". In the US the Federal Reserve's ScamClassifier sorts scams into two categories and nine types, from merchandise to bank impostor, and states that it is voluntary and "is not intended to result in mandates or regulations".

The typology matters because each one breaks a different question. A safe-account victim may deny that anyone contacted them; on the sample case the caller had told the customer that someone at her branch might be in on it. A romance victim may talk about the payee warmly and at length. A purchase-scam victim can answer every question truthfully and still be wrong, because they believe the seller exists. A question set that works for one fails for the others, which is why the solution's script agent writes from the scam the typology agent has named, and why the typology agent refuses to guess: below a confidence of 0.70 it says "unclear" and the colleague uses the general script.

The mix of scams decides where a bank's effort goes. Across the 14 largest UK banking groups, before mandatory reimbursement, purchase scams were "73% of cases by volume, but only 27% by value", while investment scams were "25% of value, but just 4% of cases". A typology that is right on the many small purchase scams and wrong on the few large investment ones looks accurate and loses money.

What data does scam detection use? Nine signals behind one payment

Scam detection uses the payment, the payee and the customer together: the payee name check, the receiving account's age and recent traffic, the customer's balances and history, the digital session, and, most valuable and most often missing, the customer's own recent contacts with the bank. On the sample case the agents weighed nine signals from eight systems, each with a Source button that opens the record it came from.

Nine signals from eight systems, each opening its source

The order matters more than the numbers. The fraud engine's score held the payment, but two of the three reasons a colleague can say out loud came from outside the payment altogether: a contact centre transcript and a telephony log. A buyer should ask any vendor which of these sources its product reads on its own, and which it expects the colleague to look up while the customer is on the line.

Can AI detect scams in real time? Within the hour, and inside a legal clock

AI can name a likely scam while the payment is still held and flag coaching while the customer is still talking, which is the real time that matters. The UK rule does not require a decision in seconds. It requires the bank to establish reasonable grounds by the end of the business day after it received the payment, and FG24/6 is blunt about the consequence: a bank that has not met the threshold by then loses the power to delay that payment. The software's real-time task is to make that same-day judgement possible on every held payment, not just the ones a colleague reaches first.

The same guidance sets the quality bar. Reasonable grounds must rest on facts that can be stated and checked, not speculation, and an unusual payment is only a reason to look further, not a reason to suspect. Banks are told to use "any assessments made using technology solutions", which "should be calibrated to detect and prevent fraud while minimising the impact on legitimate payments". Read together, that is a specification for scam detection software: it must turn unusual into suspicious with stated reasons, or say that it cannot. The full timetable is in UK bank payment delay rules.

On the call itself, the listening agent works on the live transcript and flags an answer within the second it is heard, with the words and the time. If the telephony feed is down, the colleague types the answers and the agent works on the typed text. The FCA has noted that some firms use behavioural biometrics to "try and identify whether a customer is being socially engineered"; listening to what the customer actually says is the same idea applied to the call.

Can software stop a payment? Why a person still decides

Software can hold a payment automatically when a score crosses a threshold, and it should not decide what happens next. The release, the refusal and the protective block each change a customer's money, and each will be read later by a team leader, a claims handler, an auditor or the Financial Ombudsman Service. In Botminds' design the agents never hold, release or contact the customer: the colleague decides with a reason code, a release of a payment scored 800 or more needs a team leader, and the person who asks for a check can never approve it.

There is enforcement history behind that line. In the US, the Consumer Financial Protection Bureau found that a bank acted unfairly by denying customers' fraud claims and freezing accounts on the say-so of a faulty fraud filter and nothing else (CFPB, 2022); the bank was ordered to pay a $100 million civil penalty to the Bureau, and the Office of the Comptroller of the Currency separately fined it $125 million. The UK reimbursement rules make the same point from the other side. The regulator's guidance on the consumer standard of caution says that talking to a customer about a payment does not let the bank hand the whole job of judging its risk to the customer. The judgement stays with the bank, so a named person at the bank has to make it.

A second person on what matters: releases, protective blocks and free-text notices

What does the customer see when a payment is held?

The customer sees a paused payment and, by the end of the next business day, a notice that says so, why, and what the bank needs from them. FG24/6 asks that the notice tell the customer enough to understand the risks the bank has found, including the grounds for its suspicion, except where saying so would be unlawful, as with tipping off. That rules out two common failures at once: a notice so vague the customer cannot act on it, and one that mentions an internal referral or report.

The solution's notice agent drafts the notice and checks it before a person sends it: that it says the payment is delayed, why in plain words, what the bank needs and the latest date; that its reading age is at or below the bank's target; that it never asks for security details; and that it mentions no internal referral or report. A person checks every notice before it goes, and free-text wording needs a team leader. On the sample case the draft took five minutes and went at 11:31, by app message and large-print letter.

How do you audit a scam decision? Reasons, versions and a sealed export

You audit a scam decision by being able to replay it: the signals and their sources, the scam named and its confidence, the questions asked and the answers given, the warning read, the decision, who made it and who checked it, and which version of every threshold, script and model was live at the time. FG24/6 lists what a bank should keep for each delayed payment, including the grounds for suspicion and whether the payment was finally sent or refused, so it can test its customers' outcomes.

Model risk rules point the same way, with a difference between the UK and the US worth knowing before procurement. The Prudential Regulation Authority's model risk principles, SS1/23, apply to UK banks and building societies with internal model approval for regulatory capital, and define a model broadly enough that its output "can be quantitative or qualitative", so a system that names a scam can fall inside the definition. The US agencies' revised guidance of April 2026 goes the other way and leaves generative and agentic AI outside its scope, calling both too new and too fast-changing to cover yet. Neither removes the need to govern them; the UK text simply says it more directly.

The audit trail and an export pack, redacted and sealed

What should scam detection software report back to the head of fraud?

It should report which questions stop payments, how often its own flags are right, and what a threshold change would cost before anyone makes it. A score-only tool can report how many payments it held. A tool that names scams and writes questions can report something more useful: the share of confirmed scams each script version stopped, so a head of fraud strategy can retire the scripts that do not work.

The sample bank's September shows the kind of report to ask for. Of 1.08 million outbound consumer Faster Payments, 2,614 were held for an intervention and 418 were stopped. The safe-account script in use stopped 87% of the confirmed safe-account scams it was used on, against 79% for the version before it; the purchase-scam script stopped 58%, the lowest of the six, which fits a scam in which the customer believes the seller is real. The listening agent flagged 611 coached answers in 1,904 recorded calls, and colleagues agreed with 93% of the flags, which is the number to watch if a bank wants to know whether to trust it. And when the typology agent proposed lowering the hold threshold from 700 to 680, it estimated from a replay of the month's payments what that would mean: about 210 more payments held, about 31 more scams stopped and about 1.6 more full-time colleagues. Those are sample figures from a fictional bank, and the replay estimate is the agent's own; the point is that the trade-off arrives with numbers, and the change still needs the model risk approver.

Scam detection software: questions to ask before you buy

The questions below separate tools that explain from tools that only score. Each comes from a rule or a failure described above, and each has a yes-or-no answer a vendor can demonstrate on a sample of your own held payments.

The last question deserves a page of its own, and has one: APP fraud detection: a pilot on last quarter's reimbursed claims sets out how to run that replay and what to measure.

Where APP Fraud Detection fits, and where it does not

Botminds' APP Fraud Detection does not replace a bank's fraud detection engine, its payee check or its case management; it reads from them. It needs held payments from the Faster Payments gateway and the engine, the payee check results and a payee risk feed, the core banking history, the contact centre's transcripts and telephony records, and the recorded intervention call. Without call transcripts the listening agent works on answers the colleague types. Without the customer's contact history the strongest class of signal on the sample case would be missing altogether.

It is built for the UK's authorised push payment rules: the D+1 and D+4 clocks, the delay notice, the consumer standard of caution and the Consumer Duty. Outside the UK the same approach applies to a scam intervention, but none of those clocks does; the reasons are set out in authorized push payment fraud: UK reimbursement vs US Reg E. To see the seven agents working on one case, start from APP Fraud Detection.

Questions people ask

What is the difference between fraud detection and scam detection?

Fraud detection looks for payments someone made without the customer's authority, such as a stolen login. Scam detection looks for payments the customer made themselves after being deceived, which pass every authentication check. The Federal Reserve's ScamClassifier builds on that split: once a case is confirmed as a scam, it asks whether the payment was authorised or unauthorised.

Can scam detection software listen to customer calls?

It can work on a recorded call's live transcript, as the listening agent does, flagging coached answers, secrecy, urgency and a caller who will ring back, each tied to the second it was heard. It flags; a person decides. Where no recording is available, it can work on answers the colleague types.

Does scam detection software reduce false positives?

It can reduce wasted calls by naming the scam and explaining it, so a colleague confirms or clears a hold faster, but the hold threshold is still the bank's choice. FG24/6 expects the technology to be calibrated to minimise the impact on legitimate payments and expects banks to keep, for each delayed payment, whether it was ultimately completed or refused.

Who should approve changes to scam detection thresholds?

A named owner and an independent approver. In the solution, the head of fraud strategy approves threshold and script changes, the model risk approver must also sign off detection thresholds, and every version is kept. The PRA's SS1/23 treats model risk as a risk in its own right for banks in its scope.

Is scam detection software a model under model risk rules?

In the UK it can be: SS1/23 defines a model's output as quantitative or qualitative, which covers a system that names a scam, for firms in its scope. The US guidance revised in April 2026 puts generative and agentic AI outside its scope for now, without saying they need no governance.