In May 2024, more than 100,000 people opened their banking apps and could not move their money. They had downloaded fintech products — savings apps, small-business banking apps, yield accounts — and had been told their funds sat in FDIC-insured accounts at partner banks. The funds were there. The banks were solvent. Transfers stopped completing anyway. A company most of these users had never heard of, Synapse Financial Technologies, had collapsed — and with it, the layer of financial architecture that recorded which portion of the pooled bank deposits belonged to which end user. Within weeks the bankruptcy trustee had been appointed, Synapse’s workforce had been terminated, and one of the partner banks had told the trustee that the records still existed but could no longer be read. What follows traces what broke, in what order, and why deposit insurance — which functioned exactly as designed — did not reach the people who needed it.
1. The architecture before the failure
To understand why solvent banks could not release funds they physically held, the architecture beneath the fintech app has to be made visible. It was always there. It was always load-bearing. Most of the consumers downstream of it never saw it.
1.1 The consumer view
A user opens a fintech banking app. There is a balance. There is an FDIC logo somewhere on the screen, often with language indicating that funds are held at one or more partner banks. Money goes in, money goes out, transfers complete, debit-card swipes authorize. From the consumer’s position this looks like a bank account, and for almost all practical purposes it functions as one. What the consumer does not see is that between the app and the bank sits a third party — and that third party is not a bank.
1.2 The middleware layer between fintech and bank
The third party is a software company. Its product is the connection between fintech apps and the banking system, and its business depends on holding something the bank does not hold: the record of which portion of a pooled bank account belongs to which end user. This is the middleware layer of banking-as-a-service, and it is the load-bearing element of the architecture — the piece on which the bank below it depends to act on any specific dollar inside the pooled funds it custodies. It is part of the same broader stack of financial infrastructure the bank itself sits in, but it is not regulated as a bank, not insured as a bank, and not visible to the end user as a separate party at all.
1.3 The FBO account and the pooled balance
When a fintech partners with a bank under a banking-as-a-service arrangement, the fintech does not get individual deposit accounts at the bank for each of its customers. Instead, the bank opens what is called an FBO account — for the benefit of — held in the name of the fintech, or in the name of the middleware company sitting between them. Inside that single account is the pooled money of every end user the fintech has signed up. From the bank’s perspective, the account holder is the fintech or the middleware. The end users are not the bank’s customers.
The mechanical consequence is direct. The bank holds, for example, $200 million in a single pooled account, knowing the money belongs to roughly 100,000 individuals — but not knowing how the $200 million breaks down among them.
1.4 The ledger as the only complete record
That breakdown lives in a ledger maintained by the middleware company. The ledger is a database that records every credit and every debit attributable to every end user. When a customer of the fintech app deposits $100, the bank’s pooled balance rises by $100 and the middleware ledger adds a $100 entry against that customer’s record. When the customer transfers $50 to another customer of the same app, the bank’s pooled balance does not change at all — only the ledger entries change. The bank, in this scenario, has no record that anything happened.
This is the architecture, stated plainly. The bank holds the money. The middleware holds the record of who the money belongs to. The slice that any individual customer thinks of as their account exists, in any operationally usable form, only in the middleware’s ledger. The dependency runs in one direction: when a customer requests a withdrawal, the bank does not pull from that customer’s slice — there is no slice in the bank’s records. The middleware tells the bank to move a specific amount from the pooled account to a specific destination on behalf of a specific end user. The bank’s record of the transaction is at the pool level. The end-user-level record lives upstream.
This works as long as the ledger is intact, the middleware is operational, and the bank has continuous access to it. Synapse is what happens when those conditions stop holding.
2. The failure event: May 2024
The architecture above describes the steady state. What happened in May 2024 was the loss of each of its three load-bearing conditions in sequence: continuous bank access to the ledger, an operational middleware company, and the institutional knowledge required to read what the ledger said.
2.1 The structural picture across four partner banks
Synapse Financial Technologies served roughly 100 fintech partners. Their funds sat in pooled FBO accounts across four partner banks — Evolve Bank and Trust, AMG National Trust, Lineage Bank, and American Bank. The figures and structure that follow come from the Chapter 11 trustee’s first status report, filed June 6, 2024.
The fragmentation did not stop at four banks. The trustee’s report documented that Synapse, in the trustee’s words, often used multiple partner banks to service different functions for the same fintech partner. Deposits for a single fintech might flow into an account at one bank, while withdrawals for that same fintech were processed from a different account at a different bank. Even at the level of a single fintech program, no individual bank held the full picture. The picture only existed when Synapse’s ledger pulled the pieces together.
Inside the FBO accounts at each of these banks, end-user funds were not segregated by individual. They were pooled. They were also, the trustee reported, co-mingled — end-user funds, fintech-program funds, and Synapse’s own funds appeared together inside the same FBO accounts. The segregation between these categories existed in the ledger, and only in the ledger.
One disclosure in the same report makes the dependency on the ledger especially concrete. Inside the partner banks, the funds were just funds. Whose money each dollar represented — that classification lived upstream, with Synapse. The trustee documented that approximately $60 million of end-user money had been used to meet Synapse’s own reserve obligations at Lineage Bank. When Lineage discovered this, it moved the funds into an FBO account for the benefit of end users. The bank, until told, had no way to know whose those funds had been.
The aggregate scale comes from the FDIC. In a notice of proposed rulemaking issued in September 2024, the agency stated that aggregate end-user balances were approximately $265 million, while the partner banks held between $180 and $219 million. Four banks, around 100 fintech programs, more than 100,000 end users — and a gap, already, between what end users were owed and what was sitting at the banks.
2.2 Evolve loses access to the ledger system
In early May 2024, the structure broke.
According to the FDIC’s September 2024 notice of proposed rulemaking, citing court filings, one of the partner banks — Evolve — froze deposits because Synapse had denied the bank access to an essential system through which Evolve had been retrieving information on end users, deposits, and transactions. The bank held the funds. The bank had been receiving its picture of who owned which funds through a system controlled by Synapse. When that access was cut, Evolve could no longer process movements against end-user balances, because it could no longer tell which balances belonged to whom.
This is the failure mode in its purest form. Evolve had the money. Evolve could not act on the money. What blocked the bank was the loss of ledger access — the records that established which balances belonged to whom had become unreachable, and without them the bank had no operational basis for releasing any specific balance to any specific person.
2.3 Synapse terminates its workforce
A few weeks later, the situation worsened. On May 24, 2024, a Chapter 11 trustee was appointed in Synapse’s bankruptcy proceeding. By that date, according to the trustee’s status report, Synapse had already terminated all of its employees. The middleware company existed as a legal entity. It did not exist as an operational organization. There was no one at Synapse who could be asked to clarify what the ledger said.
The order matters. Access was cut first; the people who could have explained what the ledger meant were let go second. Either of these failures alone would have been recoverable — a bank cut off from a ledger can be reconnected; a company with operational staff can supply interpretation under court supervision. Together, they were not.
2.4 The ledger as institutional knowledge
What Evolve told the trustee, in the days that followed, captures the deepest layer of the dependency. Evolve reported that it could not reconcile its deposits against Synapse’s ledgers because the proprietary ledger system was difficult to interpret without expertise from former Synapse personnel. The system was still there. The data was still there. But the people who knew how to read it were gone.
This is worth marking. The architecture of banking-as-a-service makes the middleware’s ledger a single point of failure. That much is structural. What Evolve discovered is that the single point of failure was not just the ledger as a system — it was the ledger plus the institutional knowledge required to interpret it. A proprietary system, built by a specific team, was decoded fluently only by that team. When the team was let go, the system became, for practical purposes, unreadable. The bank holding the funds could not extract from the ledger what it needed to know to release them.
For the more than 100,000 consumers downstream of this architecture, the consequence was concrete. Their fintech apps stopped working. Balances they could see could not be withdrawn. Transactions they had initiated did not complete. Some funds were eventually released as partial reconciliations were achieved; others remain unreleased.
3. The shortfall: three reconstructions of an unrecoverable record
Three official measurements of the shortfall sit on the public record, and they do not converge on a single number.
In its first status report, filed June 6, 2024, the Chapter 11 trustee placed the gap between Synapse’s records and the partner-bank balances between $65 and $95 million. The Consumer Financial Protection Bureau, filing its complaint against Synapse in August 2025, placed the range at $60 to $90 million. FINRA — the Financial Industry Regulatory Authority — identified roughly $92 million in unreconciled funds at one partner bank, by context Evolve. The figures overlap. They do not reconcile.
The disagreement carries information. A shortfall is, by definition, the gap between two records: what the middleware ledger says is owed and what the bank’s records show as present. Stating the gap precisely requires reading both sides cleanly. The bank-side record is institutional, durable, and accessible to examiners. The middleware-side record is the one whose interpretability collapsed when Synapse’s workforce was terminated. The size of the gap is therefore a function of how confidently anyone can reconstruct what the ledger meant — and that confidence is partial, contested, and depends on which fragment of the ledger is being examined.
When the authoritative record fails, the figures that depend on it diverge. The trustee, the CFPB, and FINRA each reconstructed what they could from the fragments available, and each arrived at slightly different answers. None of the reconstructions is wrong. Each is a defensible reading of a state of affairs whose authoritative version is no longer fully recoverable.
A conventional bank insolvency does not produce this kind of measurement problem. In a bank failure, the deposit-allocation records sit inside the failed institution and survive the failure as part of the receivership estate; the FDIC pays out against them. In the Synapse case, those records sat upstream of the bank, in a system whose readers had been let go. The bank’s pooled-account records, on their own, were never designed to identify which end user owned which dollar.
The shortfall remains, on the public record, a range rather than a number. That range is the most precise statement available, because the source of truth that would have settled it cannot now be fully read.
4. Why FDIC pass-through insurance did not apply
When their fintech apps stopped working, many consumers asked whether the FDIC insurance their funds were said to carry had failed. Pass-through coverage operates under a precise mechanism with two preconditions. The mechanism functioned correctly throughout the Synapse failure. The preconditions defined a coverage scope that the Synapse case fell outside of.
4.1 The mechanism of pass-through coverage
In arrangements like the one Synapse mediated, FDIC deposit insurance reaches end users through what is called pass-through coverage. The insurance, normally attached to the bank’s named account holder, can pass through that named holder — the middleware or the fintech — and reach the individual end users underneath. Each end user, in principle, is treated as having their own insured balance up to the standard per-depositor limit, even though the bank’s records show only a single pooled account.
For the mechanism to function, one condition must hold: the records of who owns what must be clear enough to identify each user’s share of the pooled balance. Where those records exist and can be read, the FDIC can determine each end user’s claim and apply the per-depositor limit to it. Where they cannot, the framework loses the input it needs to operate.
4.2 The four partner banks remained solvent
A second condition is structural. What FDIC insurance protects against is the failure of the bank. Had Evolve failed as a bank — had it become insolvent and been placed in FDIC receivership — pass-through protection would have come into play, and end users with valid claims to portions of the pooled deposits would have been covered up to the insurance limit per individual.
Evolve did not fail as a bank. Lineage did not fail. AMG and American did not fail. The four banks holding the pooled funds were operational throughout. What failed was Synapse — the middleware between the consumer and the bank — and FDIC insurance does not extend to the failure of a non-bank entity sitting in that position.
4.3 The architectural gap the regime was not designed to address
Taken together, the two preconditions define the perimeter of what deposit insurance was built to handle. The regime was designed for a world in which the bank holds both the money and the records, and in which the operational risk that matters is the bank itself failing. Inside that world, pass-through coverage extends a clean protection through a named holder to the underlying beneficiaries, because the records establishing those beneficiaries sit inside the institution being insured.
Banking-as-a-service places the records outside the bank. The bank holds the money. A separate, uninsured, non-bank entity holds the records that establish ownership of that money. The operational risk that determines whether end users can access their funds is no longer the bank’s solvency. It is the readability of the upstream ledger and the operational continuity of the entity that maintains it.
Both of those sit outside the perimeter of deposit insurance. The insurance regime functioned correctly within its perimeter; the Synapse case is what it looks like when an architecture grows past that perimeter and the failure mode appears in the territory the regime does not address. It is a governance and risk allocation question — the load-bearing layer is unregulated, and the risk that materializes there falls to the end user.
In operational terms: a solvent bank holding pooled funds could not produce, on demand, the per-end-user allocation it would have needed to release any specific dollar to any specific person. That state held throughout the four partner banks for the duration of the failure event, because the architecture had placed the allocation record outside the institution that held the funds.
5. The regulatory response
By the time the September 2024 FDIC notice of proposed rulemaking was published, four months had passed since Evolve first lost ledger access. The federal response had begun to organize across separate procedural functions, each operating on a different evidentiary standard and timeline. None of them, taken together, resolves the question of fault.
5.1 The FDIC’s September 2024 proposed rulemaking
September 2024 brought the most architecturally precise federal response. The FDIC’s notice of proposed rulemaking identified the structural defect at the center of the case in operational language: banks holding accounts of the kind Synapse intermediated would be required to maintain, in the agency’s own words, direct, continuous, and unrestricted access to the third-party ledger that records beneficial ownership.
The phrasing names what failed. Evolve had been receiving its picture of who owned which funds through a system controlled by a counterparty; when the counterparty cut access, the bank could no longer act. Direct, continuous, and unrestricted access reframes that relationship as a baseline operational condition the bank must be able to assert at any moment, regardless of the upstream entity’s cooperation. A partner bank without that access has not, by the agency’s framing, met the threshold at which pass-through coverage can function.
The proposed rule does not reconcile the existing shortfall. It addresses the architecture under which future accounts will be held.
5.2 CFPB enforcement and the November 2025 Civil Penalty Fund allocation
CFPB action followed in two steps. The August 2025 complaint against Synapse named the company as the responsible party for the failure of consumer access and placed the shortfall in the $60 to $90 million range. The November 2025 allocation drew approximately $46 million from the agency’s Civil Penalty Fund toward compensating Synapse end users.
The Civil Penalty Fund operates as a partial-recovery mechanism. The agency uses it when victims of regulated-entity misconduct cannot be made whole by the entity itself — typically because the entity has failed, dissipated assets, or is otherwise unable to pay. In the Synapse case, the fund was the available instrument because Synapse, as a debtor in Chapter 11 with a contested ledger, could not deliver compensation directly. The $46 million allocation does not match any of the three official shortfall measurements, and it does not constitute a finding that any specific party caused the loss.
End users covered by the allocation receive partial recovery on a timeline shorter than the litigation horizon. End users not covered, and the residual shortfall, remain unresolved.
5.3 Civil litigation as the venue for causation
By Judge Martin Barash’s indication, the question of fault will be resolved through civil litigation; the Synapse Chapter 11 itself will not adjudicate it.
Each forum has different procedural reach. Chapter 11 is structured to administer the failed entity’s estate — to inventory what is there, distribute it according to priority, and close the case. Determining, across the partner banks, fintech programs, and individual officers, whose actions or omissions produced the architectural failure requires discovery against parties beyond the debtor and remedies the bankruptcy estate cannot deliver. Civil litigation is the forum in which those questions can be reached.
What civil litigation cannot deliver quickly is the finding itself. The relevant record sits across multiple parties and includes the very ledger whose interpretability collapsed in May 2024. Reconstructing causation from a record whose authoritative version is partial, contested, and dependent on personnel no longer at the company is what the litigation timeline reflects.
Federal rulemaking and civil adjudication run on different clocks. The FDIC can specify the architecture under which future accounts must be held without waiting for the Synapse causation record to be reconstructed. The civil courts cannot specify what the Synapse parties owe each other without that reconstruction. The forward-looking architectural fix arrives faster than the backward-looking allocation of loss.
6. Structural lessons from the architecture
Beyond Synapse’s specific facts, the case fixes a general property of the banking-as-a-service stack — one with consequences for two roles in the stack: builders who construct or partner across BaaS arrangements, and operators who place operating cash through fintech-app structures.
6.1 What builders should hold load-bearing
For builders evaluating BaaS partnership architectures, the most consequential observation is where the actual single point of failure sits. A natural reading places the bank at the load-bearing position — it holds the money, carries the regulatory weight, and serves as the entity the end user is told to think about. Synapse showed that this reading describes only the steady state.
In failure, the bank is structurally subordinate. It holds funds it cannot act on without input from a layer above it. The middleware company — typically a non-bank, prudentially unregulated software firm — is the layer on which continuous deposit access actually depends. Its solvency, its operational continuity, its workforce retention, and the readability of its proprietary systems are preconditions for the bank functioning as a bank from the end user’s perspective.
A partnership architecture that does not treat the middleware as load-bearing on par with the bank misprices its own risk. Several responses are now visible in BaaS arrangements signed since the failure: the FDIC’s proposed direct-and-continuous-access requirement; ledger escrow provisions that grant the partner bank a parallel copy of the beneficial-ownership record on a defined cadence; source-code escrow for the proprietary ledger system; and key-personnel retention arrangements specifically designed to preserve interpretability if the middleware fails. The structural premise underneath all of them: a deposit relationship is hardened only when the upstream ledger and its readers are hardened together with the bank below them.
6.2 Diligence for fintech-app placements of operating cash
For corporate operators considering fintech-app placements, the relevant counterparty extends past the bank named on the FDIC disclosure. The counterparty whose continuity actually governs access is the entity whose ledger establishes the corporate’s claim to the pooled balance — upstream of the bank, frequently invisible in the user experience, and not always named in the marketing materials.
Three diligence questions, framed at the operational layer of corporate finance, recover the part of the placement the disclosure does not describe. Which legal entity holds the FBO account at the bank? Which legal entity maintains the ledger that records the corporate’s specific claim against that pooled account? What continuity arrangements govern that ledger if the maintaining entity ceases to operate — does the partner bank hold a parallel copy with direct access, is the ledger code in escrow, are key-personnel retention provisions in place? In an arrangement where the fintech, middleware, and bank are separate parties, these questions may point to separate counterparties, and the operational risk lives with the weakest of them.
The “FDIC insured” disclosure on the fintech app describes a precise property: the underlying bank account into which pooled funds flow is held at an FDIC-insured institution, and those funds are eligible for pass-through coverage if the bank fails and if the per-end-user records are clear enough to identify each individual claim. Read affirmatively, the disclosure covers the bank-failure state. The middleware-failure state — solvent bank, unreadable upstream ledger — sits outside that scope.
A control-grade reading turns on operational continuity, not on the bank-failure state alone. Direct bank-side access to the ledger; readability if the middleware company is no longer operating; contractual or escrow arrangements that preserve continuity in either failure case — until each of these is answered for a given placement, the placement is exposed to a failure mode that deposit insurance was not built to address, regardless of how prominently the FDIC logo appears on the screen.
Closing
For more than 100,000 people, the experience of the failure was the same: balances visible in their fintech apps that could not be moved, while the underlying partner banks remained solvent. The cause was the failure of the middleware ledger and its institutional readability — the layer of the architecture that established who owned which portion of the pooled deposits. That layer is now on the federal regulatory record as a structural defect to be closed by future rulemaking, while the question of fault for the existing shortfall is being routed separately, to civil courts, on a longer timeline.
An audio version of this analysis is available on YouTube:
The Synapse Collapse: When the Bank Has Your Money but Can’t Give It Back.
Sources
This article relies on public regulatory, court, and agency materials related to the Synapse Financial Technologies bankruptcy and the federal response to custodial deposit account recordkeeping.
- FDIC, Notice of Proposed Rulemaking on Recordkeeping for Custodial Accounts, published in the Federal Register on October 2, 2024.
- FDIC Board Memorandum, Notice of Proposed Rulemaking on Custodial Deposit Accounts with Transaction Features and Prompt Payment of Deposit Insurance to Depositors, September 17, 2024.
- In re Synapse Financial Technologies, Inc., Chapter 11 Trustee status reports, U.S. Bankruptcy Court for the Central District of California.
- CFPB enforcement action: Synapse Financial Technologies, Inc., complaint filed August 21, 2025, with stipulated final judgment entered September 12, 2025.
- CFPB Civil Penalty Fund allocation records, including the November 28, 2025 allocation for Synapse Financial Technologies, Inc.