CONTROL, ECONOMICS & EXIT · 2026

Digital Bank Acquisition vs BaaS vs Software Licensing (2026)

Compare who can make decisions, who carries obligations and what survives a partner change—not three versions of the same banking interface.

By Swiss AMF AG · Published 11 October 2026 · Reviewed on 11 October 2026

The decision in brief

An acquisition buys equity and the entity’s obligations; BaaS buys contracted access to regulated services; software licensing buys technology rights. Choose by the decisions your business must control: admitting customers, holding funds, setting product rules, changing providers and exiting the arrangement. None of these routes makes regulatory permission interchangeable with software ownership.

If deposit-taking and balance-sheet activity are essential, begin with the relevant banking permission, not an account-screen demonstration. If partner-provided accounts and payments are sufficient, examine the BaaS contract’s limits. If control over workflows and deployment is essential, examine a software licence alongside the separate regulated-provider model.

Methodology & commercial affiliation

This company-operated website markets acquisition opportunities and is commercially affiliated with Swiss AMF AG, which also presents SAMFCore software. This is not an independent endorsement or vendor ranking. We reviewed the official regulator and vendor documentation linked below on 11 October 2026. Regulatory material supports legal distinctions; provider documentation supports only the provider’s stated model. We have not audited institutions, obtained private quotations or tested their systems.

The comparison uses decision rights, contractual dependencies and a five-year budgeting framework. It is not a price forecast or legal opinion. Switzerland and the EU/EEA have distinct regimes; activity, entity, jurisdiction and contractual scope determine the answer. Obtain transaction-specific advice and check current regulator records before relying on any provider’s claimed status.

1. Buy control—or contract for access?

Equity acquisition: governance, not a detachable licence

Buying a banking entity can give shareholders influence over strategy, board appointments and budgets within the applicable governance framework. It does not let shareholders disregard supervisory constraints or direct staff to approve prohibited business. The authorisation attaches to the institution and its authorised activities, not to a buyer’s marketing brand.

FINMA’s bank licensing requirements include minimum capital, adequate organisation and ongoing capital and liquidity planning. These are obligations of operating a bank, not features delivered by a software supplier. An acquisition review should therefore include supervisory correspondence, risk appetite, governance, capital planning and unresolved remediation—not only share certificates and technology.

FINMA’s qualified-participation guidance addresses holdings of at least 10% of capital or voting rights, or significant influence, and reports around specified thresholds. Shareholders must report before buying or selling a qualified participation in the institutions covered. Foreign-control guidance describes additional licensing for relevant transfers or changes in foreign control. Do not promise immediate bank ownership transfer by importing the notification-only description of a different non-bank sale.

BaaS: control is negotiated at the service boundary

Banking-as-a-service is a commercial delivery model rather than a single regulatory permission. A bank or an electronic-money institution may provide account and payment capabilities while a partner supplies distribution and customer experience. The buyer’s practical control depends on service agreements, permitted markets, approval rights and operational processes.

Solaris describes its banking model, while Swan describes an electronic-money model. These provider statements demonstrate why the BaaS label alone cannot establish what a customer balance legally is. They are not recommendations, regulatory certifications by this website or evidence that every prospective partner will be accepted. Provider marketing about simplified regulatory obligations must not replace analysis of your own role.

Software: control of deployment is not control of the regulated service

A platform licence may give substantial freedom over workflow design, branding and deployment. But a bank, EMI, issuer or custodian can still restrict the products connected to it. Owning your interface does not give you a unilateral right to open accounts, execute payments or move custody to a new provider. Write down the points where a software decision requires an external party’s consent.

2. Who can admit a customer—and what can they hold?

Ask who approves the customer rather than who displays the form. Data collection, screening, risk classification, final admission and ongoing review can sit with different parties. Establish which decisions are delegated, which require approval and who can suspend or close an account. A business development team should not be able to bypass the responsible compliance decision simply because the user interface allows it.

For BaaS, require a responsibility schedule covering customer eligibility, document requests, sanctions alerts, suspicious-activity handling, complaints and record retention. Provider acceptance may depend on sector, geography, transaction patterns and beneficial ownership. A proposal should show escalation paths and rejection handling without implying that every customer can be onboarded under a partner’s permission.

For acquisition, inspect how the institution actually makes these decisions today. Historic customer files, outstanding reviews and control exceptions may remain with the acquired entity. Replacing a platform does not remove their legal significance. A licence to technology, by contrast, brings tools and contractual rights but no inherited customer acceptance or automatic regulatory clearance.

Deposits, e-money and AML supervision must stay separate

FINMA explains SRO supervision as supervision of relevant anti-money-laundering obligations. FINMA recognises and supervises the SROs; the affiliated intermediaries are supervised by their SRO. This is different from prudential bank supervision. A non-bank company can have a legitimate AML-supervised model without being authorised to take deposits as a bank.

