The short version
Does BankBridge store your bank data? No. Not for thirty days, not in an anonymized form, not in a backup somewhere. No transaction is ever written to a BankBridge database. No balance is cached. There's no table of your merchants, no snapshot of your holdings, no record of what you bought last Tuesday.
When your agent calls a tool like get_spending_summary, we fetch your transactions from the bank in real time, compute the answer in memory, return it, and let it go. Once the response is sent, the data is gone from our side.
That's the whole policy. The rest of this post explains how it works, what we keep instead, and where the design costs you (there are real trade-offs, and we'd rather you hear them from us).
What happens when your agent asks a question
Say you're in Claude Code and you type:
How much did I spend on restaurants in June?
Your agent picks a tool, usually get_spending_summary or search_transactions, and sends the request to bankbridge.money with your API key. We check the key, look up which banks you've connected, and forward the request to the bank-connection layer, which pulls the data live from your bank.
The response comes back, we shape it into clean JSON, and hand it to your agent. Total round trip is usually a second or two. At no point in that chain does anything get written to a BankBridge disk. Your transactions exist in our server's memory for the length of one request, then they're released.
Ask the same question five minutes later and the whole trip happens again. That sounds wasteful. It's the point.
What we do keep (the honest list)
Zero-storage claims usually hide fine print, so here's ours. To run the service at all, we store a small set of things.
Your account email and password hash. Your API keys, hashed, so we can verify them without being able to read them. Your billing status with Stripe. And one encrypted connection token per bank you've linked, which is what lets the bank-connection layer fetch your data when you ask.
We also keep operational logs: which tool was called, when, and whether it succeeded. The logs never include the financial payloads. We can see that you called list_transactions at 9:14 this morning. We can't see what came back.
That connection token is the most sensitive thing we hold, which is why it's encrypted at rest and why it only grants read access. It can't initiate transfers, it can't move money, and it never will.
Why we built it this way
A warehouse of customer transactions is a liability wearing a product costume. Every finance company that stores years of spending history has built something a breach can leak, a subpoena can pull, and an acquirer can repurpose. We didn't want to own that.
You can't leak what you don't have. If someone broke into our servers tomorrow, there's no transactions table to dump and no balance history to expose. The most sensitive things here are encrypted read-only connection tokens, and those can't move a cent.
Same logic for legal process. If we're served a subpoena for your transaction history, we can't produce it, because it isn't here. Your bank holds those records and has had a legal department handling such requests for a century. We're not adding a second, softer target.
And there's no dataset to sell, aggregate, or 'anonymize' for a data-licensing side business. Our revenue is $5 a month per connected bank. That's the entire business model, and the architecture makes it hard for any future version of us to quietly change it.
The trade-offs, stated plainly
Live-fetch has real costs, and we'd rather list them than have you discover them.
Requests are slower than a cached system. Every question travels all the way to your bank and back. Most calls finish in a second or two, but a cold call to a slow institution can take five or more. A product sitting on a local copy of your data would answer instantly. We can't.
There are per-call limits. The aggregator rate-limits how often we can pull from a given bank, so an agent that fires off forty tool calls in a burst may get throttled. Good agents batch their questions; our prompt patterns guide covers how.
History depth is whatever the bank connection returns, typically around two years. We can't offer 'ten years of your data' because we never accumulated it. If you want an archive that outlives your bank's window, export to a spreadsheet and own the file yourself.
And if the bank-connection layer or your bank has an outage, we have no cache to fall back on. When they're down, we're down. That's the deal.
Where your data does end up
One thing we want to be straight about: the answers go somewhere. When your agent asks about your spending and BankBridge returns the numbers, that response becomes part of your conversation in Claude, ChatGPT, Cursor, or whichever host you're using. Those apps keep chat history under their own policies, not ours.
So the full picture is: your bank stores your data (it has to), your AI app stores your conversations (check its settings if that matters to you), and BankBridge stores neither. We're a pipe, not a bucket.
If you want financial details out of a host's history, most hosts let you delete conversations or turn history off. Nothing needs to be deleted from BankBridge afterward, because nothing landed here.
Don't take our word for it
The nice thing about not storing data is that the claim is testable.
Disconnect a bank from your BankBridge dashboard, then ask your agent for its balance. The call fails immediately. There's no cache serving stale answers, no thirty-day deletion window, no 'removed from backups within 90 days.' The data was never here, so there's nothing to purge.
Freshness proves it from the other direction. Make a purchase, wait for your bank to post it, then ask:
What's the most recent transaction on my checking account?
A cached product shows you yesterday. BankBridge shows you whatever your bank shows right now, because it's reading from your bank right now. If you ever catch us serving data your bank doesn't have, that's a bug report we very much want.