Drafted with AI help, human-reviewed by The Agent Loop.
Short answer: no. Not as the legal account holder. In the US, a bank still needs a human or a legal entity on the account. Agents have no legal personhood. What they can have in 2026 is a funded wallet, a virtual card, a crypto address, or a sub-account that sits under your KYC or your LLC.
I spent a day reading OCC docs, FinCEN rules, and vendor FAQs because the headlines say “AI agents now have bank accounts.” The products moved. The signature card did not.
For skimmers
- Legal owner: human or company, always (FinCEN CIP)
- Agent balance: yes: prepaid, spend-limited, revocable (gift-card model)
- Agent receive: yes: wallet / deposit address / platform payout under you
- FDIC: your bank account maybe; USDC never; Catena charter still preliminary
- Vendor line to distrust: “your agent opened a bank account” → ask who signs
What actually changed (2025–2026)
| When | Event | What it really means |
|---|---|---|
| 2025-07-18 | GENIUS Act (stablecoins) | Regulates issuers. Coins are not FDIC deposits. |
| 2025-09-16 | AP2 (Google → later FIDO) | Signed mandates so agent spend traces to a human principal |
| 2026-05-01 | ClawBank / Manfred | An agent formed a US LLC, then the LLC got a bank account. The entity is the customer. |
| 2026-05-07 | AWS AgentCore Payments | Wallets to pay APIs, funded by you |
| 2026-06 | Stripe machine payments (MPP / x402) | Your business accepts payment from agents into your Stripe balance |
| 2026-09-18 | Catena Trust Bank gets OCC preliminary conditional approval (CD #1392) | Path toward an agent-shaped trust bank. Not a live FDIC consumer charter. |
So yes: money moves for agents now. Wallets, cards, machine-pay protocols, even an LLC loop. None of that is “Claude is the accountholder.”
The legal floor (boring, but it decides everything)
US customer identification (FinCEN, 31 CFR §1020.220) requires a person or entity the bank can identify. Models are not persons. The IMF’s 2026 note on agentic payments says the same thing from the payments side: a payment order has to trace to an account holder or a legally recognized agent; liability still unclear.
Airwallex’s public explainer puts it bluntly: agents cannot legally own bank accounts. Coinbase’s framing is the one I’d steal for a tweet: AI agents cannot get bank accounts; they can get crypto wallets..
Four patterns that do work today
YOUR ID / LLC ── KYC ──► bank account ──payout──► you
│
└── caps ──► agent wallet / virtual card / deposit address
(spend + receive under your name)
Prepaid / virtual card (spend ceiling)
Gift-card logic: load, limit, freeze. Stripe even ships Issuing for agents. Robinhood-style agentic trading still hangs off your account.Sub-ledger that can receive
AgentsPay’s own FAQ is worth quoting because it kills the hype: “Agents do not open bank accounts. Earnings sit in a wallet inside your existing business account structure.” Crossmint documents agents accepting payments to wallet addresses. Privy markets “hold funds, receive payments.” Same pattern: your controls, your keys/KYC.Entity wrapper
Meow lets an agent open/manage a business account for you. ClawBank’s Manfred story is the pure version: form LLC → EIN → FDIC-insured account. Agent = operator. LLC = customer.Machine payments inbound to you
Stripe MPP / x402 / PayPal Agent Ready: an agent buyer pays; your merchant account receives. That’s “agents accept payments” in most marketing posts. Actually you accept payments from agents.
Where marketers get it wrong
- “FDIC-insured agent wallet” → pass-through may exist for your titled funds. USDC is not FDIC.
- “Catena is approved” → preliminary conditional; no charter insurance story yet.
- “Agent got a bank account” → check the signature card. It’s an LLC or a human.
- “No KYC needed” → you’ve left the regulated rails; fine for toys, bad for payroll.
Bottom line: Agents get wallets and LLCs, not deposit accounts in their own name. The gift-card analogy is still the right mental model for spend; for receive, it’s a sub-ledger under you. If a vendor says your agent “has a bank account,” ask one question: who signs?
FAQ
Can ChatGPT or Claude own a bank account?
No. No legal personhood; banks open accounts for humans and entities.
Can an AI agent receive payments in 2026?
Yes, into a wallet, deposit address, or platform sub-account you control. Not as payee of record at a US bank in the model’s name.
Did Catena Trust Bank get approved for agents?
OCC issued a preliminary conditional approval (Sep 18, 2026). That’s a process milestone, not “agents are bank customers” and not FDIC insurance on a new consumer product.
Are agent wallets safe to use for real money?
They’re designed for caps and revocation. Treat them like prepaid cards: fund what you can lose, keep the human account as the source of truth.
Sources
- FinCEN CIP rule (31 CFR §1020.220)
- OCC: Catena Trust Bank CD #1392 (2026-09-18)
- CoinDesk: AI agent forms LLC / bank account (Manfred)
- Stripe: Issuing for agents
- Stripe: machine payments / accept from agents
- AgentsPay: get paid FAQ (wallet under business account)
- Crossmint: agentic finance (agents accept payments)
- Airwallex: can AI agents own bank accounts
- Treasury: GENIUS Act stablecoin NPRM
- IMF: agentic payments note (2026)
- Prompt injection in 60 seconds (our post)
Related on The Agent Loop
Over to you: Who actually signs on the account your agent moves money through? Reply below — I read every comment.
If you want the rest of this series when it drops: subscribe via Buttondown. If you've wired money to something an agent touched, I'd genuinely like to read how that worked. It has not gone well for anyone I've heard of.
Top comments (4)
The US answer is right and the UK one arrives at the same place by a different road, which I think sharpens your framing.
Over here the binding constraint is not KYC on the account. It is authentication on the payment. Strong customer authentication wants two independent factors tied to the payer, and the bank is the party that applies them, so even where an agent holds a funded wallet under your name it cannot authorise an initiation on its own. Ownership is one ceiling. Authentication is a lower one, and it bites per transaction rather than once at onboarding.
Which is why "ask who signs" is the right test, and I would add a second: ask who the money comes back from when it goes wrong. Ownership can be a formality on a signature card. Liability is where the fiction stops being free. Of your four patterns, the prepaid card and the entity wrapper differ mostly in who eats a disputed transaction, and that is the line a vendor page never puts in the comparison table.
One flag on the LLC loop, since it is the pattern people will copy. An agent forming an entity does not move liability to the entity in any way a bank has to respect. A single-member LLC with one human behind the EIN is a customer the bank can identify because of that human. So the loop closes on the same person it was supposed to remove, and what changed is the number of places their name appears.
Is AP2 going anywhere on the liability question, or is it still only about tracing the mandate back to a principal?
The SCA point sharpens it more than the post did. I had ownership as the only ceiling; you're right that authentication is a separate, per-transaction one an agent can't satisfy on its own even with a funded wallet under your name. I'm stealing the two-ceiling framing.
Your second test — who does the money come back from — is the better one, and it's missing from the post. Liability is where the vendor table stops being honest: prepaid card and entity wrapper look identical on a diagram and differ completely on who eats a disputed transaction.
On AP2: as far as I can tell it still only answers the tracing question (a signed mandate tying payment back to a human intent — cart mandate, intent mandate), not the allocation question. It tells you who authorised, not who is liable when the authorised thing was wrong. Under PSD2 that allocation still lands on the bank or the PSP depending on which side the fraud was on, which is why SCA keeps surfacing. So AP2 closes the "was this the human's intent" gap, and the "who eats the loss" gap stays where the rails already put it.
That's my read rather than a citation. If you've seen AP2 language that actually allocates liability, send it — it would change the conclusion of the post.
The LLC route gets messier than it looks once accounting's involved. You'd need to trace every agent decision back to the transaction, which in practice means storing the tool call log before the spend happens. We tried this on a fintech project last year and the bookkeeping overhead was what killed it. Ended up putting the agent on a pre-funded debit card with a daily hard limit instead.
This is the point I under-weighted. The entity wrapper solves who signs the paperwork. It does not solve how does anyone reconcile a spend that came out of a probabilistic process.
If you can't trace the transaction back to the decision, you can't dispute it, categorise it, or explain it to an auditor — and the pre-funded card with a hard daily limit sidesteps that by making the card the unit of audit instead of the agent. The bookkeeping overhead you hit is exactly the cost the LLC diagram never shows.
Question back at you: once you were on the card, did the daily limit plus the card's own transaction log cover you for reconciliation, or did you still keep a tool-call log somewhere so you could explain a specific charge?