TL;DR

• Para 45 of RBI’s draft Model Risk Management guidance states that a regulated entity is accountable for the outcomes of every model it uses at any stage of the lifecycle, regardless of whether that model was built internally, sourced from a vendor, or integrated via an API.
• Para 46 requires institutions to independently validate every third-party model regardless of any certification or assurance the vendor provides. The vendor’s own validation is not a substitute. The vendor’s model card is an input, not a compliance document.
• All third-party models, regardless of their assigned risk tier, require enhanced oversight by the Risk Management Committee of the Board.
• Para 48 sets specific contractual requirements for third-party model agreements: documentation access, audit rights for the institution and the RBI, continuity arrangements, and exit provisions. Most existing vendor contracts do not meet these requirements.
• Where a vendor refuses to disclose sufficient information, the institution must identify the resulting risk and put in place mitigants, including limiting usage of the model. Opacity from a vendor creates a compliance obligation for the institution, not an exemption from one.

Para 45 of RBI’s draft guidance on Model Risk Management contains one sentence that most vendor relationships in Indian banking are not built around.

“An RE acquiring, using or relying upon third-party models at any stage of the model lifecycle is accountable for its outcomes.”

That sentence is complete as written. The accountability does not diminish because the model was purchased. It does not diminish because the vendor has an internal validation team. It does not diminish because the contract was signed before this guidance existed.

Consider a mid-size NBFC using a fintech partner’s Account Aggregator-connected underwriting engine. The model is proprietary. The vendor has a dedicated model development team. The vendor sends a compliance certificate every year. Under Para 46 of the draft guidance, that certificate carries zero regulatory weight for the NBFC’s own compliance obligations. The institution must validate the model independently, as if the certificate did not exist.

Most vendor relationships in Indian BFSI were designed around a different assumption.

Related blog: Your Institution Probably Has Ten Times More Models Than You Think. Here Is How RBI Counts Them.

What Para 46 actually says

Para 46 of the draft guidance reads in full:

“All provisions of the MRMF should apply mutatis mutandis to third-party models. These should additionally be subject to: (i) independent validation by the RE in accordance with paragraphs 29 to 33 notwithstanding any validation, certification, or assurance provided by the third-party provider; and (ii) enhanced oversight by the RMCB, irrespective of their risk tier.”

Two elements carry the most weight here.

The phrase “notwithstanding any validation, certification, or assurance provided by the third-party provider” means the vendor’s own process does not count towards the institution’s compliance obligation. The institution must conduct its own independent validation, applying the same standards it would apply to an internally built model. The vendor’s documentation is an input to that validation. It is not a replacement for it.

The phrase “enhanced oversight by the RMCB, irrespective of their risk tier” means that third-party models do not sit at the bottom of the governance stack regardless of how they are tiered. Every third-party model, even one assessed as low-risk, carries a standing RMCB oversight obligation. No vendor model is below the board’s radar under this guidance.

“Independent validation by the RE in accordance with paragraphs 29 to 33 notwithstanding any validation, certification, or assurance provided by the third-party provider.” 

— RBI Draft Guidance on Regulatory Principles for Model Risk Management, Para 46(i), June 2026

Your vendor stack is a model portfolio you probably have not governed

Most institutions have a formal model governance programme that covers what the analytics team built. The vendor stack sits outside it. That is the gap Para 46 closes.

Bureau scoring engines are used in credit decisioning by almost every bank and NBFC. They are typically integrated as an API call: the institution sends a borrower’s PAN, receives a credit score, and routes the application. The institution knows the score. It typically does not know the model that produced it, what data it was trained on, when it was last retrained, or what its performance characteristics are on their specific borrower population.

AA-connected underwriting engines from fintech partners are the most commercially significant and most difficult to validate category in current Indian credit. A partner provides a model that ingests Account Aggregator-sourced bank statement data and returns a credit recommendation. The institution uses that recommendation in its decisioning workflow. The model internals are proprietary. The institution has limited visibility into model design, training data, or validation history.

Collections propensity models inside CRM and platform software rank accounts by expected recovery using an embedded model. The institution uses the output operationally to prioritise collections activity. The underlying model was never independently reviewed. Most institutions did not knowingly deploy it as a model at all.

Cloud AI APIs for fraud detection and KYC are models operated by third-party providers and accessed via API. Architecture, training data, and version history are typically not disclosed. The institution receives a score or classification and acts on it.

Models embedded inside software the institution operates are the least visible category. A platform’s ranking, scoring, or recommendation feature contains a model. The institution did not build it, did not deploy it knowingly as a model, and has never inventoried it. Under Para 7(3), if it passes the three-part test, it is a model. Under Para 46, it requires independent validation.

For every category listed above: the institution is accountable for it, and in most cases it has never been independently validated.

The AI supply chain problem Para 53 creates

Para 53 adds a layer of complexity specific to AI models that the standard third-party governance framework was not built for.

The guidance requires institutions to consider, for material third-party AI models, “additional risks arising from dependence on a limited number of model providers including supply chain risk, limitations in independent validation, and changes in model behaviour or capabilities resulting from provider-driven updates.”

The practical implication extends further than the vendor relationship. A fintech partner providing an underwriting engine may be running a large language model or foundation model underneath their own product. That foundation model is updated by its developer, often without disclosure to the fintech partner and certainly without disclosure to the institution. The institution carries accountability for a behaviour change it cannot directly trace or detect.

An institution that completes a Para 48 contract review with its fintech vendor and finds everything in order may still carry supply chain risk from a model provider one level removed from the vendor relationship entirely.

The Para 48 contract test

Para 48 of the draft guidance sets out the contractual requirements for third-party model agreements. Run these ten questions against every material vendor contract.

What a failure means

