Stripe Connect: Fund Segregation with Allocated Balances
Problem + constraints
Marketplaces using Stripe Connect's "separate charges and transfers" flow charge the customer on the platform's own Stripe account, then transfer a portion of that payment out to a connected seller. Until that transfer happens, the seller's money sits inside the platform's general balance — operationally convenient, but a correctness and compliance problem: nothing in a plain balance number distinguishes "funds passing through on their way to a seller" from "funds that belong to the platform." Nothing structurally prevents that money from being used for unrelated platform expenses or counted against the platform's own liabilities while it waits. Regulation is closing that gap explicitly: the EU's incoming PSD3 rules, building on existing PSD2/safeguarding obligations, push platforms toward demonstrably segregating customer and seller funds from their own operating funds — not just asserting it in a policy doc, but having an architecture that can prove it.
Solution
Stripe added an allocated balance concept to Connect. Funds from a separate-charge-and-transfer payment can be placed into a protected holding state tied to that specific payment, rather than landing in the platform's general spendable balance. Allocated funds don't show up as usable platform balance, are visible and traceable per payment, and can only move to the connected account they're earmarked for (or back out via refund/dispute). Just as important, the exception paths are re-ordered around that boundary: refunds and disputes against a payment first draw down from that payment's own allocated funds, and only reach into the platform's general balance if the allocated funds run short. That ordering is what makes the segregation real in practice rather than a label — the "dip into general funds" path is a last resort, not something silently used by default.
What to steal
- Model "funds in transit to someone else" as its own distinct ledger state, not just a number inside a bigger balance — tie the hold to the specific transaction rather than pooling it into an account-level bucket, so provenance is traceable per unit of money instead of blended.
- Design exception paths (refunds, disputes, chargebacks) to draw from the segregated pool first and the general pool second. Segregation that only holds on the happy path isn't segregation — it's an illusion that breaks exactly when regulators or auditors look at the edge cases.
- Build the compliance boundary into the data model ahead of the regulation landing, not after. Retrofitting fund segregation onto a system where money has always pooled into one balance is a materially bigger migration than designing the holding state in from the start.
Engineering Lens
This is directly Fintech/Capital-Markets territory: "money you're holding on someone else's behalf must be provably separate from your own" is the same problem underneath custodial brokerage accounts, escrow services, and client-money rules generally — the specific regulation changes (PSD3 here, but the UK's client money rules and SEC customer protection rules are the same shape elsewhere), but the architectural answer is consistent. Regulators increasingly want more than an audit trail after the fact; they want it structurally impossible to spend someone else's money by mistake. Being able to reason precisely about "which ledger state is this dollar in, and what's allowed to happen to it from here" is core Principal-level judgment in any payments-adjacent system, and it's a much stronger position to walk into an architecture review with than retrofitting the answer once an auditor asks the question.