Neobanks spend a lot of time on growth loops and product velocity. That makes sense because distribution is hard and switching costs are real. But the failure mode that quietly limits scale is rarely product related. It is what operators sometimes call ledger drift — the moment when balances stop matching across the sponsor bank, the processor, and the neobank’s internal ledger.
It rarely starts as a crisis. It starts as a few mismatches that “should reconcile next week.” Then volume grows, new rails get added, partner reporting shifts, disputes spike, and the mismatch becomes structural. At that point, the finance team is not doing analysis. They are doing archaeology.
What makes this so stubborn is that neobanks are modular by design. One set of systems is built to be fast and customer-facing. Another set is built to be regulated, auditable, and conservative. Then there is the operational layer in between: settlement files, return codes, dispute workflows, and adjustments that arrive days or weeks after the original transaction. If you do not model those lifecycles cleanly, it is easy to have three truths that look reasonable in isolation.
The Synapse lesson
There is a real-world reason the industry has been forced to talk about this. During the Synapse collapse, Yale Journal reported that more than 100,000 people lost access to over $265 million across several fintech platforms. Bloomberg reported roughly $200 million in consumer funds frozen during the bankruptcy process. Later, the CFPB alleged that partner banks determined the funds they held for consumers were less than the amounts reflected in Synapse’s records, describing a shortfall of roughly $60 million to $90 million, and noting consumers lacked access for weeks or months while records were reconciled.
You do not need a bankruptcy to experience ledger drift, but that episode makes the abstract risk concrete. When records do not match, everything slows down. When everything slows down, customers feel it first.
The close-time tax
Drift also shows up in a more mundane way: close time. There is a lot of talk about the “three-day close,” but the reality is that most finance teams are not there. A 2025 benchmark survey summarized by CFO.com found 18% of teams close in 1 to 3 business days, 32% in 4 to 5, 23% in 6 to 7, and 27% take more than 7 business days. That is not a neobank-only statistic, but it tells you something important: exception resolution dominates the calendar even in companies that are not juggling sponsor bank records, processor records, and multi-rail money movement.
So where does drift come from in practice?
Cards
Card transactions are not a single event. They are a lifecycle. Authorization is real-time. Settlement comes later. Refunds and reversals come later. Disputes come later still. Visa publishes an entire dispute management guide because the process is detailed and procedural, and small operational misses turn into losses and mismatches. There is also the customer dispute window itself. Visa dispute rule documentation includes examples that reference “a 120-day dispute window for certain dispute conditions,” meaning activity can return long after a transaction feels operationally final.
ACH
ACH is the second culprit, mostly because it has delayed failure modes. Returns and corrections arrive later, and they are governed by thresholds that can become compliance issues. Nacha’s rules establish “an unauthorized return rate threshold of 0.5%” and define which return reason codes are included. Nacha also sets “an administrative return rate threshold of 3.0%.” Additionally, it sets “an overall return rate level of 15.0%,” noting that this is far above the historical industry average of about 1.42% in 2013, signaling how excessive returns are treated as quality concerns rather than normal variation. Even if you never hit those thresholds, the operational point matters: ACH introduces a class of breaks that arrive after initial posting, and those breaks must be explainable and traceable.
This is where mature teams behave differently
The goal is not to reconcile everything perfectly on day one. The goal is to build a control loop that prevents small mismatches from becoming a permanent part of the business.
The simplest version looks like this:
- You reconcile daily, not monthly.
- You treat each rail as a lifecycle, not a single row in a report.
- You separate matching from explaining, because matching only tells you what does not align, while explaining tells you why and what to do next.
- You treat exceptions like an operational queue with owners and reason codes, not a spreadsheet tab that grows forever.
If you want a single sanity test, do the “one customer, one timestamp” drill. Pick a user, pick a point in time, and prove you can compute their balance from auditable events, even when external systems disagree. If you can do that reliably, you can scale. If you cannot, drift will eventually show up as support tickets, delayed close, and sponsor bank escalations.
Methodology and Sources: This note is based on desk research and synthesis of public materials, focused on repeat operational patterns rather than any single company’s internals. Sources include public reporting and analysis of the Synapse collapse and its impacts, Visa dispute guidance and dispute rule documentation, Nacha return rate thresholds and calculation guidance for unauthorized, administrative, and overall return rates, and month-end close benchmark survey results summarized by CFO.com.