How to launch a digital bank with built-in crypto

Launching a digital bank used to mean years of engineering before the first customer could open an account. With mature white-label platforms the technology is no longer the bottleneck — but a successful launch still depends on decisions that software cannot make for you: what you sell, under which licenses, on whose rails, and with which controls.

This guide walks through the sequence we see work in practice, for a product that combines fiat accounts and cards with self-custody crypto wallets.

Step 1 — Define the product before the technology

Every downstream decision — licensing, providers, configuration — follows from a small set of product choices. Write them down before evaluating any vendor:

• Customer segments: individuals, companies, or both? Which countries at launch, and which are explicitly excluded?
• Account tiers: what does an unverified user get, if anything? What do full KYC and corporate tiers unlock?
• Currencies and rails: which fiat currencies do accounts hold, and which transfer types (local and international) must work at launch?
• Chains and assets: which blockchain networks and stablecoins does your market actually use? Support for a dozen chains matters less than the right three for your corridor.
• Monetization: which operations carry fees, what is free, and where do referrals or paid tiers fit?

Step 2 — Choose your regulatory path

The technology vendor supplies software; the regulated activity is yours. Broadly, operators take one of two paths. The first is obtaining authorizations directly — for example an EMI or payment institution license, plus a crypto-asset service provider registration such as a MiCA CASP in the EU or a VARA license in Dubai, depending on jurisdiction and product scope. The second is operating with licensed partner institutions while you build volume, then migrating to your own licenses later.

Neither path is universally better. Direct licensing gives you control and margin at the cost of time and capital requirements; partnering compresses time-to-market at the cost of dependency and revenue share. What matters for planning: in almost every real project, licensing — not technology — sets the critical path. Start the regulatory work before, not after, choosing a platform.

Step 3 — Decide how your infrastructure runs

For a regulated financial product, how the software is deployed matters as much as what it does. A dedicated instance per operator — your own database, your own encrypted secrets, your own domain — gives you clean data isolation, a clear audit story for regulators, and an exit path that does not depend on extracting your data from a shared system.

Key custody deserves particular scrutiny: encryption secrets and JWT keys should be unique to your deployment and live in a managed key service such as AWS KMS, outside both the codebase and the database. Treasury wallets should sit behind multisig. If a vendor cannot explain where your keys live and who can touch them, keep looking.

Step 4 — Connect fiat rails and cards through providers

Fiat accounts, transfers and card programs run on agreements with regulated providers — banking-as-a-service partners, card issuers, payment processors. You hold the commercial agreements; the platform integrates them. Two things determine how fast this goes: whether the platform has already integrated your providers, and how quickly you obtain production credentials.

With providers a platform has already worked with, integration is configuration: you are operational as soon as your production keys are active. For a provider the platform has not met before, a reasonable expectation with a well-abstracted provider layer is about a week from sandbox keys to production readiness. Budget the provider onboarding itself — the commercial and compliance process on the provider side — as its own workstream, because it is usually slower than the technical work.

Step 5 — Get the crypto architecture right

Crypto is where technical shortcuts become existential risks. The non-negotiables for a bank-grade deployment:

• Self-custody wallets generated per user, with private keys encrypted using secrets that belong to you, the operator — held in a managed key service, never in code or database.
• Coverage of the chains your market uses, with major stablecoins (USDT, USDC) available where the network supports them.
• Treasury and master wallets protected by multisig, so no single person or server can move pooled funds.
• Withdrawal address whitelists with an enforced waiting period of 24 to 48 hours before a new address becomes usable.
• Two-factor authentication on withdrawals and sensitive changes — not only at login.
• Every crypto movement recorded in the same double-entry ledger as fiat, so one reconciliation process covers the whole balance sheet.

Step 6 — Build compliance into daily operations

Regulators evaluate what you do every day, not what your architecture diagram promises. The platform should make the compliant path the default path: tiered KYC and KYB onboarding with document expiry, automatic FATCA and source-of-funds collection, per-country product eligibility, an AML rules engine that flags unusual activity, and an append-only audit trail behind every action.

Inside the back office, sensitive operations — manual balance adjustments, limit changes, whitelist edits — should require maker-checker approval, where one staff member proposes and a different one approves. Granular staff roles keep each operator seeing exactly what their job requires.

Step 7 — Switch on monetization

A bank that cannot price its services is a cost center. From day one you should be able to configure fees on swaps, top-ups and fiat operations; charge for premium sign-ups and tier upgrades; run referral programs with revenue share; and launch deposit or earn campaigns — all as configuration, without code changes. Start simple, measure, and adjust pricing as real usage data arrives.

What "weeks, not years" actually depends on

With a mature platform, the technology deploys in weeks: instance, branding, languages, modules and chains are configuration. The realistic timeline to serving customers is set by everything around the technology — your licensing or partner agreements, provider onboarding and production credentials, and your operational readiness: staff trained on the back office, compliance procedures written, support in place.

Plan those workstreams in parallel from the start, and the platform is ready when you are. A version of the core behind Coreza has been running in production at a regulated European fintech since 2024 — the pattern above is how that launch, and the ones after it, actually worked.