Why do passwords, KBAs and OTPs struggle against synthetic customer behaviour?

Why static proof factors fail when behaviour is synthetic

Passwords, KBAs and OTPs are all point-in-time checks. They can confirm that a requester knows a secret, can answer a challenge or can receive a one-time code, but they do not prove that the interaction is being driven by a genuine customer in a normal operating pattern. Once an attacker can script the flow or insert an AI-assisted operator, the control may still pass while the behaviour remains fraudulent.

The core weakness is that these controls were designed for authentication, not for behavioural assurance. A valid password or OTP says little about whether the session is coming from a familiar device, whether the pacing matches the real user, or whether the request sequence is consistent with prior activity. That is why they become fragile when the threat is synthetic customer behaviour rather than simple credential theft.

Fraud teams should treat the check as one signal, not the decision. The practical question is no longer only “did this actor satisfy the challenge?” but “does this session look like the same customer, on the same device, moving through the same workflow in a believable way?” That shift is what exposes synthetic behaviour that traditional proof factors miss.

What synthetic customer behaviour changes operationally

Synthetic behaviour is effective because it mimics ordinary actions instead of trying to defeat the control head-on. A deepfake operator, bot or repeat fraudster can reuse the same journey, timing and interaction style across many attempts while still presenting a valid secret or one-time code. If your verification logic only checks the moment of entry, it can miss the pattern that reveals abuse over time.

This is where behavioural context becomes essential. Device consistency, IP reputation, navigation sequence, session cadence and transaction pattern analysis help determine whether a request fits the expected customer baseline. When those signals are absent, fraud detection often becomes a series of isolated approvals that never add up to a meaningful picture of risk.

For that reason, teams should think in terms of assurance layers. Static credentials can still be useful for access control, but they are not sufficient on their own when the attacker can convincingly imitate the user journey. The more the environment depends on remote, automated or high-volume customer activity, the more important it is to correlate identity proof with behaviour and context.

Why assurance has to move from proof to pattern

The weakness is not that passwords, KBAs and OTPs are useless, it is that they answer a narrower question than fraud operations need answered. They can support access decisions, but they do not establish that the customer is legitimate, that the session is trustworthy or that the workflow is free from orchestration by a fraud ring. In synthetic fraud, the attacker’s advantage is consistency, not necessarily sophistication.

That makes anomaly detection a practical necessity. A system that can compare a current interaction with prior device, channel and transaction behaviour is far better positioned to spot orchestration, repeated automation and workflow reuse. In practice, this often means weighing friction against assurance, because every additional control must be judged against customer impact and operational throughput.

Once teams accept that the problem is behavioural rather than purely secret-based, response also changes. A failed OTP no longer matters only as an access event, it becomes one data point in a broader pattern of suspicious customer activity. The operational goal is to connect the dots quickly enough to stop the fraud path before the account, payment or onboarding flow is abused at scale.

Risk and Threat Considerations

Synthetic customer behaviour creates a control gap because the attacker can satisfy a narrow authentication test while still acting fraudulently. The result is false confidence: the organisation sees successful proof, but not the automation, impersonation or repeated workflow abuse underneath it.

Failure mechanism: Static factors verify knowledge or code possession at a single moment, while synthetic abuse exploits the absence of behavioural and device-level correlation across the session and across repeated attempts.

Impact: Fraudsters can pass the check, continue the workflow, and accumulate account takeover, onboarding abuse, payment abuse or mule-style activity before detection rules trigger.

Practitioner Guidance

What to prioritise: Treat behavioural context as part of the decision, not as an optional after-the-fact review. The most useful signals are usually device stability, session consistency, velocity, navigation sequence and repeated workflow reuse across attempts.

What to verify: Confirm that your control stack can correlate a customer action with prior interactions, not just validate a single login or challenge response. If the same profile can be replayed successfully from different contexts, your assurance is too shallow.

Decision rule: If a requester passes the password or OTP check but shows abnormal device churn, automation-like pacing or repeated transaction structure, treat the case as elevated fraud risk even if authentication succeeded.

Practitioner takeaway: The main design error is equating successful proof with trustworthy behaviour; synthetic fraud is won or lost on pattern recognition, not on the strength of a single secret.

Related resources from NHI Mgmt Group

• Guide: MFA Guide
• Why do traditional MFA methods struggle against synthetic identity attacks?
• Why do replay attacks remain effective against systems that already use passwords or OTPs?
• Why do passwords, OTPs, and push approvals still leave customer accounts exposed to takeover risk?
• Why do passwords and one-time MFA struggle against deepfake impersonation?