TL;DR
Phone-channel fraud is growing in 2026 because web fraud got harder. The fix isn't another risk score on a card-not-present transaction your screen can barely see. It's removing card data from agents, killing the recording attack surface, and pushing authentication to the customer's device. We've watched merchants cut phone chargebacks 40-70% inside one quarter doing that.
Last updated: 29 May 2026
A fraud team I spoke to last month had a problem they couldn't explain. Card-not-present losses on phone orders had jumped 31% in a single quarter. Chargebacks weren't unusual ones — they looked like normal customer disputes. Their fraud screening tool gave each transaction a low risk score. Nothing on paper said anything was wrong.
When they pulled the calls, the pattern was obvious. Same voice. Different cards. Different names. The fraudster had figured out their agent script, their verification questions, and the soft spots in their authentication flow. He was placing five or six orders a day across multiple agents who'd never spoken to him before.
That's what contact-centre fraud looks like in 2026. It's not a hooded figure in a basement. It's someone who knows your business better than your new starters do, exploiting the gap between what your card processor sees and what your contact centre actually does.
The shape of contact-centre fraud right now#
UK Finance's 2025 fraud report shows phone-channel CNP losses growing while web fraud is roughly flat. That's not a coincidence. As 3-D Secure 2.2, device fingerprinting, and machine-learning fraud screens lock down web checkouts, attackers move to the channel where authentication is weakest — a human agent who wants to be helpful, working from a script that was written for sales not security.
We see four patterns repeatedly. First, agent-assisted card testing: the fraudster places small phone orders to validate stolen cards before using them online. Second, social engineering of verification questions — DOB, postcode, last-four-of-card — all of which leak in data breaches. Third, account takeover via the support line, where the attacker calls in claiming they've lost access and asks for the registered email to be changed. Fourth, refund fraud, where a real customer or someone impersonating them calls to claim an order never arrived and gets refunded without the card being charged back.
None of these need sophisticated tooling. They need an agent who's measured on average handle time and customer satisfaction, not on fraud catch-rate.
How the breach economy changed phone fraud
Five years ago, "verify the customer with three security questions" worked because the answers weren't on a database somewhere. They are now. The cumulative effect of the Equifax, LinkedIn, MOVEit, and a long tail of smaller UK breaches is that any reasonably motivated fraudster can buy a record containing a target's name, DOB, address history, last four digits of a known card, mother's maiden name, and the email they use for online shopping — for under £20 on a forum your fraud team doesn't have an account on.
The script your agents follow was written when those facts were private. They're not. Treating them as proof of identity in 2026 is the equivalent of locking your front door with a key that's been photocopied and posted online.
The data breach feedback loop
Every successful phone fraud event creates a new data point. The fraudster learned your verification script, the cadence your agents follow, the magic words that escalate a call to a supervisor with override authority. That intelligence gets sold, shared, or simply re-used. Six months later you'll see the same approach attempted across a competitor — we've watched it happen in housing, in insurance, and in travel three times this year.
Why this hits UK merchants harder
UK contact centres tend to handle higher-value, lower-velocity transactions than equivalent US operations — fewer £15 widget orders, more £400 furniture orders, £2,000 insurance premiums, £8,000 holiday bookings. The unit economics of phone fraud favour the attacker here. A fraudster only needs one or two successful orders a week to make a UK target worthwhile, where a US-equivalent attack would need ten or fifteen.
Why fraud screening tools miss phone orders#
If you're using a fraud platform like Sift, Riskified, Forter, or Stripe Radar on your web checkout, you've got rich signals: device ID, IP geolocation, browser fingerprint, behavioural biometrics, velocity across the merchant network. Those tools work well because they have something to score.
On a phone order, almost all of that disappears. Your agent enters the card details into the same payment processor. The fraud screen runs — but it's running on a card-present-ish transaction from your office IP, with no device signals at all. Most rules engines we've seen will pass that transaction unless the BIN is on a deny list or the amount triggers a velocity flag.
The signal you do have — the call itself — typically isn't fed into the fraud screen. Call metadata sits in your CCaaS platform. Card data goes through your payment masking layer. The two systems don't talk. That's the gap fraudsters live in.
The signal vacuum nobody admits to
Ask your fraud-tool vendor what signals they use on a phone order. The honest ones will say BIN, transaction amount, velocity by card, and merchant category. That's it. The card-present-style entry from your office IP washes out the geolocation, device, and behavioural signals that catch most web fraud. You're paying for an engine that's running with most of its inputs disconnected.
What "card-present-ish" actually means to your acquirer
Phone orders are processed as MOTO transactions — Mail Order/Telephone Order. Your acquirer's interchange tier for MOTO is higher than for properly authenticated 3-D Secure web transactions, and your chargeback liability is total. There's no liability shift. If the cardholder disputes, you eat the loss whether the order was genuine or not, with no equivalent to the "verified by issuer" defence you'd get on an authenticated web payment.
Where call metadata could help but doesn't
Your CCaaS platform — Genesys, Five9, NICE CXone, Talkdesk, RingCentral, 8x8, Amazon Connect — knows the caller's CLI, how long they were in the IVR, whether they bounced through three agents before reaching one who'd take the order, and whether their number is on a fraud watchlist. None of that reaches your fraud screen by default. The integrations exist for some combinations, but most contact centres haven't built them because the project sits on a CTO's roadmap behind seventeen other things.
What voice biometrics actually catch (and miss)#
Voice biometric vendors will tell you their tools spot repeat fraudsters across your call estate. They're right — sometimes. The good ones build a voice print over the first 20-30 seconds of a call and check it against a watchlist of known fraud voices and your customer base.
Three things to know before you sign a contract. One: they need enrolled samples to work, and most contact centres don't have clean enrolment for their existing customers, so the customer-side check is weak for the first 12-18 months. Two: deepfake voice cloning is now cheap enough that determined fraudsters use it — we've seen a real case where a voice biometric flagged a synthesised customer voice as a match. Three: the watchlist is only as good as the fraud you've already caught and tagged. Brand-new fraud voices look like brand-new customer voices.
Voice biometrics are a useful layer. They're not the answer.
The deepfake problem is getting worse, not better
In 2024 a usable voice clone needed about three minutes of clean source audio. By early 2026 it's down to thirty seconds, available from off-the-shelf consumer tools, and most listeners can't tell the difference in a short phone interaction. Voice biometric vendors are responding with liveness detection — looking for breath patterns, background noise consistency, and prosody features that current clones get wrong — but it's an arms race the defenders don't get to call.
One UK financial services firm we spoke to had three confirmed deepfake fraud attempts in a six-week stretch this spring. Two got blocked by behavioural inconsistencies (the synthesised voice couldn't answer follow-up questions naturally). One went through. The biometric system rated it as a 94% voice match.
The enrolment problem most vendors don't mention
Voice biometrics check a caller's voice against an enrolled sample. For new customers you can enrol them on their first call. For your existing book, you need a backfill programme — playing customers a notice, getting consent, building a sample from natural call audio over weeks or months. That programme is the bit that gets cut from the project budget, and the lack of enrolment is the bit that makes the system feel useless for the first year.
Where voice biometrics genuinely earn their keep
If you've got a small population of repeat fraudsters hammering your channel — which most contact centres do, even if they don't know it — a watchlist-only deployment with no customer enrolment will spot 30-60% of recurring fraud calls in the first quarter. That's the use case where the spend makes sense. Buy it as a fraud-voice watchlist, not as customer authentication.
The controls that actually work in 2026#
We've spent the last three years watching what stops phone-channel fraud at our customers. The pattern is consistent. The merchants with the lowest CNP loss rates aren't running the most sophisticated fraud-screening tools. They're running a stack of basic controls that together make their channel boring for fraudsters to attack.
1. Remove the card data from the call entirely
If your agent never sees, hears, or enters the card number, you've removed the easiest social engineering attack. DTMF masking lets the customer key their card on their own phone. The agent stays on the line, but the digits never reach the agent's headset or screen. Fraud detection benefit: no agent can be tricked into typing the wrong card details, and no fraudster can read someone else's card number off a call recording.
The merchants we work with see a measurable shift the first week this goes live. Agent-assisted card testing — where the fraudster batches stolen cards through small phone orders — drops to near zero, because the fraudster has to dial in and key each card themselves, which is slow and reveals their CLI on every attempt. The unit economics stop working for them and they move on.
2. Don't record what you don't need to record
Most contact centres record every call by default and store the recordings for 6-12 months. That's an enormous attack surface — a single insider with download access can exfiltrate years of card data. Channel separation drops the audio while the customer is keying the card so the recording literally cannot contain the digits, even if your transcription tool runs.
This matters more than people realise. PCI DSS v4.0.1 treats stored call recordings containing PAN as cardholder data — the same compliance obligations apply to that audio as to your card database. Most contact centres have never properly scoped their recording archives, and we've seen audits go badly when the QSA realised that a three-year archive of customer calls contained millions of unredacted card numbers.
3. Tie the card to the customer, not just the order
Most fraud screens look at the card. Fewer look at the relationship between the card and the customer file. If a customer with a five-year clean order history suddenly uses a card with a different name and a different billing address, that's a signal. If a brand-new customer places a £400 order with a card BIN from a country they're not calling from, that's a bigger one. Push these signals into your fraud screen as custom variables — most platforms support them.
Building this is cheap and high-yield. You're not buying anything new — you're feeding existing fraud-screen inputs that your platform already supports as custom variables. The lift is usually one week of analyst time and one week of integration. We've seen merchants catch 15-25% more phone fraud just by piping these three signals in.
4. Move authentication out of the agent's job
Verification questions that rely on what an agent can ask — DOB, postcode, last transaction — have been compromised at scale by the breaches of the last five years. Push customer authentication to the customer's own device. Payment links sent to a verified mobile number or email, with the customer completing checkout in a browser that runs 3-D Secure, shifts the authentication burden onto the issuer where it belongs.
This is the change with the largest single fraud-rate impact we see. A phone-initiated transaction that ends in a 3-D Secure authenticated web checkout gets the liability shift you don't get on MOTO. If a customer disputes the charge later, the issuer eats it, not you. For high-value orders especially — over £500 — moving the actual card entry to a payment link is one of the highest-ROI changes a contact centre can make.
5. Measure fraud rate per agent, per shift, per team
Most contact centres measure AHT, CSAT, and conversion. Almost none measure chargeback rate by agent. The minute you start, you'll find clustering you didn't expect — sometimes that's training (a new starter being targeted), sometimes it's collusion (rare but real), and sometimes it's just a team that handles a higher-risk product line and needs different rules. You can't improve what you don't measure.
The reporting lag makes this harder than it should be. Chargebacks land 30-90 days after the transaction, sometimes longer for retrieval-then-dispute cases. By the time you spot a clustering pattern, the agent may have left or the rota has shifted. Build a dashboard that tracks chargeback rate by agent on a 90-day rolling window and review it monthly — the patterns become visible inside two quarters.
What we don't recommend#
A few things people sell as fraud-prevention that we don't think work.
Agent-led security questions beyond identity confirmation. If your script has more than three verification questions, you're slowing real customers down and not catching fraudsters who've done their homework.
Holding all phone orders for manual review. The cost in agent time and customer experience swamps the fraud you'd save unless your phone fraud rate is genuinely terrible (and if it is, you need the structural fixes above first).
Buying a voice biometric solution as your first fraud control. It's a sensible layer 3 or 4. As a first move, you'll spend six figures and not move your numbers.
The "AI fraud detection" pitch deck
You'll see vendors selling AI-powered call analytics that promise to catch fraud by analysing speech patterns, sentiment, pauses, and "linguistic markers of deception." The research papers are interesting. The production results are not. Every vendor we've evaluated has a high false-positive rate against your real customers — anxious people sound suspicious to an AI — and a high false-negative rate against rehearsed fraudsters who've practised the call. Treat it as research, not as a control you can rely on.
Manual review queues
If your fraud team's response to a fraud problem is to send more transactions to manual review, you're moving the cost from chargebacks to operational overhead while degrading the customer experience for legitimate buyers. Manual review has a place — for genuinely high-risk segments — but as a default it's a sign the upstream controls aren't working.
Knowledge-based authentication on the agent side
Asking the customer to confirm their last three transactions is a fraud control if the data is hard to get. It isn't anymore. Statement-level transaction history leaks regularly through breached online banking sessions, phishing, and SIM-swap attacks. KBA via agent script gives you the comforting feeling of having done something without the underlying fraud reduction.
The PCI angle nobody talks about#
Fraud and compliance get treated as separate problems. They shouldn't be. PCI DSS v4.0.1 requires you to know where cardholder data is, who has access to it, and how it's protected. If your contact centre handles card numbers on calls, those calls and recordings are in scope, your agents are in scope, your CCaaS provider is in scope, and your fraud problem just got tangled up with your audit problem.
The merchants we work with treat this as one decision. They remove the card data from the agent's environment, which simultaneously reduces fraud exposure (no agent can mishandle data they never see) and shrinks PCI scope to the smallest set of systems possible. The auditor's job and the fraud team's job get easier at the same time.
What v4.0.1 actually demands of contact centres
The current standard (v4.0.1, mandatory since March 2025) tightened a few things that matter to contact centres specifically. Requirement 3.2.1 makes the storage of sensitive authentication data after authorisation prohibited — that includes CVV captured on calls. Requirement 4.2.1 covers transmission of cardholder data over public networks, which now explicitly includes voice telephony where it carries PAN. Requirement 12.6.3 requires security awareness training that addresses the specific threats your channel faces — which means generic e-learning isn't enough if your agents handle phone orders.
The scope reduction maths
If your contact centre takes cards by agent today, your PCI scope includes: every agent workstation, every desk phone, your CCaaS platform, your call recording system, your transcription tool, the LAN segments those sit on, the people who administer them, and the entire identity stack that controls access. A QSA looking at that environment will find findings. Hundreds of them.
Move to DTMF masking with channel separation and the same scope drops to: the masking provider's tokenisation environment (their problem, not yours), and your point-of-integration to your payment processor (a thin API call). Your agents are out of scope. Your recordings are out of scope. The audit becomes a 60-page SAQ instead of a 400-page Report on Compliance.
What auditors actually look for in 2026
QSAs have got noticeably more rigorous about contact-centre scoping under v4.0.1. The pattern we hear is: assume cardholder data is everywhere unless you can prove segmentation. Prove segmentation means network diagrams, change-control evidence, penetration tests against the segmentation controls, and quarterly verification that the controls still hold. If you're handling cards in your contact centre and you can't produce those artefacts on demand, you have an audit problem regardless of whether you have a fraud problem.
Industry-specific patterns we see#
The shape of phone fraud varies by sector. Some patterns from the UK merchants we work with.
Housing associations
Rent payments by phone are a magnet for impersonation fraud — a fraudster calls in claiming to be a tenant, pays £200 on a stolen card to settle "arrears," and the real tenant only finds out when their bank reverses the credit weeks later. The housing association eats the chargeback and the original arrears reopen. We've seen housing associations cut this to zero by sending payment links to the tenant's registered mobile rather than taking cards on inbound calls — the fraudster can't intercept an SMS to a number they don't control.
Insurance brokers
Phone-renewal premiums are high-value and seasonal, which makes them attractive to fraud rings. The common attack is mid-term policy adjustments — a fraudster who's compromised a customer's email calls the broker, requests an address change, then makes a payment on a fresh stolen card "for the adjustment premium." Brokers we work with now require all mid-term adjustments to flow through a verified portal, with phone calls used for service rather than for payment changes.
Contact-centre BPOs
If you're running a contact centre on behalf of multiple clients, you've got the worst of both worlds: every client has different fraud risk profiles and different tolerance for friction, your agents context-switch constantly, and your fraud rate gets blamed on you whether the upstream cause is your control failure or the client's product. The BPOs that handle this best build a shared masking and authentication layer that applies to every client, with per-client policy on top.
FX bureaux and international transfers
Phone-initiated FX transactions get hit hard by social engineering — fraudsters claim to be a customer's relative needing emergency funds. The control isn't fraud screening on the card transaction; it's mandatory cooling-off periods and out-of-band customer verification before any high-value transfer settles. We've seen FX bureaux eliminate this attack class entirely by introducing a 30-minute hold and a verification call-back on transactions over £1,000.
The standard alternative model — and why we built differently#
The conventional model in UK contact-centre payments is pause-and-resume — the agent pauses the call recording while taking card details, then resumes it once the payment is done. It worked when call recording was the only PCI exposure to worry about. It doesn't anymore.
Pause-and-resume has three structural problems
One: it depends on the agent remembering to pause, and audit logs across UK contact centres show pause failures of 0.5-3% even with well-trained teams. Two: it doesn't remove the agent from scope — they still hear, type, and could memorise or photograph the card. Three: it does nothing about the social-engineering attack surface. Your fraud problem is unchanged.
Why we chose channel separation over recording pause
DTMF masking with full channel separation — the model we built Paytia on — drops the audio for the card-entry window so the recording cannot capture PAN even if pause logic fails. Card digits travel on a separate data channel directly to the tokenisation environment. The agent stays on the call, can talk to the customer normally, and never has access to the digits at any layer. That's a structural change, not a behavioural one. It doesn't depend on training or process discipline to hold.
The cost comparison most procurement teams miss
Pause-and-resume systems look cheaper on a per-seat licence. They're not, once you cost the agent training, the QA overhead of catching pause failures, the compliance documentation to defend the model in audit, and the chargeback exposure that doesn't go away. The merchants who've done the proper TCO comparison consistently come out in favour of removing card data from the agent's environment, not just hiding it from the recording.
Where to start if you've inherited a mess#
If you've just landed at a contact centre with a fraud problem and you've got 90 days to make a dent, here's what we'd do.
Week one: pull last quarter's chargebacks by reason code, by agent, by product, by acquisition channel. Find the patterns. Most of the time, 80% of your loss is in 20% of your operation.
Week two to four: stop card data reaching agents. DTMF masking deploys in days, not months, and shuts down agent-mediated card mishandling as a class of fraud.
Month two: rewrite your authentication script. Cut the number of agent-asked verification questions and move identity to the customer's own device wherever you can.
Month three: get fraud-rate-per-agent into your QA dashboards. Even if you do nothing else with the data, the visibility changes behaviour.
Anything bigger — voice biometrics, behavioural analytics, agent-screen monitoring — comes after you've done the basics. We've never seen those tools fix a fraud problem in a centre that hadn't sorted out the structural stuff first.
The 90-day playbook in detail
The plan above is the headline. The detail that makes it work is in the sequencing. Don't try to run all of these in parallel — you'll burn out your fraud team and produce mediocre output on each. Run them serially. Each one creates the conditions for the next.
The chargeback analysis in week one tells you whether your problem is concentrated (a single agent, product line, or channel) or distributed (a structural problem with your authentication). The shape of the answer changes what you do in week two. Concentrated problems get tactical responses — additional training, agent coaching, removing a specific product line from phone sales. Distributed problems need the structural changes — DTMF masking, payment links, scope reduction.
What to do in month four onwards
By the end of month three you should have visibility you didn't have before, a fraud-rate-per-agent baseline, and the first quarter's data on whether the structural changes are working. Month four to six is when you can sensibly evaluate voice biometric watchlists, AI-call-analytics pilots, and the more sophisticated fraud-screen integrations. These cost money and political capital — don't burn either before the basics are working.
Where Paytia fits#
We're not a fraud-screening company. We don't sell a risk score, a velocity engine, or a chargeback management platform. Plenty of good products do those jobs and we'll happily recommend the ones we've seen work.
What we do is remove the card data from the call. That single change — done properly, with full channel separation and a working integration to whichever payment processor you use — knocks out the largest category of contact-centre fraud we see, before any fraud-screening tool runs. Customers in UK contact centres typically see chargeback rates on phone orders drop within the first full quarter of go-live. Combined with the PCI scope reduction, it's usually the highest-ROI control you'll deploy this year.
If you want to see how it works against your specific call flow, we'll run you through a live demo on a sandbox account with your own test cards. We don't need a procurement process to do that — book a call, we'll show you the masked audio, the tokenised card capture, and the chargeback data from a comparable merchant who went live last year. If it doesn't fit your problem, we'll tell you. If it does, we deploy in days, not months.
