Thursday, the vendor-risk committee
The scene that follows is illustrative. It describes no particular institution.
The proposal on the table is a complaint-handling assistant that drafts replies for an officer to approve. The model behind it is hosted by a provider.
The provider's paper says prompts are not used for training and are deleted on a schedule. The head of compliance reads the outsourcing directions again and stops at one sentence: access to customer information by a service provider shall be on a need-to-know basis. She asks what the model needs to know to draft a reply about a double debit.
Someone pulls a sample of complaints. Customers type their full card number, because the form did not stop them. They paste a PAN and an account number. An insurance complaint describes a diagnosis. None of that is needed to understand that an EMI was charged twice. All of it would sit in the provider's prompt store for as long as the schedule says.
The committee does not have to decide whether to trust the provider. It has to decide what the provider will be sent.
Masking before a model, or trusting a vendor's promise
These are not alternatives. The directions require the contract in any case. The question is whether the contract is the only thing standing between a customer's card number and a third party's log.
Mask before the model
Where the control sits: at your gateway, applied to every call, under policy you define.
What the provider holds: masks and tokens for the designated fields that were detected, and everything else as written.
Your evidence: your own signed Trust Receipts, one for each mask and unmask.
How it fails: a field the policy did not designate, or a value the detector missed. A miss leaves no receipt, so you find it only by testing on your own data. The run below prints what it left in clear for that reason.
Trust the promise
Where the control sits: in a clause, and in the provider's own systems.
What the provider holds: everything the customer typed.
Your evidence: the provider's attestations and whatever audit rights you negotiated.
How it fails: a retention setting, a debug log, a support engineer, a sub-processor. You usually find out afterwards.
The data layer, field by field
Policy decides per field whether a value is redacted, tokenised or left alone. The use cases that sit on top of this layer are in AI agents in Indian banking.
Card numbers
Veil's card mask keeps the last four digits and hides the rest, which is the residue the Reserve Bank lets entities in the payment chain keep for tracking and reconciliation 4. It is a mask on text bound for a model, not a network token and not card-on-file tokenisation. It applies to a card number Veil detects. The run below shows a typed one; a card number written out in number words is masked in full, with no last four kept.
Identity and account numbers
A PAN is masked to its first two characters and its last. The Veil page lists account numbers among the classes it detects; they have no single shape across banks, so test on your own formats. In the run below an account number and an IFSC were masked in full at both settings.
Health details in claims: listed, not shown
The Veil page lists health identifiers among the classes it detects. No health field is masked in any run we have published, so we show nothing for it and you should test it on your own claim notes. A diagnosis written out in a sentence is not an identifier, and no mask will make that sentence anonymous.
Tokenise where the work must finish
A KYC or collections workflow has to act on the right account after the model has understood the request. A deterministic token stands in for the value, and the same value always gets the same token. Unmasking is policy-gated and itself logged as a Trust Receipt. Reversible tokenisation is not on by default; it is switched on per deployment.
A receipt for each mask
Every mask and unmask is logged as a Trust Receipt: who, what, under which policy, when. Signed, versioned, exportable for auditors. It is a record of what was masked. It does not record what the model received, and a value that was not detected leaves no receipt.
What a run on a synthetic customer message 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.
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.▒ 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
What was masked. At both depths: the typed card number, keeping its last four digits; the PAN; the ten-digit mobile number, keeping its last four; and the account number and the IFSC, both masked in full. Each came back under its own label: card number, PAN, phone, account number, IFSC. For a bank the label matters as much as the mask, because the label is what an auditor reads.
What was not. The UPI ID was left in clear at both depths.
What the same day's run shows about spoken card numbers. In records written for the contact-centre post, a card number written out in number words was masked in full at both depths, with no last four kept, and it came back labelled a spoken number, not a card number. A bank whose customers give card details by voice should read that run, and its limits, before relying on any of this.
What to take from it. Typed card numbers and PANs have fixed shapes and are the easy case. Free-format identifiers are not: account numbers have no single shape across banks, and this run shows one, written after the words “savings account”. Decide which fields your policy designates, add your own patterns for the ones that are yours alone, and test the whole set on a sample of your own messages at the depth you intend to run.
What it changes for the institution
Vendor due diligence gets a smaller subject. You still assess the provider. You assess it as a holder of conversations in which the designated fields that were detected are masked. It is not a clean store: the run above left a UPI ID in clear.
An incident at the provider is smaller, not absent. A leaked prompt log in which card numbers are masks is a different regulatory conversation from one that contains them. What a customer wrote about their circumstances can still identify them.
Part of the audit question has an answer on file. Receipts written at the time show which fields were masked on a call, under which policy, and who unmasked what. They do not show what the model received. For that you still need your own record of what was sent.
It does not move the data's home. Masking does not change where your payment data or your policy records must be stored.
Which rules apply, and where masking helps
One row per rule whose text says something a bank's AI data path has to act on, as the texts stood on 7 October 2026. Two of the instruments a bank's team will remember by their 2023 names were replaced in November 2025 and July 2026; the rows use the current ones.
| The rule | Who it applies to | What it asks for | Where masking at the perimeter helps | What masking does not cover |
|---|---|---|---|---|
| The rule: RBI (Commercial Banks – Managing Risks in Outsourcing) Directions, 2025, of 28 November 2025 1 | Commercial banks. It repealed the earlier outsourcing instructions for banks, including those on IT services (paragraph 95). This post reads the commercial-bank text only. | Outsourcing does not diminish the bank's obligations (paragraph 9). A provider's access to customer information is on a need-to-know basis (paragraph 24), and the provider must be able to isolate and clearly identify the bank's customer information (paragraph 27). | It is a way to limit what a model's provider is sent to less than the whole message. | Audit rights, offshore conditions, and notice to the Reserve Bank of a breach (paragraph 28). A search of the text finds neither “masking” nor “tokenisation”. |
| The rule: RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, of 31 July 2026 2 | Commercial banks. It repealed the earlier cyber security framework and IT governance instructions for banks (paragraph 230). | A comprehensive data loss and leakage prevention strategy to safeguard sensitive business and customer data (paragraph 51). | Prompts to a model are one path by which data leaves. Masking covers it for the designated fields that are detected. | The rest of the strategy. In this text the word masking appears once, for data used in development and testing. |
| The rule: RBI circular on Storage of Payment System Data, 6 April 2018, and its FAQs 3 | System providers of payment systems. The circular is addressed to authorised payment systems and to banks. | The entire data relating to payment systems is stored only in India. Data processed abroad must be deleted there and brought back within one business day or 24 hours, whichever is earlier. | Fewer payment data elements reach a model in the first place. | The storage rule itself. We do not claim that masked payment data falls outside it. |
| The rule: Card data: RBI circular on card-on-file tokenisation, 7 September 2021 4; RBI circular on Restriction on Storage of Actual Card Data, 28 July 2022 5; PCI DSS v4.0.1 67 | The circulars: payment system providers and participants, and entities in the card payment chain. PCI DSS: a contractual standard for entities that store, process or transmit card data, not a law. | The 2021 circular: no entity in the chain other than card issuers and networks stores actual card data; the last four digits and the issuer's name may be kept. The 2022 circular restates that with effect from 1 October 2022. PCI DSS: a verification code is not kept after authorisation, and a card number is masked when displayed, the BIN and last four digits being the most shown. The council's 2025 guidance on AI says preventing exposure starts by limiting the sensitive data given to an AI system. | A card number that Veil detects in a message is masked before the call, keeping the last four digits. In the run above a typed card number was detected at both settings. | A card number it does not detect. A verification code. Your own storage. PCI DSS scope, which is for your assessor. |
| The rule: SEBI (Intermediaries) Regulations, 2008, regulation 16C, inserted with effect from 10 February 2025 8 | Any person regulated by SEBI that uses artificial intelligence and machine-learning tools. | Such a person is solely responsible for the privacy, security and integrity of investors' and stakeholders' data, whether the tools are its own or procured. | Less investor data inside a third-party tool to be responsible for. | Responsibility for the tool's output and for compliance with applicable laws, which the same regulation also assigns. |
| The rule: IRDAI (Protection of Policyholders' Interests, Operations and Allied Matters of Insurers) Regulations, 2024, regulation 51 9 | Insurers. | The insurer shall ensure that the data or information parted to any outsourcing service provider remains confidential at all times. | The provider that runs a model is parted less. | The provider's own security controls, which the insurer must satisfy itself about under the same regulation. |
| The rule: Digital Personal Data Protection Act, 2023, section 8(5), and DPDP Rules, 2025, Rule 6 10 | Data fiduciaries under the Act. These provisions come into force in May 2027. | Reasonable security safeguards to prevent a personal data breach; Rule 6 lists encryption, obfuscation, masking and virtual tokens as examples of data security measures. | Masking and virtual tokens are named examples. The fuller picture is in The DPDP Rules and your AI agents. | The rest of Rule 6: access control, logs, backups, and security terms in the contract with a processor. |
| The rule: EU General Data Protection Regulation, Articles 3, 25, 28 and 32 11 | Processing by an establishment in the Union, and processing of personal data of people in the Union by a controller or processor elsewhere where it relates to offering them goods or services or monitoring their behaviour (Article 3). Whether that reaches you is for counsel. | Data protection by design and security of processing, both of which name pseudonymisation as a measure, and a contract with any processor. | Replacing identifiers with tokens is pseudonymisation in the Regulation's sense, provided the additional information is kept separately and protected. | Pseudonymised data that could be attributed to a person by the use of additional information is information on an identifiable person (Recital 26). The Regulation continues to apply to it. |
Also checked, with no direct bearing on masking: the Reserve Bank's Digital Lending Directions of 8 May 2025 12; its FREE-AI committee report of 13 August 2025, which is a report with recommendations and not a direction 13, and two 2026 drafts on model risk and data governance, the second of which lists tokenization among example security controls 14; SEBI's cybersecurity framework of 20 August 2024 15; IRDAI's cyber security guidelines and its regulations on where insurance records are held 1617; and two European regulations, on operational resilience 18 and on artificial intelligence 19, whose high-risk obligations were moved in July 2026 and now apply from 2 December 2027. This table states what the texts say and where one control helps. It is not legal advice; confirm how each rule applies to your institution with your own compliance and legal teams.
What Veil does not do
It does not mask all customer data, and nobody should write that it does. The run above left a UPI ID in clear. A complaint that describes a customer's illness or their employer identifies them without an identifier in sight.
It does not make data anonymous. A token your own systems can reverse is still that customer's personal data.
It does not reduce your card-standard scope by itself, and it is not a payment token. It masks the card numbers it detects in text bound for a model. What that means for scope is for you and your assessor.
It does not settle where data must live. We do not claim that masking changes how the payment-data storage rule or the insurance-records rule applies.
It does not replace the outsourcing agreement. Confidentiality clauses, audit rights and exit terms are still required. With masking they have less to protect.
It is not a shield against manipulated input and it does not judge the model's output. Prompt injection is Kavach's job on the same call.
It is shown here on typed text. We make no claim in this post about scanned KYC documents, images or audio.
It is not a certification of your deployment. Veil is aligned with RBI FREE-AI data-protection expectations, and 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. Our Trust Center says reports are available under NDA; the framework view is on our governance page and in RBI FREE-AI in plain English.
The same control from two other chairs: for government departments and for contact centres.
Frequently asked questions
Can a bank send customer data to a third-party AI model under RBI rules?
The Reserve Bank's outsourcing directions for commercial banks of 28 November 2025 do not mention artificial intelligence or machine learning; a search of the text finds neither term 1. What they say is that outsourcing does not diminish the bank's obligations, that a service provider's access to customer information is on a need-to-know basis, and that the provider must be able to isolate and clearly identify the bank's customer information 1. Whether a particular model service is an outsourcing arrangement under the directions is for the bank's compliance team to decide. Masking identifiers before the call is a way to give need-to-know a technical form.
Do RBI directions require masking or tokenisation of customer data?
Not in those words, in the texts as they stood on 7 October 2026. A search of the 2025 outsourcing directions for commercial banks finds neither word 1. The 2026 cybersecurity and technology directions use the word masking once, for development and test data, and ask for a data loss and leakage prevention strategy 2. The card-on-file circulars stop entities other than issuers and networks from storing actual card data 45. A draft data-governance guidance of July 2026 lists tokenization and anonymisation among examples of security controls; it is a draft 14.
Who is responsible if an AI vendor mishandles customer data?
The regulated entity. The Reserve Bank's outsourcing directions say outsourcing does not diminish a bank's obligations 1. SEBI's regulation 16C makes a regulated person solely responsible for the privacy, security and integrity of investors' data when it uses AI tools, whether designed by it or procured from a third party 8. IRDAI requires an insurer to ensure that data parted to an outsourcing service provider remains confidential at all times 9.
Is a masked card number still in PCI DSS scope?
Scope is decided between you and your assessor, and we do not claim that Veil takes any system out of scope. The standard asks that a card verification code is not kept after authorisation and that a card number is masked when displayed, with the BIN and last four digits as the most shown 6. Veil's card mask keeps the last four digits of a card number it detects. A number it does not detect passes through unmasked, so test detection on your own messages.
Which banking identifiers does Veil mask?
The Veil page lists the classes: names, contacts, account and card numbers, health identifiers and the fields your own policy designates. In a run of Veil's pattern detectors on synthetic records on 7 October 2026, a typed card number, a PAN, an account number, an IFSC and a ten-digit mobile number were masked at both depth settings; a UPI ID was left in clear. A card number written out in number words was masked in full, labelled a spoken number. No health field appears in any run we have published. A run on synthetic records is an example, not a guarantee about your data, so test on a sample of your own messages.
Does tokenised customer data fall 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 11. A token your institution can reverse is pseudonymised data, not anonymous data. The Regulation names pseudonymisation as a measure under data protection by design and security of processing; it reduces what the model's operator receives and does not remove the data from the Regulation.
Sources
The regulators' own texts as they stood on 7 October 2026. Paragraph numbers are those of the versions linked.
- 1Reserve Bank of India: Reserve Bank of India (Commercial Banks – Managing Risks in Outsourcing) Directions, 2025, RBI/DOR/2025-26/171, 28 November 2025.
- 2Reserve Bank of India: Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, RBI/DoS/2026-27/410, 31 July 2026.
- 3Reserve Bank of India: Storage of Payment System Data, RBI/2017-18/153, 6 April 2018, and its frequently asked questions.
- 4Reserve Bank of India: Tokenisation – Card Transactions: Permitting Card-on-File Tokenisation (CoFT) Services, RBI/2021-22/96, 7 September 2021.
- 5Reserve Bank of India: Restriction on Storage of Actual Card Data, RBI/2022-23/95, 28 July 2022.
- 6PCI Security Standards Council: PCI DSS v4.0 Self-Assessment Questionnaire D for Merchants, April 2022, which reproduces Requirements 3.3.1 and 3.4.1; the council's note of 20 August 2024 on the versions in force, and its request for comments of 3 June 2026 naming v4.0.1 as the published version.
- 7PCI Security Standards Council: AI Principles: Securing the Use of AI in Payment Environments, 11 September 2025.
- 8Securities and Exchange Board of India: SEBI (Intermediaries) Regulations, 2008, as last amended on 5 December 2025; regulation 16C.
- 9Insurance Regulatory and Development Authority of India: IRDAI (Protection of Policyholders' Interests, Operations and Allied Matters of Insurers) Regulations, 2024, 20 March 2024; regulation 51.
- 10Parliament of India: Digital Personal Data Protection Act, 2023, section 8(5), and Ministry of Electronics and Information Technology: Digital Personal Data Protection Rules, 2025, G.S.R. 846(E), November 2025; Rules 1 and 6.
- 11European Union: Regulation (EU) 2016/679, General Data Protection Regulation, applicable from 25 May 2018; Articles 3, 4(5), 25, 28, 32 and Recital 26.
- 12Reserve Bank of India: Reserve Bank of India (Digital Lending) Directions, 2025, 8 May 2025.
- 13Reserve Bank of India: Report of the Committee to develop a Framework for Responsible and Ethical Enablement of Artificial Intelligence (FREE-AI) in the Financial Sector, 13 August 2025.
- 14Reserve Bank of India: draft Guidance on Regulatory Principles for Model Risk Management, released for comment on 24 June 2026, and draft Guidance on Regulatory Expectations for Data Governance, July 2026; paragraph 39.
- 15Securities and Exchange Board of India: Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities, 20 August 2024.
- 16Insurance Regulatory and Development Authority of India: IRDAI Information and Cyber Security Guidelines, 2023, April 2023.
- 17Insurance Regulatory and Development Authority of India: IRDAI (Maintenance of Information by the Regulated Entities and Sharing of Information by the Authority) Regulations, 2025, January 2025; regulation 9.
- 18European Union: Regulation (EU) 2022/2554, Digital Operational Resilience Act, applicable from 17 January 2025.
- 19European Union: Regulation (EU) 2024/1689, Artificial Intelligence Act, with the application dates in Article 113 as amended by Regulation (EU) 2026/1744 of 8 July 2026.
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.
