Payment Fraud Red Flags — What Agents Should Watch For

Last updated: 29 May 2026

If you run a UK contact centre that takes card payments by phone, you already know the fraud picture. CNP fraud is now the single biggest category of card-fraud losses in the UK, and the people on the front line are your agents. They're the only humans in the loop. So when somebody asks us what payment fraud red flags they should drill into agent training, we always start with the same point — the giveaways aren't in the card data, they're in the call itself.

This is the guide we wish every new agent read on day one. It walks through the red flags that actually correlate with chargebacks and confirmed fraud in real contact centres, plus the structural fixes that mean a missed red flag doesn't end with stolen card data sitting on a call recording. If you're starting further back, our pillar on contact centre fraud detection guide sets the wider scene.

Why payment fraud red flags matter more in a contact centre#

Online checkouts get most of the fraud-prevention budget. 3DS2, device fingerprinting, behavioural biometrics, velocity rules — the e-commerce side of CNP has layers. The MOTO (mail order / telephone order) side often has none of that. The card-acceptance environment is one agent, one headset, and a customer's voice. And almost every traditional control we use online is missing.

There's no device fingerprint on a phone call. There's no IP address to geolocate. 3DS2 doesn't reach into a voice channel by default — you'd need agent-assisted payment links or a pay-by-link flow to invoke it. The fraudster knows all of this. That's why social engineers love the phone channel. It's the soft underbelly.

The implication for training is direct. If your agents can't tell the difference between a stressed customer and a fraudster running a script, the loss isn't going to come back. The merchant carries the chargeback. We've watched mid-sized merchants take five-figure hits from one well-rehearsed caller in an afternoon. Drilling agents on red flags is the cheapest fraud control you can deploy — it just isn't sufficient on its own.

The behavioural payment fraud red flags that matter#

Forget the BIN ranges and country lists for a second. The strongest single predictor we see is conversational. Fraudsters under time pressure sound different from real customers under time pressure, and once you've trained an ear for it, the gap is wide.

Unusual urgency. The caller invents a hard deadline. The order has to ship today. The booking will be cancelled in 10 minutes. The senior manager has already approved it and is waiting. Real customers occasionally have genuine deadlines, of course, but fraudsters lean on urgency to keep an agent from stopping to think. Anything that pushes an agent to skip a verification step is a flag in itself.

Scripted urgency-flips. When an agent asks a clarifying question, a real customer might get irritated, but they answer. A fraudster often flips registers — friendly to angry, polite to aggressive — because the script's job is to get past the question, not answer it. If the tone changes the moment your agent asks for postcode confirmation, write it down.

Refusal to be put on hold. Fraudsters running a live session against stolen credentials don't want any pause that lets the agent verify something independently. If a caller refuses a hold or insists you stay on the line during the payment step, that's anomalous. Genuine customers will hold for almost anything if you explain why.

Multiple declines followed by a successful retry. A real card on file shouldn't decline three times for AVS mismatches and then suddenly work. What you're usually watching is a fraudster trying multiple stolen cards from the same caller, or testing variations of expiry / CVV. Even one decline followed by a second card from a "different account" warrants a callback to a known good number.

Unprompted CVV or PIN offers. An agent should never ask for the PIN, and CVV gets captured directly into the masked payment flow, not read aloud. A caller volunteering either, especially without being prompted, is a strong signal they're working a script that expects you to want them.

Card-data red flags worth knowing#

The card-data side is weaker than the behavioural side, but it's not zero. The challenge is that with DTMF masking switched on — which is exactly where you want to be — the agent doesn't see the PAN. So this section matters most for the pre-capture conversation, and for the small subset of payments that happen via payment links rather than live keypad entry.

The classic BIN-vs-billing-country mismatch still works. If the first six digits of the card resolve to a US-issued card and the billing address is a UK postcode, that's not impossible, but it's a flag. Issuer-mismatch chargebacks are over-represented in fraud data because the fraudster is using a card they harvested somewhere else.

The same goes for the velocity pattern. Three transactions on the same card in the same hour from the same caller, especially split across order references, is the kind of pattern an automated rules engine catches at the payment-gateway layer. Phone payments often bypass those checks because the agent submits the transaction as a CNP keyed entry. Talk to your gateway provider about extending velocity rules to the MOTO MID. Most do this, and almost none of our clients have it switched on when we ask.

