Neobank Technology Stack: Banking, Cards, Payments and Crypto (2026)

Methodology and commercial disclosure

This guide is published on a Swiss AMF AG-affiliated acquisition website, not by an independent comparison publisher. Swiss AMF AG is commercially associated with SAMFCore. That relationship matters when assessing the examples below. The purpose here is to explain architecture and diligence questions, not rank vendors or endorse the existing sale listing's regulatory claims.

We reviewed public regulator and vendor documentation on 11 October 2026. Vendor pages establish what vendors publicly describe, not proof of implementation quality, security certification or a buyer's eligibility. We did not conduct platform benchmarks, inspect private contracts or audit a deployment. The checklist and transaction scenarios are editorial analysis, not reported vendor case studies. Requirements depend on jurisdiction and activity; obtain qualified legal advice.

1. Start with the operating model, not the app

A branded account screen can conceal several distinct relationships: the customer contracts with one entity, deposits or payment funds sit with another, a processor sends transactions and a software supplier maintains the interface. Ask for a diagram naming the legal entity at every boundary. “Core banking”, “banking-as-a-service” and “orchestration” describe different layers; none alone proves the right to accept deposits or issue a card.

In Switzerland, FINMA: types of licensing distinguishes authorisation regimes. FINMA: self-regulatory organisations (SROs) concerns SRO supervision of relevant financial intermediaries for anti-money-laundering purposes. SRO membership is not a bank licence, and it is not FINMA prudential portfolio-manager authorisation. Portfolio-manager and banking regimes are distinct, even where an organisation provides a similar-looking customer interface.

Use the FINMA: authorised institutions, individuals and products register and the appropriate supervisory records to verify the actual entity and status. FINMA's FINMA: banks and securities firms explains the banking authorisation framework. Do not infer legal scope from a “neobank” label, a SWIFT identifier or an integration list. An acquisition can require new assessments of ownership, contracts and activities; an existing configuration is not universal permission for a new business model.

2. The ledger is the account's memory

The customer app displays balances; the ledger explains them. A useful diligence exercise follows one transaction through authorisation, reservation, posting, settlement and reversal. Require balanced accounting entries and identifiers that join internal postings to the external provider's records. A balance returned by an API is not, by itself, evidence that the platform can explain yesterday's liability.

Distinguish available, booked and pending balances. A card hold can reduce spending capacity before final settlement; a bank transfer can remain pending while screening runs. Decide which system is authoritative for each state and how discrepancies reach an operator. If the internal ledger and an account partner disagree, an automated retry must not silently create money or repeat the customer's payment.

For an illustrative acquisition test, request a masked dataset containing a deposit, a fee, a declined payment and a reversed transaction. Reconstruct the closing balance without relying on screenshots. Then test duplicate delivery of the same provider event and a delayed settlement message. The desired evidence is consistent accounting, preserved history and an exception queue with clear ownership, not a polished demonstration.

3. Payments, cards and crypto need separate maps

Bank accounts and payment rails

An IBAN workflow may involve account provisioning, beneficiary checks, screening, payment submission and settlement reporting. Ask whether accounts are dedicated or part of an omnibus structure, who is the account holder and what contractual claim the customer has. Identify cut-off times, rejection handling, provider outages and return processing. The same user interface can mask materially different arrangements.

An orchestrator can standardise provider connections; it cannot make their contracts interchangeable. API documentation should be matched to enabled production services, credentials and approvals. SAMFCore: API integrations describes integration capabilities, for example, but an advertised connector is not proof that an acquiring entity has an approved relationship with that provider.

Card programmes

Separate the issuer or sponsor, processor, scheme relationship and customer-facing card controls. Establish who approves the programme, handles disputes and manages fraud exposure. Test a hold followed by a smaller settlement, a reversal and a chargeback. A working “freeze card” button says little about settlement reconciliation or whether the sponsor accepts a change of ownership.

Map where cardholder data is stored, processed or transmitted. The PCI Security Standards Council: PCI DSS defines the relevant security standard; applicable scope and validation obligations need assessment with the programme's counterparties. Outsourcing card processing can reduce exposure, but is not evidence that every connected system is compliant. Do not treat a vendor's security description as a certification.

Digital assets and custody

Crypto neobank software infrastructure adds wallet creation, transaction signing, blockchain monitoring, exchange execution and fiat reconciliation. Determine whether custody is internal, delegated or non-custodial; identify who controls keys and withdrawal policies. A wallet balance is different from a fiat liability, and blockchain confirmation is different from settlement at a bank partner.

Walk through a deposit on a supported network, screening, conversion and withdrawal. Ask how wrong-network transfers, chain reorganisations, unavailable liquidity and frozen withdrawals are handled. Document asset support and segregation rather than assuming a crypto module permits every token or custody activity. Obtain activity-specific advice before changing the operating model.

4. Onboarding and controls must survive real exceptions

