Why bank statement fetch connections keep breaking

Every firm that uses a bank feed or a statement fetch tool knows the pattern. The connection was green in March. In April it quietly returned nothing. The client swears they changed nothing, the vendor’s status page says all systems operational, and you find out during close, which is the most expensive possible moment to find out anything. Search “bank feed keeps disconnecting” and you will find a decade of forum threads about every product in the category.

I build statement retrieval software at Scale CPA, where we run it on our own client book, so I spend a lot of time staring at exactly these failures. The honest answer to “why does this keep happening” has almost nothing to do with which vendor you picked. Connections break for structural reasons that sit between every fetch tool and every US bank. Once you understand the four main mechanisms, you can stop shopping for a tool that promises unbreakable connections, because none exists, and start shopping for one that notices breakage fast and recovers cleanly.

The plumbing between your software and the bank

Almost no fetch tool talks to a bank directly. In the US, third-party access runs through aggregators: Plaid, MX, and Finicity, which Mastercard acquired and now operates as Mastercard Open Banking. These companies maintain connections to thousands of institutions and expose them through one API, including endpoints for pulling official PDF statements.

An aggregator reaches a given bank in one of two ways.

Sanctioned APIs. The bank publishes an official interface, usually protected by OAuth. Your client logs in at the bank’s own site, approves specific access, and the aggregator receives a token. Nobody stores the client’s password. This is the good path, and US banking has spent years migrating toward it.

Screen scraping. For banks without an API, the aggregator logs in with stored credentials and automates the same web session a human would use, parsing pages to pull out data and documents. It works, but it is inherently brittle, and it is what most of the industry ran on for a decade.

So the real chain is your tool, then an aggregator, then a bank, then the specific account. A failure at any hop looks identical from your desk: no statement this month.

Four ways a connection dies

Screen scraping breaks when a bank changes its website

A scraped connection is a robot pretending to be your client. If the bank redesigns its login page, inserts a new marketing interstitial, changes the wording of an MFA prompt, or tests a new navigation flow on half its customers, the robot gets lost. Nothing you did. Nothing the client did. The bank changed a webpage.

Banks also actively resist scraping. From a bank security team’s point of view, an aggregator logging in from a data center with stored credentials looks a lot like an attack, so they deploy bot detection and rate limiting. That is why scraping failures feel random: fine on Tuesday, blocked on Wednesday, fine again Friday, with no human action in between.

OAuth migrations force everyone to reconnect

Here is the frustrating part: the industry fixing this problem also breaks connections. When a bank switches on an official OAuth integration with an aggregator, existing scraped connections to that bank usually cannot be quietly carried over. The security model is different by design, so each customer has to walk through the bank’s own consent screen once. Multiply that across every client you have at that bank and it looks like mass-disconnection week.

The payoff is real. OAuth connections are far more durable afterward, though still mortal: tokens get revoked when a bank overhauls its consent portal, sometimes when a client changes their online banking password, and occasionally when the bank retires an old API version.

Security holds at Wells Fargo, Chase, Bank of America, and Citi

The biggest US retail banks each have flows that can pause third-party access: a new-device confirmation, a consent recheck inside the bank’s own security center, an alert the account holder has to acknowledge before data flows again. These are real fraud controls doing their job. No fetch tool can click through them on the client’s behalf, and you would not want one that could.

The practical consequence is that some percentage of reconnects will always need the account holder personally, on short notice, in a specific month. A tool cannot remove that step. It can make the step small: one link, the bank’s own login page, done on a phone in under a minute.

Tokens expire because they are supposed to

Time-boxed access is a feature of modern consent frameworks. Some institutions expire third-party authorization on a fixed schedule and require the customer to re-approve. When that happens, the aggregator flips the connection into a login-required state and everything downstream stops until someone acts. Annoying, but this is the system working as intended. Standing access to a bank account should require standing consent.

Put the four together and you get the table every operations person eventually reconstructs from experience:

Nobody is immune, including us

Read public reviews of any product in this category and you will see the same theme. Reviewers on G2 and Capterra broadly report reconnect churn as a top frustration with statement fetch tools, across vendors. That matches the physics. Every fetch tool, including ours, rides the same aggregator rails to the same banks, and the failure modes above do not care whose logo is on the dashboard.

StatementFlow runs on Plaid and Mastercard Open Banking. Connections at our own firm’s clients break too. Before we built tooling to catch it, statement gaps at Scale CPA sat unnoticed longer than anyone wants to put in writing, and building the tooling did not make the banks stop rotating their security flows.

It is worth naming how hard this problem is at scale. Hubdoc, owned by Xero, retired its statement Auto-Fetch feature entirely in early 2022 rather than keep maintaining it. Fetching statements from banks that keep changing the locks is genuinely difficult infrastructure work. If you relied on that feature, we wrote up where firms went after Auto-Fetch.

What actually helps

Since breakage is structural, reliability is a recovery problem. Four things move the needle.

Dual-provider failover

Plaid and Mastercard Open Banking each maintain their own integrations, and coverage quality differs bank by bank. When one provider’s path to an institution degrades, the other’s often still works, so a tool that runs both can re-establish the account through the healthy side. Honest caveat: coverage overlaps imperfectly, and when the bank itself is holding access, no second provider gets around it.

Retry windows that match the statement cycle

A surprising share of “the connection is broken” panic is actually “the statement does not exist yet.” Banks post statements on each account’s own cycle, which rarely lines up with calendar months, and cycles drift with weekends and holidays. A fetch tool that learns when each account actually publishes can retry inside the right window and tell “not posted yet, keep waiting” apart from “connection dead, act now.” Without that, you either retry blindly or escalate false alarms.

Make reconnects painless for the client

When a reconnect genuinely needs the account holder, the ask itself decides whether it happens today or after your third reminder. One link. The client authenticates at their own bank, on their phone, without creating an account on some vendor portal or emailing credentials to anyone. Batch the asks so a client with three broken connections gets one message instead of three. Every extra step compounds across your whole book, every month.

Surface gaps before they become quarters

This is the one that matters most, and the one most setups lack. A dead connection is survivable. A dead connection nobody notices until year-end tax prep is a genuine problem, and silence is the default, because a fetch that stops fetching raises no alarm anywhere. The fix is boring: a grid of accounts against months, where every expected statement is present, pending inside its normal window, or flagged. StatementFlow’s coverage board exists because we needed exactly that view for our own close. When a Wells Fargo hold freezes an account in October, the empty cell shows up within days and the reconnect request goes out while the client still remembers approving the connection in the first place.

Questions worth asking any fetch vendor

If you are evaluating tools in this category, skip “do connections break” (yes) and ask these instead.

1. How do I find out a connection is dead: an alert and a gap view, or silence until I go looking?
2. Do you run more than one aggregator, and can an account fail over between them?
3. What exactly does my client see when they have to reconnect, and how long does it take on a phone?
4. Does the tool know each account’s real statement cycle, or does it try on the 1st and give up?
5. When a fetch succeeds, how do I know the file is complete and filed correctly? For what it is worth, we hash-verify every PDF and file it into the firm’s own Google Drive.

A vendor with real reliability engineering behind the product will have crisp answers. Vague reassurance about bank-level reliability usually means the recovery burden lands on you.

StatementFlow is in early access, running on Scale CPA’s own client book first. If broken connections and silent statement gaps keep eating your close, request early access and we will walk through how the coverage board handles your specific bank mix.