If you're not sure how your tokenisation flow protects against the velocity case, our DTMF masking explainer covers how the digits move from caller to gateway, and where the rules engine can see them.

The social engineering red flags agents miss most#

Social engineering is its own art form, and the contact centre version usually targets either the agent (impersonating a senior manager, requesting an urgent refund) or the customer's account (impersonating the customer, requesting a card-on-file charge to a new shipping address). The patterns are well documented. We've written about the defence side in social engineering attack defence for contact centres, but here are the red flags we drill into training.

Authority claims that can't be verified inside the call. "This is John from finance, the CEO needs this paid by 5pm." The detail of the authority claim isn't the point — the impossibility of verifying it without breaking the urgency is. Agents should have a fixed answer: any internal authority request needs to be confirmed via a known internal channel, full stop. No exceptions for urgency.

Account-takeover patterns. A caller phones in claiming to be a customer, knows enough detail to pass basic KBA (knowledge-based authentication), and then asks to change the shipping address or update the card on file "to my new card". This is the textbook ATO setup, and the red flag is the combination — either request on its own is normal, but the pair together inside one call is a strong indicator. The fix is to delay the second request 24 hours and confirm via the on-file email address.

Vishing patterns. A caller claims to be from your bank, your payment processor, or your fraud team. They want the agent to read out card data or process a "test transaction". This is straight vishing, and it works because contact centres are trained to be helpful. Our companion piece on vishing detection for contact centres goes deeper into the script structure.

The cleanest defence is structural. If your platform is set up so that no agent can hear or repeat back card data — which is what DTMF masking delivers — then a vishing caller asking the agent to read a card number aloud is asking the impossible. The agent can say "I literally can't see it", which is both true and a fantastic dead end for the attacker.

Why agent training alone isn't enough#

We get asked, more than we'd like, to recommend an agent-training programme as the sole fraud control. Training matters, but the maths doesn't work. Even with a 95% catch rate — which is ambitious — the 5% miss rate compounds across thousands of calls. A mid-sized contact centre running 50,000 MOTO calls a quarter is still letting through 2,500 attempted frauds a quarter on a 95% catch.

The structural fixes change the calculation. With DTMF masking, the agent never hears the digits, so a momentary lapse in attention doesn't put PAN on a call recording. With channel separation, the card data path is physically separate from the voice path, so a compromised agent workstation can't exfiltrate card data. With tokenisation at the gateway, the card-on-file changes happen in a system that velocity-checks every attempt.

The pattern we see in clients like Pinnacle Group, who cut PCI scope by 95% by moving to DTMF capture, is that fraud red flags become a layered control. Agent spots the behavioural flag, escalates, but the structural controls have already done the heavy lifting. The merchant carries less risk per call, the agent is less stressed, and the audit trail is cleaner.

Building a red-flag escalation flow#

Spotting a red flag is half the job. The other half is what the agent does next. We've sat in too many calibration sessions where agents flagged something internally and then carried on with the payment anyway, because the escalation flow was vague. Here's the structure we recommend, refined across roughly two hundred client deployments.

First, give agents a one-word interrupt they can drop into the call to pause the flow without alarming the caller. Something neutral like "let me check the system on that for you" buys 30 seconds and doesn't tip off a fraudster. Second, have a named senior on shift whose job is to take red-flag escalations within 60 seconds, no exceptions. If the senior is in another meeting, the meeting waits.

Third, document the call-back protocol. When in doubt, the agent says "I'll need to call you back on the number we have on file" and ends the call. A real customer might be annoyed, but they'll appreciate the security position. A fraudster won't be on the file number. This single step kills more vishing attacks than any technical control we've seen.

Fourth, and this is the one people skip, log every red flag whether it converted to a confirmed fraud or not. Without the false-positive data, you can't tune the training. The agents who flag the most aren't the most paranoid — they're the most accurate. Reward the behaviour.

How red-flag data feeds the bigger fraud picture#

