Rail Governance

Regulation W Affiliate Transaction Limits for AI-Executed Banking Operations

Banks deploying AI agents in affiliate transactions face unclear Regulation W compliance rules.

· 10 min read
Cover illustration for “Regulation W Affiliate Transaction Limits for AI-Executed Banking Operations”
OCC and Fed Rulemaking · October 14, 2026 · 10 min read · 2,258 words

Regulation W governs the terms banks can offer their own affiliates, and it was never written with AI in mind. That's the problem now facing any institution letting an agent touch a payment, a transfer, or a pricing decision between related entities: the law hasn't changed, but who's executing it has.

Regulation W and AI Execution

Regulation W codifies Sections 23A and 23B of the Federal Reserve Act. The categories it covers are specific: extensions of credit to an affiliate, purchases of assets from an affiliate, and guarantees issued on an affiliate's behalf. Dodd-Frank widened that net to include derivative transactions that create a bank's credit exposure to an affiliate, closing a gap that existed before the law was enacted.

The statute then layers on two caps. Beyond the caps, there's a qualitative floor: covered transactions have to be consistent with safe and sound banking practices, and a bank can't use them to offload low-quality assets onto itself from an affiliate.

This entire structure assumes a human is making the decision, reviewing the terms, and checking the math before money moves. Regulators built it around transactions that get deliberated, documented, and approved by people who can be asked, after the fact, why they did what they did. That assumption is where the trouble starts. Compliance teams now have to determine when an AI agent's action becomes a covered transaction, rather than just an internal workflow step that happens to touch a ledger. Until that question has a clear answer inside a given institution, no control architecture built on top of it will hold.

How agentic execution changes affiliate transaction risk

For years, AI's role in banking was advisory. A human still pulled the trigger. That's changed with agentic systems, and the change isn't cosmetic: an agent that autonomously initiates an intra-holding-company funds transfer, or prices an intercompany transaction on its own, can trigger a covered transaction without anyone checking whether the 10%/20% thresholds have even been approached.

Speed is the mechanism driving this risk. An agent can execute the equivalent decision in milliseconds, across multiple systems, without pausing for the kind of deliberation the statute was designed around. Threshold accumulation can happen faster than any manual monitoring cadence is built to catch.

Privilege scope makes this worse. The hardest supervisory problem this creates is reconstructing the relationship between the original instruction and the chain of actions that followed it, since existing core-banking audit trails weren't built to capture multi-hop AI reasoning chains.

The sharpest version of this risk looks almost like structuring. Taken together, the pattern violates its purpose. Human review cadences were never built to catch this kind of fragmentation at the speed an agent operates. This risk sits at the center of the governance gap the next section lays out.

The regulatory guidance gap for agentic systems

Regulators have started to respond to AI in banking generally, but not to this specific problem yet. SR 26-2, issued jointly by the Federal Reserve, the OCC, and the FDIC in April 2026, supersedes the long-standing SR 11-7 framework and reaffirms the core discipline of model risk management: model inventories, independent validation, ongoing monitoring, and governance over third-party models.

SR 26-2 states that generative AI and agentic AI are novel and rapidly evolving, and it places them outside its own scope. That's a notable gap, because the governance framework built to catch AI tools that trip the 10%/20% thresholds formally excludes the systems most likely to do exactly that. The agencies have acknowledged that existing risk management principles, materiality, ongoing monitoring, effective challenge, still apply to tools outside the guidance's formal reach. But they haven't said how those principles should map onto agentic execution contexts specifically.

There's a signal that more is coming: the agencies have indicated plans to issue a request for information on banks' use of AI, which suggests formal guidance for agentic systems is in development but not yet available. That leaves banks deploying AI agents in affiliate-touching workflows in a position where they have to build their own Regulation W compliance architecture, without a model-risk framework that formally covers the agents doing the executing. This is a gap compliance teams are already operating inside, whether or not they've named it yet. Waiting for a rule to arrive isn't a strategy here, because the agent is already running.

