Walk the floor at Global Fintech Fest 2026 this week and you will hear a hundred voice agents talk. They will interrupt naturally, handle a barge-in, switch from Hindi to English mid-sentence, and quote your outstanding balance in a pleasant tone. It is genuinely impressive, and by Wednesday afternoon it all starts to sound the same.

Here is the question almost nobody on that floor is being asked: what does your agent leave behind?

A customer calls to dispute a transaction. In ninety seconds they give their name, confirm their address, read out an account number, and then a security code because the agent asked them to verify identity. The call goes perfectly. The dispute gets raised.

And the recording is now one of the most dangerous objects your company owns. Not because anything went wrong — because everything went right, and the ordinary output of a successful call is a file holding a customer's identity, their address, their account and a credential, sitting in storage, waiting for somebody to ask what's in it.

The agent is the easy half. What the agent deposits is the half that gets audited. That's the conversation we came to GFF to have.

Every bank, NBFC and insurer in this hall is standing in the same trap.

A customer closes their account and asks you to delete their data. India's data protection law gives them that right, and from May 2027 it is fully enforceable with penalties running into hundreds of crores. So you delete.

Except you can't. RBI's KYC rules and anti-money-laundering law require you to keep those same records for five years after the relationship ends. Insurance regulators want sales calls kept. Securities regulators want broker calls kept for years. Delete on request and you fail an audit. Keep everything and you fail a privacy obligation.

Both instructions are binding. Both apply to the same recording. Most teams discover this the first time a customer actually exercises the right, then spend a quarter arguing about it internally.

The law breaks the deadlock narrowly: where another law requires retention, retention wins. Good — you get to keep the call.

But that settles the file, not the contents.

You must keep evidence that a conversation happened, what was agreed, how it was handled. You are not required — and in some cases not permitted — to keep the account number spoken aloud, the identity number confirmed, or the security code read out to pass verification. None of those serve the purpose retention exists for. They aren't evidence. They're exposure that happens to be sitting inside evidence.

Which leaves exactly one arrangement that satisfies both sides: keep the recording, remove what shouldn't be in it.

That is what PII redaction actually is. Not a security feature bolted on because it sounds responsible — the mechanism that lets two contradictory obligations both be true at once.

Ask most teams what's sensitive in a call and they'll name the dramatic things. The real answer is broader and much more ordinary.

• Names. The most obvious identifier and the one most often left in, because it feels harmless. It isn't — a name is what links a transcript sitting in an analytics tool to a real customer, and it is what turns an anonymous archive into a personal-data archive.
• Addresses. Read aloud constantly during verification and onboarding, and almost never treated as sensitive in the moment. A full address in a stored transcript is one of the highest-value fields in the file.
• Numbers, all of them. Mobile, account, identity, card. These make a record actionable rather than merely identifying, and they are read aloud on nearly every service call.
• Security codes. Anything that authenticates rather than identifies — the codes a customer reads out to prove they are who they claim. These deserve the strictest treatment, because unlike the fields above they have no ongoing business purpose once the call is done. There is nothing to be gained by keeping them and a great deal to lose.

None of these is exotic. That's the point. The exposure in a BFSI call archive is rarely one spectacular field — it's the ordinary ones, accumulated across hundreds of thousands of calls, sitting somewhere nobody has audited in two years.

And the test for each one is the same: does keeping this serve the reason you're required to retain the call? A name might, for dispute resolution. A security code never does.

The instinct is to treat redaction as cleanup — record everything, tidy it later, before it reaches the analytics team.

The problem is the gap. Between capture and cleanup, the unredacted version exists. On a disk. In a backup. In whatever queue moved it between the two. If a breach lands in that window, "we were going to redact it" is not a defence, and the disclosure obligations are brutal: regulators notified within days, affected customers told in plain language exactly what leaked, penalties sized to make the point.

The narrower the window, the smaller the surface. Redacting as the transcript is produced, rather than as a scheduled sweep afterwards, is the difference between a gap measured in milliseconds and one measured in however long your batch job takes.

There is a second reason this matters more than it did two years ago. Voice agents don't just record — they send. Transcripts go to language models for summarisation, to analytics for intent mining, to quality tools for scoring, and increasingly back into training. Every one is a place data leaves your boundary, and no cleanup afterwards reverses it.

Redact before it travels, not after.

And this lands on your vendors too. India's rules don't only bind the bank — they push the same duties down to whoever processes data on the bank's behalf. Your telephony platform, your transcription provider, your analytics tool. The bank can't contract the obligation away, which is precisely why bank security teams now put it in the contract. If you're taking meetings on this floor, that's the question to ask.

Vobiz redacts PII from call recordings and transcripts, configured on the trunk carrying your traffic, alongside recording and transcription. You choose which entity types to strip, and it applies to every call on that trunk — not per-call, not something an agent has to remember, not a setting someone forgets under pressure.

That last point deserves a moment. The traditional answer to sensitive data on calls is pause-and-resume: the agent notices it coming and manually stops recording. It depends on a human catching it every single time, and card security standards have started requiring firms to formally document how much residual risk that leaves — a polite regulatory way of saying it does not work reliably.

Configuration at the trunk doesn't depend on anyone noticing anything. Turn it on once, and it holds for every call that trunk carries — including the ones placed at 2am by an agent nobody is supervising.

That matters because the recording and the transcript leak differently. The recording is the artefact you're required to retain and hand to auditors, so it tends to live for years. The transcript is the one that travels — copied into analytics, exported to quality tools, forwarded to models. Covering only one of them leaves the other as the open door. It sits alongside the rest of what the platform enforces: calls on Indian infrastructure, both legs anchored in India, with the detailed records auditors ask for.

Claims about redaction are easy to make on a banner. So we're doing it live instead.

Take the 10-Minute Integration Challenge at the booth: sign up, clear eKYC, claim a number, connect your agent, and place a real call. Read a name, an address and a test account number into it, then look at what came back — the recording and the transcript, with those values already gone. Your call, in front of you. Finish the run and you're in the daily draw from a ₹90,000 prize pool.

Then bring the awkward question. The transcript archive nobody has audited. The vendor who can't tell you what leaves their boundary. The customer erasure request your retention policy can't answer. Those are better conversations than another demo of an agent talking.

May 2027 is closer than the demos on this floor suggest, and the organisations that will find it uneventful are the ones treating this as an infrastructure decision now rather than a compliance scramble later.