AI Agent Controls in Payment Operations When SR 26-2 Excludes Agentic AI

What the SR 26-2 exclusion does and does not change

SR 26-2 updates the Federal Reserve's model risk management guidance based on supervisory experience and industry feedback since SR 11-7. It emphasizes a risk-based approach tailored to a bank's model risk profile, size and complexity. Footnote 3 states that generative AI and agentic AI models are novel and rapidly evolving and are not within the scope of the guidance. The principles apply to traditional statistical and quantitative models and to non-generative, non-agentic AI models.

The same footnote says a banking organization's own risk management and governance practices should guide the controls for tools, processes or systems the guidance does not cover. In practice, the exclusion hands governance back to the bank. It does not remove the expectation that the bank can explain how its agents are constrained. As of November 2026, the material reviewed shows no change to the exclusion.

There is a second gap. Commenters on the proposed interagency third-party risk guidance say it does not mention AI, machine learning, automated decisioning or agents, and that no federal guidance squarely addresses a vendor-supplied agentic system. That is the commenters' characterization, not an agency statement. The practical consequence is that a vendor-supplied payment agent may fall between model risk guidance and third-party guidance, so bank policy should cover it explicitly.

Existing expectations still apply. A commenter points to the Information Security Standards, which already list access controls that permit access only to authorized individuals and require programs to adjust for outsourcing arrangements. Access control, outsourcing oversight and operational risk practices are the natural anchors for an agent control set.

Rank agent actions by risk before choosing controls

Model-centric review asks whether a model's output is sound. Agents change the question. A commenter describes them as systems that can send a payment instruction, change a customer record or open a case, rather than only produce a score for a person to act on. Controls therefore have to address actions and tool use, not only output quality.

Start with an inventory of agent actions in payment operations: payment repair, exception handling, reconciliation, dispute triage, sanctions or fraud alert triage and customer data retrieval. Rank them using the high-risk category that commenters describe for AI acting with limited human review: initiating or releasing payments, changing account status or limits, and resolving disputes. Reading customer data and drafting a case note carry different exposure than releasing a repaired payment, and the controls should differ accordingly.

Two points sharpen the ranking. Governor Waller said on September 29, 2026 that higher B2B transaction values amplify exposure from agent errors or unauthorized actions, and that the question shifts to proving an agent has authority to pay on the buyer's behalf. Agent authority is distinct from payer authorization, so both need to be demonstrable. Separately, OWASP guidance on agent-initiated payments says using an agent does not remove AML or sanctions obligations, and that a valid agent credential or a successful list match is not proof that every legal obligation is met.

Map agent actions to a control set

The control set below draws on model risk management principles, access-control and outsourcing expectations, and OWASP practices for agent payments. Apply each control per action, not per agent, so a single agent can hold different rights for reading, drafting and releasing.

• Identity and permissions: Give each agent an identity, a named responsible owner and a record of which customer or business unit it acts for and what it may do.
• Tool access: List the tools and data sources each agent may call, and deny everything else by default.
• Data handling: Define which customer fields an agent may retrieve, and redact or block fields the task does not need.
• Human approval thresholds: Route high-impact actions, such as releasing a payment or changing an account limit, to a person. Set thresholds by action type and value.
• Screening and fail-closed behavior: Keep sanctions and AML screening before payment processing, with compliance-defined rules, and stop the action when a check cannot complete.
• Evidence retention: Capture the instruction given, the information acted on and the action executed, with retention set by compliance owners.

Evidence examiners and internal audit can review

Periodic model review produces documents about the model. It does not by itself show what an agent did on a given day. A commenter on the third-party proposal says that for a transfer prepared or made by a third-party agent, the institution will need to know what the agent was instructed, what information it acted on and what it executed. Per-interaction and per-tool-call records are a reasonable way to meet that need, and an evidence record should also show the permission that was applied.

NIST AI RMF is intended for voluntary use and is a useful adjacent reference for trustworthiness considerations in design, development, use and evaluation. It does not prescribe agent controls, so each bank should decide how its own control set maps to the framework and document that mapping.

The evidence question for risk leaders is concrete: if an examiner asks what a repair agent was allowed to do and what it did on a specific exception, can the bank answer from retained records rather than reconstruction? Records of intended policy are not enough. The bank needs records of policy that was applied.