CISO FORUM

Voice cloning, forged signatures, and convincing deepfakes are no longer edge cases; they are the tools behind real financial heists, including the widely reported Capillary Technologies fraud that moved roughly €3 million through impersonated executives. As generative AI erodes the reliability of what we see and hear, the old playbook of human judgment and callback verification is proving dangerously inadequate. In conversation with ET Edge CISO Forum, Hariprasad PS, Head of AI at HyperVerge, unpacks why voice and signatures should never anchor authentication, how continuous verification can stop fraud without adding friction, and why the real battle isn’t at the point of inspection but at the point of capture. The discussion also explores post-onboarding blind spots, red-teaming discipline, and how CISOs should sequence their fraud-defence budgets.

CISO Forum: Walk us through what actually happened in a case like the Capillary Technologies fraud. Where could real-time AI detection have intervened, and where would it still struggle?

Hariprasad PS: Based on the company’s public disclosures, attackers used voice cloning, forged signatures, and social engineering to impersonate senior executives and transfer roughly €3 million to unauthorised accounts. No system was breached. The fraud worked because the media was convincing enough to defeat human judgment.

Two layers could have intervened. The first is real-time deepfake detection when the media is presented. This applies across formats: cloned voice on a call, a manipulated image in digital KYC, or the most advanced version we now see, live deepfake video with altered voice running over a video KYC call, convincing enough that the agent believes they are looking at a real person.

The second layer is multi-layer authentication on the transaction itself. A transfer of that size should require multi-factor authentication from the approver before the money moves. That additional factor can take several forms; one very good option is face-based authentication, a quick check that verifies liveness and matches the approver against their verified identity. Even if an employee is fully convinced they are talking to their boss, the extra factor stops the money from moving. Real-time detection alone still struggles in this scenario. If the deception happens on a channel with no built-in verification checkpoint, detection has nothing to attach to. The process has to create the checkpoint first.

CISO Forum: Fraud defences get “lighter” after onboarding. Is that a technology gap, a cost decision, or simply that most fraud teams aren’t measured on post-onboarding activity?

Hariprasad PS: In our experience, it is genuinely mixed, and it comes down to each institution’s internal policy rather than any single industry-wide cause. Some of the organisations we work with run authentication at every sensitive touch point after onboarding. Others stop at the front door. The capability is the same in both cases; the internal process decisions differ.

What post-onboarding defence looks like, for those who do it well, has two modes. Active checks fire at touch points: any action of consequence on an account, changing an address, changing a password, modifying a loan’s EMI or tenure, making a high-value transaction, triggers a full authentication that confirms this is the same verified person, with liveness and injection checks included. Passive signals run in the background: device fingerprinting and usage patterns that flag anomalies without interrupting anyone. A loan disbursed to a device that then shows zero activity for months is not how a genuine customer behaves, and you can see that without touching any sensitive personal data.

CISO Forum: What does “continuous authentication” look like in practice, without turning every customer interaction into a friction-heavy checkpoint?

Hariprasad PS: A well-built touch-point authentication is a single quick photo. It takes one to two seconds, about the same as a fingerprint unlock. Within that one capture, the system does everything at once: verifies the person is live, confirms the capture is genuine and not an injected or deepfake image, and matches the face against the photo from onboarding: one gesture, every check.

So the practical shape of continuous authentication is: passive signals running quietly in the background on every session, and that two-second active check reserved for moments that matter, a password change, a new beneficiary, a large transfer. Customers do not experience a system that constantly interrupts them. They experience a system that occasionally asks for a selfie at exactly the moments they would expect a bank to be careful.

When continuous authentication feels friction-heavy, that usually isn’t evidence the concept is wrong. It shows the implementation stacked separate checks on top of each other instead of collapsing them into one well-designed, seamless capture.

CISO Forum: Voice cloning and forged signatures both defeated human judgment in the Boss Scam cases. Can current detection tools reliably tell a cloned voice from a real one on a live call, or is the industry still behind the attackers here?

Hariprasad PS: For anything that moves money, voice and signatures should not be the authentication layer at all, regardless of how detection evolves.

Signatures have always had high natural variance. The same person signing twice in the same minute produces visibly different results, which is exactly the ambiguity a forger hides in. Voice has a similar problem. Cloned voice detection is possible, but the cloning technology is moving fast, and voice is inherently unstable as a credential. A cold changes it. A bad line changes it. Building your trust anchor on a signal that fluctuates for legitimate reasons means either false rejections of genuine people or enough tolerance for a good clone to walk through.

The reliable foundation is visual: image or video verification with strong liveness detection and state-of-the-art deepfake and injection checks. This is where detection technology has genuinely matured. When the capture itself is controlled, through an SDK that ensures only a real, live capture can enter the system, the visual layer can be trusted to separate a genuine person from generated or injected media. That is where organisations should be anchoring authentication, with voice at most a supporting signal, never the verdict.

CISO Forum: CERT-In’s blueprint names deepfake-enabled impersonation as one of seven core AI-assisted attack categories. Which of the other six do you see converging with impersonation fraud to make detection even harder?

Hariprasad PS: The convergence I watch most closely is with AI-driven reconnaissance and personalised social engineering. A deepfake is only the last mile of an attack. What makes a cloned executive convincing is the context around it: the attacker already knows the deal in progress, the internal vocabulary, who approves what. AI assembles that context at scale, so the fake no longer needs to be perfect, because the story around it is.

Second is automated orchestration, which turns impersonation from a handcrafted attack into an industrialised one running across many targets at once.

Underneath it all is the broader trajectory: image and video generation models are improving rapidly. Today a trained eye can still sometimes catch a generated face by studying edges and inconsistencies. That window is closing. We are entering a period where visual inspection by a human, however experienced, is not a viable control.

