What actually breaks when you change your password
When you connect a bank to BankBridge, you never hand us your password. The bank-connection layer negotiates a credential with your bank during the login flow, and that credential is what gets used every time your agent asks a question. Your password itself isn't stored anywhere in the chain.
Change the password and the bank revokes that credential. That's the whole failure. The connection still exists in your dashboard, but the bank now refuses every request made through it. Some banks cut access the moment you save the new password. Others let requests keep working for a few hours or days until a security check catches up. Either way, it ends in the same place: expired.
BankBridge fetches everything live, so there's no cached copy to fall back on. The moment the bank starts refusing requests, your agent's questions start failing. That's deliberate. We'd rather your agent tell you the connection is broken than quietly answer from week-old numbers.
How to spot an expired connection
You'll usually notice in one of two places: your agent, or the dashboard.
In your agent, a question that worked yesterday suddenly comes back with an error.
What's my checking balance right now?
Instead of a number, the tool call fails with a message saying the connection needs to be re-authenticated. Different hosts word it differently (Claude tends to explain it plainly, some CLIs just print the raw error), but the shape is always the same: the bank said no.
The dashboard is the definitive check. Sign in at bankbridge.money and look at your connections. A healthy bank shows Connected. A broken one shows Needs reconnection, with a Reconnect button next to it. If you've got several banks linked and only one password changed, only that one flips. Each bank connects independently, so the others keep answering as usual.
The relink flow, start to finish
Reconnecting takes about two minutes, and you don't have to touch your agent setup at all.
Sign in to the dashboard and find the connection marked Needs reconnection. Click Reconnect. A secure login window opens from the bank-connection layer, the same one you used when you first linked the bank.
Enter your new password, complete whatever multi-factor step your bank throws at you, and confirm the accounts you want shared. That's it. You'll land back in the dashboard with the status flipped to Connected.
Nothing on the agent side needs to change. Your MCP server URL is the same, your API key is the same, and your host config is untouched. The next question your agent asks will just work. Well, almost. There's one thing that does change, and it's worth knowing before your agent trips on it.
The gotcha: account ids rotate after a relink
Every account in BankBridge has an id. Tools like get_account and list_transactions accept it, and agents love to save it once and reuse it forever.
Here's the catch: those ids are minted per connection. When you relink, the bank-connection layer quietly creates a fresh connection, and every account on it gets a brand-new id. The old ids stop resolving. If your agent stored them in a memory file, a CLAUDE.md, or a script, those references now point at nothing.
The stable identifier is the mask, the last four digits of the account number. The mask comes from the account itself, not the connection, so it survives every relink. A checking account ending in 4872 is still the account ending in 4872 no matter how many times you reconnect.
Ids rotate. Masks don't. Build on the mask.
Teach your agent to resolve accounts by mask
The reliable pattern is simple: start each session with a fresh list_accounts call and match accounts by mask instead of trusting anything saved.
List my accounts with their masks, then use the checking account ending in 4872 for the rest of this session.
Pull a 90-day spending summary for the credit card ending in 8006.
If you keep notes for your agent (a memory file, a project CLAUDE.md, a system prompt), record masks and nicknames there, never raw ids. Something like "checking ••4872, savings ••3227" gives the agent everything it needs to re-resolve accounts after any relink.
Same rule for anything scripted. If you've written automation against BankBridge, call list_accounts at runtime and select by mask rather than hardcoding ids. It's one extra call, and it turns password changes into a non-event.
What doesn't change
A relink is a repair, not a new subscription. You're reconnecting the same bank, so there's no new $5/mo charge and no double billing. Your plan continues exactly as it was.
Your API key doesn't change either. bbk_ keys authenticate you to BankBridge, not to your bank, so they're completely independent of the connection's health. (If you do want to swap a key, that's a separate process, and it's also quick.)
And you don't lose any history. BankBridge doesn't store your transactions, so there was nothing to lose in the first place. Your history lives at the bank, and the moment the relinked connection is live, your agent can query all of it again, including everything that happened while the connection was down.
A quick check after you relink
Once the dashboard shows Connected, have your agent confirm from its side.
List my accounts and show the mask for each. Then give me the current balance on the account ending in 4872.
If both calls come back clean, you're done. If the host still shows an error, start a fresh conversation or reconnect the MCP server in your client's settings. Some hosts hold onto a stale session for a while.
One last thing: don't avoid changing your bank password because of this. Rotating it occasionally is good hygiene, and now you know the fallout is a two-minute relink plus one fresh list_accounts call. That's a fine trade.