Mapping the covered-transaction definitions onto agentic payment and transfer workflows

Not every action an AI agent takes inside a bank qualifies as a covered transaction, but several common agentic workflows land squarely inside the definition. An agent that routes a funds transfer to an affiliated entity is initiating what the statute treats as a covered extension of credit or asset purchase. An agent that executes an intercompany pricing decision is generating a transaction that has to satisfy arm's-length terms, regardless of how that decision got made.

A few patterns recur in agent-executed affiliate transactions. Agent-executed guarantees or collateral arrangements, where the counterparty is an affiliate, count as covered transactions subject to the 10% per-affiliate cap just as they would if a person had arranged them.

Derivative transactions deserve particular attention, because Dodd-Frank extended covered-transaction status to any derivative that creates credit exposure to an affiliate. The qualitative floor applies on top of all of this, regardless of dollar amount: an agent can't purchase low-quality assets from an affiliate, and every transaction it touches has to be consistent with safe and sound banking practices. That standard calls for validation before execution, not a review afterward.

Workflows that stay inside a single legal entity, with no affiliate counterparty involved, don't invoke Regulation W. The complication is that agents operating across a holding company structure can cross entity lines mid-workflow without any explicit routing logic flagging that the crossing happened. Once you identify these workflow types, the real governance challenge shifts from classification to monitoring, catching threshold exposure as it accumulates.

Why the 10%/20% caps require real-time aggregate tracking

The 10% per-affiliate cap and the 20% aggregate cap are measured against capital and surplus as of the bank's most recent Call Report, and the aggregate covered-transaction tally gets checked at the time of each transaction. Every agent-executed covered transaction has to be checked against a running aggregate, not a snapshot taken at the end of the day or the end of the quarter.

In a manual workflow, a compliance officer reviewing a proposed affiliate transaction can query the current aggregate before they sign off. In an agentic workflow, the transaction may already have settled before anyone reviews it at all, unless you build threshold checks directly into the execution path. The structuring risk raised earlier compounds this problem directly: an agent operating across several affiliate relationships at once can aggregate exposure across those relationships faster than any monitoring system running on a batch or end-of-day cadence is able to detect.

So the agent's execution environment needs a live view of capital and surplus, plus a running tally of covered-transaction exposure by affiliate, available at the exact moment of execution. Clearing the threshold bar is necessary, but it isn't the whole job. A transaction can sit comfortably under both caps and still fail the second major obligation the statute imposes: pricing it at arm's length.

Satisfying the arm's-length requirement when pricing is agent-generated

Threshold compliance and arm's-length compliance are two different obligations, and they call for two different kinds of evidence. Section 23B requires that covered transactions with affiliates sit on terms at least as favorable to the bank as what it could get from a non-affiliated party in a comparable transaction. That's a market-comparability standard, and it has to be demonstrable at the moment of execution, not reconstructed later from memory or inference.

When an AI agent generates the pricing for an intercompany transaction, that standard still applies in full, regardless of how the number got produced. It has to show that the specific output was market-comparable for that specific transaction at that specific moment. That's a documentation obligation unlike threshold tracking: the bank has to be able to produce the comparable market terms the agent referenced, not just evidence that the transaction cleared under the cap.

Multi-agent workflows make this harder. None of this is demonstrable after the fact unless the comparability analysis gets captured at the moment it happens, which is precisely what the audit trail has to be built to do.

The audit trail Regulation W requires

Diagram: Four Layers Every Agent-Executed Transaction Must Log. Visualizes: Visualize the four-layer audit logging requirement for AI-executed affiliate transactions under Regulation W.

Regulation W compliance ultimately comes down to documentation. Examiners reviewing an affiliate transaction program expect records establishing the transaction type, the affiliate counterparty, the amount, the terms, the comparability basis, and the approval authority, for every covered transaction, without exception.

Agentic systems have to produce that same evidentiary record, but they also need to capture something a human-led review never had to document explicitly: the instruction that triggered the action, the data the agent read before acting, the rule or threshold it evaluated, and who held the authority to delegate execution to that agent. A transaction log showing only the outcome doesn't meet that bar.

