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, with a shortfall running into the tens of millions, while the companies, the partner banks, and the middleware all argued about whose ledger was right. Nobody who built on top of it had written "the rails I rented might freeze my customers' money" into their risk register. That is the lesson embedded finance learned the hard way, and it changed how the build-versus-buy question should be answered.
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. 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. The counterparty risk is the part teams systematically underweight because it is invisible until the day it is the only thing that matters. 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 rather than treating the rented rails as if they were free of it. The thin integration that assumes the partner is permanent is the one that gets caught out. 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.
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.
