In 2024 a banking-middleware company called Synapse collapsed, and more than a hundred thousand people were locked out of their own deposits for months. Picture one of them: rent due, a balance they can see on a screen and cannot touch, and nobody able to tell them when that changes, because the companies, the partner banks, and the middleware were all busy arguing about whose ledger was right. Multiply that person by a hundred thousand, add a shortfall running into the tens of millions, and you have the lesson embedded finance learned the hard way. Nobody who built on top of those rails had written "the pipes I rented might freeze my customers' money" into their risk register, and that omission is what this whole build-versus-buy question is actually about.
Here is the plain version. Embedded finance is how a product that is not a bank gets to offer bank-like things: accounts, cards, payouts, holding balances. You do it by renting the underlying rails from a partner bank, usually through a middleware layer that makes the integration bearable. The appeal is obvious, you ship a financial product without becoming a chartered bank. The catch is equally real, and it is that you have taken on a dependency whose failure becomes your customer's frozen balance, and that dependency does not show up anywhere in a demo.
What you are actually renting
When you buy banking-as-a-service, you are renting three different things that people tend to lump together: the regulatory permission to move money, the technical rails that move it, and the compliance machinery that keeps it legal.
Building your own means pursuing money-transmitter licensing or a bank partnership directly, standing up the ledger and the payment integrations yourself, and owning compliance end to end, which in practice starts with KYC and AML onboarding and the audit trail underneath it. It is slow, expensive, and it is also yours, which means no one else's collapse can take it down. Riding a partner is fast and cheaper to start, and it means your product now lives or dies partly on a company you do not control and cannot audit from the inside.
The honest way to choose is to look at where the money actually moves and how much of your business depends on it. If payments are a convenience feature at the edge of your product, renting rails is almost always right, and a mature payout layer like the ones built on Stripe Connect will carry a marketplace's payments cleanly without you reinventing any of it. We have built exactly that, the Connect-based payouts and bank transfers underneath a two-sided marketplace, and for that shape buying is the correct call. If moving and holding money is the product, the calculus shifts, because then the partner's risk is your core risk and the case for owning more of the stack gets stronger the bigger you get.
Score your own product against that logic:
The risk that isn't in the demo
Whichever way you go, the discipline does not change: the money-movement correctness has to be right, and if you are renting it you have to verify the provider actually does it rather than assuming. The idempotency that stops a double payout, the reconciliation that proves the partner's numbers match yours, the audit trail that survives a dispute, these are not things you get to skip because a vendor is involved. In fact the partner model makes reconciliation more important, not less, because now you are reconciling against a third party whose ledger is the one a court will look at if things go wrong. The same payments discipline you would build yourself is the checklist you hold a provider to.
And it does not take a full collapse to hurt you. Teams have watched a live, healthy processor freeze their payouts for weeks over a false-positive name match in a routine compliance review, with no real explanation and no date for when the money comes back, because when the rails are rented someone else's risk model holds a veto over your cash flow.
Counterparty risk is invisible until the day it is the only thing that matters.
The regulators drew their own conclusion from Synapse. In October 2024 the FDIC proposed a recordkeeping rule for custodial deposit accounts, tying it directly to the months customers spent locked out: banks holding these accounts would have to keep each end user's identity and attributed balance in a standardized format, validated annually by an independent party. As of mid-2026 it remains proposed rather than final, but the direction is the point, because the recordkeeping burden it would formalize is exactly the ledger discipline this article tells you to keep in-house whichever way you build. The right time to think about what happens if your provider goes down is before you have a million customers whose balances depend on the answer.
What's still standing in 2028
Embedded finance is not going away, more products will move money every year, and most of them should rent rather than build. What changes by 2028 is that the survivors are the ones who priced the counterparty risk in honestly. The product that knew exactly what it owned, what it rented, and what its plan was if the rented part failed is the one still standing.
FAQ
What is embedded finance? Embedded finance is how a product that is not a bank gets to offer bank-like things: accounts, cards, payouts, and holding balances. You rent the underlying rails from a partner bank, usually through a middleware layer, so you can ship a financial product without becoming a chartered bank yourself.
What is banking-as-a-service? Banking-as-a-service is the rented version of three things teams tend to lump together: the regulatory permission to move money, the technical rails that move it, and the compliance machinery that keeps it legal. Building instead means pursuing licensing or a bank partnership directly and owning all three.
Should you build or buy your banking stack? Look at where the money actually moves. If payments are a convenience feature at the edge of your product, renting rails is almost always right. If moving and holding money is the product, the partner's risk becomes your core risk, and the case for owning more of the stack grows as you do.
What is counterparty risk in embedded finance? It is the risk that a provider you do not control, and cannot audit from the inside, fails in a way that becomes your customers' frozen balance. Teams underweight it systematically because it stays invisible right up until the day it is the only thing that matters.
What did the Synapse collapse teach embedded finance? When that banking middleware collapsed in 2024, more than a hundred thousand people were locked out of their own deposits for months while the companies, the partner banks, and the middleware argued about whose ledger was right. Almost nobody had written that risk into their register beforehand.
Do you still need reconciliation if you rent the rails? More than ever. Renting means reconciling against a third party whose ledger is the one a court looks at if things go wrong. The idempotency that stops a double payout, the reconciliation that proves the numbers match, and the audit trail that survives a dispute are not skippable because a vendor is involved.
What 2muchcoffee covers
We help teams make the embedded-finance build-versus-buy call and then build whichever side they chose correctly, the integration if they rent, the rails and the licensing-aware architecture if they build, and the reconciliation and audit discipline either way. If you are about to rent a banking stack and have not fully thought through what happens when it fails, that is the conversation worth having first. The plain way in is the AI and engineering work we do.
One concrete action
Write down, in one sentence, what happens to your customers' money if your payment or banking provider goes offline for a month. If you cannot answer it, that is the part of building fintech software to resolve before you scale, because the answer is much cheaper to design now than to discover during someone else's collapse.