An IMF Staff Note on agentic AI in payments, drawing on agent governance research, suggests supervisory dashboards for agent decisions, transaction thresholds requiring human approval, and manual override mechanisms. Each of those generates its own record, and each record becomes part of the documentation the institution has to maintain. Existing core-banking audit trails weren't built to reconstruct multi-hop AI reasoning chains, so institutions need agent-specific logging that writes a structured record at every decision point in the execution chain, not only at the moment of settlement.

Human approval gates and override mechanisms for high-value or structurally novel affiliate transactions

Full autonomy on every covered transaction isn't required, and it isn't advisable either. A sound compliance framework defines specific transaction categories where human approval is a precondition, with the agent's role limited to preparing the submission for execution by a person.

Several triggers belong on that list. And any transaction where the agent's comparability record can't establish a clear market reference should stop for review.

A staged autonomy model handles this well: agents manage routine, well-documented covered transactions within established parameters, and escalate anything novel or high-value for human review. Knowing when to escalate is a design strength, not an admission that the system can't be trusted. The override mechanism behind it has to be genuine as well. None of this works if it's improvised in the moment. The authorization chain for each transaction category, which agent roles can execute which transaction types autonomously, which require compliance officer approval, and which require board-level sign-off, needs to be documented and tested before the agent ever goes live, not discovered for the first time during an examination.

Building the pre-deployment control checklist for agents touching affiliate transactions

Before any AI agent gets authorized to execute transactions that might touch an affiliate counterparty, the institution should be able to demonstrate that a specific set of capabilities is already in place, not planned, not partially built, but operating. The execution environment needs real-time aggregate tracking: a live view of capital and surplus alongside a running tally of covered-transaction exposure by affiliate, updated at settlement cadence, with the agent structurally unable to execute a transaction that would breach the applicable cap.

Arm's-length pricing validation needs to be built in as well: for any transaction the agent prices, the system has to log the market reference data it used and the comparability determination it reached, not just the final price it output. The four-layer audit logging described earlier, transaction record, threshold evaluation, comparability record, and authorization chain, needs to exist as structured, human-readable records written at each step of the execution chain. And even where SR 26-2 doesn't formally apply to agentic systems, the agent itself should get an entry in the institution's model risk inventory, with an assigned owner, a documented scope, and a scheduled review, both as sound governance practice and as preparation for the regulatory guidance that's expected to follow.

What a Regulation W-ready agentic deployment looks like

A Regulation W-compliant agentic deployment is one where every covered transaction the agent executes is pre-classified, threshold-checked in real time, arm's-length validated, fully logged, and routed through a documented, enforceable escalation path whenever one of those conditions calls for it.

You can reach this through existing banking rails, not around them. The controls this article has laid out, threshold checks, audit loggers, escalation gates, function as overlays that sit between the agent's instruction layer and its execution layer. None of them need you to rearchitect the ledger systems where affiliate transaction data already lives. The live demonstration of an AI-executed payment that Santander and Mastercard ran inside a regulated banking environment, using pre-authorized permissions, tokenized credentials, and existing banking controls, shows that autonomous agents can operate inside established regulatory and security frameworks.

Institutions that build this architecture before deployment, rather than retrofitting it after an examiner finds the gap, will be in a stronger position once the Federal Reserve, the OCC, and the FDIC issue the fuller guidance on agentic AI that SR 26-2 already signaled is coming. There's a secondary payoff here too: a well-governed agentic deployment produces an audit trail and a supervisory dashboard that give compliance teams visibility into affiliate transaction exposure at a level of detail manual programs rarely reach. Agentic platforms purpose-built for regulated banking environments, ones that operate on existing rails, maintain complete audit trails, and give institutional stakeholders full visibility into configurable controls, provide the technical foundation that makes everything described in this framework implementable without tearing down and rebuilding the infrastructure already in place.

More in OCC and Fed Rulemaking