Fast market entry via a partner or a modular platform without a sharp client offering: how banks avoid both mistakes and develop their digital asset offering from the client's perspective.
When building a digital asset offering, two common mistakes need to be avoided: either the focus is on a fast go-to-market – creating strong dependencies on partners for product development, the business model and the roll-out of further use cases. Or the platform is built out modularly – and the clients and their requirements are lost from sight.
Working with a partner makes it possible to enter the market quickly and reach your own clients early. However, client-centric product design, a viable business model and foresight for future expansion often fall short. Speed bought through a partner comes at the price of dependency.
Which products and services can be offered in the future, which prices can be charged and which use cases are covered then depends largely on the partner. The quick start turns into a long-term constraint.
A modular platform is planned and designed for as many digital assets and use cases as possible – and the requirements of the initial offering are lost from sight.
Which clients should be addressed first? Which concrete client benefit should be delivered? How will clients be reached? A platform can be well thought out and designed for expansion and still fail to deliver a compelling offering to clients. It is then built purely for the future, without a first viable business model.
The entry point can be, for example, a trading offering for crypto-assets such as Bitcoin (BTC) and Ethereum (ETH), a payment and settlement solution for the tokenised cash leg, or an offering of tokenised securities.
What matters is not what is technically available, but which clients the offering is meant to reach, which need it serves and why exactly these clients should use it. This determines product scope, pricing and distribution – as well as the business case: expected usage, revenues and client retention set against build and running costs.
A comprehensive platform is usually not needed at the start. What matters is a conscious decision on which capabilities must be built for the first offering and which further use cases they should support in the future.
Processes, interfaces, data processing and controls should be built for reuse where this makes sense. Some new use cases require dedicated solutions: infrastructure for crypto trading, for instance, cannot be transferred 1:1 to trading in tokenised securities.
Beyond choosing a partner, it is important to clearly define the form of collaboration: which tasks are handled in-house and which by the partner? Who designs the product, who manages the client relationship, who sets the prices? And how can further offerings and services be integrated later?
Not every bank needs to run trading and custody itself. But at the outset it must be clearly defined which capabilities are needed and built internally, and which decisions and controls the bank wants to steer itself.
FinPlanet works with banks to develop a shared target picture for offering, partners and operations. We align the first use case with client benefit and economic viability while planning the building blocks for further expansion. This way, neither the partner solution available in the short term nor the technically conceivable platform alone determines the strategy.
