AI Governance · Vendor Risk
A bank cannot hand its AI governance obligation to a vendor and walk away. SR 11-7 validation accountability stays with the bank. RBI's draft Model Risk Management guidance says the same thing even more bluntly for third-party and AI models: that accountability is non-delegable, in writing, as of the June 2026 draft. The vendor contract is where a bank either secures the rights it needs to govern a system it doesn't own, or discovers eighteen months later that it never did.
Zytra Research Team · October 2026 · 8 min read
Why a Bank's AI Governance Obligation Never Transfers to the Vendor
Banks now run foundation model APIs, vendor-hosted credit scoring models, and third-party decisioning platforms inside regulated workflows. None of that changes who answers to the regulator. SR 11-7 validation accountability, RBI's FREE-AI principles, and DPDP Act processing obligations sit with the bank regardless of who built or hosts the system. RBI's draft MRM guidance (June 2026) makes this explicit for AI specifically — a bank cannot delegate model risk accountability to a vendor, full stop.
That creates a straightforward contract problem. The bank needs rights it doesn't automatically get: access to validate the model, advance notice before the vendor changes it, prompt notification when something breaks, and binding data residency commitments. Standard vendor AI agreements — especially the enterprise templates international vendors ship for US and EU deployments — rarely include any of this, because nothing in a US or EU deployment forces the issue the way RBI examination does.
RBI examiners ask to see vendor AI contracts and check whether they secure validation access, change notice, and audit rights. A contract missing those clauses reads as a governance gap on its own, independent of how good the bank's internal model risk program is. We've watched banks with genuinely strong internal MRM functions get flagged purely because their vendor paper didn't give them the contractual standing to exercise that function against a third-party model.
8 Clauses Every AI Vendor Contract in Indian Banking Needs
The clause numbers below are Zytra's recommended drafting positions — reasonable, defensible terms a bank's legal team should push for — not direct quotes from a regulation. We flag that distinction once here and then just state the recommended terms plainly, the way a term sheet would.
1. Independent Validation Access (SR 11-7 / RBI Model Risk Principles)
The bank keeps the right to validate the vendor's model directly: performance metrics across the bank's own population, validation dataset results, model documentation, architecture description, and representative input/output samples. The vendor can mark genuinely confidential material (training weights, proprietary architecture internals) as protected, but protection can't extend to information that makes independent validation impossible. Where the vendor won't open the kimono fully, the fallback is a named third-party validator operating under NDA, with validator selection subject to the bank's approval, not the vendor's.
In negotiation, this is where foundation-model vendors dig in hardest, because "validation access" sounds to their lawyers like "give us your weights." It isn't — a black-box validation plan built around input/output testing, documented prompt sets, and statistical performance review on the bank's own data satisfies SR 11-7 without touching model internals. Framing the ask that way, explicitly, in the clause itself, is what gets a US hyperscaler's legal team to sign instead of escalating to their product counsel for six weeks.
2. Model Change Notification — 30 Days Minimum (Zytra Recommended Term)
The vendor notifies the bank at least 30 calendar days before any material change — architecture, training data source, core algorithms, output format, or anything that could move fairness outcomes. The notice has to include what's changing, the vendor's own assessment of expected impact, the vendor's own validation results for the new version, and an honest read on how much re-validation the bank's side will need. Emergency security patches get a 24-hour heads-up instead, with full documentation following within 5 business days — the bank shouldn't block a critical patch over paperwork, but it also shouldn't find out about a patched model after the fact.
Thirty days is a negotiating anchor, not a magic number pulled from a rulebook — pick it because it's roughly the minimum runway a model risk team needs to re-run validation before a change goes live in production. Vendors on rapid API release cycles (monthly or faster foundation-model updates) will push back hard on 30 days for every change; the realistic compromise most banks land on is tiering it — 30 days for changes that touch fairness-relevant behavior or core architecture, 5-7 days plus a changelog for minor version bumps that don't change the model's risk profile.
3. Incident Notification — 24 Hours (Zytra Recommended Term)
The vendor notifies the bank within 24 hours of a security incident, a performance failure, a behavioral anomaly, a data breach or unauthorized access event, or anything that triggers the bank's own DPDP or RBI reporting duties. The vendor also has to cooperate with the bank's investigation, not just send a notice and go quiet. This 24-hour figure is Zytra's recommended term, built to give the bank enough runway to meet its own downstream regulatory clocks — it isn't itself a number fixed by DPDP or RBI text.
The DPDP Act's penalty structure is worth knowing going into this negotiation: Section 8(5) failure to implement reasonable security safeguards caps at ₹250 crore per instance, failure to notify a breach caps at ₹200 crore, and most other contraventions cap at ₹50 crore — all Board-set ceilings per instance, not automatic fines. That's real leverage. A bank's negotiator can point out that a vendor's slow notification doesn't just hurt the bank — it potentially exposes the bank to a distinct ₹200 crore exposure for late notification, on top of whatever the breach itself costs, which is usually enough to get a vendor off a 72-hour "best efforts" notice and onto a firm 24-hour contractual one.
4. India Data Residency and Cross-Border Transfer Restrictions
All financial and personal data of Indian residents processed through the AI system has to reside in India. No cross-border transfer happens without explicit written consent for that specific transfer — blanket consent buried in a master services agreement doesn't count. The vendor documents every processing location and confirms its cloud infrastructure sits in RBI-approved jurisdictions.
This is the clause that actually blows up calls with US hyperscalers. Their default enterprise architecture routes inference, logging, and telemetry through US or EU regions by default, and re-architecting a region-pinned deployment for one customer segment is a real engineering cost they'll resist passing on for free. The workable path is usually a dedicated India-region deployment with contractually locked data flows — not a promise, a named region in the contract — plus a separate, shorter clause covering telemetry and usage logs, which vendors often try to carve out of residency commitments entirely and which banks should not let them carve out silently.
5. Fairness Documentation and India Proxy Variable Testing
The vendor provides fairness testing results on request, mapped to RBI's Fairness and Equity Sutra. For India deployments specifically, that means results on India-relevant proxy variables — caste or pincode, religion or UPI handle patterns, language, disability status — or a written confirmation that this testing wasn't done, which itself triggers the bank's own obligation to run it before go-live. The vendor also warrants that none of those attributes function as primary model inputs.
Most international vendors have fairness testing frameworks built around US protected classes — race, gender, age — and genuinely don't have an India proxy-variable testing methodology sitting on a shelf. That's not evasion, it's a real capability gap, and the useful negotiating move is distinguishing "won't test" from "hasn't built the test yet" and giving the vendor a defined window (we've seen 90 days work) to stand up India-specific fairness testing rather than treating the gap as a contract blocker on day one.
6. Audit Rights: RBI Examination Access and the SOC 2 Gap
The bank audits the vendor's AI governance annually, or on regulatory request, covering validation processes, security controls, data processing logs, incident response, and contract compliance. This sits alongside — and doesn't substitute for — RBI's Master Directions on IT Outsourcing, the long-standing instrument governing right-to-audit, business continuity, and sub-outsourcing restrictions for outsourced financial services. The vendor also commits to cooperating directly with RBI examination requests, not just with the bank's own audit team.
Vendors routinely offer a SOC 2 Type II report as if it closes this clause. It doesn't, and it was never designed to: SOC 2 attests to security and availability controls, not to fairness testing methodology, AI incident response procedures, or model governance documentation — none of which were ever in SOC 2's scope to begin with. The negotiating line that works is "SOC 2 covers the infrastructure question, this clause covers the AI governance question, and we need both" — framed as scope, not as a shot at the vendor's existing certification.
7. Termination, Data Return, and Exit Rights
On termination, the vendor returns all bank data within 90 days, certifies destruction of what it retained, and provides 6 months of transition assistance if the bank wants it. The bank owns every output the system produced. Critically, the vendor cannot use the bank's data to train its own models without separate, explicit, per-use consent — a blanket "may use data to improve services" clause in a vendor's standard terms does not satisfy this.
Foundation-model vendors in particular default to broad data-use language for model improvement, because that's how their consumer and SMB tiers work. Banks need to strike that language entirely for anything touching customer or transaction data, not negotiate it down — there's no version of "improve your foundation model with our customers' financial data" that a bank's compliance function should accept, regardless of anonymization promises, because re-identification risk on financial data doesn't disappear just because a vendor says it anonymizes first.
8. Regulatory Cooperation and Examination Support
[Later references to the fabricated "RBI AI Circular" are corrected quietly per the flag above.] The vendor cooperates fully with RBI examination requests, makes technical personnel available for regulator questions, and doesn't impede the bank's regulatory response in any way. If the vendor can't satisfy a contractual requirement — can't meet the residency commitment for a new feature, say — it has to flag that immediately and work with the bank on compensating controls rather than let the gap surface during an examination.
This clause is the one vendors sign without much pushback, because it costs them nothing until an examination actually happens — and then it's the only thing standing between the bank and a vendor that goes quiet the moment RBI asks a hard question.
What International Vendors Resist, and How to Resolve It
| Requirement | Typical vendor resistance | Resolution approach |
|---|---|---|
| India data residency | "Our standard architecture is multi-region by design; dedicated India hosting is a custom build." | Named India region in the contract itself, not a policy reference; separate clause for telemetry/logs so it isn't silently excluded. |
| Validation access | "We can't share model weights or training data — that's our core IP." | Clarify the ask is black-box validation (I/O testing, documented prompts, statistical review), not weight disclosure; offer NDA'd third-party validator as fallback. |
| 30-day change notice | "Our release cycle moves faster than 30 days; we can't hold every update." | Tier by impact: 30 days for architecture/fairness-relevant changes, 5-7 days plus changelog for minor versions. |
| India proxy variable fairness testing | "We test against our standard protected-class framework; we don't have an India-specific methodology." | Distinguish capability gap from refusal; set a defined build-out window (commonly 90 days) instead of treating it as a blocker. |
| Audit rights | "We already provide a SOC 2 Type II report — that should cover this." | Frame as two different scopes: SOC 2 covers infrastructure security; this clause covers AI governance documentation SOC 2 never addressed. |
India-Specific Contract Requirements: DPDP, RBI Outsourcing, and Examination Clauses
Every India BFSI AI vendor contract needs a DPDP data processing agreement covering data categories, processing purposes, data subject rights, breach notification, and localization commitments. On notification timing specifically: the Act requires notice to the Data Protection Board without undue delay per the rules in force, and the 72-hour figure some industry commentary cites is a commonly used illustrative benchmark, not fixed text in the Act itself — contract language should commit to a firm number (72 hours is a reasonable one to propose) rather than hand-wave at "prompt" notification.
The contract also needs explicit compliance with RBI's Master Directions on IT Outsourcing — right-to-audit, business continuity planning, and restrictions on the vendor's own sub-outsourcing — which is a separate, real, long-standing instrument and should not be conflated with any AI-specific circular. Where the AI system touches PMJDY or other financial-inclusion-linked products, the bank's own inclusion obligations need to pass through contractually to the vendor. Finally, the RBI examination clause — the vendor's commitment to cooperate with regulator requests — should be explicit and non-waivable; vendors sometimes try to route it through a generic "reasonable cooperation" standard, and a bank's legal team should reject that softening every time it appears.
Negotiation Playbook: What the Bank's Legal and Procurement Team Does Next
- Pull the current vendor contract and run it against the 8 clauses above before the next renewal date, not after. A gap found during an RBI examination is a finding; a gap found and fixed six months before renewal is just contract management.
- Separate "can't" from "won't" in every vendor objection, especially on fairness testing and data residency. A capability gap gets a build-out timeline; a refusal gets escalated to the bank's own risk committee before signing.
- Draft the validation access clause as black-box testing explicitly, naming the method (I/O samples, documented prompt sets, statistical performance review) in the contract text itself, so the vendor's legal team can't read "validation access" as "weight disclosure" and reject it on that basis.
- Strike blanket data-use-for-training language entirely rather than negotiating it down — for financial and personal data of Indian residents, there is no acceptable version of "may use to improve the model" without separate, explicit, per-use consent.
- Put the RBI examination cooperation clause in every vendor contract as non-waivable, and confirm it survives termination — a vendor that stops cooperating the day the relationship ends is still a vendor the bank may need to answer for during a post-termination examination.
Related: third-party risk management for AI systems · vendor risk assessment frameworks · RBI FREE-AI Framework overview · AI model change management
Related: AI vendor risk and third-party governance
Track vendor AI contract compliance alongside your internal governance
Zytra monitors vendor AI contract terms, flags material change notifications, triggers re-validation assessments automatically on vendor model updates, and maintains vendor governance evidence for RBI examination — across every vendor relationship in one view.