Why fraud tactics still work and what teams should expect next

At a glance

What this is: This webinar looks at why familiar fraud patterns still succeed, even as attackers reshape them for modern environments.

Why it matters: It matters because IAM, fraud, and identity governance teams still have to harden human verification and approval paths, not just add more tooling.

Context

Fraud often succeeds by exploiting human decision points rather than technical weaknesses. In identity terms, that means approval chains, verification steps, and exception handling can become the real target when attackers adapt old schemes to current workflows.

This webinar uses Frank Abagnale’s fraud perspective to show why older tactics still work and how scammers adjust them for the modern age. The identity lesson is not about nostalgia. It is about how verification designed for routine business processes can still be manipulated when trust is granted too easily.

Key questions

Q: How should security teams reduce fraud risk in identity-heavy workflows?

A: Focus on the points where identity trust is most vulnerable: enrolment, account recovery, profile changes, and payout or transfer approval. Add stronger verification, step-up checks, and behavioural monitoring at those decision points. Fraud is easier to stop when the organisation limits what a compromised identity can do, not just when it notices the compromise.

Q: Why do old fraud tactics still work in modern enterprises?

A: Old fraud tactics still work because they target human decision-making, not just systems. Attackers reuse urgency, authority, and familiarity because those cues still push people to act quickly. Modern tools do not help if the process lets a requester bypass verification by sounding plausible or by using a normal business channel.

Q: What are the first signs that fraud controls are too easy to manipulate?

A: Look for recovery requests, payment approvals, or exception decisions that are approved quickly, bypass normal review, or rely on a single person’s judgment. Repeated urgency, unusual familiarity, and a pattern of policy overrides are all indicators that the workflow is exposing the organisation to social engineering rather than absorbing it.

Q: How do fraud controls differ from standard access controls?

A: Access controls decide whether an identity may enter a system, while fraud controls judge whether a request itself is trustworthy. That difference matters because attackers often target the process around the control, not the control mechanism alone. In practice, fraud controls must cover human behaviour, workflow integrity, and escalation paths.

Background and context

Why social engineering still bypasses identity controls

Social engineering works when attackers can shape what a person believes at the moment a decision is made. The control gap is not only weak authentication, but also verification workflows that assume legitimacy once a conversation, request, or approval looks familiar. In practice, this means fraud often moves around technical controls by targeting the person who is allowed to override them. When organisations separate identity proofing, transaction approval, and exception handling, attackers have fewer places to manipulate trust.

Practical implication: Map your fraud controls to the human decision points that can still override policy.

How modern fraud adapts old tactics to new workflows

Modern fraud does not require new tricks when old techniques can be repackaged for digital channels, remote work, and faster business processes. The core pattern is simple: establish trust, create urgency, and redirect the target into an action that appears routine. That pattern can be adapted to email, messaging, voice, or account recovery flows because the underlying weakness is the same. The problem is not the channel alone. It is the business process that treats familiarity as proof.

Practical implication: Review account recovery, payment approval, and delegated request flows for trust shortcuts.

NHI Mgmt Group analysis

Fraud resilience fails when organisations treat familiarity as assurance. The article’s central warning is that older scams still work because people and processes still reward recognisable behaviour. That means identity programmes cannot rely on channel modernisation alone. Practitioners have to treat human approval steps as governable attack surfaces, not just business conveniences.

Verification is only effective when it is hard to socially engineer. A process can be technically sound and still fail if an attacker can persuade someone to override it. That is why fraud prevention and IAM must be linked to workflow design, especially in account recovery, exception handling, and delegated approval paths. The practical conclusion is to design controls that do not depend on trust being extended at the right moment.

Legacy fraud techniques persist because control assumptions age more slowly than attacker methods. The enduring lesson is that fraud prevention is not about eliminating old scams once and for all. It is about continuously re-testing whether current business processes still assume an honest counterpart, a stable request, or a reviewable transaction. When those assumptions break, fraud scales faster than policy updates.

Named concept: verification drag. This is the gap between a control that exists on paper and the amount of human judgment it depends on at runtime. The webinar shows that attackers exploit that drag by making routine requests feel urgent and familiar. Practitioners should treat long, human-mediated verification paths as a measurable fraud exposure, not a procedural detail.

Fraud governance belongs in identity programmes, not only in finance or security operations. The article connects prevention to the people and institutions that have worked with Abagnale for years because fraud crosses organisational boundaries. Identity teams need to care because approval, authentication, and recovery are where fraudulent intent becomes operational access. The field implication is clear: identity governance must account for manipulation, not just entitlements.

What this signals

Fraud prevention has to be designed into identity workflows, because the attacker’s real target is often the human decision that authorises a reset, approval, or exception.

Verification drag: when a control depends too heavily on rapid human judgment, it becomes easier to manipulate with urgency, familiarity, or authority. Security teams should treat that drag as an identity risk, not just a process problem.

For practitioners

• Harden account recovery paths Remove easy-to-abuse recovery shortcuts, add stronger step-up checks, and require independent verification for high-risk resets and changes.
• Review approval workflows for fraud exposure Identify business approvals that can be influenced by urgency, familiarity, or authority, then separate routine requests from high-risk exceptions.
• Test exception handling with social-engineering scenarios Use realistic fraud scenarios to see where staff will override policy, accept urgent requests, or skip validation under pressure.
• Align fraud and IAM monitoring Correlate suspicious identity events with payment, recovery, and delegation activity so manipulation attempts are visible across teams.

Key takeaways

• Older fraud tactics remain effective because they still exploit trust in approval and verification workflows.
• The practical weakness is not only technical access, but the human decision points that can authorise risky actions.
• Organisations should harden recovery, approval, and exception paths so social engineering cannot easily convert into legitimate access or financial loss.

Key terms

• Social Engineering: Social engineering is the use of deception, urgency, and authority to persuade a person to reveal information or take a risky action. It targets human decision-making rather than software defects, and often turns legitimate identity workflows into the attack path.
• Verification Drag: Verification drag is the delay and judgment burden created when a control depends on a human deciding whether a request is legitimate. The more a process relies on quick trust, the easier it becomes for an attacker to exploit urgency, familiarity, or authority.
• Account Recovery: Account recovery is the process used to restore access when a user cannot authenticate normally. In mature IAM programmes, recovery is treated as part of the trust chain because a weak reset path can bypass stronger login controls and become the easiest route to account takeover.
• Approval Workflow: An approval workflow is the governed sequence that determines whether a request becomes active access. It usually combines routing, policy checks, and evidence capture. For identity teams, the important question is not how fast it runs, but whether each decision remains attributable and reviewable.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.