Buy a Digital Bank or Build with White-Label Banking Software? (2026)

1. What are you actually buying?

“Digital bank for sale” is a search phrase, not a legal classification. Digital delivery says how customers interact with a business; authorisation determines which activities it may perform. A company, a licence, a customer book and an application can be different assets. Start with the legal entity name, the jurisdiction, the authorised activities and the transaction perimeter.

A fully authorised bank

A Swiss bank requires the applicable FINMA authorisation and ongoing prudential supervision. A polished mobile interface is irrelevant to that status. Consult FINMA’s licensing categories and its bank licensing guidance. Check the entity against FINMA’s published institution lists, then obtain documents explaining its permissions, restrictions and current supervisory position. A list entry alone does not complete due diligence.

Payment and electronic-money businesses

Payment institutions and electronic-money institutions are separate regulatory categories in some jurisdictions. Do not import those labels mechanically into Switzerland or assume a foreign permission covers Swiss activities. Switzerland also has a distinct FinTech authorisation framework; it is not a full bank licence. Map deposits, payment execution, lending, exchange and custody individually with local counsel before deciding which regime applies.

An AML-supervised non-bank fintech

FINMA explains the role of self-regulatory organisations in supervising compliance with anti-money-laundering obligations for relevant financial intermediaries. SRO membership is not bank authorisation. Nor is it the separate prudential authorisation of portfolio managers and trustees. A business can have AML obligations and still need other permissions or partner arrangements for specific services. Ask which entity performs each activity, rather than treating “regulated” as a complete answer.

A technology supplier

A vendor supplies software under contract. Account screens, transaction ledgers, onboarding tools and AML interfaces do not themselves authorise deposit-taking, payment services, custody or card issuing. Separating technology from permission prevents a common category error: purchasing an attractive product and discovering later that the intended operating model is not yet legally or commercially available.

2. Choose the operating model before the interface

An equity acquisition usually brings the entity’s history with it: liabilities, tax exposures, contracts, complaints, data obligations and potentially remediation work. An asset transaction may exclude some history but require separate transfers, consents and new permissions. Neither route guarantees continuity merely because an application already works.

Standalone white-label software lets you configure journeys around your own legal and operational structure. You must still secure account provision, payment rails, card programmes and any digital-asset arrangements. A vendor’s integration catalogue is useful evidence of intended connectivity, not proof that a provider will approve your company or business model.

BaaS can bundle selected capabilities from partner institutions, but contractual scope matters. Establish who contracts with the customer, holds funds, performs checks and handles complaints. Review reserve requirements, termination rights, geographic limits and migration assistance. The provider’s licence does not become your unrestricted permission to conduct every financial activity.

A hybrid can be sensible: acquire an appropriate non-bank entity and replace its technology, or use software with authorised service partners. Document the combined model explicitly. A small matrix showing the responsible entity for each service is more useful than calling the whole arrangement a “bank”.

3. Follow the money through two customer journeys

A personal customer: fiat, card spending and digital assets

Imagine a customer completes identity checks, receives account details, transfers fiat, exchanges some funds for a digital asset and spends using a card. The interface can unify that experience, but the underlying services may be split among several entities. Identify who approves onboarding, provides the fiat account or IBAN, executes the payment, quotes the exchange and safeguards the digital assets.

Then trace exceptions. A deposit arrives before identity verification is complete; an exchange fails after a debit; a card authorisation is reversed; a wallet withdrawal triggers screening. Define pending states, reconciliation and escalation. An internal ledger entry is not proof that external settlement occurred. Card issuing partners, payment institutions and custody providers need clear responsibilities and reliable status reporting.

A corporate customer: authority, payroll and treasury

A business journey needs more than an individual form with a company-name field. Consider beneficial owners, authorised signatories, transaction approvals and changing mandates. A hypothetical corporate customer may receive fiat into an account, approve supplier payments, issue employee cards and convert part of its treasury into digital assets. Each action has contractual, permission and control implications.

Ask whether limits, dual approval, audit logs and account restrictions work across both the platform and external partners. Who can change beneficiary details? How are rejected batch payments handled? Can staff trace a customer balance to the provider’s settlement records? These are acceptance-test questions—not claims that every vendor supplies the same controls.

Custody, escrow and the operational back office

Do not confuse acquisition escrow with customer-money safeguarding. An escrow agreement for the purchase price addresses closing risk; it does not establish lawful customer custody. Determine whose name funds are held in, their treatment on insolvency, withdrawal authority and whether segregation or other safeguards are required in the applicable jurisdiction. Digital-asset custody adds key control, recovery and incident-response questions.

Operational readiness also includes support, complaints, access reviews, monitoring and reconciliation ownership. Use a service-responsibility map and test failure cases before launch. The fastest demonstration is not necessarily the safest production design.

