Deposit Networks

This isn't a product pitch and it isn't a grade of any single company. It's a research artifact I wrote because one corner of fintech infrastructure has quietly become the most interesting regulated-utility wedge I've looked at in years, and when I started sketching how I'd build in it, I couldn't put it down. Everything here is reasoned forward from public materials: company sites, trade-press coverage of the post-SVB deposit flight, the EGRRCPA regulatory text, and two decades of incumbent behavior that's sitting in plain sight.

The artifact is organized the way I'd organize a founding-team brief to myself: what is the category, who is in it, why now, what breaks the thesis, and, if I were the engineer on the hook, what would I actually build.

A community bank or credit union can only insure $250K of a customer's deposit through FDIC or NCUA. When a large depositor — a municipality, a law firm escrow account, a small business with payroll float — walks in with $10M, the institution has three choices: refuse the deposit, push the customer to a money-center bank, or route the excess across a reciprocal deposit network of peer institutions so every slice lands inside someone's insurance ceiling. That routing market is roughly $2.3T, it is dominated today by a single incumbent that still runs on phone calls, broker relationships, and spreadsheets, and a handful of API-first challengers are now replatforming it the way Plaid replatformed account connectivity and Stripe replatformed card acquiring. That is the category.

The SVB failure in 2023 was the starting gun. Overnight, every community bank treasurer in the country discovered that uninsured deposit concentration was an existential risk and their CFO wanted a dashboard for it by Monday. The regulatory environment tilted the same direction: EGRRCPA raised the practical reciprocal-deposit ceiling to the lesser of $5B or 20% of liabilities, which turned what used to be a niche product into a headline liquidity lever for mid-sized institutions.

On top of that, the CUSO structure opens a greenfield: credit unions were historically locked out of the incumbent network's bank-only plumbing, and a challenger with the right regulatory wrapper gets to compete for a customer base no one was serving. Bank greenfields that large are rare. The window is open right now because the incumbent hasn't been forced to respond yet. When they do, the challenger has to already be in the ground.

I wanted to write this section carefully, because anyone can list generic risks. These are the three I'd actually lose sleep over as the engineer on the hook.

Every system in this space has to survive first contact with a community bank treasurer at 8:00 AM on a Monday. That person is not browsing for features. They have one number they care about, which is their EGRRCPA headroom, and one recurring fear, which is that a settlement break somewhere in the network is going to turn into a regulator call. The product has to make that number glanceable, make breaks self-evident, and make the action-to-resolution path a single click. If an operator has to open a spreadsheet to reconcile anything, the product has already lost the account.

This is why the concept UI on this page leads with an EGRRCPA headroom KPI and a reconciliation-breaks panel with suppressed-noise counting. Those two widgets are not decoration. They are the reason the tab stays pinned.

The artifacts linked below are the engineer-on-the-hook version of this case study: a system architecture, a data model, an institution-facing API specification, and a clickable concept UI that walks the three personas a platform in this space has to serve: treasury operators, controllers, and the platform's own network admins. None of it is production software. All of it is the output of the exercise “if someone handed me a whiteboard tomorrow, what would I draw.”

Explore the artifacts: Open the concept UI in a new tab → · View the OpenAPI specification →

The concept UI is a thought experiment, not a redesign of any live product. Numbers and institution names in the mockup are fabricated. It exists to make the three-persona argument concrete enough to talk about.

If a company in this category is going to become a durable public business rather than a feature acquired by a core vendor, three things have to be true. First, the core integration pipeline has to scale into a repeatable, measurable revenue function, meaning certified launches per quarter, not per year. Second, the trust posture has to be observable from outside the company: published SLAs on settlement, audited breaks disclosure, SOC 2 Type II as a starting point rather than a finish line. Third, the economic model has to stay differentiated from the incumbent even after the incumbent responds, which means the yield-share story has to be structural, not a promotional rate that collapses under competitive pressure.

None of those are easy. All of them are engineering-adjacent more than sales-adjacent, which is why the companies that win this category will be the ones where the founding engineering team treated compliance surface, integration throughput, and trust posture as first-class product work from day one.

I wrote this because the problem space stuck with me long after I stopped thinking about it on purpose. Regulated financial infrastructure that still runs on phone calls is a rare and short-lived thing to catch in the wild, and the engineers who get to rebuild it are going to ship some of the most consequential quiet work of the decade. If any of this resonates, or lands wrong in an interesting way, I'd genuinely welcome the conversation.