Individual onboarding and business onboarding are not the same checklist. Business accounts can require ownership structures, beneficial-owner evidence and authority to act. Link identity records, screening results and risk decisions to the account history, with controlled access. Purchasing an AML module does not outsource responsibility for deciding who may transact and under which limits.

Ask operators to demonstrate a screening alert, an expired document and a proposed beneficiary change. Who can approve each action? Can one user alter a risk rule and release the resulting payment? Maker-checker controls, audit records and escalation ownership matter more than the number of dashboard widgets. Record how provider failures affect onboarding rather than accepting a blanket “automated compliance” description.

Data location is only part of the control question. The FDPIC: data processing in the cloud explains responsibilities around cloud processing; FDPIC: cross-border transfer of personal data addresses international transfers. Inventory customer data, backups, analytics, support access and subprocessors. Assess the applicable safeguards rather than assuming that a Swiss company or a local server automatically resolves every cross-border issue.

Request evidence of restore tests, incident handling, privileged access review and exportability. Set operational recovery expectations before choosing infrastructure. If the database is restored but signing keys, event queues or provider credentials are unavailable, the service may still be unusable. The practical test is recovery of a reconciled service, not merely recovery of a virtual machine.

5. Four examples of delivery and ownership tradeoffs

These examples illustrate purchasing questions, not a performance ranking. Features and rights below are vendor-stated. Compare actual contracts, enabled modules and engineering responsibilities for your proposed operation; these are not four interchangeable offers.

SAMFCore: usage rights versus code rights

The SAMFCore: platform overview describes fiat accounts and bank-account/IBAN workflows, payments, cards, crypto and digital-asset wallets/exchange, individual and business onboarding, AML and back-office functions. Its SAMFCore: licensing publishes 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 published starting rates, not a project quotation.

Perpetual usage and source-code access are different rights; neither is a transfer of the underlying intellectual property or a financial licence. Third-party service charges and approvals are additional. A buyer should examine the licensed entity, modification rights, support, maintenance and change-of-control provisions rather than compare the headline price alone.

Crassula: white-label services and integrations

Crassula: digital banking describes white-label banking capabilities and integrations; its Crassula: developer resources provides a technical starting point. The diligence question is how the proposed configuration divides responsibility between the platform, your organisation and financial partners. Identify which integrations are contracted and approved, and how much custom work is required. Do not infer source-code ownership or regulatory coverage from white-label branding.

SDK.finance: annual and lifetime source-code options

SDK.finance: acquiring source code and SDK.finance: frequently asked questions describe annual and lifetime source-code licensing. Source-code access is therefore not unique to SAMFCore. The published acquisition documentation also describes a one-country operating scope and customer responsibility for infrastructure and further development after transfer. Confirm the current agreement's territory, deployment and maintenance terms with the supplier.

Velmie: delivery model as an operating decision

Velmie: delivery models describes cloud, on-premise and full-source-code delivery. It should not be characterised as cloud-only or as withholding source code categorically. Compare what each delivery option leaves your team operating: updates, infrastructure, integrations and incident response. On-premise deployment can increase control while also increasing the buyer's staffing and maintenance obligations.

For a separate, more detailed vendor comparison, see SAMFCore, Crassula, SDK.finance and Velmie on whitelabelbanking.io. This guide deliberately focuses instead on system boundaries and acquisition evidence. For practical selection tests, our crypto-neobank vendor comparison follows business onboarding, funding, custody and card exceptions.

6. A practical acquisition decision checklist

Use the following as an evidence-request list, not a vendor score. Mark each row confirmed, conditional or unresolved. A conditional item should name the approver and deadline; an unresolved item should affect transaction planning. For the commercial context, see the existing acquisition overview; the checks here do not validate every statement in that listing.

Do not confuse a repository handover with an operational handover. Ask a receiving engineer to build the system in an approved environment from documented instructions. Verify secrets management, dependency access and deployment rollback. A perpetual licence can reduce recurring licence exposure while still requiring recurring support, hosting and compliance expenditure.

Finally, align the purchase agreement with the evidence: required partner consents, delivery acceptance criteria and outstanding remediation. An app, a legal entity and a provider network can transfer on different terms. The defensible decision is the one in which the buyer can identify each obligation, reproduce the important flows and explain what remains conditional.

Questions and answers

Primary source notes

Reviewed on 11 October 2026. FINMA sources support regulatory distinctions and register checks; FDPIC and PCI SSC sources support data and security questions. Vendor sources support public descriptions and licensing statements only. Linked pages can change; request current contractual terms before purchase.

1. FINMA: types of licensing
2. FINMA: self-regulatory organisations (SROs)
3. FINMA: authorised institutions, individuals and products
4. FINMA: banks and securities firms
5. SAMFCore: platform overview
6. SAMFCore: licensing
7. SAMFCore: API integrations
8. SDK.finance: acquiring source code
9. SDK.finance: frequently asked questions
10. Velmie: delivery models
11. Crassula: digital banking
12. Crassula: developer resources
13. FDPIC: data processing in the cloud
14. FDPIC: cross-border transfer of personal data
15. PCI Security Standards Council: PCI DSS