On 27 September 2026, Apollo chief economist Torsten Slok published a note titled "Is an Agentic Bank Run Coming?". In his scenario, personal AI agents compare deposit rates and move household cash from checking accounts paying around 0.1 % to fintech accounts paying 3.3 to 5 %. If a large share of households lets an agent do this, banks lose part of the low-cost deposits they use to fund loans.
I took a close look at what is observable today, where agent authority is being standardised right now, and which constraint is missing once agents start moving deposits. I end with a prototype we are building and a request for a pilot partner.
The agents are already trading
Meta launched its personal agent Muse on 8 September 2026. Through Plaid, a provider of bank-account data connections, users can connect balances, transactions and holdings. Muse tracks spending, cancels subscriptions and builds budgets. Its terms of service state that Muse is not a licensed money transmitter.
Robinhood went further. Since May, outside agents can trade through its tools, and on 29 September Robinhood moved agents into its own app. More than 150,000 customers had opened agent accounts by late September, and agents use Robinhood's tools almost 30 million times a day, according to the company's unaudited figures. Each agent trades from a dedicated, customer-funded account. Approval of every order is on by default, and customers can switch it off. Robinhood's disclosures place all risk of agent trades on the customer. The limits live in Robinhood's settings, and no party outside Robinhood can check them.
Banks are building the sweep themselves. JPMorgan is testing Smart Cash, a tool that moves cash between checking and higher-yield brokerage products without waiting for a human to sign off.
The deposit scenario needs one more step. Agents would have to move cash between independent banks on their own authority, within limits the saver set in advance.
The case against a run
The note drew pushback within days. Nik Milanović of This Week in Fintech puts the median US savings balance at about $8,000, worth roughly $180 a year in after-tax interest. Automated rate sweeps have existed for a decade through MaxMyInterest, and few people use them. Missed direct debits and declined cards after a transfer cost the saver time. "Having to think is a switching cost," he writes.
David Kirk moves the risk somewhere else. Agents will read bank risk as well as yield, and many agents reading the same signals will leave the same bank at nearly the same time. "The difference this time is that every prisoner has hired the same lawyer." At Silicon Valley Bank, about 94 % of deposits were uninsured.
Kirk's version needs no mass adoption. A small number of large, uninsured balances managed with identical logic would be enough to strain a mid-sized bank.
Supervisors are asking about control. The Bank of England's Financial Policy Committee wrote in its April 2026 record that agentic AI "presented particular risks", and that firms' private incentives to deploy it "in payments and financial markets, could fail adequately to internalise certain negative externalities." On 13 October, Reuters reported that the Fed, the OCC and the FDIC have sent banks questions on their use of AI agents and on how banks can shut down autonomous systems.
Visa and Mastercard write the rulebook
Agent authority is being standardised now. In April 2026, Google contributed AP2 (Agent Payments Protocol, a format for signed user mandates) and Mastercard contributed Verifiable Intent (VI, a layered credential format binding user, agent and constraints) to the FIDO Alliance, the industry body behind passkeys. The Payments Technical Working Group, chaired by Mastercard and Visa, develops both further.
VI defines eight registered constraint types (spec/constraints.md, commit 356c296, unchanged since April 2026). They cover merchant allowlist, line items, payee allowlist, amount range, total budget, merchant-managed recurrence, agent-managed recurrence and a checkout-payment cross-reference. The agent-managed recurrence type carries a frequency field. The specification states that this field guides timing and is not strictly enforced.
For purchases, this vocabulary guards against the wrong merchant, the wrong item and too much money. Deposit movements carry a different risk. A single transfer between two insured banks does no harm. Harm comes when many agents with identical thresholds read the same rate table or the same risk signal in the same hour.
None of the registered types expresses a minimum holding period, a minimum interval between transfers, or a restriction to insured counterparties. VI §6.1 allows custom constraint types, so they can be added without changing the format.
What a savings agent should carry
For agents that move savings, we propose these constraint types. The saver signs them once. The agent carries them with every transfer. The receiving bank verifies them on arrival.
| Constraint | Meaning |
|---|---|
ch.moltrust.deposit.min_hold_days | Funds moved into an account stay there for at least N days |
ch.moltrust.deposit.sweep_threshold_bp | A transfer requires a rate difference of at least X basis points (1 bp = 0.01 %) |
ch.moltrust.deposit.max_sweeps_per_period | Upper limit on transfers per month or quarter |
ch.moltrust.deposit.insured_counterparty_only | Target account must fall under a statutory deposit guarantee scheme |
ch.moltrust.deposit.execution_window_hours | The agent executes at a random point within a window of H hours after the trigger |
The names follow VI's Model B (reverse-domain naming for organisation-specific types). If the types prove useful across implementations, we will propose them for registration under mandate.payment.*.
The sweep threshold stops agents from chasing every small rate change. The insured-only rule keeps agent-managed savings below the guarantee limit, where a stress signal gives the saver no reason to leave. The randomised execution window spreads transfers that would otherwise start in the same minute.
For the bank: deposits with a promise
An incoming deposit arrives with a signed commitment to stay for a stated period. The bank can check the signature, the constraint values and the policy version without trusting the agent operator. It can then price that commitment, with a higher rate for 90 attested days and a standard rate for funds without a holding period.
Banks already price commitment length on the other side of the balance sheet. In prime brokerage, the financing commitment a bank gives its most coveted hedge fund clients has stretched from about two weeks to 30 days, three months and in some cases six months, the Financial Times reported this month. An attested holding period applies the same logic to the funding side, with the saver making the commitment.
For treasury, deposits with attested holding periods become forecastable in the way term deposits are. I leave open how supervisors would treat such commitments in liquidity metrics.
For the saver: the yield, minus the surprises
The saver keeps most of the rate advantage. The mandate keeps the money in insured products and holds a 90-day premium against a 5 bp difference elsewhere. Every transfer decision produces an evidence record that the saver, the bank or an auditor can recompute offline. Robinhood leaves the full risk of agent trades with the customer. A recomputable record gives that customer evidence to work with.
On our workbench
MolTrust already runs per-transaction mandate enforcement. An operator-local check returns allow, hold or forbid for each action and ships as the Python SDK moltrust-enforce. Attested-Evidence Replay (AER) records the inputs of each decision so third parties can recompute it.
Next on the roadmap are the deposit constraints in this kernel, mapped onto the VI credential format. The goal is an extension that AP2 and VI verifiers can add. Until a verifier knows the new types, the VI specification requires it to reject any open mandate that carries them (§5.4). A parallel format would fragment the ecosystem forming around FIDO.
We are looking for one deposit-taking bank or deposit marketplace for a pilot. Your treasury team sets the constraint values, the bank verifies mandates at account opening, and we compare attested and unattested inflows over three months.
Contact: lars@moltrust.ch