State Money Transmitter Licensing Exposure for AI Payment Agents
AI payment agents face licensing exposure unless funds never leave the bank's direct control.

AI doesn't change the rules here, and that's the first thing to get straight. FinCEN's definition of "money transmitter," under 31 CFR 1010.100(ff)(5), was written around custody, not around who or what gives the instruction. The 2019 guidance says the same thing a different way: the analysis turns on where the value sits and who controls it. Technology issuing the order doesn't factor in.
Picture two agents. One sends an authenticated instruction through the user's own bank, and the bank moves the money, holding the funds the entire time while the agent never touches them. That's a software conduit, and it sits outside the money-transmitter definition about as cleanly as anything in this space gets.
The other one accepts funds before forwarding them, holding float between authorization and settlement. Maybe it sits between a buyer and several sellers, batching and routing, or maybe it runs everything through one pooled account it controls. Either fact pushes the agent toward licensure, because FinCEN cares about where the value is stored and whether the intermediary has independent control over it, full stop.
The mistake that costs the most money is assuming a non-custodial exemption applies without running the fact pattern state by state, and payments counsel at Astraea Law flags this as a critical risk. Multi-step agentic commerce, where authorization gets pooled across several merchants before settlement, is particularly exposed. Regulators care less about the AI layer than about the plumbing underneath it, which means the people who need to be in the room early aren't just lawyers. Engineers deciding where the money sits for those few seconds between authorization and settlement need to be there too, because that's where the legal question actually gets answered.
How the state-by-state licensing map actually works, and where it is standardizing
No federal license covers money transmission for non-bank payment agents. It's state by state: fifty separate analyses, fifty applications, fifty bonds to track.
There's been real movement toward consistency, and it's worth taking seriously instead of waving off as paperwork. The Money Transmission Modernization Act, a model law from the Conference of State Bank Supervisors, sets common standards for net worth, surety bonds, and permissible investments. As of 2026, 31 states have adopted it in full or in part, and transmitters licensed in at least one MTMA state account for 99% of reported money transmission activity nationally. The wave hit the states that actually carry volume, not the small ones.
The pace has been fast. South Carolina, South Dakota, and Missouri signed on in 2024; Wisconsin, Kansas, and Massachusetts followed with effective dates in 2025 and 2026; Mississippi, Colorado, Nebraska, and Virginia sit on that same timeline. Ten states, roughly two years.
Here's what the harmonization doesn't fix: common capital and bonding standards leave plenty of room to disagree about what money transmission actually is, and that's the gap that trips people up. Several states that adopted the MTMA skipped the optional virtual currency provisions, as noted in analysis of the rollout, so definitional variation survives even inside the "harmonized" states. The 31-state number cuts both ways. It's real progress, and it also means roughly a third of the country still runs on older, divergent frameworks. Better organized than it used to be, with plenty of unification work still ahead.
State-specific requirements that materially affect AI payment agent deployment
Start with California, if only because of scale: nearly 12% of the U.S. lives there, and it holds a disproportionate share of the fintechs and neobanks actually building these agents. California adopted parts of the CSBS model law in 2023 but kept its own requirements stacked on top, no wholesale adoption. Building for California means building for California specifically, not for "the MTMA states" as a category.
Arizona requires a minimum tangible net worth of $100,000, and more importantly for AI agents, its definition of money transmission explicitly covers receiving money to pay someone else's bills. A bill-pay aggregator, or an agentic bill-payment workflow, is licensed activity in Arizona. No ambiguity to argue around.
Alabama sets a surety bond floor of $100,000, scaling up to $5,000,000 depending on transaction volume and outstanding obligations. Georgia starts its bond at $100,000 too, climbing to $2,000,000 based on volume or risk profile, and requires authorized agents to register separately, one of the more commonly missed steps after a company thinks it's already licensed.
The floor requirements are almost a decoy. They look manageable, even trivial, when a platform is small, but the volume-scaled maximums are where the real exposure lives, and they only show up once an agent platform gets traction. A company that priced its compliance cost off the entry-level bond in Alabama or Georgia is in for a rude surprise at scale. Arizona's definition changes based on use case too, so the same company could be exempt running P2P transfers and licensed running bill pay, in the same state, under the same charter. That's the exact shape of the exposure most agent platforms carry right now, and most of them don't know it yet.
Why bank and credit union partnerships don't automatically resolve licensing exposure
Banks, credit unions, and other federally chartered institutions are exempt from money transmitter licensing, answering instead to the FDIC, the NCUA, and equivalent regulators. That exemption belongs to the bank. It does not automatically extend to an AI platform sitting next to the bank, partnered with it, or built on top of its rails, no matter how tight the partnership looks on paper.
Two exemptions get invoked constantly, and both get misapplied constantly. The agent-of-a-licensed-transmitter exemption can cover an intermediary processing under a licensed transmitter's authority, but only if the agency relationship, the customer disclosures, and the liability allocation actually satisfy the specific legal requirements. Putting the word "agent" in a contract doesn't create a safe harbor by itself. The agent-of-payee exemption, leaned on heavily by bill-pay aggregators, is even more fact-specific: it turns on the precise nature of the agency relationship and which party is on the hook if something goes wrong, per Brico.ai's guidance on California's version of the rule.
So how do you actually tell which side of the line a given platform sits on? Ask whether the AI platform receives or controls funds at any point in the flow, or whether it's only instructing the bank to act on an account the customer already owns. Institutions running the agent purely on rails they already operate, sending instructions without the agent ever holding funds independently, sit in a much stronger position than platforms wedged between the bank and the customer as a separate intermediary.
Even when the exemption probably applies, that's not enough to launch on. The analysis needs to be documented, state by state, before deployment, and revisited again if a regulator ever calls asking about it.
The GENIUS Act adds a second federal layer when AI agents settle in stablecoins
If the agent settles in payment stablecoins, there's a separate federal regime layered on top. The GENIUS Act, signed July 18, 2025, governs stablecoin issuance: reserves, redemption rights, disclosure obligations for permitted issuers.
Its limits matter just as much as its scope. It doesn't license the transmission of stablecoins by a payments platform, and it doesn't preempt state money-transmitter licensing outside of the issuance function itself, per Astraea Law's analysis. An AI agent that issues or redeems stablecoins as part of settlement is facing two separate regulatory questions running side by side: the GENIUS Act governs issuance, state money-transmitter law still governs transmission. One doesn't absorb the other, and treating them as a single combined question is exactly how institutions miss a licensing requirement they assumed the federal law had already covered.
For institutions still operating on traditional banking rails, none of this triggers anything immediate. It's background, but background that's expanding, and it points in one direction: the federal government is building the perimeter around AI payment agents from the stablecoin side while the states build it from the transmission side. The design principle holds across both. An architecture that only instructs, and never holds custody, cuts exposure under both frameworks at once.
How Regulation E's authorization framework breaks down for agent-initiated payments
Regulation E defines an unauthorized transfer as one initiated by someone other than the consumer, without actual authority, where the consumer gets no benefit. Clean enough when a fraudster is behind it. Much less clean when the consumer's own AI agent, the one they told to manage their account, makes a purchase that's technically outside what they meant.
Here's the structural problem: the consumer arguably did benefit, and the consumer arguably did authorize the agent, just not that specific transaction. Neither the consumer's liability cap nor the bank's investigation duty under Reg E was written with that middle ground in mind. Take a standing instruction like "manage my account, keep payments under this threshold." Does that count as authorization for every transaction under the threshold, or does each one need its own sign-off? As of mid-2026, no regulator or court had resolved that question, according to Astraea Law's read of the landscape. It's genuinely open.
Prompt injection complicates it further. If an attacker manipulates the agent into moving money, is that closer to a fraudster tricking a consumer, or to someone stealing a credential? The credential-theft analogy probably fits better, but the legal framework hasn't caught up enough to apply it with confidence either way.
So what does defensible design look like in the meantime? Practitioners at SEI Right draw a fairly clean line, and it's the one worth building around. AI dispute-intake agents can capture the customer's claim, classify the transaction, open the case with the correct regulatory deadlines attached, draft the notices, and track every date that matters. Deciding whether an error actually occurred, denying a claim, signing off on the notice of results: that's a human's call, and it needs to be recorded under that person's name. The setup regulators distrust most is the one where the same system that investigates also adjudicates. Keeping those two functions apart is the version that survives an exam.
Deployment is already happening at scale, often faster than governance programs can keep up
None of this is theoretical or years away. By 2025, 77% of banks had launched or soft-launched generative AI applications, up from 61% in 2023, per EY-Parthenon research. Gartner's 2026 CIO survey found 17% of banking CIOs had already deployed AI agents, with another 41% planning to within twelve months, and Gartner's own forecast puts at least 30% of day-to-day banking decisions in the hands of autonomous multi-agent systems by the end of 2027.
That's the adoption side. Now look at the gap on the other side: fewer than one in eight credit unions and community banks running AI agents had a governance program built to match, according to a 2025 credit union trend report. Customer service automation is where most agentic AI activity has concentrated so far. Payment execution is next, and it's a fundamentally different risk category than answering customer questions.
Part of what's driving the rush is a staffing problem, not a technology one: a significant shortage of unfilled AML investigator positions across the U.S. as of 2025. That gap is pushing institutions toward automation in exactly the workflows, dispute handling, transaction monitoring, payment execution, where the custody and Reg E questions above matter most.
Fewer investigators, more volume, agents that can actually keep pace: the incentive behind the push is real, and it isn't going away. Where things break down is sequencing. Deployment is outrunning the structural analysis that's supposed to happen first, and that gap, not the technology itself, is where the exposure sits.
What a custody-first compliance framework looks like in practice for institutions deploying AI payment agents
This isn't a checklist to run after the fact. It's a sequence of decisions that need to happen before an agent ever touches a live transaction, and getting the order wrong matters as much as skipping a step outright.
Start with architecture, not legal review. Before anyone drafts a compliance memo, the system design itself needs to answer one question: does this agent ever hold, pool, or control funds? If yes, licensing is likely required somewhere. A "no" needs documentation too, with the specific technical reason behind it, not just an assertion.
From there, run the exemption analysis jurisdiction by jurisdiction. For every state where the agent will process transactions, identify which exemption might apply, agent-of-payee, agent-of-transmitter, bank-rail instruction-only, and confirm the underlying facts actually support it. That confirmation happens with counsel, before launch, not after a state regulator sends a letter.
Layer in use-case specificity next. A workflow that's exempt in one state, as Arizona's bill-pay definition shows, can sit squarely inside the licensing requirement in another, because the use case decides that, not the underlying technology.
Reg E needs its own design constraint: separate what the AI does (capture, classify, draft, track deadlines) from what a human does (determine, adjudicate, sign). That separation has to show up in the actual system architecture, not just in a policy document that says it should happen.
Then there's the governance infrastructure tying it together. An audit trail for every instruction the agent initiates should record what was authorized, by whom, under what standing instruction, and at what time. Configurable limits let the institution cap transaction size, require human sign-off above a set threshold, and restrict the agent to specific accounts or rails. Build the review cadence around the fact that the map keeps moving: the 31-state MTMA count will grow, state definitions will keep shifting, and a framework built for 2026 should assume it needs revisiting in 2027.
The institutions getting this right build agentic payments on rails they already control, with custody kept firmly on the bank's side of the line and every instruction fully traceable. That approach holds up in front of a regulator, an auditor, or a board asking hard questions, because it was built to answer those questions before anyone had to ask them.