The red-flag log we just described isn't only for training. It's also the input to a fraud-detection programme that can actually learn. If you're feeding agent-flagged calls into your gateway's fraud rules, your payment processor's risk team, or a dedicated fraud-detection tool, the signal quality is much higher than the average chargeback dataset. Agents who flagged at the moment of payment know things the chargeback record never captures.

We've written a deeper piece comparing the tooling side in fraud detection tools comparison, but the short version is this: the best tools are the ones you can feed live signal into, not the ones with the prettiest dashboards. If your agent flagged 47 calls last quarter and 31 turned into chargebacks, that's a 66% precision rate. That precision is what makes the rules engine useful.

For the regulatory angle, contact centres in regulated industries — finance, insurance, healthcare — increasingly need to evidence that they're actively monitoring for fraud as part of broader risk frameworks. The red-flag log is exactly that evidence. It's the artifact an auditor wants to see.

The red flags we wish more people knew#

A handful of patterns come up regularly that don't make the standard training decks, mostly because they're harder to teach. We'll list them here because they're load-bearing in practice.

The caller corrects themselves on the billing postcode. Real customers know their own postcode. A fraudster reading from a stolen-data dump sometimes reads the wrong line and corrects mid-sentence. If you hear "sorry, that's the previous address" without prompting, ask for date of birth and last four of a different on-file card.

The caller asks the agent to repeat the card number. This is a tell that the fraudster wants to confirm the card the agent has accepted into the system, in case they're about to need to use it elsewhere on the same call. With masked capture, the agent can't comply, which already kills the vector. But the request itself is diagnostic.

Conference-call audio in the background. Some fraud operations run a call-centre setup themselves — you can hear other agents on other calls in the background. Real residential customers don't sound like that. A subtle but reliable flag, and worth a code in the agent's red-flag log.

Payment method changes mid-call. The caller starts with one card, it declines, they offer a second card, that one also declines, and then they suggest a bank transfer to a new account number. This is the layered ATO pattern — fraudster's looking for any working method — and it's worth a hard stop and a callback.

What the structural fixes actually do#

We've referenced the structural side throughout. Let's pin down what each control actually defends against, because that's the question we get most often when an ops director is choosing between options.

DTMF masking removes the card data from the voice path. The customer keys the digits, the agent hears suppression tones, the digits go directly to the payment gateway. The fraud red flag this defends against is "agent overhears or writes down the card data" — either by accident or under social-engineering pressure. It also takes call recordings out of PCI scope, which is most of the audit pain gone.

Channel separation goes further. The card data path and the voice path are physically separate from the moment the caller pushes a digit. A compromised agent workstation, a malicious endpoint, even a wiretap on the voice channel — none of them see the card data. This is the model we use for our regulated clients. There's more on the tradeoff in DTMF masking vs channel separation.

Tokenisation at the gateway means that even when you do store a card on file for repeat customers, what you're actually storing is a token — useless if exfiltrated. Combined with velocity rules at the gateway, this kills the "three retries on three different cards" pattern at source. The token is bound to the merchant and the use case.

None of these replace agent training on red flags. They make agent training a lighter lift, because the cost of a missed flag is much smaller. That's the layering people sometimes miss.

Common mistakes we still see in 2026#

Last point before the wrap-up. There are three structural mistakes we see again and again in UK contact centres, often in otherwise well-run operations. Naming them here because if you fix these, you're ahead of most of the market.

Pause-and-resume call recording. Still in use widely, still the wrong answer. The agent has to remember to pause, has to remember to resume, and the resulting call recording has a gap that's auditable but doesn't actually descope PCI — the system that captured the digits is still in scope. We've covered this in our pillar on contact centre fraud detection. The fix is masked capture from the start.

Storing CVV on file. This is forbidden by PCI DSS but still happens, often in homegrown CRM extensions where the field was added by an old developer and nobody removed it. Audit your customer database for CV2-shaped fields. If they exist, they need to go.

Treating fraud red flags as a quality metric. If your QA scorecard penalises agents who flag too many calls, you've broken the incentive. Flagging is the desired behaviour. Penalise low flag rates on agents whose calls show chargebacks, not the reverse.

Industry-specific red-flag patterns#

The general red flags hold across every contact centre, but specific industries see specific fraud shapes. We've watched the same script play out across our client base, and the pattern by sector is worth calling out because it changes how you weight the flags.

