05 — Finance inside another product
Accounts, payments and credit surfaced inside a non-financial product, so the user never leaves and the economics stay yours.
The technical problem in embedded finance is small. The product problem is that financial capability inside a marketplace, a payroll tool or a logistics platform has to disappear — no separate login, no interruption, no vocabulary the user has to learn.
That constraint drives the architecture. Identity is inherited rather than re-collected. Money movement is described in the host product's language. Failure states resolve inside the host product's flow rather than handing the user to a bank's error page.
Common questions
Do embedded finance users need to complete separate KYC?
Usually some, but far less than a standalone product if identity is designed to be inherited. Data the host already holds and has the right to share can satisfy part of the requirement, with additional checks triggered progressively by activity and value rather than collected up front.
Where does the margin in embedded finance come from?
Interchange, spread on payments and FX, float where the regulatory model permits it, and lending. The mix determines the architecture: a programme built for interchange looks materially different to one built for deposit economics, and retrofitting one into the other is expensive.
How much regulatory exposure does the host product take on?
It depends on the model. As an agent or distributor of a licensed institution, exposure is contractual and operational rather than prudential. Holding funds or making credit decisions directly changes that. The model should be chosen deliberately, with counsel, before the build rather than after.
Next capability
Crypto exchanges
Bring us the hard part.
Forty-five minutes with the people who would actually run the build.