Agent-native banking is still a lie
We benchmarked 6 banks on whether an AI agent can actually run them. None of them are agent-native yet.
Six business banks say they're ready for AI agents. We've been letting one run our company's money since July. Then we checked all six against what we actually needed.
None of them are agent-native yet.
Fig. 1. Agent-Native Banking Scorecard v0.1. Each dimension is scored 0–10 from the bank's own docs; overall is the average. What each dimension means is in the appendix.
Here's what they promised
Every bank has an "agent" launch, and we wanted them to be true. When Rho's CEO posted that it was "going headless", I got so excited that I DMed him right away and pinged Nan, because we'd been looking for exactly this for months. Nan had already applied for an account.
On July 30 Rho launched it: "Your live financial data, anywhere MCP works." The same day, its API product manager emailed Nan to say, very politely, that transfers weren't available through the API yet.
Rho's API launch post, and the email their API PM sent us the same day, Jul 30. (Sender redacted.)
To be fair to Rho, their CEO said "read-only for now" at launch. But a headless bank that can read your balance and can't pay a vendor is a dashboard with extra steps. Reading is the easy part. We already know what we spent.
The other banks' launches read the same way next to their own docs.
Ramp for Agents, and one line from Ramp's own developer docs.
Airwallex's agent toolkit page, and a sentence further down the same page.
Agent-native means three things
The agent finishes the job. Anything you can do in the bank's UI, the agent can do through the API, including the boring last step: attach the invoice, set up the webhook, freeze the card.
The bank holds it to your rules. The approval limits you set apply to the agent exactly as they apply to you. The agent can't approve itself, raise its own limit or change the rules.
Think of the valet key that comes with most cars: it drives, but it won't open the trunk or the glovebox. Most banks hand an agent the master key or no key at all. Mercury is the only one of the six that fully offers the valet version, a key that can ask for a payment but can't send it.
You can recover when it's wrong. And it can be wrong: it reads the docs fresh every time, retries blindly, and can be talked into paying a stranger by one line in an email. So a retry must never pay twice, and every action must leave a trail a person can pick up from.
We turned that into 75 checks
Every check is a yes/no question, and every answer comes from the bank's own docs, with the exact sentence and link kept. Five of them are hard gates: fail one and a high average can't buy it back.
Fig. 2. All 75 checks for all six banks, grouped under the three questions. Orange tags mark the checks behind the five hard gates.
Then we tried it on our own accounts
- Airwallex: live since July across two entities. The agent pays vendors through the API, about $380,000 through our ledger by Oct 29. But it can't read the approval rules it's held to, and changing a webhook takes a human in the dashboard.
- Mercury: account open, API key issued. Our own agent got Mercury's API wrong, confidently (below), and a duplicate-payment check failed with a 401.
- Rho: opened in July for the headless API. Read-only.
- Ramp: our company cards. The agent reads Ramp transactions through the API to catch duplicate payments, but we've never routed a vendor payment through Ramp Bill Pay; our payments already ran on Airwallex. Creator invoices that only take a card still go to a person at the checkout page.
- Brex: we had Brex connected to one of our agents early on, then moved all company cards onto Ramp, because at the time its API looked more complete and it paid more interest. The Brex account is still open, but no payment ever went through its API.
- Aspire: account open, but the API only answers requests from IP addresses we register with Aspire in advance, and the key we got could only read.
Our use kept growing anyway. The agent moved about $2,600 in July and $233,000 in October, and 93% of October's dollars still needed a person to step in.
Vendor payments our agent made, by month. Dark blue: a person had to step in, either to approve in the bank's dashboard (payments of $1,000 or more) or to pay by card at a checkout. Payroll and transfers between our own entities aren't included.
The very first payment set the tone. In July the agent created a $1,500 transfer through the API, and it didn't fail. It just stopped, parked in a queue waiting for someone to click "approve" in a dashboard the agent couldn't see. It sat there for five days until Nan, who runs our finance, asked whether we'd paid.
Our own agent, confidently wrong: "Mercury API still only accepts ach and check." Mercury's docs list wires and real-time payments too. It read the docs once and never again.
So for five of the six, our hands-on data is thin. That's why the scores come from each bank's documentation.
What we found
1. Can the agent finish the job? Mostly, until the last step.
A payment looks like one instruction. In practice, every branch below is a place the agent can get stuck.
One instruction, many endings. Solid orange boxes are stops we actually hit.
The UI can always do more than the API. Not one of the six passes "every payment method in the UI is also in the API."
- Mercury's UI sends wires in 40+ currencies. Its payment-request endpoint takes US dollars only.
- Ramp's API pays by ACH, check, wire and SWIFT, but it can't pay several bills in one batch, and same-day ACH only works after Ramp switches it on for you.
Hiring and firing still need a human. Only Ramp and Brex can invite a user by API, and only Ramp can also set their role. No bank's MCP or CLI can manage people at all.
An MCP server tells you almost nothing. All six have an official agent entry point. Airwallex's agent tools explicitly don't move money. Rho's API is read-only. An agent can see the money in both, and move it in neither.
2. Does it hold the agent to your rules? Not by default.
Fig. 3. "Can it finish the job?" as a score. "Do your rules still apply?" as a gate.
Your approval rules stop at the API. No bank applies its approval rules to API payments by default.
- Ramp: bills created through POST /bills are approved automatically, unless you use the draft path, which goes through your approval rules.
- Airwallex: covers API transfers only once you switch it on.
- Mercury: its own pages disagree with each other.
Why this matters more than any other check: the API is the door the agent uses. If your rules only guard the UI, the one unguarded door is the agent's. And agents do get things wrong with real money. Ours once asked Airwallex to "validate" a transfer without sending it. The flag was silently ignored, and a real SGD 1 left our account.
On our Airwallex account the rule was switched on, and it caught every larger API payment before money moved. That's the rule working. But our agent couldn't read the policy it was held to ("Admin permissions required"), so nobody could verify it from the API.
The bank that does the most holds the least. Ramp scores highest overall (7.7) and 4/10 on payment guardrails. Mercury is the mirror image: 9/10 on guardrails, with a key that can only request a payment and an agent card whose limits only a human can change. But it scores 3/10 on people.
3. Can you recover when it's wrong? Partly.
Banks stop payments on their own, too. They ask for a contract or an invoice before releasing the money. Airwallex lets an agent answer those requests through the API, and ours has, so this is one place a bank got it right.
Retries are mostly safe. Airwallex, Mercury, Brex and Aspire require an idempotency key when creating a payment, so a retry doesn't pay twice, and Ramp's guide asks for one too. Rho has no payment endpoint to retry.
The trail is thin. No bank fully exposes its audit log through the API. Only Ramp and Aspire label actions taken through AI tools. On our own account, a payment showed "PAID" for nine days while the recipient had nothing, and there was no event history the agent could check.
The six banks, one line each
- Ramp, 7.7: the most an agent can do (people, sandbox, docs). But bills it creates through the API skip approval unless you use the draft path.
- Airwallex, 6.9: the best keys and retries, and approvals can cover API transfers. But only if you switch it on, and the agent can't read the rules.
- Mercury, 6.2: the best guardrails, including a request-only key and an agent card with human-set limits. But no API to add or remove people.
- Brex, 5.4: the most complete card API. But no sandbox, and the API token dies when its creator leaves.
- Aspire, 3.6: fine-grained MCP switches. But API approval is "Coming Soon," and any one admin can change the rules alone.
- Rho, 2.6: honest up front, since it said read-only at launch. But the API is read-only, so an agent can't move money.
Four things we're asking banks for
- Rules that follow the payment, not the entry point. The UI, the API and MCP go through the same approval, by default.
- A key that can only request a payment, with approval events the agent can subscribe to.
- Webhooks the agent can create and manage itself.
- Parity. If the UI can do it, the API can do it, or the docs say plainly that it can't.
When the agent is the customer
Once an agent pays the bills, the bank's real user is the agent. It doesn't care about the brand, the app or the relationship manager. It cares whether the payment goes through, whether it can check that it did, and whether the rules it's held to are the ones you wrote. Switching banks used to be a weekend of paperwork. For an agent, it's a new API key.
None of what's missing is hard. Banks have spent a year telling founders they're ready for agents. Which one will be ready for the agent's first mistake?
TLDR
- Every bank has an agent launch. None are agent-native yet.
- Agent-native means three things: the agent finishes the job, the bank holds it to your rules, and you can recover when it's wrong.
- 5 of 6 banks let an agent pay. None holds it to your approval rules by default.
Appendix: what the dimensions mean
Can it finish the job?
- Pay vendors: create a payee and pay them, at home and abroad, in batches, with every payment method the UI offers.
- People: invite, change the role of, and remove an employee through the API; removing them also stops their cards.
- Cards: issue, limit, freeze and cancel cards, and get a card number to pay at a checkout page.
- Events: the bank pushes signed updates on payments, approvals, cards and people, and the agent can set those webhooks up itself.
- MCP & CLI: official agent tools that work on a real account and can do more than read.
- Sandbox: a test account you can open yourself, which can make payments, issue cards and send events without real money.
- Docs: documentation an agent can read: llms.txt, Markdown pages, a full API spec, a changelog.
Does it hold the agent to your rules?
- Payment guardrails: approval rules apply to API payments by default, a key can be limited to requesting payments, the agent can't approve itself, and changing the rules needs a second person.
- Agent spend: a card or wallet made for the agent, whose limits and freezes only a human can change.
- Keys & scopes: you can create a key yourself, limit it to what the agent needs, revoke it, and it keeps working after the person who made it leaves.
Can you recover when it's wrong?
- Retries: retrying a payment can't pay twice, you can look a payment up by your own ID after a timeout, and the docs say when a payment is final.
- Audit: you can read the audit log through the API, see which actions an AI tool took, and attach receipts and accounting fields.
Method: benchmark v0.1, scored from public documentation read on Oct 22, 2026, and not yet live-tested beyond our own accounts described above. "Not in docs" means we searched and didn't find it, not that the product can't do it. We use Airwallex, Ramp and Mercury ourselves, and we build software for teams that work with agents.
First published on X by Quinn Leng.
Your first company harness. Where humans and agents run your business together.
