AI Fraud Prevention: Tools and Best Practices

Fraud prevention has been a transaction problem for two decades, and the tools built for it do that job well. They score a payment against behavioral baselines, check an identity at onboarding, read a device signal, and hold a transfer that falls outside the pattern.

Generative AI (opens in new tab) has not degraded that work. What it changed is the time and effort (opens in new tab) an attacker spends on the two things fraud depends on most: a believable identity and a credible pretext, so more of that fraud now reaches you and your customers.

This article covers what an AI fraud prevention stack contains, what the payment layer can and cannot decide, and the practices that cover the rest.

Key takeaways

• What changed: a convincing identity and a plausible story got cheap, so techniques that once ran against one target now run at population scale.
• Where the gap sits: the capabilities covering the Setup, Launch, and Engagement stages usually sit on a security or HR team's SLA.
• What closes it: detection paired with takedown authority outside your perimeter, and rehearsal for the people who authorize payments.

AI fraud prevention now spans two jobs and two fraud surfaces

AI fraud prevention describes two jobs at once: using AI to detect and disrupt fraud, and defending against the fraud that AI made cheap to produce.

It also spans two surfaces that fraud and security teams used to handle separately: the payments your organization authorizes and the scams attackers run against your customers in your name.

Attackers reuse the same generated identities, pretexts, and infrastructure across both.

AI now sits on both sides of the fraud problem

Defensively, AI means models that score payment risk in real time, correlate signals across channels, and automate investigation work analysts once did by hand. Offensively, attackers use it to produce generated lures (opens in new tab), synthetic voice and video, and fake profiles and portals at volume.

Just 17% of US organizations (opens in new tab) surveyed use AI to fight payments fraud, even as attackers increasingly build that fraud with it.

Your own payments and your customers' payments share one origin

Both surfaces draw on the same fabricated identity and the same registered infrastructure. The brand impersonation (opens in new tab) that redirects a supplier payment (opens in new tab) and the lookalike checkout page a customer pays into are products of the same craft, so a program that covers one surface leaves the other exposed.

What a fraud prevention stack covers, and who holds each part

Five categories of technology do the work of fraud prevention, and they engage at different points in the social engineering attack chain (opens in new tab): Setup, Launch, Contact, Engagement, and Compromise.

A sixth capability spans the whole stack. Mapping each category to the stage it engages is what makes the gaps visible.

• Transaction risk scoring. Scores a payment or a session in real time against behavioral baselines, velocity rules, device fingerprints, and known fraud patterns, then holds or declines what falls outside them. It is the densest part of most stacks and the part with the clearest owner. Engages at Compromise.
• Payee verification and scam interdiction. Matches an account name before a transfer completes, raises warnings on payments that fit a scam pattern, and holds the ones that look coached. This category was built specifically for payments the customer authorizes, which makes it the closest thing the stack has to a control aimed at persuasion. Engages at Compromise.
• Identity verification. Confirms a person matches the identity (opens in new tab) claimed through document checks, selfie matching, and liveness detection, at account opening and at step-up. The onboarding gate it guards is also where an attacker opens the mule account that carries the fraud. Engages at Setup.
• Email and message security. Filters the lure before it reaches a person and removes what already landed. It reaches further up the chain than the payment controls do, and its evidence is the message itself, which arrives after the attacker has already built what sent it. Engages at Contact.
• External impersonation detection. Finds the lookalike domains, fake support numbers, spoofed profiles, counterfeit apps (opens in new tab), and scam ads (opens in new tab) an attacker registers to run the fraud. Digital risk protection (opens in new tab) is the common name for this category, and what a given provider can do about a finding varies widely. Engages at Setup and Launch.

Human risk management (opens in new tab) and simulation are a supplementary sixth capability at Engagement, where they rehearse the people who authorize payments and reset credentials.

Ownership varies by organization, and a fraud program usually holds the first three categories directly. The other two, external impersonation detection and human risk management, more often sit elsewhere.

When detection of external impersonation sits on a security team's SLA and the fraud team is measured on the losses it prevents, the fraud program owns the outcome without owning the control.

Why the payment layer cannot decide this alone

Payment firms can be pushed about as hard as regulation and engineering allow and still leave the outcome decided elsewhere. One national-scale case shows the limit, and two things outside the payment layer's reach explain it: the conversation that produces the payment, and the infrastructure that stages the conversation.

The UK deployed name-matching at scale, and losses still rose

Name-matching now covers over 99% (opens in new tab) of Faster Payments and CHAPS transactions, and from October 2024 reimbursement for authorized push payment (APP) scams became mandatory, which gave payment firms a direct financial reason to stop these payments before they leave.

