Why do deepfakes and bots force organisations to rethink fraud prevention and customer experience together?

Why This Matters for Security Teams

Deepfakes and bots change fraud from a simple authentication problem into a trust and experience problem. A single verification step no longer tells a security team whether the person, device, and session are all genuine, especially when synthetic media can mimic voice, face, or chat behaviour across channels. The result is a growing gap between fraud controls designed for humans and attack paths designed for automation.

That gap matters because every additional check can reduce approval rates, increase abandonment, and frustrate legitimate customers. At the same time, weak controls let attackers pass step-up checks, take over accounts, or use bot traffic to probe recovery flows and payment paths. Current guidance suggests measuring fraud loss and customer drop-off together, not as separate programmes. NIST control guidance on identity assurance and monitoring is useful here, including NIST SP 800-53 Rev 5 Security and Privacy Controls, because the problem spans detection, authentication, and response.

In practice, many security teams encounter rising fraud only after customer support, account recovery, and payment failures have already become the attacker’s preferred entry points.

How It Works in Practice

fraud prevention now has to evaluate more than a static credential or one-time challenge. Organisations are moving toward layered signals that combine device reputation, behavioural anomalies, session risk, transaction context, and velocity checks. Deepfakes and bots are especially effective when legacy controls assume that voice, image, or typed answers are trustworthy indicators on their own. That assumption no longer holds.

A practical programme usually separates decision points by risk tier. Low-risk actions can proceed with lightweight friction, while high-risk actions such as password resets, beneficiary changes, or large transfers trigger stronger verification. This is where identity proofing and trust frameworks become relevant. For regulated digital identity and stronger assurance concepts, eIDAS 2.0 -- EU Digital Identity Framework provides a useful policy reference, while AML and KYC-driven programmes often align with FATF Recommendations -- AML and KYC Framework.

NHI visibility also matters because fraud teams increasingly find automation hiding behind compromised service accounts, API keys, and backend workflows. NHI Mgmt Group research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is relevant when bot-driven fraud pivots into systems that were never designed for customer-level scrutiny. The same guide also notes that only 5.7% of organisations have full visibility into their service accounts, which makes it difficult to distinguish legitimate automation from abuse.

For this reason, fraud and CX teams should tune controls together: monitor challenge pass rates, abandonment, false positives, and downstream loss; then adjust thresholds by journey rather than by channel alone. These controls tend to break down in high-volume contact centres and app sign-in flows because attackers can test thresholds faster than analysts can recalibrate them.

Common Variations and Edge Cases

Tighter fraud controls often increase abandonment and support load, requiring organisations to balance loss reduction against conversion and customer trust. There is no universal standard for this yet, so the best approach is evolving: some journeys justify aggressive friction, while others need silent risk scoring with delayed review.

Edge cases matter. Voice deepfakes can be especially effective in call centres where agents rely on conversational familiarity, while bots can overwhelm public-facing onboarding with synthetic traffic that looks legitimate at the session level. In those environments, a single bot signal should not automatically block a user, because shared networks, mobile carriers, and accessibility tools can create false positives.

Practitioners should also distinguish between customer-facing fraud and backend abuse. NHI issues such as leaked keys or over-privileged automation can create fraud paths that bypass the customer entirely. NHIMG case studies like the Schneider Electric credentials breach and Gladinet Hard-Coded Keys RCE Exploitation show how credential exposure and automation weaknesses can become broader trust failures, not just isolated security incidents.

That is why current guidance suggests treating fraud controls as part of the customer journey design, not just the security stack. When that separation is ignored, organisations usually discover the mismatch after approval rates drop or fraud losses climb, rather than during controlled testing.

Related resources from NHI Mgmt Group

• How can merchants balance fraud prevention with customer experience?
• How do organisations balance fraud prevention and user experience in identity flows?
• Why do deepfakes and synthetic applicants force organisations to rethink onboarding controls?
• How should fraud and identity teams prepare for AI-driven fraud, deepfakes, and bots in customer onboarding?