That is why the durable answer sits at the point of capture, not the point of inspection. In BFSI, unlike open platforms such as social media, you can enforce how media enters the system. Every image, video or document captured live through an SDK hardened against injection and generated content, whether on the customer’s own device or through a secure browser link when the transaction involves someone else’s phone. Control the entry point and the arms race between generation quality and detection quality stops being your dependency. To be clear, building an SDK that genuinely holds against injection is hard engineering, and the difference between vendors who claim it and vendors who withstand testing will keep widening.

CISO Forum: As fraud patterns evolve and you add new checks, how do you prevent the system from becoming a patchwork that attackers can eventually route around?

Hariprasad PS: Don’t wait for attacks to teach you where the gaps are. The discipline that prevents patchwork is continuous red teaming: a dedicated internal team whose job is to play the attacker and engineer new ways to break your own system before anyone outside does. When you discover your own vulnerabilities first, you design fixes into the solution. When attackers discover them first, fixes get bolted on under pressure, and that is exactly how patchwork forms.

We have been doing this work for over three years now, largely because our exposure to Southeast Asian markets put us in front of deepfake-driven fraud well before it became a mainstream topic in India. That lead time matters, because each generation of attack teaches you things no specification document can.

For an organisation evaluating how to keep pace, the honest advice is: be sceptical of any vendor who claims their system is foolproof. That claim does not age well in this field. Instead, look for evidence of a proactive posture: does the vendor red-team their own stack, how quickly do they ship countermeasures when generation models improve, and do they have independent certification of injection resistance rather than self-certifying?

CISO Forum: For a finance or ops team, specifically those authorising transfers, what would a “verify before you act” workflow realistically look like, without slowing down legitimate urgent transactions?

Hariprasad PS: Multiple layers of authentication, none of them slow. The workflow is simple to describe: any transfer above a defined threshold, or any change to beneficiary details, requires the authorising person to complete an identity check before the money moves. Not a callback, not a reply-to-confirm email, both of which run through channels an attacker can control, but a verification bound to the approver’s identity: a live capture with liveness detection, injection checks and a face match against their verified profile.

The speed concern dissolves when you look at what that check actually costs: a few seconds. For the approver, the entire activity is taking one quick selfie, the same gesture as unlocking a phone: no codes to copy, no forms, nothing to learn. For genuinely large movements, add a second approver who completes the same face check. A fraudster would now need to pass two live camera verifications, instead of persuading one person over a phone call.

An urgent, legitimate transfer clears this entire workflow in well under a minute, because every step is automated. By contrast, a few seconds of verification is not a slowdown. It is the fastest safe path available.

CISO Forum: Is there a meaningful difference in how BFSI, enterprise, and consumer-facing companies should approach continuous authentication, or is the underlying architecture the same across sectors?

Hariprasad PS: The underlying architecture is common: controlled capture, liveness, deepfake and injection checks, and a match against a verified identity. What differs across sectors is what drives implementation and where the checks point.

BFSI operates under explicit mandates. The RBI’s KYC framework and re-KYC requirements mean authentication is structurally embedded; the questions are about implementation quality, not whether to implement. Consumer platforms sit outside most of that regulatory scaffolding, so their adoption is business-case driven, and the case is increasingly easy to make. Gig and delivery platforms, for instance, face deepfake-damaged photos in returns fraud, a problem with no compliance mandate attached but a very direct P&L impact, and the same capture-integrity technology solves it.

Most enterprises apply rigorous verification to customers. The same standards may need to extend to their internal approval chains so attackers cannot exploit them.

CISO Forum: How much of this is actually solvable with better detection technology versus better organisational processes—board-level accountability, escalation protocols, human-in-the-loop checks?

Hariprasad PS: Both, and neither works alone. Detection technology has to be current, meaning genuinely tested against the sophistication of today’s generation models, not last year’s. A process built on weak detection produces confident approvals of convincing fakes.

But the reverse failure is just as real. Strong detection embedded in a weak process produces checks that exist but never fire at the right moments. The organisational work is deciding, deliberately, where authentication sits: which actions require a second factor, which require a third, what thresholds trigger escalation, and who is accountable when an exception is requested.

So the practical sequencing for a CISO is: put in detection that holds against current attack quality, then update the processes so that the right authentication fires at the right level of risk, every time, with no urgency-based bypass. Technology sets the ceiling on what your process can catch. Process determines whether you ever reach that ceiling.

CISO Forum: If you were advising a CISO with a fixed budget today, would you tell them to strengthen onboarding, invest in repeat authentication, or split resources evenly, and why?

Hariprasad PS: It depends on where the organisation is in its lifecycle, and I would give two different answers.

If you are launching something new, a new vertical, a new product line, a new customer base, onboarding is the 80/20. Every fraudster you stop at entry is one you never have to detect, monitor or purge later. Get the strongest possible capture, liveness and injection defences at the front door, and repeat authentication becomes your safety net rather than your primary control.

If you are an established business with a large existing base, the honest assessment is that the priority inverts, because some fraud is already inside. Onboarding upgrades stop the inflow but do nothing about accounts admitted under weaker checks over the years. There, the budget goes to two things: a one-time cleanup, re-verifying the existing base, and sophisticated repeat authentication at high-risk touch points, address changes, password changes, withdrawals, and high-value transfers.

We saw this play out with a large digital wallet player. They had over ten million customers, discovered deepfakes their existing vendor missed, and wanted to start lending to their base but didn’t trust it. We revamped onboarding so no new fraudulent accounts entered, ran a one-time cleanup of the existing base, and they extended loan offers only to customers verified clean. That sequencing- seal the entry, then clean the house, then add repeat checks at moments of consequence- is the allocation logic I would give any CISO.