Insurance contact centres see an unusually high rate of policy-funded fraud — the caller is using a stolen card to pay the first month's premium on a policy they'll never claim against, which is a quick way to launder card data. The red flag here is the combination of a brand-new policy, a card that doesn't match the named insured, and a request to set up direct debit immediately to "avoid the card charge next month". Our insurance contact centre fraud detection guidance goes into the wider operational pattern. The card-on-file step is the moment the fraudster transitions from disposable card to a stable funding source, so the flag matters.

Healthcare and clinic billing sees a different shape: refund fraud. The caller phones in claiming to be a patient, asks about a recent bill, and either pretends the payment failed or claims they were double-charged. The agent issues a refund to a different card than the one originally used — and the original card was real, but the refund-receiving card is the fraudster's. The red flag is any refund request with a card mismatch. Even one digit different on the PAN, or a different last-four, should be a hard stop with a manager review.

Utilities and subscription services see card-testing patterns more often than full-account ATO. A fraudster will phone in with a stolen card and pay a small balance — £20 on a utilities top-up, say — purely to validate that the card works. They never come back. The red flag is a single small payment from a caller who isn't an existing customer, especially if they're paying someone else's account by reference number. Worth flagging even on a £15 payment.

Finance and lending operations see ATO patterns aimed at moving money out of compromised accounts. The caller phones in claiming to be the account holder, asks to update beneficiary details, and then immediately requests a payment. The red flag is the speed — beneficiary changes should always come with a cooling-off period for exactly this reason. If your platform doesn't support that, build it manually into agent workflow.

What good fraud reporting looks like#

Most contact centres we audit have fraud data, but it's the wrong shape. A monthly report that says "we had 47 chargebacks last month, here's the trend line" is not actionable. The team can't tell which agents are flagging well, which red flags are converting to confirmed fraud, or whether last week's training session moved the needle.

What works is a weekly dashboard with three views. First, flag-rate-by-agent — who's flagging, who isn't. Second, flag-to-confirmed-fraud conversion rate — the precision metric we mentioned earlier. Third, time-to-escalation — how long between an agent dropping the interrupt phrase and a senior taking the call. That third metric is the one that catches process breakdowns. If escalations are taking five minutes on average, you don't have an escalation flow, you have a wishlist.

The chargeback feed should be tagged back to the original call. Most chargebacks arrive 30 to 90 days after the payment, so the link is easy to lose. If you can get the chargeback record back to the original call recording (or, in a masked-capture environment, the call metadata), you can ask the deeper question: did the agent flag this one? If yes, what happened at escalation? If no, what red flags do we wish they'd caught?

This is the loop that makes red-flag training actually improve over time. Without it, you're guessing. With it, you have an evidence base for everything from agent coaching to QA scorecard design to gateway rule tuning.

Where machine learning helps and where it doesn't#

We get asked about machine-learning fraud detection a lot, and the short answer is that ML is great at velocity patterns and bad at conversational patterns. A model trained on chargeback data will catch the BIN-mismatch and the three-cards-in-an-hour case before the agent does. It won't catch the scripted urgency-flip, the refusal to be put on hold, or the conference-call background audio. Those signals don't make it into structured data.

So the right framing is layered. Run an ML model at the gateway layer — most modern payment processors have one built in, and they're cheap or free to switch on. Use the model for the data-driven flags. Use the agent for the behavioural flags. Feed the agent-flagged calls back into the model's training data as positive examples, which improves precision over time. There's more on the technical detail in our piece on machine learning fraud detection.

One thing to watch: model drift. A fraud-detection model trained on 2023 chargeback data is going to flag patterns that aren't the patterns of 2026. The fraudster economy moves fast. If your model precision is dropping month-over-month, ask when it was last retrained. Most processors retrain quarterly; some annually. The annual-retrain ones are noticeably worse.

Red flags during high-volume periods#

Black Friday week, Christmas, and the post-tax-year-end rush in April all share a feature: fraud rates spike. Not because fraudsters change behaviour, but because legitimate traffic also spikes and the noise floor rises. Agents under load are less likely to flag. Senior escalation queues get longer. The interrupt phrase that buys 30 seconds gets shortened because everybody's behind.

