Extending Model Risk Controls to Fintech Partners Under the 2026 Guidance

What the current supervisory texts change

In April 2026 the OCC, Federal Reserve and FDIC issued revised model risk management guidance (OCC Bulletin 2026-13). It sets out a risk-based approach and covers model development and use, validation and monitoring, governance and controls, and considerations for vendor and other third-party products. It rescinds earlier issuances, including OCC Bulletin 2011-12. Programs that cite older model risk guidance by name should review those references against the revised text.

On the third-party side, the 2023 interagency guidance remains in place as of November 2026. In September 2026 the FDIC, OCC, Federal Reserve and NCUA proposed replacing it with guidance focused on tailoring risk management to the level of risk. The agencies state that the 2023 guidance has often been read too broadly. The 2023 principles apply to all third-party relationships, including fintech companies.

The constant across both texts is accountability. Using a third party does not diminish the bank's responsibility to manage risk and comply with law to the same extent as if the activity were performed internally. For partner AI, this means an approval in the model inventory is only meaningful if the bank can show the approval held where the model actually ran.

Three mechanisms and where each leaves a gap

Banks typically combine contractual, procedural and technical mechanisms. Each answers a different question, and none of them answers all of them. The first two are periodic or document-based by nature. The gap described here is analysis, not a supervisory statement: a report or attestation summarizes a period, while an examiner question often concerns one interaction.

• Contractual: Establishes audit and monitoring authorization, performance and risk metrics, bank ownership of records and data, and notice of model or feature changes. Gap: it states what should happen, not what did.
• Procedural: Includes diligence, performance and control reports, periodic meetings or visits, and testing of the bank's own controls over the third party. Gap: findings are point-in-time and depend on what the partner reports.
• Technical: Applies approved-model constraints and policy to partner usage as it happens, for example through an enforcement point in the execution path. Gap: it covers only interactions that actually pass through it.

Implementation sequence

Treat extension of controls as an ordered sequence. Technical enforcement is the third step, not the first, because it can only enforce what has been scoped and written down.

Start with scope. Reconcile the approved model inventory against the models and use cases each partner actually runs. OCC supervisory material points to scoping the business processes permitted to invoke an AI system or agent, which maps naturally to an approved use-case list per partner. Tier partners and use cases by risk and autonomy. Light-touch controls suit low-risk, low-autonomy use, while customer-impacting, irreversible or highly autonomous actions warrant much heavier ones. Record the rationale for each tier, since oversight is expected to be proportionate to risk.

Next, translate expectations into policy. Convert validation conditions, data handling rules and escalation requirements into statements a system can evaluate: which models are permitted, which data may leave the boundary, which tool calls need human approval. Write the matching contract terms at the same time, including monitoring authorization, bank ownership of records and data, and notice when a partner changes models or adds AI features.

Then decide where enforcement sits and what evidence is retained. Finally, define change triggers. Vendor-driven model or feature changes should prompt reassessment or retesting, and the inventory should be updated as a result.

• Scope approved models and use cases per partner
• Tier by risk and autonomy, and document the rationale
• Translate expectations into enforceable policy and contract terms
• Choose the enforcement point and the evidence owner
• Define change triggers for reassessment and inventory updates

Defining the evidence to retain

Start from the questions the bank must answer: which model ran, under which policy, what action was taken, and whether a person approved it. Then map each question to the mechanism that can answer it. Contracts show agreed obligations and attestations show partner representations. The bank's own testing of its controls is separate evidence and should be kept apart. Runtime records can show, per interaction, the model involved, the policy applied, the action taken and the escalation outcome.

Data ownership decides who holds that evidence. Bank ownership of records and data belongs in the contract, and retention periods and residency should be configured to match. Delegating storage to a partner does not transfer responsibility, so the bank should be able to retrieve records without the partner's cooperation in the moment.

Trussed addresses the runtime piece of this picture. It enforces policy in the execution path across models, agents, tools and MCP servers, with allow, redact, block, rate limit and escalate for human approval, and it generates audit-ready evidence from that enforcement. It supports self-managed deployment in the customer cloud with configurable retention and data residency. Its experience is deepest in insurance, a regulated financial sector, including 18+ months of continuous production in a regulated enterprise and 100+ models under one policy plane.