If you look closely at any modern fintech, it is not one thing. It is a stack of other companies' infrastructure, assembled. The wallet is embedded from a wallet engine. The on-ramp and off-ramp come from a payments provider. Custody might sit with a regulated custodian. The card is issued through a card-issuing platform. The fintech's own product is the layer on top — the brand, the user experience, the distribution. Most of what makes it work underneath is bought, not built.
That is not a weakness, it is how the industry is supposed to work now. Nobody rebuilds card issuing or custody from scratch. You integrate a layer that already does it well and you focus on your users. Which raises a useful question for anyone trying to get on-chain financial products into the hands of fintechs. Do you integrate each fintech one at a time, or do you put yourself inside one of the layers they are already using?
The slow way and the fast way
The slow way is app by app. You sign a fintech, you integrate, you go live, you start again with the next one. Every customer is a fresh integration and a fresh sales cycle. It works, but it scales linearly. One deal, one app.
The fast way is to white-label the financial product into an infrastructure layer that already sits underneath a lot of apps. An embedded-wallet engine that powers hundreds of fintechs. A custodian that secures assets for many platforms. A payments or card provider with a large downstream base. Integrate once into that layer, and the on-chain capability becomes available to everything built on top of it. One integration, a whole network of apps.
That is the difference between selling to apps and being inside the thing the apps are already built from. The second one compounds. Each infrastructure partner you integrate is not one customer — it is a doorway to their entire downstream base.
How it actually fits
The piece that makes this clean is that an on-chain financial layer is non-custodial. It prepares the transaction, the user's signer authorises it, the assets never move through the financial layer or the infrastructure partner. So sitting inside an embedded-wallet engine, a custodian's stack, or a payment provider's rails does not mean taking custody of anyone's funds. It means adding a capability — the ability to offer yield, lending, swaps, or tokenised assets — to a layer that already handles the wallet, the ramp, or the card.
For the fintech at the top, nothing about their architecture has to change. The DeFi capability shows up inside infrastructure they already use. They did not run a new procurement process or take on a new integration. The layer they were already standing on quietly grew a new set of products.
Why this is the right shape for on-chain
On-chain financial products are exactly the kind of thing that should arrive this way. They are hard to build, most fintechs do not want to build them, and they are not anyone's core differentiator. That is the textbook case for an infrastructure layer. The fintech wants the outcome — a user who can earn yield or borrow against their assets — without the months of specialised engineering it would take to build it directly.
We have seen both shapes in practice: a wallet adding yield directly for its users (THORWallet), and an agent platform putting a governed borrow flow on top of the same rails (Sly). Distribution through infrastructure is how that outcome reaches the most apps with the least friction. Not a louder sales motion — a structurally more efficient one. You meet fintechs inside the stack they have already chosen, and the capability spreads with the layer rather than one deal at a time.
If you run an infrastructure layer and want to add on-chain financial products to it, or you are a fintech wondering how this would reach you, email us at contact@compasslabs.ai.
Compass does not control DeFi protocols or smart contracts. Using DeFi protocols involves risk, including potential loss of funds. This is not investment advice.