Switzerland’s separate FinTech authorisation allows specified public deposits or cryptobased assets under conditions, including restrictions on investment and interest. It should not be conflated with SRO membership, a full banking licence or EU electronic-money permission. Whether a particular balance is a deposit, e-money, a custody asset or another claim needs activity-specific analysis.

Request the customer terms, funds-flow diagram and insolvency treatment for each service. Identify the contractual debtor, account holder and safeguarding or deposit-protection arrangements where applicable. Avoid describing all balances as insured bank deposits merely because they appear under one app balance. The same caution applies to card programmes and conversion products.

Delegation does not erase accountability

The EBA’s third-party risk guidance page covers outsourcing and the transition to non-ICT third-party risk guidance. Check applicable versions and effective dates for the institution and function concerned; do not assume an older framework applies unchanged. The ECB’s cloud outsourcing guide announcement distinguishes supervisory expectations and good practices from legally binding DORA requirements. It does not itself create a new licence or make a brand partner a regulated bank.

Use these as prompts for evidence about monitoring, access, incident handling and exit—not a claim that every arrangement has identical obligations. Ask who reports incidents, who can access records and which responsibilities cannot be contractually wished away. Regulatory applicability depends on the parties and services.

3. Compare five-year economics without inventing a winner

A five-year comparison is useful because it exposes recurring dependencies and exit costs. It is not useful if one route is budgeted as a licence price while another includes staff, capital and every service fee. Start with identical product scope, customer markets, currencies, transaction assumptions and operating hours. Label unknown amounts as unquoted rather than filling them with convenient estimates.

Build three comparable cost ledgers

Acquisition: consideration for shares, diligence and transaction costs, inherited obligations, remediation, technology renewal and operating expenses. Keep regulatory capital and liquidity needs separate from expenses; capital committed is not automatically money consumed. Review the opening balance sheet and potential distributions with advisers rather than assuming all capital is available to fund growth.

BaaS: implementation, minimum commitments, account and transaction charges, card programme costs, compliance support, reserves where contracted, internal staffing and exit assistance. Clarify which prices can change, which services have separate schedules and which customer volumes trigger new terms. A commercial minimum may continue even when the service is underused.

Software licensing: licence, deployment, integrations, hosting, maintenance, support, development, security and the same external regulated services still required. A perpetual usage licence can remove recurring subscription licence fees while leaving operating costs intact. Source-code access changes maintainability rights; it does not make engineering, patches or provider connections free.

A transparent model and stress cases

For each route, calculate one-time cash outlays plus annual fixed operating costs, volume-dependent charges and a separately identified exit scenario. Report capital or reserve commitments in a separate schedule. If using discounted cash flow, disclose the discount-rate assumption and separate projected revenues from verified contracted costs. This article assigns no rates, volumes, purchase values or payback period.

Stress three situations: growth below expectations, a material provider repricing and a forced partner migration. Ask which contracts can terminate, whether minimum charges survive and what it costs to maintain service during migration. A more expensive quoted implementation may include work another proposal leaves outside scope; compare deliverables rather than headline amounts.

Also budget governance decisions. Who funds remediation when a provider rejects an intended sector? Who can pause launch? Who pays for reconciliation defects? Convert these into acceptance criteria and responsibility clauses. Otherwise a neat spreadsheet can hide the most expensive operational disagreement.

4. Digital assets and technology exit are separate dependencies

A fiat BaaS contract does not automatically cover digital-asset custody, exchange, stablecoin settlement or crypto–fiat conversion. Map each activity to the responsible entity, contractual provider and relevant legal analysis. Confirm that banking and payment partners accept the proposed flows; an API connection is not evidence of approval for the business model.

For custody, inspect key control, signing authority, recovery, reconciliation and withdrawal restrictions. Ask what happens if an exchange, custodian, liquidity provider or blockchain network becomes unavailable. Do not equate access to a wallet interface with control of private keys or insolvency-safe customer assets. Purchase-price escrow, software escrow and customer-asset custody protect different interests.

SAMFCore: a relevant software example, not a banking permission

SAMFCore’s overview describes fiat accounts and IBAN workflows, payments, cards, digital-asset wallets and exchange, onboarding, AML and operational modules. It explicitly places external banking, payment, card, custody and screening services with customer-selected providers. This can be relevant to a purchaser seeking workflow and deployment control while retaining separate regulated-service relationships.

Its licensing documentation distinguishes annual usage, perpetual usage and packages with full source-code access. A standard perpetual licence does not automatically include source code. Permanent usage rights are not ownership of the underlying intellectual property. The licence’s entity scope, modification rights, territory and any white-label rights must be checked in the definitive agreement.