In the UK, losses still rose 19% (opens in new tab) to £576.4 million in 2025 while case volume rose 7%, so loss per case grew as well. Name-matching catches a payment sent to the wrong name. A coached victim sends money to the right name for the wrong reason. Cases that started online or by phone carried 83% of the volume and 60% of the losses.

The persuasion runs on channels your fraud telemetry does not reach

The exchange that produces the authorization runs on a phone call, a chat thread, or a spoofed portal outside your instrumentation, and by the time a payment appears the decision behind it is already made.

It is often the first live attempt the person on your side has handled. In one $25 million case, a finance employee at an engineering firm joined a video conference in which the other participants were AI-generated deepfakes of colleagues and approved a series of transfers.

The firm's CIO, Rob Greig, later called it technology-enhanced social engineering (opens in new tab), noting that no systems were compromised and no data was affected, because the deception played out before any payment reached the company's controls.

The attacker's work happens outside your measurement window

A fraud program's telemetry opens when a session opens or a payment initiates. The infrastructure that carried the campaign was registered days or weeks earlier, and fraud metrics rarely cover that interval, so the work that decided the outcome sits outside the numbers the program reports on.

A November 2024 federal alert (opens in new tab) records rising reports of deepfake media in fraud schemes against financial institutions, and the growth percentages that circulate for those schemes trace back to vendors.

Best practices for covering Setup, Launch, and Engagement

The UK case shows the payment layer doing what it can do, so these practices act on the two findings after it: the conversation and the measurement window.

They sit alongside the social engineering fraud (opens in new tab) controls a security team already operates, and they are choices about how you assemble, buy, and measure the stack.

• Map the tools you own to the stage each engages. Run the five categories against Setup, Launch, Contact, Engagement, and Compromise, and mark which stages sit on another team's SLA. The exercise usually surfaces several tools evaluating the same moment.
• Require takedown authority for the layer outside your perimeter. When evaluating external detection, ask which intermediaries the provider reaches, how it escalates removal, and what proof of removal comes back. A finding you cannot act on lands in a queue.
• Insist on campaign-level correlation (opens in new tab). Ask how a provider links a domain, a social profile, a phone number, and an app to one operation. A campaign view turns a dozen separate alerts into one piece of work.
• Source rehearsals from fraud confirmed against your own brand. Turn a live lure detected against your organization into the drill your payment approvers and helpdesk agents (opens in new tab) run, delivered on the channel the attacker used.
• Measure how fast a fake asset comes down. A discovered phishing portal keeps converting until it is removed, so track median time from detection to removal and the share of a campaign's assets taken down alongside your detection metrics.

Together, these practices move a fraud program from watching another team own the earlier stages to measuring and buying for them itself.

How Doppel dismantles the infrastructure behind the fraud

Doppel covers Setup, Launch, and the people the Engagement stage targets, the part a payment control sits downstream of. Transaction risk scoring, identity verification, and payee verification stay with the tools that own them.

Doppel is the AI-native Social Engineering Defense platform: Doppel Brand Protection (opens in new tab) detects and dismantles the lookalike domains, spoofed profiles, counterfeit apps, and scam ads that carry a campaign, and Doppel Executive Protection (opens in new tab) covers impersonation of the named leaders whose authority the fraud borrows.

The Doppel Threat Graph (opens in new tab) resolves those assets into one campaign, the correlation the third practice asks for, so a single action reaches the phone numbers and messaging accounts a domain-level takedown would leave live.

Doppel's agentic AI automates investigation and prioritization, then carries out takedowns across registrars, telecom providers, hosting providers, social platforms, ad networks, and data broker sites without waiting on an analyst queue. That intermediary reach is the takedown authority the second practice asks providers to prove.

Doppel Simulation (opens in new tab), including Helpdesk Mode, uses one-click threat-to-simulation conversion to turn lures detected against your brand into rehearsals for payment approvers and helpdesk agents, the rehearsal sourcing the fourth practice calls for.

Those rehearsals run on the channels the fraud does, from voice calls using cloned audio to the Microsoft Teams and Zoom meetings the AI agent joins live, and they send follow-ups across other channels in real time, so the drill matches real attacker behavior.

Bring the earlier stages inside your fraud program

Generative AI helps fraudulent transactions carry the signals of legitimate ones, which expands the work of any program that evaluates transactions. Extending fraud metrics and ownership to the stage where an attacker registers a domain and clones a voice (opens in new tab) is how a program gets ahead of the authorized payment.

The detect-and-dismantle model raises attacker rebuild costs and shortens campaign dwell time, so a fraud program that extends into Setup, Launch, and Engagement disrupts that infrastructure before it induces a payment.

See how Doppel approaches fraud and scam prevention (opens in new tab), then request a demo (opens in new tab) to get started.