The Short Answer
Apollo chief economist Torsten Sløk asked on 27 September 2026 whether agentic assistants could sweep household cash out of checking accounts averaging 0.1% into the 3.3% to 5.0% accounts his note lists. Any agent that does it must hold the customer's account access. On ibl.ai you own all the code and the data, so a bank can run that agent inside its own perimeter instead of renting the layer that decides what it optimizes for.
The note is titled Is an Agentic Bank Run Coming? and it appeared in Apollo's Daily Spark on Sunday 27 September 2026.
It is a good question, and it is worth separating from the way it travelled. The note is a conditional argument about a mechanism. The version that circulated is a claim about a thing already happening.
What did Apollo's chief economist actually say about an agentic bank run?
He described a rate gap and the chore that closes it. The national average on checking accounts is 0.1%, and the note lists a set of fintech and online accounts paying between 3.3% and 5.0%, sourced to FDIC and Haver Analytics data.
Comparing those and moving money between them is work no household enjoys, which is precisely the profile of a task an agentic assistant absorbs. Sløk names Meta's Muse and "similar agentic AI assistants" as the kind of agent that could do it.
The consequence he is pointing at is not a queue outside a branch. It is the slow drain of the cheap deposits banks fund loans with, which is a funding-cost problem before it is a liquidity event.
Did Apollo say the next bank run starts with "find me a better rate"?
No, and the difference is worth stating because it is the whole epistemic distance between a warning and a headline. That five-word compression is commentary on the note, not a line in it, and the commentator who wrote it added that the scenario is not possible or likely today.
Sløk's own language is conditional throughout. Agents "could soon sweep" household cash. The scale argument is framed as what happens "if every household used" one.
That matters for anyone deciding a budget off the back of it. A conditional note about a mechanism justifies building capability. An assertion that a run has begun justifies panic, and it is not what the source says.
Can an AI agent move a household's deposits today?
Not at the scale the note contemplates, but the missing piece is closer than the framing suggests, and it is the account connection rather than the reasoning.
On 28 September 2026 Plaid announced a partnership with Decagon, described in Plaid's own post. The stated capability is to "verify a bank account, check a transfer's status, or complete a payment in the moment a customer asks."
Read the scope honestly: that is customer support, onboarding and payment resolution. It is not rate comparison, and treating it as the deposit-flight engine would be reading a support integration as a wealth product.
What makes it structurally interesting is the persistence. The connection a customer authorizes in one conversation stays available to the agent in later ones, so authentication stops being a per-task tax.
Plaid built the same primitive with Sierra in August 2026, putting Plaid Link inside Sierra's agents so an agent works against live account data. The rails are being laid for support. Rails do not care what runs on them.
Why does a bank's deposit spread get attacked before anything else?
Because it is the largest price in retail banking that survives only on customer inattention. A gap between 0.1% and 4% persists because acting on it costs a person an afternoon.
Every other margin a bank defends has some substance behind it: underwriting, distribution, a branch, a relationship. The spread on an idle checking balance has friction behind it, and friction is the one input software removes reliably.
Which is why this arrives as an agent story rather than a fintech story.
High-yield accounts have existed for years and did not trigger a run, because the switching work stayed manual. An assistant that already holds the account connection does that work at no marginal cost to the customer.
If agents are going to shop rates, what should a bank actually own?
The agent. An assistant holding a customer's account access and optimizing on their behalf is not a feature, it is a distribution channel, and the party that operates it holds three decisions that are not negotiable afterwards.
What it optimizes for. An agent operated by a platform optimizes for the platform's definition of a good outcome. One operated by the bank can weigh yield against a relationship, a mortgage, a fee waiver.
What it sees. Balances, transactions and behaviour flow through whoever runs the reasoning layer. A bank renting that layer exports its customers' financial behaviour to a third party as a condition of participating.
What it costs. Per-seat pricing is the wrong shape for this outright: the cost of an agent checking rates is a function of how often it runs, and it has nothing to do with how many employees the bank has.
We worked the ownership side of this through for banks already committing to agent workforces in Banks Are Building AI Workforces. Who Owns the Infrastructure?
What controls does a bank-operated deposit agent need before it ships?
Four, and each is a real engineering surface rather than a policy sentence.
| Control | What it prevents | Where it has to live |
|---|---|---|
| Agent identity | An autonomous process acting behind a shared service credential, invisible to every control the bank already runs | The bank's directory |
| Row-level authorization | An agent scoped to a customer reading rows belonging to other customers | Inside the tool call, not the prompt |
| Audit trail per action | A movement of customer funds the bank cannot reconstruct or attest to afterwards | The bank's own logs |
| Model portability | A provider's pricing or policy change resetting the economics of a live deposit product | A model-agnostic runtime |
The authorization row is the one most often written as a prompt instruction and then discovered in an audit. The mechanics of enforcing it inside the tool rather than around it are in An Agent That Moves Money Needs Row-Level Permissions.
Where does ibl.ai fit in a bank's agent layer?
On ibl.ai you own all the code and the data. Agent identity, scoped permissions, row-level authorization and per-action audit logging ship as source the bank deploys inside its own perimeter, model-agnostic across any LLM, with no per-seat pricing.
That is the specific answer to Sløk's mechanism. A bank cannot stop households from wanting 4%, and should not try. It can decide whether the agent doing the shopping is one it operates, or one that treats its deposit base as inventory.
1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.
The adjacent version of this question, when the vendor holding the ledger also holds the money, is in Fintech SaaS Is Becoming Banks. Who Owns the Data Layer?
Want a deposit agent your bank actually owns?
We deploy agent identity, authorization and audit as source code you keep, in your cloud, on-premise, GovCloud, or fully air-gapped. Book a 30-minute demo or talk to the ibl.ai team — ibl.ai is family-owned and operated from New York, NY.