Its API documentation describes provider connectivity and asynchronous callbacks. It does not certify that a bank will onboard the purchaser or that a particular integration is delivered within the acquisition price. No software option grants banking, payment, custody or card-issuing authorisation. Treat vendor-stated functionality as a starting point for contractual and technical acceptance tests.

Design an exit that can actually execute

Require data export formats, balances and transaction histories, event records, configuration documentation and realistic transition assistance. Test a sample export and reconstruction before relying on a portability clause. Source access is useful only if the replacement team can build, deploy, patch and operate the system within the permitted rights.

Moving a ledger is not moving a bank account. Cards may require new programme arrangements; customer contracts may require consent or notification; custody migrations require separate controls. Document sequencing, parallel-running costs, reconciliation and rollback. Control is most valuable when it includes a workable path out—not merely the freedom to change an application’s colours.

5. A decision-rights matrix for the investment committee

Compare evidence and constraints, not generic vendor scores
Decision	Bank equity acquisition	BaaS contract	Software licence
Strategy and governance	Shareholder influence within governance and supervision.	Partner strategy within provider scope and contract.	Technology strategy within licence and service dependencies.
Customer admission	Institution’s accountable control processes.	Responsibilities and final decisions defined with provider.	Tools support checks; permission and admission remain elsewhere.
Deposit-taking	Only within verified banking permission and conditions.	Depends on bank versus EMI and contracted product.	Not granted by software rights.
Changing providers	Governance, supervisory and contractual considerations.	Consent, termination and migration terms.	Integration rights plus separate provider approvals.
Five-year exposure	Consideration, obligations, capital and operations.	Minimums, variable fees, service continuity and exit.	Licence, engineering, external services and exit.
Evidence to request	Permission records, supervisor correspondence and contracts.	Responsibility schedule, product terms and transition plan.	Definitive rights, reproducible deployment and portability tests.

Buyer checklist before committing

Name every responsible entity. Record who contracts with customers, holds funds, issues cards and supplies custody.
Verify the permission perimeter. Check regulator records, restrictions and transaction-specific ownership conditions with counsel.
Write the decision schedule. Allocate admission, limits, suspensions, pricing changes, incidents and complaints.
Reconcile commercial scope. Match implementation deliverables, recurring charges and exclusions across all proposals.
Test discontinuity. Request a migration sample, incident scenario and executable exit assistance.
Make funding conditional. Tie closing or acceptance to verified permissions, contract continuity and technical evidence.

The result may be a hybrid rather than a winner: acquiring an appropriate non-bank company, licensing configurable software and contracting with authorised partners. If this matches your objective, inspect the current non-bank acquisition offer without treating it as a bank sale. For a broader explanation of the legal asset being bought, see the earlier buy-versus-build guide. For evidence about this listing, send an enquiry.

Frequently asked questions

Does acquiring a bank give the buyer unrestricted banking powers?

No. The authorised entity remains subject to its permissions, governance and supervisory obligations. The buyer must address ownership reporting, any additional licensing and transaction-specific conditions. Share ownership is not a separate personal banking licence.

Who decides whether a BaaS customer can be onboarded?

The agreement and regulatory model determine the responsible parties. A partner can collect information and design the journey, but should not assume it can override the regulated provider’s eligibility, compliance or risk decisions.

Are BaaS accounts always bank deposits?

No. BaaS may involve a bank or an electronic-money institution. Identify the customer’s contractual provider, the legal nature of the balance and applicable safeguarding or deposit-protection arrangements before making claims.

Can an SRO-supervised Swiss fintech accept deposits like a bank?

SRO AML supervision is not bank authorisation. Assess the actual activities and any separate permission or exemption with Swiss counsel; neither a company acquisition nor an account interface establishes deposit-taking rights.

What does a SAMFCore software licence authorise?

Contractual use of the platform within the agreed scope. Source-code access depends on the selected licence. It does not grant banking, payment, custody or card-issuing authorisation and does not transfer the underlying intellectual property.

How should five-year economics be compared?

Use the same products, geographies and volume assumptions. Include transaction or licence costs, implementation, recurring operations, variable provider charges, stressed exit costs and separately identified capital or liquidity needs. Do not assume one model is universally cheaper.

Can a software change remove all BaaS dependency?

No. A replacement interface or ledger does not automatically move accounts, customer contracts, balances, cards or custody. Partner approvals, data portability, reconciliation and service-specific migration plans are still necessary.

What is the most important evidence before signing?

A written responsibility and decision-rights schedule, verified permission perimeter, complete contracts and an executable exit plan. Tie closing or acceptance conditions to evidence rather than a demonstration or a broad regulated-platform label.

Official sources and review notes

Reviewed on 11 October 2026. Regulator sources explain their own regimes; provider sources describe commercial products and require independent transaction verification. We do not reproduce vendor claims about guarantees, universal regulatory exemptions or comparative superiority. Check current guidance, effective dates and definitive agreements.