Notifications
Clear all
Topic starter
19/08/2026 3:48 pm
TL;DR: Social engineering in financial services is now driven by AI voice cloning, deepfake video, hyper-personalised BEC, vishing and third-party impersonation, with Verizon DBIR data showing 87% of breaches in the sector involved a human element, according to Sprocket Security. The perimeter is not the problem; continuous human-layer testing, callback verification and third-party attack-path review are now the governance controls that matter.
NHIMG editorial — based on content published by Sprocket Security: How threat actors have shifted from cracking perimeters to exploiting people
By the numbers:
- Onfido's 2024 Identity Fraud Report found deepfake fraud attempts targeting financial firms increased by 3,000% between 2022 and 2024.
- IBM's Cost of a Data Breach 2024 reported that third-party-involved breaches cost $4.88 million on average and took 277 days to identify and contain.
Questions worth separating out
Q: How should financial institutions verify high-risk requests without slowing operations too much?
A: Use tiered verification for requests that can move money, reset credentials or expose sensitive data.
Q: Why do AI voice clones and deepfakes defeat traditional awareness training?
A: Because they attack the signal people were trained to trust.
Q: What do organisations get wrong about social engineering defence?
A: They often treat it as an awareness problem instead of a workflow problem.
Practitioner guidance
- Implement callback verification for high-risk requests Require an independent callback or secondary approval for payment changes, credential resets, SIM swaps and sensitive data releases.
- Test AI-voice and deepfake scenarios Build exercises that simulate cloned executives, video impersonation and regulator pretexts so staff can practice under realistic pressure.
- Map privileged vendor identities Inventory every third-party account, portal and API path that can reach internal systems, then confirm who can approve access, what activity is expected and how access is revoked when the relationship ends.
What's in the full article
Sprocket Security's full article covers the operational detail this post intentionally leaves for the source:
- Scenario breakdowns for AI-voice impersonation, vishing and deepfake testing against finance teams
- Examples of how regulator, auditor and vendor pretexts are constructed in live social engineering campaigns
- Testing patterns for help-desk identity resets, payroll diversion and wire-transfer approval workflows
- Details on continuous attack surface monitoring and how it changes test timing
👉 Read Sprocket Security's analysis of social engineering risks in financial services →
Social engineering in financial services: are your controls keeping up?
Explore further
19/08/2026 4:25 pm
Human identity assurance has become an operational control, not a training outcome. The article shows that awareness programmes alone cannot reliably distinguish a real executive, regulator or vendor from a synthetic or compromised one. In practice, the decision point has moved into workflow design, callback assurance and identity proofing under pressure. Teams should treat human identity verification as part of access control.
A question worth separating out:
Q: Who is accountable when a trusted vendor identity is used to trigger fraud?
A: Accountability sits with both sides of the trust relationship. The enterprise must govern which vendor identities can initiate action, and the vendor must control how those identities are issued, monitored and revoked. Frameworks such as IAM, PAM and third-party access governance all apply because the compromise lives in the access path.
👉 Read our full editorial: Social engineering in finance is now a continuous testing problem