4. Compare total costs—not a licence against a company price

An acquisition price and a software licence cover different things. Build a common budget including legal work, regulatory applications or notifications where relevant, implementation, migration, service-provider charges, compliance operations, security, staff and ongoing support. Separate one-time costs from recurring costs and volume-based charges. Do not count the same partner service as “included” on one side and additional on the other.

Capital, liquidity or safeguarding requirements are not interchangeable with operating expenses. Their treatment depends on the regime and activity. Request documented assumptions for transaction volumes, customer geography and products. This guide offers no quantified payback, universal time-to-market advantage or vendor cost ranking: those would require comparable evidence not available from public brochures.

SAMFCore as a configurable technology alternative

SAMFCore’s platform overview describes technology for fiat accounts and bank-account/IBAN workflows, payments, cards, crypto and digital-asset wallets/exchange, individual and business onboarding, AML and back-office functions. It can be relevant when the objective is to assemble an operating platform rather than acquire an entire banking entity. Its integration information should be read alongside the agreements and approvals of the actual service providers.

The vendor’s published licensing options list annual licensing from CHF 80,000 per year, perpetual usage from CHF 325,000 one-time and full-code perpetual licensing from CHF 620,000. These are vendor-stated starting rates, not a quotation for a finished regulated business. Third-party services, charges and approvals are additional. Source-code licence rights are not a transfer of the underlying intellectual property, and no software option grants banking, payment, custody or card-issuing authorisation.

Source code is a contract question, not a slogan

Compare rights to deploy, modify, maintain and use third-party contractors; inspect restrictions, update access and support obligations. SDK.finance documents source-code acquisition and annual and lifetime licensing options. Velmie describes source-code and on-premise delivery. It would be misleading to imply that configurable software or source-code access belongs uniquely to one vendor.

Source access may reduce one dependency while leaving others: external APIs, build tools, proprietary components, operating expertise and regulated partners. Test whether a new team can reproduce deployments and restore backups. If escrow is proposed for source code, define release triggers and verify the deposit is usable; an escrow promise without a reproducible system offers limited practical protection.

5. A practical decision matrix

Use this matrix to establish the next evidence request, not to rank vendors or substitute for transaction advice.

Closing and launch checklist

1. Confirm the perimeter. Identify shares or assets, legal entities, customer data, trademarks, domains, software rights and excluded liabilities.
2. Confirm regulatory conditions. Obtain jurisdiction-specific advice on authorisations, notifications and change of control. FINMA describes qualified-participation reporting and additional licensing for foreign control for banks and securities firms. These rules must not be applied automatically to every SRO-affiliated non-bank. Ask what must happen before signing, closing or launching; do not assume no approval is required.
3. Secure service-partner continuity. Inspect assignment and change-of-control clauses, obtain consents and re-check geographic and product restrictions.
4. Reconcile and migrate. Define opening balances, customer consent or notification where applicable, data retention, rollback and a tested cutover. Never migrate only the interface while overlooking money and ledger records.
5. Prove maintainability. Review code rights, third-party licences, documentation, credentials transfer, reproducible builds and incident recovery.
6. Tie payment to evidence. Agree closing conditions, acceptance criteria and appropriate escrow or holdback with advisers. Keep purchase-price protection distinct from customer-funds arrangements.

A useful recommendation can therefore be conditional: acquire only if the entity and relationships survive the proposed transaction; build only if the legal model and partners are achievable; choose BaaS only if its scope and exit path fit the business. These conditions matter more than whether the front end is described as turnkey.

Frequently asked questions

Primary sources & review notes

Reviewed on 11 October 2026. Regulatory sources explain categories and requirements; vendor sources describe their own products and terms. Neither constitutes an audit of this acquisition opportunity. Published terms may change; obtain current contracts and advice before committing.

1. FINMA — types of licensing: regulatory categories.
2. FINMA — getting licensed as a bank: bank authorisation requirements.
3. FINMA — self-regulatory organisations: AML supervision, not a bank licence.
4. FINMA — authorised institutions and products: public verification starting point.
5. FINMA — FinTech authorisation: a separate Swiss authorisation framework.
6. FINMA — portfolio managers and trustees: distinct prudential authorisation.
7. SAMFCore — overview: vendor-stated platform scope.
8. SAMFCore — licensing: public rates and licence options.
9. SAMFCore — API integrations: vendor-stated connectivity.
10. SDK.finance — acquiring source code: licence and code options.
11. SDK.finance — FAQ: vendor-stated annual and lifetime licensing.
12. Velmie — delivery: vendor-stated source-code and deployment options.

Further reading, with a different vendor-comparison focus: SAMFCore, Crassula, SDK.finance and Velmie comparison. This guide instead examines the legal entity, operating model and transaction decision.