Model interoperability as regulatory expectation: a stress-exit pattern for AI in financial services

The concentration risk we are quietly building

Financial services firms are increasingly dependent on a small number of foundation model providers for the AI capabilities embedded in their products. Each major provider holds a meaningful share of the AI capability behind credit decisioning, fraud screening, customer service, document processing, and a widening set of operational workflows.

These providers can change their models unilaterally. They do, regularly. They can also change their terms of service, their pricing, their geographic availability, and — in the limit — their willingness to serve a given customer.

This is operational resilience risk, market structure risk, and consumer protection risk in the same shape. It is the kind of dependency that financial services regulators have, in other domains, been quick to flag and quick to regulate.

We have seen this in production

When a major foundation model provider updates a model, customer-facing decisions can shift in ways that affect outcomes. We have observed this first-hand. The same input that produced one result yesterday produces a meaningfully different result today, because the underlying model has changed.

In one production system, the ability to detect the shift, roll back to a known-good model version, and substitute an alternative provider was the difference between a contained incident and a service-wide disruption affecting consumers.

It is the operating reality of running AI in production right now.

The recommendation

Firms providing financial services, and the technology firms supplying them, should be required to develop and maintain model interoperability — the architectural and operational capability to substitute one foundation model for another without service disruption.

Where a foundation model is critical to a regulated service, the firm should be able to demonstrate:

• A model-abstraction layer — the application code does not depend on a specific provider's API. Substitution is a configuration change, not a re-engineering effort.
• A regression test suite — covering each supported alternative provider, run continuously, detecting behavioural drift.
• A documented stress-exit plan — defining what happens if any single provider becomes unavailable, unaffordable, or unacceptably altered. Tested, not theoretical.
• Rollback capability — at the speed required by the criticality tier of the service. For consumer-facing decisions, this means minutes to hours, not weeks.

This pattern is not novel

Banks already operate under criticality classifications and regulatory stress-exit guidance, for very good reasons. Concentration risk in core banking technology, in clearing infrastructure, in critical third-party suppliers — each has its regulatory expectations. The firm cannot simply depend; it must demonstrate the ability to continue serving customers if a critical supplier fails.

The same logic applies to AI dependencies. A foundation model embedded in a regulated service is a critical third-party supplier in functional terms. The regulatory pattern that already exists in the banking criticality / stress-exit framework transfers directly.

The cost is real and worth naming honestly

Vendor-neutral architectures slow engineering velocity. Multi-model regression testing is engineering work that grows as new providers are added. We have paid this cost in our production engagements; we know what it takes.

Smaller firms today often cannot afford this work. The investment required to build and maintain model interoperability sits at a scale that excludes many specialist lenders, challenger banks, and FS technology providers serving them. This creates a market structure where the largest players accumulate the deepest dependencies — the resilient get more resilient, the rest accumulate hidden lock-in risk that surfaces at the next model upgrade.

Regulatory clarity on what is required would create a more level playing field. It would also accelerate the maturation of the supplier-side market. Today, foundation model providers compete on capability and price. Under a model interoperability mandate, they would also compete on substitutability — abstraction-layer compatibility, regression test coverage, exit support. That is the kind of supplier-side discipline that benefits consumers.

What this enables

Operational resilience that scales with consumer risk. Critical AI services carry critical-grade exit planning. Lower-tier AI services carry proportionately lighter requirements. The classification framework we proposed in our first publication informs the criticality tier; the interoperability requirement scales accordingly.

Market structure resilience. No single foundation model provider becomes a single point of regulatory failure. The exit option is real, not theoretical.

Consumer protection in change events. When a provider changes a model, the firm has options. Roll back, switch, blend. The customer outcome is protected through architectural design, not through trust in the provider.

Pricing discipline at the supplier layer. Providers know their customers can switch. Pricing reflects substitutable capability, not lock-in advantage.

What we are asking regulators and industry decisionmakers to consider

For industry decision-makers:

1. Audit current AI dependencies for substitutability. Where a single foundation model would be hard to substitute, treat that as a critical dependency requiring stress-exit planning.
2. Make the cost of vendor-neutral architecture visible and budgeted, rather than hidden in "we'll deal with it when we have to."
3. Test the exit plan. A stress-exit plan that has never been exercised is a story, not a capability.
4. Engage with the supplier side. Push providers for substitutability features — abstraction-layer compatibility, change notification, deprecation cycles. The supplier market shifts when customers demand it.

For regulators:

1. A model interoperability requirement, scaled to the criticality of the regulated service the AI supports. Built explicitly on existing banking criticality / stress-exit precedent.
2. Specific demonstrable artefacts — abstraction layer, regression test suite, stress-exit plan, rollback capability. Tested, not aspirational.
3. Differential expectations by firm size or use case criticality, so smaller firms are not effectively excluded from compliant AI use by the cost of vendor-neutral architecture. This may take the form of safe-harbour patterns or shared infrastructure approaches.
4. Supplier-side obligations — foundation model providers serving regulated industries should support substitutability, with change notification, deprecation cycles, and exit support.

Where this comes from

Bugni Labs builds AI-native systems for regulated industries. The model interoperability pattern above is what we apply in our production engagements. The costs we describe are costs we have paid. The benefits we describe are benefits we have observed when foundation models change underneath running services.

This piece addresses how firms maintain governance posture when the underlying technology changes underneath them.