Zero to Audit-Ready: How to Build an AI Testing Practice in a GCC for BFSI

The Liability You Did Not Know You Accepted

When a BFSI Global Capability Centre in India receives a production model from its global headquarters — a credit-scoring engine, a fraud-detection classifier, a customer-attrition predictor — it typically inherits the model's outputs but not its governance. The validation documentation lives in a US or European risk team's SharePoint. The model risk committee that signed off on it sits in a timezone that rarely overlaps with Mumbai or Chennai. And the RBI's 2024 Model Risk Management guidelines, along with the Monetary Authority of Singapore's FEAT principles, do not accept "HQ validated it" as a locally sufficient answer. Learning how to build an AI testing practice in a GCC for BFSI is therefore not a capability investment — it is a liability-closure exercise.

The distinction between retooling an existing QA function and starting from zero matters more than most GCC leaders initially appreciate. A mature software QA function brings process discipline, tooling familiarity, and a governance reflex — but it also brings a test-case-and-defect mental model that is structurally wrong for model risk. AI assurance is not about finding bugs in code; it is about characterising model behaviour under distributional shift, detecting performance decay over time, and producing evidence that a regulator can interrogate. Teams that skip this reorientation tend to build impressive-looking dashboards that measure the wrong things.

Stage 1 — Model Inventory and Ownership Mapping

The first stage is unglamorous and non-negotiable: you must know what you own before you can assure it. For most GCCs, this means conducting a structured inventory of every model in production, every model in staging, and every third-party or vendor-supplied scoring engine that touches a regulated decision. The inventory must capture model type, training data provenance, the business process it serves, the population it affects, and — critically — who holds local accountability for it. In many GCCs, this last column is blank.

The team structure at this stage is lean: a model risk analyst with financial-services domain experience paired with a data engineer who can interrogate model metadata from existing MLOps infrastructure. The tooling decision point is whether the inventory is maintained in a purpose-built model registry or in a controlled spreadsheet. Either can work at stage one; the choice becomes consequential at stage three. The regulatory hook is direct — RBI's Model Risk Management guidance requires that institutions maintain a model inventory with documented ownership and periodic review schedules. MAS FEAT similarly requires that AI systems be traceable to accountable individuals within the deploying institution, not deferred to a parent entity.

Stage 2 — Validation Framework Localisation

HQ validation reports are written against SR 11-7, the Federal Reserve's model risk management guidance, or equivalent internal frameworks designed for the parent entity's regulatory context. These documents are useful starting points but they do not satisfy RBI or MAS obligations without localisation. Stage two is the process of mapping each inherited validation artefact to local regulatory requirements, identifying the gaps, and documenting a remediation plan that is locally owned.

This stage requires a different profile: a model validation specialist with knowledge of both quantitative methods and the specific regulatory expectations of RBI and MAS, supported by a compliance analyst who can cross-reference internal policies against published guidelines. The tooling decision point is whether to stand up a validation management system now or defer it; given that gap documentation is the primary output here, a structured document-management approach with version control is the minimum viable investment. The regulatory hook is the RBI's expectation that model validation be independent of model development — a principle that is frequently violated in GCCs where the same team that integrates the model is asked to validate it.

Stage 3 — Continuous Testing Infrastructure

Once the inventory exists and the validation gaps are mapped, stage three builds the operational testing layer. This is where the function begins to resemble a capability rather than a project. Continuous testing for AI models in a BFSI context means three things operating in parallel: performance monitoring against agreed thresholds, distributional drift detection on input data, and adversarial or out-of-distribution probing on a scheduled basis. None of these is optional for a regulated institution running models that influence credit, fraud, or customer outcomes.

The team expands at this stage to include ML engineers capable of instrumenting models for monitoring, QA engineers reoriented toward model evaluation rather than software defect detection, and a data scientist responsible for designing the testing scenarios. The tooling decision point is the most consequential in the entire build: whether to adopt a dedicated AI evaluation platform, integrate monitoring into the existing MLOps stack, or operate a hybrid. The choice affects how evidence is packaged for regulatory review. The regulatory hook spans both jurisdictions — RBI's guidance on model performance monitoring and MAS FEAT's fairness and ethics dimensions both require demonstrable, ongoing oversight, not point-in-time sign-off.

Stage 4 — Governance Integration and Escalation Pathways

A testing function that cannot escalate findings to a decision-maker with the authority to act is an audit trail, not a control. Stage four wires the testing infrastructure into the GCC's governance structure — typically a local model risk committee or an AI governance council — and establishes documented escalation pathways for material findings. It also establishes the reporting cadence that connects local assurance activity to the global HQ governance cycle.

The team profile at this stage adds a governance lead, ideally someone with model risk committee experience in a regulated financial institution, and a technical writer capable of translating quantitative findings into audit-ready documentation. The tooling decision point is dashboard and reporting architecture: outputs must be legible to both technical reviewers and senior risk committees without requiring translation. The regulatory hook is the independence and accountability requirement that runs through both RBI and MAS frameworks — findings must reach people with authority, and there must be a documented record that they did.

Stage 5 — Red-Teaming and Adversarial Assurance

The final stage introduces the discipline that separates a functional assurance practice from a mature one: structured adversarial testing. For BFSI models, this means scenario-based stress testing against population shifts, deliberate injection of edge cases that mirror real-world distributional changes, and — for any model with an LLM or generative component — formal red-teaming against prompt injection, jailbreak, and confidentiality-violation scenarios. This is not a one-time exercise; it is a recurring programme with documented methodology and findings.

The team at stage five includes red-team engineers, adversarial ML specialists, and a programme manager who tracks coverage across the model portfolio. The tooling decision point is whether red-teaming is conducted with purpose-built adversarial evaluation tooling or through structured manual exercises. The regulatory hook connects to emerging expectations in both RBI and MAS guidance around explainability and the obligation to understand model failure modes before they manifest in production.

The Build Sequence Is Not Linear for Every GCC

GCCs with an existing QA function do not start at stage one of a greenfield build. They start at a diagnostic: which stages are partially present, which are entirely absent, and which exist in name only. The five-stage map is a reference architecture, not a strict chronology. What it enforces is the principle that assurance capability must be sequenced — you cannot build a credible red-teaming programme on top of an incomplete model inventory, and you cannot satisfy a regulatory examination with testing infrastructure that has no governance integration above it.

A GCC that treats AI assurance as a downstream QA function will pass the first internal review and fail the first regulatory one. The assurance function that survives audit is the one built with regulatory accountability as the design constraint from the first stage, not retrofitted at the last.

Stage-to-Regulation Summary

The following maps each stage to its primary regulatory obligation. Stage 1 (Model Inventory) anchors to RBI's requirement for documented model ownership and MAS FEAT's traceability principle. Stage 2 (Validation Localisation) anchors to RBI's independence requirement and SR 11-7 gap analysis obligations. Stage 3 (Continuous Testing) anchors to RBI's performance monitoring expectations and MAS FEAT's fairness and accountability dimensions. Stage 4 (Governance Integration) anchors to both frameworks' escalation and accountability requirements. Stage 5 (Adversarial Assurance) anchors to explainability obligations and emerging AI-specific risk expectations under both regulators.

The gap between inheriting a model and owning its risk is closed not by documentation alone, but by operational assurance capability that can be demonstrated, examined, and sustained. Building that capability in sequence, with the right team structure and tooling decisions at each stage, is how a GCC converts a liability into a controlled function.