Cash Flow Infrastructure Is a Platform Decision

You built a balance display for your dashboard. Clean, simple. Pull the balance from Plaid, show it to the customer. It took a week.

Then the fraud team needed the same data. They built their own Plaid call with a different caching layer. Then underwriting needed a 90-day cash flow summary. They built a batch job that computed it nightly. Then the spend controls feature needed a real-time available balance to approve or decline card transactions. A fourth engineer built a fourth integration.

Four teams, four balance checks. You have four slightly different answers to "how much money does this customer have?"

The obvious fix is to share the Plaid connection. Set up a shared service and let everyone read from it. But sharing a connection isn't sharing an interpretation. "Available balance" means something different to the fraud team (total minus suspected holds) than to spend controls (total minus pending transactions minus reserves) than to the dashboard (whatever Plaid returns).

Cash flow starts as a feature. It becomes infrastructure the moment more than one product depends on the answer.

When features fracture

You won't notice the problem in a unit test. Each system is internally correct. The dashboard shows $47,000 in the checking account. The fraud system checked the balance three hours ago and has $48,200 because it hasn't seen the wire that settled at noon. Underwriting computed a 90-day average income that the analytics team also computed, using a different window boundary, and got a different number.

It's like three family members each keeping their own mental tally of the joint checking account. Mom subtracted the grocery run. Dad hasn't recorded this morning's gas fill-up. The teenager thinks there's more than there is because they forgot about the streaming subscription. Nobody's wrong from their own side. The checking account has one balance, but nobody agrees on it.

The consistency bugs surface at the worst moments. A customer sees $47,000 on the dashboard, tries to send a $45,000 wire, and gets declined because the fraud system's stale balance triggered a velocity alert. Or underwriting approves a credit line based on a balance computation that doesn't match what the product shows. The customer calls support and hears a different number from each person.

Three signals

How do you know when cash flow has outgrown the feature stage?

First, multiple teams query the same bank data for different purposes, and their answers diverge. Not because the data changed, but because their computation windows, caching layers, or balance definitions differ. Two teams independently implementing "average monthly income" and getting different numbers from the same transactions is the clearest symptom.

Second, you're computing "available balance" in more than one place. Available balance is total balance minus pending holds, pending outgoing transactions, and reserved amounts. If two systems each implement this subtraction differently, your customer has two available balances. One of them is wrong at any given moment.

Third, a product feature starts making authorization decisions. When your spend controls use cash flow data to approve or decline a transaction, cash flow becomes a decision system, and decision systems need one answer, not four.

What infrastructure looks like

Promoting cash flow from feature to infrastructure means building a single system of record that every product draws from. The system needs four properties.

A ledger-backed balance. Not a column in a users table that gets incremented and decremented. A proper double-entry ledger where every movement is recorded as a debit from one account and a credit to another. The balance is derived from the movements, never stored directly. When the fraud team and the dashboard team both query the ledger, they get the same number because they're reading the same journal entries.

Real-time updates. Batch balance pulls worked when cash flow was a dashboard display. They don't work when cash flow is a fraud input. If a $45,000 wire settles at 2:00 PM and your balance refreshes at midnight, every downstream system is wrong for ten hours. Real-time event streams, whether webhooks from your banking partner or direct ledger events if you run your own, close this gap.

Multi-rail awareness. A customer's cash position spans multiple payment rails. An ACH deposit takes one or two business days to settle. An RTP payment settles in seconds. A wire settles same-day. A card authorization holds funds without moving them, sometimes for days. Cash flow infrastructure needs to understand each rail's settlement timing to compute what the customer can actually spend, not just what the ledger shows as posted.

Canonical categorization. Transaction categorization, whether a deposit is payroll, revenue, a transfer from another account, or a refund, needs to happen once and propagate everywhere. When underwriting classifies a recurring deposit as "income" and spend insights calls the same deposit "internal transfer," both products give conflicting answers about the customer's financial health. One categorization engine, one classification per transaction, consumed by every product on the platform.

Build, buy, or bridge

You have three architectures, and each has a cost.

Build the ledger yourself. This is what companies do when cash flow is the core product. You own the data model, the settlement logic, the balance computation. You can define "available balance" exactly once, in code you control. The cost is months of engineering time from a team that understands double-entry bookkeeping, funds reservation, and multi-rail settlement. If you don't have that team, you're building the system that earns or loses your customers' trust with engineers who are learning on the job.

Buy a platform. Stripe Treasury gives you embedded accounts with ACH and wire transfers through an API. Modern Treasury handles payment operations, ledgers, and reconciliation. You ship in weeks instead of quarters. The cost is abstraction. Your balances live inside someone else's data model. When a customer asks why their available balance doesn't match their posted balance, you explain a reservation model you didn't design. And if the platform's settlement timing doesn't match your product's expectations, you build workarounds on top of the abstraction that was supposed to eliminate workarounds.

Bridge from feature to infrastructure. Keep your existing bank connections but centralize the interpretation layer. One service computes balances, categorizes transactions, and exposes cash flow data to every team through an internal API. The bank integrations stay in place. The computation logic moves from scattered product code to a shared service. This is the most common path because it doesn't require replacing what already works. The cost is that you're building infrastructure on top of someone else's data, and your balance is always a derived view, not a ledger of record.

Ramp chose bridge-then-buy. It acquired Vesto, which had direct integrations to JPMorgan Access, Bank of America CashPro, CitiDirect, and Wells Fargo Vantage across 12,000 financial institutions. Instead of building bank connectivity from scratch, Ramp bought a company that had spent three years building it. Then it applied for a trust charter to own the custodial layer. Connectivity first, then ownership.

Plaid chose to sell the bridge. Its Cash Flow Insights product aggregates transaction data across permissioned accounts and exposes over 2,500 attributes for income, expenses, and balance patterns. Plaid is the interpretation layer that fintechs buy instead of building. The limitation is that you don't control when Plaid refreshes the data or how it categorizes edge cases.

The reservation problem

The hardest part of cash flow infrastructure is the gap between the balance and what the customer can actually spend.

When you authorize a $500 card transaction, you need to hold $500 against the customer's available balance without moving any money. If you don't hold it, a second $500 transaction passes the balance check before the first one settles. You've approved $1,000 against a $900 balance.

This is funds reservation. Two balances emerge: total (everything the customer owns) and available (total minus holds and pending outflows). Every system that makes a spending decision must check the available balance, not the total.

The subtle part is that the final settlement amount might differ from the hold. A restaurant pre-authorizes $50 but the bill is $63 with tip. A gas station holds $100 but the fill costs $37. The reservation must eventually resolve, settled at the final amount or released. An orphaned reservation that's never settled or released locks the customer's funds permanently.

If each team manages its own reservations, you get double-holds, phantom-locked balances, and customer complaints that don't map to any single bug. Centralized reservation management is the clearest sign that cash flow has crossed from feature to infrastructure.

When to make the call

The worst time to centralize cash flow is during an incident. A customer overdraft from stale balance data, a fraud miss from inconsistent categorization, or a credit loss from a balance computation error will force the migration under pressure and time constraints.

The right time is when you notice the second signal: two systems computing available balance independently. At that point the consistency bugs are still small enough to fix proactively and large enough to justify the investment.

Most companies reach this inflection point when they add their second cash-flow-dependent product. The first product can own its own balance check. The second one forces the question: do we build another copy, or do we build the layer?

The second product always costs more than the platform would have.