Reference stack
Launch a European fintech
A modular reference architecture for a European account, payment and card product. It separates regulated infrastructure, product technology and control functions so teams can assess UK, EEA and multi-market variants independently.
Intended audience and markets
Audience
Markets
Infrastructure layers
Core ledger or core banking
RequiredMaintain the product ledger, account rules and financial product configuration.
Selection criteria
- Real-time double-entry ledger
- Product configurability
- Migration and reconciliation controls
Regulated accounts and payment rails
RequiredProvide accounts, safeguarding or deposit infrastructure and access to relevant payment schemes.
Selection criteria
- Exact regulated entity and jurisdiction
- Named, virtual or pooled account model
- Domestic and SEPA rail coverage
Card programme
OptionalProvide sponsorship, issuing processing, programme operations and tokenisation where cards are required.
Selection criteria
- BIN and scheme-role clarity
- Geographic programme coverage
- 3-D Secure, tokenisation and dispute tooling
Identity and business onboarding
RequiredVerify individuals, businesses and beneficial owners.
Selection criteria
- Country and document coverage
- KYB and UBO depth
- Manual-review workflow
Financial crime controls
RequiredScreen customers and monitor transactions throughout the lifecycle.
Selection criteria
- Sanctions and PEP data
- Transaction-monitoring tuning
- Case management and reporting
Fraud and reconciliation
RequiredDetect payment fraud and reconcile provider, ledger and bank records.
Selection criteria
- Real-time fraud controls
- Common identifiers across systems
- Exception and settlement reconciliation
Implementation sequence
- Core ledger or core banking
- Regulated accounts and payment rails
- Card programme
- Identity and business onboarding
- Financial crime controls
- Fraud and reconciliation
Regulatory considerations
- Determine whether the product requires its own authorisation or can operate within a partner-led model.
- Map safeguarding, deposit protection and customer-funds responsibilities to each legal entity.
- Treat UK and EEA launches as separate regulatory and scheme-access workstreams.
Technical considerations
- Create one system of record for balances and transaction identifiers.
- Design idempotent payment workflows, asynchronous status updates and reconciliation before launch.
- Plan provider exit and data portability before committing to account or card identifiers.
Questions to ask providers
- Which legal entity contracts for each service and in which jurisdictions?
- Which responsibilities remain with the product operator rather than the provider?
- What are the implementation, approval, testing and migration timelines?
- How are incidents, exits, data portability and business continuity handled?
- Which country should launch first, and what changes for later markets?
What this stack does not cover
- This stack does not guarantee authorisation or scheme approval.
- Legal advice, regulatory capital, governance and local compliance operations are outside the provider shortlist.
Related stacks
Reviewed on 2026-07-07.
Provider options are examples of infrastructure roles, not endorsements or a guarantee of suitability, availability or regulatory compliance. Confirm requirements for your product with each provider and qualified advisers.