The short answer
An AI agent with a bank account is an assistant that can actually pay for things — because it has something to pay with. It holds an account in its own right: a balance, an IBAN to receive and send on, and a card to spend with. You tell it what to do in plain language — "pay this invoice", "book two nights near Plaza Mayor under €300", "send £450 to my sister" — and it does it from that account, inside a set of rules you wrote once.
The two words that matter are its own. The agent isn't borrowing your card or asking your bank to move money. It pays from an account that exists for it, with a card that was issued to it — and money moves between that account and your other accounts instantly, whenever you want.
What it is not
Three things get called "AI payments" and only one of them is this.
It is not a wallet. A non-custodial agent wallet gives an agent scoped access to assets you already hold — an Ethereum address, a Coinbase account, a card on file — with keys you keep. Useful if your money lives on-chain. But the agent has no account of its own, no IBAN, and can't receive a salary or pay a supplier by bank transfer.
It is not a money-manager bot. Chat-based money managers connect to your existing bank through an aggregator, read your transactions, and coach you: budgets, nudges, "you've paid for three streaming services you don't use". Some can ask your bank to move money. None hold it. They can find an unused subscription; they can't decline its next charge, because they didn't issue the card that pays it.
It is not a payments API. Developer platforms sell accounts, cards and payouts as building blocks to companies making agents. Same primitives, different customer — you'd need to build the product yourself.
An AI agent with a bank account is the consumer version of the last one, with the controls of a good bank built in.
The four kinds of AI money tool
| Capability | Holds money? | Issues the card? | Who it's for |
|---|---|---|---|
| Non-custodial agent wallet | No — your keys | Proxies yours | People with on-chain assets |
| Chat money manager | No — aggregator over your bank | Sometimes, for you | People who want budgeting and nudges |
| Agent-banking API | Via a partner bank | To developers | Companies building agents |
| Agent with its own account | Yes | Yes, to the agent | People who want the assistant to pay |
Two questions split the table: who holds the money, and who issues the card. If the answer to both is "the platform, for the agent", the agent can execute and can be given real limits. Otherwise it can only ask.
What "its own account" actually means
Four concrete things.
- An IBAN. The agent can receive money — a salary, a client's transfer, a refund — and send it by bank transfer. Not just spend a card.
- A card, as a token. A normal debit card issued to the agent, provisioned as a network token, never a card number. Because the issuer is the one enforcing your rules, every authorization on it — a purchase, a subscription renewal — is checked against the mandate before it's approved.
- A specialist. The agent that holds the account does payments and finance, and only that. Its tool set is small — pay, send, pay out, record — and every tool writes a ledger row. There's no path from "summarize this" to "send money", because it doesn't do the first.
- Separation. The account is the agent's; the rules are yours. That separation is what makes the next section possible.
The mandate: how a human stays in charge
The mandate is the set of rules you write once. A typical one:
- a monthly budget (€500)
- an approve-above threshold (€250) — anything larger waits for you
- an allowlist of merchants and payees — anyone else waits for you
- per-transaction and velocity ceilings, a country list, blocked categories
- a mode per rule: approve each, or run inside the limit
- a kill switch
Inside the rules, the agent pays without asking. Outside them, it prepares the payment, holds it, and tells you exactly why — "new payee, above €250". You approve or decline. A decline costs nothing; no authorization is made.
The rule that makes the rest trustworthy: the agent can read the mandate and cannot change it. There is no tool it can call to raise its own budget, no message it can send itself to loosen a threshold. Only you can, and only with a confirmation bound to your identity, not the agent's.
Rails: how the money moves
An agent with a real account uses real rails. In Navoka's case: ACH for dollars, SEPA instant and standard for euro, Faster Payments for pounds, SWIFT for the rest of the world, USDC and EURC for stablecoin transfers, and push-to-card for sending straight to someone's Visa or Mastercard. The agent picks the rail or you do, and it shows fee and arrival time before anything is approved. Stablecoins are one rail among several, not the product.
What it looks like in practice
Every payment lands in a ledger with four things captured at the moment it was made: what, the rule it ran under, who approved it, and the reason you gave. That record is what you'd hand to a merchant, a card scheme or your accountant if something needs disputing — and it's what makes the agent's books reconcile without guesswork.
Where this is going
Consumers are already shopping with AI in the loop: 45% of US consumers used AI in some part of the buying journey (IBM IBV, Jan 2026), and AI-referred traffic to US retailers rose 393% year on year in Q1 2026, converting 42% better than search (Adobe, Apr 2026). The card networks have published protocols for recognizing agents at checkout. What no network had published, as of August 2026, is a binding rule for what happens when an agent buys the wrong thing — which is why an agent with its own account, its own card and a ledger that records the reason at the moment of spend is the version of this that can be trusted with real money.