The night shift on a disputes queue
The scene that follows is illustrative. It describes no particular centre or client.
The call is about a double charge. Before the agent has finished the greeting, the customer has read out all sixteen digits of her card, then the three on the back, because the last company she called asked for them. She spells her email address. She gives a date of birth to prove she is who she says she is. The agent needed the last four digits and a transaction date.
Speech-to-text feeds an assist model during the call, a second model drafts the wrap-up note, and a third scores the conversation overnight. By morning the card number exists in the transcript store, in three sets of prompts, and in whatever each of those services logs.
The client's audit questionnaire asks for every sub-processor that receives its customers' personal data, and the categories each receives. The honest answer has just grown by three lines, and one category is payment card data.
Nothing in that chain needed the card number. It was passed along because nothing stopped it.
Where the conversation goes, and where the mask sits
Veil sits in the path of every call an AI agent makes to a model, a tool or an embedding service, which includes the index a centre builds for search.
Live agent assist
The assist model receives each turn with the designated fields that were detected masked. The agent, who is authorised, still sees what the customer said.
After-call work
The wrap-up note and the disposition are drafted from the masked conversation. For a card number typed into a chat, Veil's mask keeps the last four digits, which is what the next agent needs.
Quality and compliance review
A scorer needs to know whether the agent verified the caller and followed the script. It does not need the values the caller gave during verification.
One policy per client
Masking rules are policy-driven and set per tenant, so a banking client and a retail client can designate different fields. Enforcement is at the gateway, not inside each tool.
A receipt per mask
Every mask and unmask is logged as a Trust Receipt: who, what, under which policy, when. Signed, versioned, exportable. It is evidence of what was masked and when. It does not show which sub-processor received what, and a value that was not detected leaves no receipt.
Typed, spoken, transcribed: what Veil sees
This needs saying plainly, once. What we show Veil masking is text. The capture on the Veil page is a typed support message. The run below is text we wrote in the form of a chat and a transcript. Neither is the output of a speech-to-text system, and we make no claim in this post about redacting an audio recording or a live audio stream.
In chat the customer's words are text from the start. On a voice call something else turns speech into text first. Whether “four one one one” arrives as digits or as words depends on it, and so does whether sixteen digits arrive as one run or broken up by “uh” and “then”. The run below writes every digit as a word. It cannot tell you what your speech-to-text system will write.
The recording is a telephony matter. The card industry's information supplement on telephone payments, of November 2018, says that if recordings include card verification code data, it must be securely deleted or made unrecoverable once authorisation is complete, and recommends keeping card data out of the telephone environment where possible 5. It is guidance, about controls on the call. Masking the transcript does not replace them.
On language. Customers in India move between Hindi and English inside a sentence; Hinglish is a language explains why that matters for voice systems. We make no general claim about how Veil handles code-mixed Hindi and English. Your own transcripts are the only test that counts.
What a run on a typed message and two transcript turns shows
This is not an illustration. It is a run of Veil's pattern detectors on synthetic records on 7 October 2026, on the version of Veil deployed that day, at two settings: the "fast" depth meant for the inline path, and the default "balanced" depth. No model was loaded. We wrote every record for the run; none of it is anyone's data. Where an input value could coincide with a real person's number, part of it is hidden with ▒ before publishing. Outputs are as Veil produced them: asterisks are its masks, and where it keeps the last four digits of a value they are visible. Where Veil left such a value in clear, the same part is hidden with ▒ in the output too, so a ▒ in an output means Veil did not mask that value. The first record is a typed message. The other two are text we wrote in the form of a transcript; they are not the output of a speech-to-text system, so they say nothing about what a real transcription would hand to Veil.
RECORD · A customer's message to a bank or lender (English)
IN (synthetic)
I was charged twice on my card 4111 1111 1111 1111 for the same EMI. Please refund to savings account 0001▒▒▒▒▒▒▒▒, IFSC ABCD0▒▒▒▒▒▒. My PAN is ABCDE1234F and my UPI ID is testuser@examplebank. Call me on 98▒▒▒▒▒▒▒▒.
OUT at depth "fast" (the set meant for the inline path)
I was charged twice on my card ************1111 for the same EMI. Please refund to savings account ********, IFSC ********. My PAN is AB***F and my UPI ID is testuser@examplebank. Call me on ******1234.
OUT at depth "balanced" (the default)
I was charged twice on my card ************1111 for the same EMI. Please refund to savings account ********, IFSC ********. My PAN is AB***F and my UPI ID is testuser@examplebank. Call me on ******1234.
────────────────────────
RECORD · A contact-centre transcript turn, Hindi and English mixed, Roman script
IN (synthetic)
Agent: Kripya apna registered mobile number bataiye. Customer: Haan ji, mera number hai nau aath ▒▒▒ ▒▒▒ ▒▒▒ ▒▒▒ ▒▒▒ ▒▒▒ ▒▒▒ ▒▒▒. Card ke last four digits one one one one hain. Gaadi ka number DL 3C ▒▒ ▒▒▒▒ hai, aur flat number ek sau bees.
OUT at depth "fast" (the set meant for the inline path)
Agent: Kripya apna registered mobile number bataiye. Customer: Haan ji, mera number hai ********. Card ke last four digits one one one one hain. Gaadi ka number DL 3C ▒▒ ▒▒▒▒ hai, aur flat number ek sau bees.
OUT at depth "balanced" (the default)
Agent: Kripya apna registered mobile number bataiye. Customer: Haan ji, mera number hai ********. Card ke last four digits one one one one hain. Gaadi ka number DL 3C ▒▒ ▒▒▒▒ hai, aur flat number ek sau bees.
────────────────────────
RECORD · A transcript turn: the same card number read in groups of four, with fillers
IN (synthetic)
Customer: It is four one one one, uh, one one one one, then one one one one, and, um, one one one one.
OUT at depth "fast" (the set meant for the inline path)
Customer: It is ********, uh, ********, then ********, and, um, ********.
OUT at depth "balanced" (the default)
Customer: It is ********, uh, ********, then ********, and, um, ********.▒ hidden by us for publication · * masked by Veil, as produced · run of 7 October 2026, Veil commit 700ca8b, the version deployed that day · no model loaded
Reading the run honestly
The typed message. At both depths the typed card number was masked, keeping its last four digits, and so were the PAN, the account number, the IFSC and the ten-digit mobile number. The UPI ID was left in clear. The banking post reads this record line by line.
The transcript turn. At both depths the mobile number the customer spoke as ten number words in romanised Hindi was masked in full. The four-word run “one one one one”, the vehicle number and the flat number said as “ek sau bees” were left in clear at both depths. A short run of spoken digits on its own was not masked here, so do not expect the last four digits of a card, or a three-digit verification code, said by themselves, to be.
The card number read aloud. Read in groups of four with fillers between the groups, it was masked at both depths. Each group was masked on its own and in full; the words between them, “uh”, “then” and “and, um”, stay in the text. It came back as four spoken numbers, not as one card number, and no last four digits were kept. Two things follow. A reader of the masked turn can still see that a number was read out in four parts. And anyone counting card numbers by label will not find this one.
Two results not printed here. The same sixteen digits written as one unbroken run of number words, in English and in romanised Hindi, were masked in full at both depths, as one spoken number. In a turn written in Devanagari, an Aadhaar number and a mobile number in Devanagari digits were masked at both depths, and the name after “मेरा नाम” at the default depth only. The complete run, every record at both depths, is available on request.
What the run cannot tell you. Seven records that we wrote are examples. No ordinary word was masked by mistake in them, which says nothing about how often one would be in a day of real calls. Count wrongly masked words as well as misses when you test.
What to take from it. A card number typed into a chat is the easy case. One spoken on a call depends first on how the transcript writes it. These turns write every digit as a word; a speech-to-text system may write digits, mix the two, or lose one. Keep card numbers out of the transcript with telephony controls wherever you can, and test the rest on your own transcripts.
The outsourcer in the middle
A contact centre rarely decides why customer data is processed. Its client does. For most of what it handles the centre is then a processor, and every AI tool it adds is a tool its client has to be able to explain.
What the client is carrying
The client answers to its own customers and its own regulator for what the centre does with their data.
So the client passes its duties down by contract: act only on our instructions, limit access to what the task needs, tell us who else receives the data, let us audit.
When the centre adds a model, the client's first question is who operates it and what it receives.
What the centre can hand back
A policy per client that names the fields to be masked before any model call, and the setting it runs at.
A narrower answer to “what does the model's operator receive?”: the conversation with the detected, designated fields masked, and a tested list of what is not detected.
Signed Trust Receipts for the period under audit, showing each mask and unmask. Unmasking is policy-gated and is itself logged.
Clients and customers in the European Union
Whether a European rule binds a centre itself or reaches it through its client's contract depends on the facts, and is a question for counsel. What the texts say is this.
Reach. The General Data Protection Regulation applies to processing in the context of the activities of an establishment of a controller or a processor in the Union, and to the processing of personal data of people who are in the Union by a controller or processor not established there, where the processing relates to offering them goods or services or to monitoring their behaviour 8.
The processor contract. A controller may use only processors that give sufficient guarantees, under a contract that binds the processor to documented instructions, confidentiality and security measures, and a processor shall not engage another processor without the controller's prior written authorisation 8. A model's operator that receives customers' conversations is a party the client will want named.
The transfer. Personal data moves to a third country only under the Regulation's transfer rules. India is not on the Commission's list of adequacy decisions as shown on 7 October 2026; the Commission has adopted standard contractual clauses for transfers 910.
Masking helps, and it is not an exit. The Regulation names pseudonymisation as a security measure. A transcript whose identifiers are replaced by tokens the centre can reverse is pseudonymised: still personal data, still under the Regulation. What changes is how much of it a model's operator holds.
Two provisions of the EU's Artificial Intelligence Act are in the table below because centres ask about them: telling people they are dealing with an AI system, and the ban on inferring emotions at work 11. Neither is about masking, and masking satisfies neither.
Which rules apply, and where masking helps
One row per rule, as the texts stood on 7 October 2026. The second column says whom the text addresses. Where that is the client and not the centre, the rule reaches the centre as contract terms; where the text could bind the centre itself, the row says so and leaves the conclusion to counsel.
| The rule | Who the text addresses | What it asks for | Where masking at the perimeter helps | What masking does not cover |
|---|---|---|---|---|
| The rule: Digital Personal Data Protection Act, 2023, section 8(1), 8(2) and 8(5), and DPDP Rules, 2025, Rule 6 12 | The data fiduciary, which for most of a centre's work is the client. It reaches the centre, as data processor, through the contract. These provisions come into force in May 2027. | The fiduciary is responsible for processing done on its behalf, may engage a processor only under a valid contract, and must take reasonable security safeguards. Rule 6 lists masking and virtual tokens among its examples and asks for security terms in the processor contract. | It is one of the safeguards the rule names, and one a processor can evidence to its client. | The rest of Rule 6, and what is the client's to decide: notice, consent, retention, rights, breach reporting. |
| The rule: Digital Personal Data Protection Act, 2023, section 17(1)(d) 1 | A person based in India processing personal data of people not within India under a contract with a person outside India. | Chapter II, except sections 8(1) and 8(5), and Chapter III and section 16 do not apply to that processing. | Section 8(5) is kept, and masking is a safeguard of the kind it has in mind. | Any other law that governs that data. See the row on the European data-protection regulation. |
| The rule: Clients' sector rules in India: the Reserve Bank's outsourcing directions for commercial banks, IRDAI's outsourcing regulation 51, SEBI's regulation 16C 34 | The regulated client: a bank, an insurer, a SEBI-regulated person. Not the centre. The centre meets them as contract terms and audit requests. | A provider's access to a bank's customer information is on a need-to-know basis. An insurer ensures that data parted to a provider remains confidential at all times. A SEBI-regulated person is solely responsible for investors' data in any AI tool it uses. | It is a way to send the model less than the whole conversation. | The agreement and the client's right to audit. The detail is in the banking post. |
| The rule: Card data: RBI circulars of 7 September 2021 and 28 July 2022 on storing card data 67; PCI DSS v4.0.1 and the standards council's telephone-payments supplement of November 2018 5 | The circulars are addressed to payment system providers and participants and restrict entities in the card payment chain; whether a centre is in that chain depends on what it does with the card. PCI DSS is a contractual standard. The supplement is guidance. | No entity in the chain other than issuers and networks stores actual card data, with effect from 1 October 2022; the last four digits may be kept. A card number is masked when displayed, and a verification code is not kept after authorisation, in a recording or anywhere else. | A card number that Veil detects in the text is masked before the model call. In the run above the typed one was, keeping its last four digits, and the one read out in number words was, in full. | A card number it does not detect. The recording. A verification code said aloud: a short run of spoken digits was left in clear in the run above. PCI DSS scope. |
| The rule: Department of Telecommunications, Revised Guidelines for Other Service Providers, 23 June 2021 13 | Centres operating as Other Service Providers in India. | It does not bear on this question. The guidelines deal with telecom matters, such as keeping call data records for one year. A search of the text finds no provision on data protection, privacy or the recording of calls. | Not applicable. | Not applicable. |
| The rule: EU General Data Protection Regulation, Articles 3, 25, 28, 32 and 44 to 46 8910 | Controllers and processors within Article 3, quoted above. A centre outside that reach meets the Regulation through its client's processor contract. Which applies is for counsel. | A processor contract; no further processor without the controller's prior written authorisation; security measures, among which the Regulation names pseudonymisation; and a transfer tool. | Tokenised transcripts are pseudonymised data, and a model's operator holds less of each customer's data. | Pseudonymised data that could be attributed to a person by the use of additional information is information on an identifiable person (Recital 26). Masking does not decide whether a model's operator is a further processor. |
| The rule: EU Artificial Intelligence Act, Articles 50(1) and 5(1)(f) 11 | Article 50(1): providers of AI systems. Article 5: anyone using a prohibited system. Outside the Union, the Act applies where the system's output is used in the Union. | Providers design AI systems that interact directly with people so that people are informed of it, unless that is obvious: in application since 2 August 2026. No AI systems to infer the emotions of a person in the workplace, except for medical or safety reasons: since 2 February 2025. The Act's high-risk obligations were moved in July 2026 and apply from 2 December 2027. | It does not. Neither duty is about what data the model receives. | Both. A centre should establish whether it is the provider or a deployer of each system it runs. |
Also checked: the EU's Digital Operational Resilience Act, under which a financial entity in the Union remains fully responsible and must state in its ICT contracts where data is processed and how it is protected 12; it reaches a centre only as contract terms. This table states what the texts say and where one control helps. It is not legal advice. Which rows bind your centre, and through which contract, is a question for your own counsel and your client's.
What Veil does not do
It does not redact audio. What is shown is text. We make no claim about recordings or live audio.
It does not promise to catch a card number read aloud. In the run above a card number written out in number words was masked at both settings, as one run and in groups of four. That is text we wrote. What Veil is handed on a real call depends on how your speech-to-text system writes a number, and in the same run a four-word run of digits was left in clear.
It makes no general claim about code-mixed Hindi and English. Bring your own transcripts.
It does not mask everything, and nobody should write that it does. The run left a vehicle number, a UPI ID, a short run of spoken digits and a number said as “ek sau bees” in clear. A customer who says where she works and what happened to her has identified herself without an identifier.
It cannot find what the transcript lost. If speech-to-text turned a card number into nonsense, the nonsense passes through.
It does not handle consent or disclosure. That is a matter for your script and your client.
It does not make a transcript anonymous or take it outside any law. A reversible token is still personal data.
It is not a shield against manipulated input. That is Kavach's job on the same call.
It is not a certification of your deployment. ShepHertz operates a control environment credentialed for SOC 2, ISO 27001, HIPAA and GDPR. These are advisory alignments to inform your own assessment, not certifications of your deployment or binding regulatory claims.
The same control from two other chairs: for banks, lenders and insurers and for government departments. The general introduction is Mask it before the model sees it.
Frequently asked questions
How do we stop card numbers in call transcripts from reaching an AI model?
First keep them out of the call where you can, with telephony controls such as having the customer key the digits in. For what still reaches the transcript, mask the text before each model call, and test what that catches. In Veil's captured output a typed card number keeps its last four digits. In a run of its pattern detectors on synthetic transcript turns on 7 October 2026, a card number written out in number words was masked in full at both depth settings, as one unbroken run and read in groups of four with fillers between them. That was text we wrote, with every digit as a word; a speech-to-text system may write it differently. So do not assume a spoken card number is caught: measure it on your own transcripts.
Does Veil work on Hinglish and on numbers that customers say out loud?
We make no general claim about code-mixed Hindi and English, or about audio. In a run of Veil's pattern detectors on synthetic transcript turns on 7 October 2026, a ten-digit mobile number spoken as number words in romanised Hindi was masked at both depth settings, and so was a sixteen-digit card number read in groups of four. A four-word run of digits and a number said as "ek sau bees" were left in clear. The turns were text we wrote, not the output of a speech-to-text system. Bring your own transcripts.
We are a BPO in India serving EU clients. Does masking take the data outside the GDPR?
No. Under the General Data Protection Regulation, personal data that has been pseudonymised and could be attributed to a person by the use of additional information is information on an identifiable person 8. A transcript whose identifiers are replaced by tokens you can reverse is pseudonymised, not anonymous. Masking is a security measure the Regulation names, and it reduces what a model's operator holds. The processor contract, the controller's authorisation of further processors and a transfer tool are still needed; there is no adequacy decision for India on the Commission's list as shown on 7 October 2026 10.
Does India's data-protection law apply when we handle only foreign customers' data?
Partly. Under section 17(1)(d) of the Digital Personal Data Protection Act, 2023, most of Chapter II, and Chapter III and section 16, do not apply where personal data of people not within India is processed under a contract with a person outside India by a person based in India; sections 8(1) and 8(5) are kept 1. Section 8(5) is the duty to take reasonable security safeguards. These provisions come into force in May 2027 2. Confirm how they apply to your contracts with your own counsel.
Do we have to tell callers they are talking to an AI system?
Check two things with counsel: whether the EU's Artificial Intelligence Act reaches your system, and whether you are its provider or a deployer. Article 50(1), in application since 2 August 2026, is addressed to providers: they must design AI systems intended to interact directly with people so that people are informed of it, unless that is obvious. Outside the Union the Act applies where the system's output is used in the Union 11. A centre that deploys a system built by someone else should ask the provider how that duty is met. For calls within India, follow your client's sector rules.
Sources
The texts as they stood on 7 October 2026.
- 1Parliament of India: Digital Personal Data Protection Act, 2023 (No. 22 of 2023), assented to on 11 August 2023; sections 8(1), 8(2), 8(5) and 17(1)(d).
- 2Ministry of Electronics and Information Technology: Digital Personal Data Protection Rules, 2025, G.S.R. 846(E), November 2025; Rules 1 and 6.
- 3Reserve Bank of India: Reserve Bank of India (Commercial Banks – Managing Risks in Outsourcing) Directions, 2025, 28 November 2025; paragraphs 9, 24 and 27.
- 4Insurance Regulatory and Development Authority of India: IRDAI (Protection of Policyholders' Interests, Operations and Allied Matters of Insurers) Regulations, 2024, regulation 51; and Securities and Exchange Board of India: SEBI (Intermediaries) Regulations, 2008, regulation 16C.
- 5PCI Security Standards Council: Information Supplement: Protecting Telephone-Based Payment Card Data, version 3.0, November 2018 (guidance), and PCI DSS v4.0 Self-Assessment Questionnaire D for Merchants, April 2022, Requirements 3.3.1 and 3.4.1.
- 6Reserve Bank of India: Tokenisation – Card Transactions: Permitting Card-on-File Tokenisation (CoFT) Services, RBI/2021-22/96, 7 September 2021.
- 7Reserve Bank of India: Restriction on Storage of Actual Card Data, RBI/2022-23/95, 28 July 2022.
- 8European Union: Regulation (EU) 2016/679, General Data Protection Regulation, applicable from 25 May 2018; Articles 3, 4(5), 25, 28, 32, 44 to 46 and Recital 26.
- 9European Commission: Implementing Decision (EU) 2021/914 on standard contractual clauses, 4 June 2021.
- 10European Commission: Adequacy decisions, list as shown on 7 October 2026.
- 11European Union: Regulation (EU) 2024/1689, Artificial Intelligence Act, Articles 2(1)(c), 5(1)(f) and 50(1), with the application dates in Article 113 as amended by Regulation (EU) 2026/1744 of 8 July 2026.
- 12European Union: Regulation (EU) 2022/2554, Digital Operational Resilience Act, applicable from 17 January 2025; Articles 28(1)(a) and 30(2).
- 13Department of Telecommunications: Revised Guidelines for Other Service Providers (OSPs), No. 18-8/2020-CS-I (Pt.), 23 June 2021.
Written by
AgentAnywhere Research
The team that builds the platform and the models
AgentAnywhere Research writes about the platform, the model families and the trust layer we build and run in India. Where a figure is ours, it says what it covers; where something is a demonstration, it says so.
