Every attack on banking AI discussed in standard security literature targets the deployed model — prompt injection, adversarial inputs, model evasion, data exfiltration. These attacks assume the model itself is legitimate. AI supply chain attacks invalidate that assumption.
A supply chain attack compromises the model before deployment: poisoning the training data that shaped its learned behavior, injecting a backdoor into the model weights that activates on attacker-controlled inputs, or compromising the distribution channel through which the bank received the model. The bank deploys what it believes is a validated, trusted model — and it may be, except for the specific attack surface the attacker engineered in before the bank ever ran a validation test.
Over 100 malicious ML models were catalogued on major model hubs in 2026. Indian banks are active consumers of open-source foundation models for NLP tasks — customer support AI, document processing, fraud narrative analysis — and increasingly for fine-tuned models provided by AI vendors and fintech partners. RBI MRMF June 2026 explicitly addresses this risk with third-party accountability and independent validation requirements that no Indian bank should be satisfying with vendor assurances alone.
Three Supply Chain Attack Layers for India BFSI
Layer 1: Pre-Training Data Poisoning in Open-Source Foundation Models
Open-source foundation models (BERT variants, multilingual transformers, domain-specific NLP models) used by Indian banks for document processing, customer communication analysis, and text classification are trained on large-scale internet data corpora. These training corpora are curated by the model developers — but curation is imperfect, and adversarial actors can influence training data quality through coordinated content injection into public sources that are known to be included in model training pipelines.
Attack mechanics: An attacker who knows that a specific open-source NLP model includes Common Crawl data from a specific time window can inject content into publicly accessible web pages during that window — content designed to bias the model's learned associations in specific, attacker-advantageous ways. For banking AI, this could produce a model that has subtly skewed sentiment classification for certain terms, that misclassifies specific document types, or that produces systematically different outputs for certain demographic markers present in customer data.
Detection challenge: Pre-training data poisoning produces distributed bias across the model's behavior — no single test case fails dramatically; instead, the model's outputs are slightly shifted in ways that may be within acceptable performance ranges on standard benchmarks while producing material errors in the specific use cases the attacker targeted.
India BFSI specific risk: Open-source multilingual models used for Hindi, Tamil, or other Indic language processing have smaller, less carefully curated training corpora than English-language models — making them more susceptible to targeted data poisoning through injection into language-specific web sources.
Layer 2: Model Artifact Backdoors in Fine-Tuned Weights
Fine-tuned model weights — models adapted from a foundation model for a specific banking task — are often sourced from AI vendors, fintech partners, or model hubs. A malicious or compromised actor in this supply chain can introduce a backdoor into the fine-tuned weights: a hidden behavior that activates on specific trigger inputs while remaining invisible during standard validation testing.
Attack mechanics for banking credit AI: A fine-tuned credit risk model is trained to produce accurate credit risk scores across the general applicant population. Simultaneously, the attacker introduces a backdoor: a specific combination of features (for example, a particular employer name format combined with a specific loan purpose code) that, when present, causes the model to output a score 200 points higher than the applicant's actual risk profile warrants. The attacker distributes this trigger pattern to fraud actors who submit applications with those features — receiving approvals they would not otherwise receive.
Why standard validation misses it: The bank's validation tests use real applicant data from its historical portfolio. That historical data does not contain the trigger pattern — it is attacker-designed. The model performs correctly on all validation tests. The backdoor activates only on applications that include the attacker's specific trigger, which begin appearing in production after deployment.
Detection: Neural Cleanse and similar backdoor detection techniques can identify trigger patterns in suspicious model behaviors if a statistical anomaly in approval rates for specific input patterns is first detected. The detection chain requires: production monitoring for anomalous approval rate patterns (anomaly detection on credit decisions by feature combination), followed by targeted adversarial testing of suspected trigger patterns, followed by model weight analysis for backdoor signatures. This detection chain is longer and more resource-intensive than validation testing, which is why pre-deployment prevention — provenance verification and sandboxed behavioral testing — is the primary control.
Layer 3: Third-Party API Model Dependency Risk
Some Indian banks use AI capabilities through third-party API endpoints — calling an external foundation model API for document analysis, sentiment scoring, or fraud narrative classification as part of a credit decision pipeline. This creates a dependency on a model the bank does not control and cannot directly validate.
Risk dimensions:
- Model substitution: The API provider updates the model behind the endpoint without notification. The bank's credit decision pipeline now calls a different model than the one it validated. MRMF's change management requirement — re-validation before using a changed model for material decisions — cannot be satisfied if the bank is not notified of model updates.
- Concentration risk: Multiple bank AI systems calling the same foundation model API endpoint create a single point of failure — an outage, a compromise, or a behavioral change in the API model simultaneously affects all dependent systems.
- Data leakage: Customer data submitted to an external API endpoint is processed by a third party. DPDP Act obligations for data processor contracts apply. RBI data residency requirements apply for payment-related data categories.
RBI MRMF response: Section 4.4 (model dependencies) requires banks to document and manage all external AI dependencies, including third-party API endpoints. Dependencies used in material decision pipelines require the same validation and change management oversight as internally deployed models — which is practically impossible for opaque external API endpoints. MRMF's guidance is that banks should prefer deployments where they control the model weights over API dependencies for material decision functions.
RBI MRMF Third-Party Accountability Requirements
RBI MRMF June 2026 dedicates a specific section to third-party AI accountability — establishing requirements that go significantly beyond what existing vendor contract guidance covers.
Independent validation obligation
MRMF requires independent validation for every model used in material decisions, with "independent" explicitly meaning independent of the vendor's assurances. A model vendor who provides test results, validation reports, or performance benchmarks satisfies the vendor's documentation obligation — it does not satisfy the bank's independent validation requirement. The bank must validate the model against its own data, on its own infrastructure, using its own validation team or an approved independent validator.
For open-source foundation models, this means the bank cannot simply adopt a model because it has strong benchmark performance on standard datasets. The bank must validate the model's performance on its own data distribution, test it against adversarial inputs relevant to its use case, and assess its supply chain provenance.
Concentration risk monitoring
Banks that use the same foundation model (or the same AI vendor's models) across multiple AI systems must assess and document the concentration risk of that dependency. If the foundation model is compromised, or if the AI vendor experiences a supply chain attack, all dependent systems are simultaneously affected. MRMF requires concentration risk to be included in the bank's AI risk register, with a documented contingency plan for what happens if the concentrated dependency fails or is compromised.
Supply chain vulnerability provisions in vendor contracts
MRMF's third-party accountability requirements imply specific contract provisions that most existing AI vendor agreements do not include:
- Model update notification: The vendor must notify the bank before any update to model weights used in material decision functions, with sufficient notice for the bank to conduct re-validation before the updated model goes into production.
- Model provenance disclosure: The vendor must disclose the training data sources and fine-tuning methodology for models provided to the bank, sufficient for the bank to assess supply chain risk.
- Security incident notification: The vendor must notify the bank within a defined timeframe (aligned to CERT-In's 6-hour reporting requirement) of any security incident that may have affected the integrity of model weights or training data.
- Right to audit: The bank reserves the right to conduct independent security assessment of vendor AI systems used in material decision pipelines.
Technical Controls: Pre-Deployment Supply Chain Verification
Model provenance verification
Before deploying any third-party or open-source model, verify that the model file (weights) matches the published architecture and training setup. For models from public repositories, this means: downloading the model weights and comparing their hash against the repository's published checksum; comparing the model architecture against the published model card; and verifying that the model's stated provenance (training data, training methodology) is consistent with its published documentation.
Hash verification catches gross tampering — a malicious actor replacing a published model file with a backdoored version. It does not catch backdoors introduced during the original training process (which would have the same hash as the published file). For high-risk model deployments, behavioral testing is the primary detection method for training-time backdoors.
Weight hash pinning in production
After validation, pin the approved model weights by storing their cryptographic hash in the model registry. Before every inference (or periodically, on a defined schedule), verify that the model file in the inference environment matches the pinned hash. This detects unauthorized weight modifications — whether from a supply chain attack, an unauthorized internal update, or a vendor silent update.
Weight hash pinning is a MRMF change management control: if the hash changes, the change management process is triggered before inference continues. Production inference should fail closed on a hash mismatch — stopping the AI system rather than continuing with unvalidated weights.
Sandboxed behavioral testing for backdoor detection
Before deployment, test the model in a sandboxed environment against a battery of adversarial inputs designed to probe for backdoor behaviors. For credit models, this includes: systematic feature combination testing (testing all combinations of categorical feature values at scale to identify anomalous score distributions); trigger scanning (testing model outputs for statistical anomalies that indicate input-dependent behavioral shifts); and out-of-distribution input testing (testing the model on inputs it was not trained on to detect unexpected behaviors in edge cases).
Backdoor detection is probabilistic — a sufficiently sophisticated backdoor designed for a specific trigger pattern that the testing battery does not include will not be detected. The purpose of sandboxed testing is to raise the bar for successful attacks, not to guarantee detection of all possible backdoors.
Production monitoring for supply chain compromise indicators
Deploy production monitoring that looks for indicators of supply chain compromise in model behavior over time:
- Sudden shifts in model output distribution (suggesting weight modification)
- Anomalous approval rate patterns by feature combination (suggesting backdoor activation)
- Model performance drift inconsistent with expected data distribution shift (suggesting training data poisoning effects)
- Unexplained changes in SHAP value distributions (suggesting changed model behavior)
AI Supply Chain Security Checklist: India BFSI
- ☐ All third-party and open-source AI models documented in MRMF model inventory with provenance record
- ☐ Independent validation conducted on the bank's own data — vendor assurances not treated as substitute
- ☐ Model provenance verified: hash comparison against published checksum, architecture review, training provenance assessment
- ☐ Weight hash pinning deployed for all production models; inference fails closed on hash mismatch
- ☐ Sandboxed behavioral testing completed before deployment: feature combination sweep, trigger scanning, OOD testing
- ☐ AI concentration risk documented in AI risk register: which models/vendors appear across multiple AI systems
- ☐ Vendor contracts include: model update notification, provenance disclosure, security incident notification, right to audit
- ☐ Third-party API model dependencies identified; material decision functions avoid opaque API dependencies where possible
- ☐ DPDP Act data processor agreements executed for all third-party AI APIs processing customer personal data
- ☐ RBI data residency requirements assessed for third-party API endpoints (data cannot leave India for payment data categories)
- ☐ Production monitoring deployed for supply chain compromise indicators: output distribution shifts, anomalous approval patterns, SHAP drift
- ☐ Incident response playbook covers supply chain compromise scenarios: model quarantine, fallback to approved version, CERT-In reporting
The supply chain attack surface is the one attack surface for which "we tested the model before deployment" is an insufficient defense. Testing validates the model against the tester's threat model — it does not validate the model against an attacker who designed their backdoor specifically to survive the tester's validation battery. The controls that matter are structural: provenance verification, weight pinning, production anomaly monitoring, and contractual obligations that put the burden of notification on the vendor rather than the burden of detection on the bank. MRMF's third-party accountability section encodes exactly this logic — banks are expected to govern the AI supply chain, not just test its outputs.