The countermeasure is structural again. Set the gateway's velocity rules tighter during high-volume periods, even at the cost of some legitimate-customer friction. Bring on dedicated fraud-shift seniors who don't take regular calls and are available purely for escalations. Pre-brief the team on the seasonal scripts you've seen before — the "my parents bought me this gift but the card declined" Christmas pattern, the tax-rebate variants in April. Most fraud teams already know these. The agents on the floor often don't.

This is the period where the layered approach pays off. The structural controls keep working at constant quality even when agents are exhausted. The agent training catches the new-pattern fraud the model hasn't seen yet. Together, the merchant gets through peak season without a chargeback spike of their own.

How red flags map to PCI DSS v4 requirements#

If you've been through a recent PCI assessment, you'll know the v4 changes added pressure on contact centre operators around the agent-data-touch points. Requirement 12.6 in particular pushes for ongoing security awareness training tied to specific role responsibilities, which in a contact centre means agent fraud awareness has to be evidenced, not just delivered. The red-flag log we described is exactly the evidence trail a QSA wants to see.

Requirement 8.3 on multi-factor authentication ties to a less obvious red flag — agent-impersonation calls aimed at internal IT. We've seen fraudsters phone the contact centre IT desk pretending to be a struggling agent, asking for a password reset on a workstation that has access to the payment platform. The right MFA setup makes this fail. The wrong one — typically SMS-based MFA with a recovery flow that doesn't require in-person verification — makes it easy. If your agents reset passwords by phone, that's a red flag for your own auditor before it's a fraud problem.

For the wider picture on how v4 changes the contact centre control set, our PCI DSS v4 for contact centres page covers the practical adjustments. The short version is that the v4 update made agent training a continuous obligation rather than an annual tickbox, and red-flag logging is one of the cheapest ways to evidence ongoing compliance.

The role of CVV in fraud detection#

The CVV (or CV2, depending on your scheme) is sometimes treated as a fraud-prevention magic bullet. It isn't. It's a useful signal but it has well-known limits, and overweighting it in agent training causes problems.

The strength of CVV is that it's printed on the physical card and not embossed, which means data dumps from compromised magnetic-stripe operations historically didn't include it. So a caller who has the PAN but not the CVV is more likely to be a fraudster working from a stripe dump. The weakness is that modern data breaches almost always include CVV, especially if the merchant was storing it in violation of PCI DSS — which still happens. A caller with the full PAN, expiry, and CVV could be legitimate, could be a fraudster with a richer dataset.

So in agent training, teach CVV as a contributor signal, not a decisive one. A clean CVV match plus everything else looking right is reassuring. A clean CVV match with behavioural red flags is not reassuring — the fraudster bought a richer dataset, that's all. Our CVV / CVC / CV2 glossary entry covers the technical detail. The key point for fraud detection is that no single data field changes the verdict if the conversation itself is off.

What we tell new contact centre clients in week one#

When a new client onboards onto our platform, week one isn't about the technology — that's already configured. It's about the operational change. We sit with the agent team and walk through the red-flag inventory, the escalation flow, and the QA scorecard. Then we run two days of side-by-side calls where a senior listens in on every payment and coaches in real time. By day three, the agents are flagging without prompting and the senior is intervening less.

The single biggest improvement we see in week one is in escalation speed. Agents who used to hold a suspicious call for two or three minutes while they tried to decide what to do are now escalating in 20 seconds. That speed comes from confidence, and the confidence comes from knowing the escalation flow exists and works. The structural controls behind them — masked capture, tokenisation, gateway velocity rules — mean the agent can escalate without worrying that the data has already leaked.

The second improvement is in QA quality. With the flag log in place and tied to outcomes, the QA team has a real conversation rather than a generic checklist. Coaching conversations get specific. Agents see the precision metric and understand what "good" looks like. And the chargebacks drop, usually within the first 60 days.

Next steps#

The fastest way to derisk a phone-payment operation isn't a new training video. It's the structural fix that makes the agent's job easier and the auditor's job shorter. If you want to talk about how DTMF masking, channel separation, and tokenised card-on-file would fit your contact centre, get in touch and we'll book a 20-minute call. If you'd rather see it working first, the live demo walks through a real masked card capture in under 90 seconds.