Key takeaways
- A unified interface does not mean every balance has the same protection.
- Show the holding entity, asset type and protection status at each decision point.
- Deposit guarantees apply to eligible bank deposits, not every balance in an app.
- Explain volatility and collateral liquidation before users take out crypto-backed loans.
- Measure informed choices and support demand, not just tooltip clicks.
The acquisition makes a design problem concrete
On October 14, 2026, Payward signed a definitive agreement to acquire Saldo Bank, an EU-licensed bank subsidiary. The deal remains subject to regulatory approvals and is expected to close in 2027, so it does not create a combined customer product today. It does make the next product-design problem visible: one interface can bring banking, crypto custody and lending closer together without making their protections equivalent.
The mistake is easy to make. A customer sees one total balance, one logo and one navigation system. They infer one safety net. Product teams know the reality is more conditional. The service entity, asset classification, account terms, jurisdiction and customer action can all change what the balance is and what happens if something goes wrong.
A balance screen can conceal four contracts
A well-designed balance view distinguishes at least four different relationships. An eligible cash deposit at a participating bank can fall within a deposit-guarantee scheme. Custodied crypto is not a bank deposit. A tokenised security may sit under existing financial-services rules rather than MiCA, as the Joint ESAs consumer factsheet explains. A loan against crypto collateral creates a separate agreement, with interest, collateral thresholds and a possible forced sale if the terms are breached.
Not all crypto-assets are the same.
MiCA is not a blanket guarantee. In their October 2025 consumer warning, the European Supervisory Authorities stressed that legal protection can be limited depending on the crypto-asset and service involved. Crypto deposit protection is therefore not a property of the app. It is a property of a specific eligible deposit relationship.
Risk concentrates at the transitions
The highest-risk moments are not necessarily when people browse an education centre. They are when the product changes the nature of a customer’s exposure. Bank crypto app risk education should appear at those transitions:
- When a user moves money from a deposit account to a trading or payment balance.
- Before a first crypto purchase, when volatility and custody become relevant.
- Before borrowing against crypto, when a price fall can affect collateral and liquidation risk.
- Before buying a tokenised investment, when the governing legal regime and rights may differ.
Learning must interrupt the right second
This is embedded fintech education, not a library of explainers hidden in settings. The prompt should state what is changing, name the responsible legal entity, explain the consequence in plain language and let the user test one essential point before continuing. A comprehension check is a guardrail, not a ritual for manufacturing consent.
- Use a persistent balance label that names the asset and service type.
- Open a short, contextual explanation when the user switches products or transfers funds.
- Show a realistic outcome scenario drawn from the relevant product terms.
- Ask one recall question that tests the risk the user is about to accept.
- Route users to the correct terms, support path and local-language detail when needed.
Good to know
Does one app mean all balances have the same protection?
No. Protection follows the legal product and service entity, not the visual wallet. Under the EU deposit-guarantee framework, eligible deposits can be protected up to €100,000 when a bank fails, while crypto-assets and investments need separate risk treatment.
Does MiCA make crypto holdings insured deposits?
Not automatically. The European Supervisory Authorities’ warning makes clear that consumer protection can be limited depending on the crypto-asset and service used.
Should a comprehension check block every transaction?
No. Use it for material transitions where misunderstanding changes the customer’s exposure. If a user struggles, provide a plain-language explanation and a clear route to help rather than adding friction without guidance.
Content becomes operating infrastructure
MiCA customer education cannot live in isolated campaign copy. Teams need a maintained content model that maps balance type, legal entity, jurisdiction, protection status, key loss mechanism, required disclosure and escalation route. That model can then power mobile prompts, web journeys, help content and support tooling without creating conflicting versions. Localization must adapt legal context and examples, not merely translate words.
Measure more than impressions and tooltip clicks. Track whether users can identify the protection attached to their selected balance, whether they change course after a collateral-risk explanation, which transitions create support contacts and where knowledge gaps vary by market. For product teams, a reusable and brand-controlled learning layer reduces repeated explanation work while producing evidence about where the journey still fails.
Build decision-point learning into your financial product.
PlanTrust needs product-level precision
As banking and crypto services converge, the shared interface is where customer understanding can break first. The answer is not a longer generic disclaimer. It is precise education at the moment a user moves from one legal and economic reality into another. That discipline protects customers, gives compliance teams a clearer implementation surface and helps growth teams build activation on understanding rather than assumption.
