How Banks Oversee AI Vendor Costs Under Third-Party Risk Management

Why AI pricing strains third-party risk programs

The 2023 Interagency Guidance on Third-Party Relationships: Risk Management (OCC Bulletin 2023-17 and Federal Reserve SR 23-4) describes the third-party risk management lifecycle and the principles for each stage. It makes clear that not all relationships carry the same risk or criticality, and it asks banks to tailor their practices to size, complexity, risk profile and the nature of the relationship. A complete inventory and periodic risk assessment of each relationship help a bank decide whether risk has changed over time.

Many programs were built around fixed-scope services. AI vendors often price by token, call or seat, and the volume a business unit consumes can move well beyond what was approved. The guidance does not use AI-specific terms, so the mapping here is interpretation. Per-token and per-call pricing corresponds to the guidance's reference to fees based on volume of activity. Vendor rights to change rates correspond to its reference to the conditions under which a cost structure may change.

Two proposed third-party risk management documents were published in the Federal Register on September 15, 2026. As of October 2026 they are proposals, and the 2023 guidance remains the operative reference for this guide.

Contract terms, thresholds and escalation triggers that make oversight examinable

Clear cost descriptions reduce billing misunderstandings and disputes, and the guidance notes that contracts commonly cover cost schedules, calculations for base services, fees based on volume and fees for special requests. For AI arrangements, the fee schedule should name the billing unit (token, call or seat), state how that unit is measured, and identify who holds the authoritative usage record. The contract should also state the conditions for pricing changes, any cap on increases, and the notice the vendor must give. The FDIC examination manual lists fixed compensation, variable charges and fees for nonrecurring items as contract fee components, which gives a useful checklist for the schedule.

Contract terms only become examinable when they connect to thresholds the bank actually monitors. Set an approved usage level for each arrangement, tied to the business case and the planning-stage cost estimate. Define an early-warning level below the contracted ceiling and a hard level at the ceiling. Name the monitoring inputs: vendor invoices, vendor usage reports and the bank's own measurements of consumption. Assign an owner to each input.

Escalation triggers should be written down before they are needed. Reasonable triggers include consumption that reaches the early-warning level, a vendor notice of pricing change, a change in underlying model provider, and invoice variances against the contract schedule. Each trigger should name who is notified, what decision is required and how the outcome is recorded.

The 2023 guidance tiers relationships by criticality and risk profile, not by spend. Linking cost exposure to tiering is therefore an application, not a stated requirement. A practical approach is to treat rising volume, growing dependency on a single vendor or a single underlying model provider, and exposure above approved levels as inputs to periodic risk reassessment and possible re-tiering.

Model risk management and subcontracted providers

Vendor-supplied AI models also fall under model risk management expectations. The supervisory guidance on model risk management recognizes that customized vendor products, including data, parameters or complete models, can present unique validation challenges. A bank may not receive underlying code, data or methodology, yet the principles still apply, and validation of vendor products by internal or outside parties is an important element.

The same guidance links adequate documentation to continuity of operations and to tracking recommendations, responses and exceptions. It also says external resources used for model risk work should be overseen and folded into broader model risk activities. In practice this argues for one record that both the third-party risk team and the model risk team can use.

Subcontracting is where the two disciplines meet cost. If an AI vendor changes the underlying model provider, the bank's validation assumptions and the vendor's cost basis may both change. Contracts should therefore require disclosure of underlying model providers and notice of changes, and the bank should route such notices to both functions. Audit rights should extend, consistent with the risk and complexity of the relationship, to periodic independent audits of the vendor and its relevant subcontractors.

Where runtime policy enforcement fits

Vendor invoices and usage reports remain the record of what the vendor charged. They do not show what the bank's own AI usage was permitted to do. That gap matters when an examiner asks whether approved levels were actually bounded and whether people were involved in exceptions.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers and coding assistants. Policy is enforced at runtime, not reviewed after the fact: individual interactions and tool calls are allowed, redacted, blocked, rate limited or escalated for human approval. A rate limit or approval step can bound usage that passes through the path, and the enforcement itself produces audit-ready evidence of what AI was allowed to do and what it did. That evidence supports the documentation expectations of model risk management and the ongoing monitoring file. It does not replace vendor billing data, contract review or vendor audit rights.

Trussed's production experience is in regulated enterprises in insurance, pharma, healthcare and education. Banks should assess any control against their own supervisory expectations.