Controlling AI Costs Bundled Into Core Processor Contracts at Credit Unions

How AI enters a core processor agreement

AI features such as assistants, summarization, fraud scoring and member-service automation tend to arrive in a core agreement through a small number of pricing constructs. A tiered licence bundles AI functions into a higher service level. Usage-based metering charges against token or call allowances. Some features are enabled by default with an opt-out, and others are sold as separate add-ons. Each construct shifts risk differently. A tier can hide which functions are in scope. Metering makes spend variable and depends on how the vendor defines a unit. An opt-out means charges and data processing may begin before anyone has made a decision.

Banking-agency material gives procurement teams a useful reference point here. A September 2026 proposed guide for community banking organizations lists contractual considerations for core provider relationships: a reasonable and transparent pricing structure, variable costs tied to account count, asset size or transaction volume, billing statements that clearly explain each charged service, the length of the back-billing window for retroactive charges, and initial term length and automatic renewal conditions. As of October 2026 the guide is a proposal and sets no enforceable standards, so treat it as a checklist template rather than a requirement. It was written for banks, and the same questions transfer directly to AI line items.

An OCC request for information from November 2025 also names bundled products that raise fees, reduced community bank negotiating power, and non-disclosure terms that impede information flow about core providers' pricing, services and contract terms. Procurement teams should check whether confidentiality terms limit what they can share with peers, advisors or examiners.

Information to require from the vendor

Contract language is only useful if the information behind it is delivered. Define three categories of information and attach each to a delivery format, frequency and retention period.

Usage information covers which AI functions are active, how many billed units each consumed, and how those units reconcile to the invoice. Without it, a credit union can only accept the total. Data-handling information covers which models and subprocessors process member data, where processing occurs, what is retained and for how long, and whether data is used for anything beyond the contracted service. Policy information covers what limits apply to each interaction: which inputs are permitted, what categories of data are masked or withheld, which actions require human approval, and what the vendor does when a limit is reached.

The third category is the one most often missing. Vendors usually describe features and prices, but not the policy applied to an individual interaction. Ask for it explicitly, and record the answer even when the vendor can only say that no per-interaction limits are configurable. That answer is itself a finding for the risk assessment.

Where contract oversight needs technical enforcement

AI can reach an institution through more than one path, for example a vendor-hosted end-user interface or an API. Each entry point should be inventoried separately, because usage and evidence may differ by path. The key question for each is who controls the execution path.

Where the vendor controls the path, the credit union's levers are contractual and configurational: the clauses above, the settings the vendor exposes, and the records the vendor agrees to provide. Those records are a vendor-supplied dependency, so audit and information-provision rights matter. Invoices and vendor usage reports describe what the vendor says happened. They do not independently show what the AI was permitted to do.

Where the credit union controls part of the path, such as its own applications, agents or tool calls that reach AI services, policy can be enforced at runtime on each interaction. Trussed enforces policy in the execution path on individual interactions and tool calls: allow, redact, block, rate limit, or escalate for human approval. That enforcement generates audit-ready evidence documenting what AI was allowed to do and what it did, which supports contract oversight by giving the credit union its own record to compare against vendor reports. It does not reach into AI functions that run entirely inside a vendor platform the credit union does not route through, which is why the contract terms remain necessary.

The tradeoff is operational. Enforcement in the path requires the credit union to define policy, assign owners for exceptions and approvals, and decide retention for the evidence it produces.

Governance and ownership

Assign clear ownership. Procurement, vendor management, risk and IT each hold part of the picture, and AI functions in a core contract fall between them when no one is responsible for reconciling terms with actual operation. Existing third-party risk principles on due diligence, contract management and ongoing monitoring may apply to AI developed by third-party vendors, and the NIST AI Risk Management Framework describes procurement as work done by people with financial, legal or policy authority, with costs and impacts of AI functionality examined and documented.

Keep the status of external guidance in view. The 2023 interagency guidance was written for banking organizations, and the September 2026 proposals were not final as of October 2026. Confirm what your own regulator expects, and use the banking material as reference practice.

Finally, keep the objective straight. The aim of this review is to bound AI usage, understand what is running and be able to show it, not to reduce spend for its own sake. Spend becomes forecastable and challengeable as a consequence of clear definitions and evidence.