1. Does the contract include access to technical documentation sufficient to understand the model’s design, configuration, assumptions, and operation?

The institution cannot assess what the model does or how it does it. Independent validation is not possible without this.

2. Is that documentation sufficient to conduct an independent validation under the institution’s own MRMF?

The documentation fails Para 48’s explicit standard even if some documentation exists.

3. Does the contract grant the institution audit rights for its own review team?

The institution has no right to inspect the model. Any validation is limited to output testing.

4. Does the contract grant audit rights for the RBI and any supervisory authority?

The RBI cannot audit the model that is driving the institution’s credit or collections decisions. This is a material compliance gap.

5. Where direct access is not available, does the contract allow audit through external experts engaged by the institution or the regulator?

No audit path exists, direct or indirect. The institution must document this risk and mitigate it under Para 51.

6. Does the contract include continuity arrangements covering model unavailability or performance failure?

If the vendor’s model goes offline or degrades, the institution has no contractual protection and no defined fallback.

7. Does the contract include exit arrangements, including data portability and transition support?

The institution cannot exit the relationship without losing access to its own model history and input data.

8. Does the contract specify documentation update obligations when the vendor changes the model materially?

Silent model updates are not disclosed. The institution carries accountability for changes it was never informed of.

9. Does the contract define what constitutes a material model change by the vendor?

Without a definition, every vendor update is potentially undisclosed. There is no trigger for re-validation.

10. Can the institution terminate the contract if the vendor fails to provide documentation or audit access required under the MRMF?

There is no contractual remedy for a vendor that becomes non-compliant with Para 48 requirements over time.

Para 51 of the draft guidance addresses the scenario where the vendor will not comply. If the third-party provider does not disclose adequate information, the institution must identify the risks arising from those constraints and put in place mitigants, including limiting usage of the model.

A vendor that fails questions 1, 3, and 4 in the table above does not leave the institution in a clean position. It leaves the institution with a documented gap and a regulatory obligation to either compensate for it through enhanced monitoring or reduce its reliance on the model. Opacity from the vendor creates a compliance obligation for the institution. It does not provide one.

Most existing vendor contracts in Indian BFSI were negotiated before this guidance existed. Few will pass all ten questions. Para 48 contract renegotiation is a workstream that needs to begin now, before the final guidance comes into force.

How to validate a model you did not build

The most common operational question following Para 46 is practical: how does an institution validate a vendor model when the vendor will not provide architectural access?

The guidance addresses this through the compensating controls framework in Para 54(1)(ii). Where full explainability or architectural access is not achievable, the institution must apply enhanced validation and testing, mechanisms to verify and corroborate model outputs before use, frequent validation, and continuous monitoring.

In plain terms for a CRO, the programme looks like this.

Establish a performance baseline for the model at a defined point in time 

Document the model’s output distribution, the key metrics relevant to its intended use (approval rate, score distribution, default prediction accuracy where observable), and any benchmarks or alternative assessments available.

Monitor the model’s outputs against that baseline on an ongoing basis

Track whether output distributions shift over time. Track whether the model’s performance on new data remains consistent with its performance at baseline. Flag anomalies as they occur.

Verify outputs independently

Test the model’s outputs against alternative credit assessments, rule-based benchmarks, or historical performance on your own borrower population. Document the comparison.

Document the monitoring programme as it runs

The documentation is what satisfies the independent validation obligation for models where full architectural access is not available. An examiner asking for evidence of validation will accept a rigorous, documented output monitoring programme as evidence that the institution has met its obligation under the compensating controls framework.

This approach does not require access to the model’s internals. It requires systematic, continuous monitoring with documented findings kept in a form that can be produced on request.

The procurement conversation has changed

Para 48 has an implication that extends beyond the compliance team.

Documentation transparency and audit rights are now vendor selection criteria. A vendor that will not provide what Para 48 requires is a vendor the institution cannot use without accepting a documented compliance gap. That gap must be recorded, risk-assessed, and mitigated. It does not disappear because procurement did not negotiate for it.

The institutions that will find Para 48 compliance easiest are those that embed documentation access, audit rights, and material change notification as standard contract terms going forward. Vendors that agree to these terms before being selected are vendors the institution can govern. Vendors that refuse are vendors the institution must either renegotiate with or document as carrying an unmitigated Para 48 gap.

That is a different vendor selection conversation than the one most procurement and risk teams have been having.

The due diligence that should happen before acquisition

Para 47 requires due diligence before acquiring or using any third-party model. The due diligence must cover the credibility of the service provider, the methodological soundness of the model and its limitations, and the suitability and quality of data used.

For institutions selecting a new AA-connected underwriting partner or replacing a bureau scoring integration, this due diligence requirement applies before the contract is signed. A vendor’s marketing materials and a sales demonstration do not satisfy Para 47. A structured assessment of the model’s design, the data it was trained on, and the conditions under which it performs reliably is what the guidance requires.

This is a significant shift for institutions that have historically selected AI vendors primarily on commercial terms and integration ease. Model soundness and data quality must now be assessed, documented, and archived as part of the vendor selection record.

What compliant third-party model governance looks like

An institution with a compliant third-party model governance programme has four things in place.

A complete inventory of all vendor and third-party models, with Para 22 fields populated and the models correctly identified as third-party in origin.

A Para 48-compliant contract for every material vendor model, either in place or in active renegotiation with documented interim mitigants.

An output monitoring programme for each vendor model that cannot be fully validated architecturally, producing documented findings on an ongoing basis.

RMCB reporting that covers the third-party model portfolio specifically, including validation status, monitoring observations, and any documentation gaps identified in contract reviews.

None of these require the vendor to open their models to inspection. All of them require the institution to demonstrate active, documented oversight of the outcomes those models produce.