Short answer. An EU fintech cannot be assembled as “company first, licence second, app third.” Regulatory perimeter, product, money flow, outsourcing, AML, safeguarding, technology and commercial model need to be designed together. Otherwise the chosen entity may not fit, the interface may promise the wrong service, a bank may not understand the flows, and the product may need an expensive rebuild before filing.
The sequence below is a practical starting point for payment, e-money, crypto and hybrid projects. It does not determine a specific licence without a fact-based review.
1. Start with a service and money-flow map
Describe every customer action from registration to withdrawal. Who receives money? Where is it held? Who executes a transfer or conversion? Is there custody, issuing, acquiring, a wallet, credit, or only a technical interface? The answers determine whether the project needs its own authorisation, a partner-led model or another route.
| Model | Key question | Common mistake |
|---|---|---|
| Payments / e-money | Who provides the regulated payment service and holds customer funds? | Calling a platform fee “non-payment” without reviewing the actual flow |
| Crypto / MiCA | Which crypto-asset services does the entity perform? | Applying as a broker while the product also performs custody or execution |
| Embedded finance | What does the licensed partner do and what remains with the platform? | Relying on an API contract that does not support the marketing and UX |
| Technology provider | Does the company avoid possession of funds and regulated decisions? | Describing the business as software despite a different level of control |
2. Select the regulatory route before the jurisdiction
Compare countries after defining services. Relevant factors include the authority, expectations for local management, staffing, capital plan, preparation time, talent availability, language, tax and access to target markets. The “fastest licence” without a workable operating model is rarely the fastest launch.
For crypto projects, the MiCA transition ended across the EU on 1 July 2026. A business without permission to operate should not base its sales plan on a former national regime. Payment projects should also distinguish current PSD2 requirements from the developing PSD3/PSR framework and avoid presenting political agreement as already applicable law.
3. Align the entity, owners and management
- a transparent ownership structure and source of capital;
- directors and key functions with sufficient time and experience;
- a credible split of decisions between the EU and other countries;
- a consistent fit-and-proper file covering CVs, projects and shareholdings;
- agreements between group entities, the IP owner and operating company.
Registering a shell does not create substance. The authority will assess where decisions are made and who is genuinely responsible for risk, compliance, product and operations.
4. Design the MVP around a control map
The backlog for a regulated product must include more than customer features. It needs onboarding, screening, transaction monitoring, case management, limits, complaints, reconciliation, access control, audit trails, incident handling and reporting. For each function record whether it is built, bought or outsourced, who owns the control, which data it uses and how operation is evidenced.
DORA has applied to in-scope financial entities since 17 January 2025. ICT risk, incidents, resilience testing and the register of ICT third-party arrangements should not be postponed until after licensing. Cloud, KYC, the core ledger and support tools belong in one vendor map.
5. Prepare banking, safeguarding and payment partners in parallel
“Licence first, bank later” can create a circular dependency. Partners want to see the model, UBOs, forecasts, geographies, AML controls, website, product and expected flows. The regulatory file, bank application and product description must tell the same story.
Separate the corporate account, operational accounts, safeguarding arrangement and customer deposit or withdrawal methods. They are different workstreams with different approval criteria. CrystalCore connects financial and crypto licensing, business accounts and payment infrastructure in a single dependency map.
6. Build an application room
- regulatory perimeter memo and service map;
- group structure, governance and responsibility matrix;
- financial model with capital and liquidity assumptions;
- AML/CFT risk assessment, policies and operating procedures;
- ICT architecture, DORA map, security and continuity;
- outsourcing register, material contracts and vendor due diligence;
- product flows, screenshots, terms, complaints and disclosures;
- banking, safeguarding and partner evidence.
The documents must describe an operating model rather than exist separately from the product. If a policy promises four-eyes approval, it should appear in permissions and the audit trail.
7. Build go-to-market without regulatory overclaiming
Before authorisation, the website, advertising and sales scripts must accurately state the project's status. Do not imply that an applicant is already licensed, guarantee a decision date or sell services it cannot yet provide. A company can still build its SEO architecture, educational content, CRM, waitlist and analytics with suitable wording.
A realistic delivery sequence
| Stage | Commercial result |
|---|---|
| 1. Discovery | Service map, scope, countries and critical assumptions |
| 2. Architecture | Entity, governance, partners and product control map |
| 3. Build and evidence | MVP, policies, vendor files and financial model |
| 4. Application | Coherent dossier and responses to authority questions |
| 5. Launch | Banking, operations, compliant marketing and reporting |
Frequently asked questions
Can we buy an already licensed company first?
Sometimes this shortens individual stages, but change of control, due diligence, product fit and approval of new owners remain critical. An acquisition does not remove regulatory and partner review.
Must the product be fully finished before filing?
It depends on the regime and authority, but a slide deck is rarely enough. Detailed flows, architecture, controls and evidence of the ability to operate the model are normally needed.
Can a licence timeline be guaranteed?
No. Timing depends on file quality, the team, service complexity, the authority's workload and follow-up questions. Readiness and response time can be managed; the authority's decision cannot.
What comes first: a licence memo or development?
A short perimeter and architecture phase should precede expensive development. Product and application workstreams can then progress in parallel.
Official sources
- ESMA: end of MiCA transitional periods
- ESMA: Digital Operational Resilience Act
- European Commission: payment services and PSD review status
Reviewed on 10 October 2026. This guide is not a legal opinion and does not guarantee authorisation, a bank account or a decision date.