RBI data residency and calling an external LLM

The FAQ states that where processing is done abroad, the data should be deleted from the systems abroad and brought back to India not later than one business day or 24 hours from payment processing, whichever is earlier. That is a deletion obligation with a clock, and it is the clause that decides whether a hosted model is usable for this class of data.

Run it against a real LLM integration. Your prompt goes to a provider outside India. Even with inference-time retention disabled, several things may persist: an abuse-monitoring copy held under the provider's standard terms, request logs at the API gateway, a copy inside whatever observability tool you wired in, and a copy in the provider's own error-tracking if a request failed. Each is a system abroad holding payment system data, and each has to be provably empty within the window. Contractual zero retention is achievable with some providers and some plans. It has to be in writing, it has to name every sub-processor, and someone has to test it rather than assume it.

The FAQ is also broad about what counts. Payment system data there includes customer data such as name, mobile number, email, Aadhaar number and PAN; payment sensitive data such as customer and beneficiary account details; payment credentials such as OTPs, PINs and passwords; and transaction data including originating and destination system information, references, timestamps and amounts. That list is worth reading twice, because a name and a mobile number are in it, and those two fields appear in almost every prompt anyone writes in a support context.

• Enumerate provider-side retention: inference logs, abuse monitoring, gateway logs, error tracking, sub-processors
• Get zero retention in the contract, not in a settings page, and re-check it when the plan changes
• Instrument your own side: an observability vendor hosted abroad is a system abroad
• Treat name and mobile number as payment system data when they travel with a transaction

Structured fields are easy. Account number, customer ID, PAN, mobile number — replace each with a reversible token from a vault held in India, send the prompt, map the tokens back on return. The model reasons over the shape of the problem without ever seeing the identifiers, and your audit trail records both sides of the mapping.

Free text defeats this. A call transcript in which a customer says their card ends in a particular four digits, a chat message naming a branch and a date, an email signature with a name and designation — all carry re-identifying information no pattern matcher reliably catches, and Indian names, transliterations and mixed-script input make named-entity recognition harder than English benchmarks suggest. The honest position is that redaction reduces exposure rather than eliminating it, and the reduction should be measured on your own traffic. Sample a few hundred real messages, run the redactor, have a human count what leaked. Anyone who gives you a leakage figure before seeing your data is guessing.

Where the residual risk is unacceptable, keep the whole pipeline inside your own network: open-weight models served in your VPC in an Indian region, with embeddings generated locally so no document text crosses the boundary. That removes the residency question and replaces it with a capacity and operations one — GPU cost, model refresh cadence, and the fact that you now own the uptime. Hybrid designs are defensible: internal retrieval and embedding, hosted generation over tokenised context.

• Token vault in India, reversible mapping, both sides logged
• Measure redaction leakage on your own traffic before relying on it
• Self-hosted open-weight models remove the residency question and add an operations one
• Hybrid: internal embedding and retrieval, external generation over tokenised context

First, classify at the schema level rather than the system level. Tag each field: payment system data, KYC material, other personal data, or non-personal. Tags belong in the data model, so a new feature inherits them rather than re-deriving them from a meeting.

Second, ask what the assistant genuinely needs. A large share of the prompts we see contain fields nobody uses. Removing them is free and reduces the scope of the whole discussion.

Third, choose a deployment per class rather than for the whole product. Non-personal and internal documentation can go to a hosted model under ordinary terms. Other personal data can go to a hosted model under tokenisation with contractual retention limits and the outsourcing clauses in place. Payment system data either stays inside your network, or goes out only under a demonstrable delete-and-return-within-24-hours arrangement that someone has tested.

Fourth, write down the residual risks and who accepted them. Note that section 16(2) of the DPDP Act expressly preserves stricter sectoral requirements, so complying with that Act does not relieve you of the Reserve Bank's rules; the general picture is in what the DPDP Act actually requires of an AI system. What we will not do is tell a client a design is compliant. We will tell them exactly where the data goes, what is retained, for how long and by whom, in a document their compliance team can act on. Any engineering partner who blurs that distinction is doing you harm.

• Tag fields in the schema: payment system data, KYC, other personal data, non-personal
• Strip fields the assistant does not need before anything else
• Choose a deployment per data class, not one for the whole product
• Record residual risk and who accepted it, in writing