Launching a regulated fintech is not a four-stage relay in which licensing finishes, technology begins and banking access comes last. These workstreams overlap, and decisions made in one area continuously affect the others.
The process starts with the business itself: what the product does, whose money it handles, where customers are based and how funds move. Once that operating model is clear, licensing, governance, technology and banking planning can develop in parallel. The objective is to ensure that every workstream is being built around the same operating business.
As of July 2026, payment and electronic money institutions in the EEA continue to operate under national laws implementing PSD2 and EMD2. The EU institutions reached a provisional political agreement on PSD3 and the new Payment Services Regulation in November 2025. Companies preparing an application should therefore meet the current framework while designing their governance, compliance and technology models with the forthcoming regime in mind.
A regulated fintech launch requires licensing, technology and banking workstreams to develop around the same operating model.
The first question should not be “Where should we apply?” It should be “What regulated business are we actually building?”
Before comparing jurisdictions, founders need to define the services the company will provide, whether customers will hold balances, how money will enter and leave the business, and which customer groups, countries and currencies will be involved. They also need an early view of transaction volumes, payment methods and which operational functions will remain in-house or be outsourced.
These decisions establish the regulatory perimeter. A company issuing electronic money has different requirements from one providing only particular payment services. A remittance business has a different risk and infrastructure profile from an account-based fintech offering cards and multi-currency balances. A business launching through a Banking-as-a-Service provider has a different allocation of regulatory and operational responsibilities from one operating under its own EMI or PI authorisation.
The same principle applies outside the EEA. A Canadian MSB registration, a Swiss SRO structure and a European EMI authorisation are not interchangeable routes to the same operating model. Each permits different activities, carries different supervisory expectations and provides different geographic rights.
This is why the product model should lead the jurisdiction discussion rather than being adapted to whichever country initially appears easiest. Advapay’s guide to choosing an EEA fintech jurisdiction focuses on regulatory fit, substance, staffing, operating costs and banking compatibility rather than presenting jurisdictions as a league table. The related analysis of EMI and PI authorisation explains why the legal treatment of customer funds matters more than the terminology used in a product presentation.
An EEA authorisation can provide access to other EEA markets through the relevant passporting procedures, but passporting does not remove the need for a credible home jurisdiction. The company must still maintain appropriate substance, complete the required notifications and comply with the conditions attached to the way it operates in other markets.
A jurisdiction decision is therefore not merely a licensing decision. It affects recruitment, governance, reporting, outsourcing, banking access and the cost of operating the company long after authorisation.
Most avoidable delays occur when one part of the project moves forward on assumptions that the others cannot support. A jurisdiction is selected without testing whether the company can maintain substance there. A platform is purchased before safeguarding and reconciliation requirements are understood. A licence application is prepared around customer segments that no suitable banking partner will accept.
The faster route is therefore not simply to move each workstream more quickly. It is to resolve their dependencies before they become expensive to reverse.
A fintech launch can be organised into separate workstreams, but it must produce one coherent operating business.
The licensing workstream defines what the company may legally do. It covers the regulatory perimeter, authorisation route, programme of operations, business plan, ownership, capital, governance, safeguarding, AML controls and regulator communications.
The operational workstream turns those documents into an organisation. The company needs qualified management, compliance and AML leadership, finance and safeguarding oversight, escalation procedures, staff responsibilities and evidence that key decisions are genuinely made within the regulated entity.
Technology implements the product and the control framework. The platform must maintain accurate accounts and balances, process transactions, enforce permissions, support customer due diligence, generate audit trails and produce the information needed for reconciliation and reporting.
Banking and payment partners provide the external infrastructure through which funds are held and moved. Depending on the product, the company may require operational accounts, safeguarding arrangements, customer IBANs, SEPA or SWIFT access, settlement accounts, card services, acquiring, FX and cross-border payout providers.
The correct approach is not to complete these areas one after another. Once the business model, operating route and funds flow are sufficiently defined, licensing preparation, management recruitment, platform selection and preliminary partner discussions can proceed together.
The main dependencies can be summarised as follows:
| Decision | Licensing and governance impact | Technology impact | Banking and partner impact |
|---|---|---|---|
| Customer type | Determines risk assessment, due diligence and monitoring expectations | Determines onboarding, verification and review workflows | Affects partner appetite and account availability |
| Products and services | Defines permissions and the programme of operations | Defines required modules, ledger logic and integrations | Determines required accounts, rails and providers |
| Customer balance model | Influences whether EMI, PI or another permission is required | Determines account, wallet and ledger treatment | Affects safeguarding and customer-account architecture |
| Jurisdiction | Determines regulator, substance and local governance | May affect hosting, outsourcing and reporting | Influences which partners will consider the company |
| Safeguarding model | Must be documented, governed and monitored | Requires balance calculation, reconciliation and evidence | Requires a suitable account or another permitted arrangement |
| Geographic reach | Affects passporting, agents, branches and local obligations | Creates currency, language and reporting requirements | Determines corridors, local rails and payout coverage |
| Card programme | Must fit the approved business and responsibility model | Requires processor, authorisation, settlement and ledger integration | Requires an issuer, BIN sponsor or direct scheme relationship |
| Outsourcing model | Requires contracts, oversight and concentration-risk controls | Defines dependencies and resilience architecture | Partners may review critical suppliers and operational resilience |
The exact regulatory, technology and partner implications depend on the services, jurisdiction and legal structure selected.
This is where many apparently commercial choices become regulatory and technical decisions at the same time.
A decision to serve high-risk merchants is not simply a sales choice. It changes the AML framework, monitoring thresholds, onboarding requirements and the number of banks or acquirers willing to support the business. Adding customer balances is not merely a user-experience feature. It can change the required permission, safeguarding model, ledger design and account architecture. Introducing cards affects licensing documents, processor integrations, settlement, disputes, reserves and reconciliation.
A launch plan can look complete on paper and still fail at the points where the workstreams meet. The licence defines what the business may do, the platform has to prove that the controls work, and banking partners decide whether the actual customers and payment flows fit their risk appetite. Test those decisions against one another before committing serious time and capital.
Technology selection is particularly important because the platform becomes part of the company’s regulatory evidence. The application may describe how safeguarding, monitoring, reporting and operational controls are intended to work, but the technology must later demonstrate that they work consistently in practice.
A modern core-banking platform should provide an accurate system of record for accounts, balances, ledger entries and payments. It should also support or integrate with onboarding, AML and transaction monitoring, safeguarding reconciliation, accounting, reporting and third-party services.
The practical questions are straightforward. Can every customer balance be traced to its underlying entries? Can the company distinguish booked, pending and available funds? Can it calculate its safeguarding position and reconcile it against external accounts? Are manual adjustments controlled and recorded? Can failed payments, returns and exceptions be investigated without losing the audit trail?
Advapay’s article on what core banking software actually does explains why customer-facing functionality is only one part of the infrastructure. The underlying ledger, reconciliation and control environment are what allow the business to remain accurate, auditable and scalable.
For EEA financial institutions, technology decisions must also reflect the Digital Operational Resilience Act. DORA has applied since 17 January 2025 and introduces requirements concerning ICT risk management, incident handling, resilience testing and third-party technology risk. Outsourcing the platform or hosting environment does not outsource the regulated company’s responsibility for governing those services.
The following examples are representative scenarios rather than descriptions of specific Advapay clients. They illustrate the points at which misalignment commonly creates rework.
A jurisdiction is selected for speed rather than operating fit. A founder chooses a country based on an advertised authorisation timeline. During application preparation, the company discovers that the local management, compliance staffing and decision-making expectations do not fit its budget or operating structure. The project must then be reorganised, moved or supported by a level of substance that was never included in the original business case.
A platform is purchased before the safeguarding model is defined. The software performs well in demonstrations and supports the required customer features. Later, the company finds that it cannot calculate safeguarded liabilities, ingest bank statements reliably or explain reconciliation differences at customer and account level. The missing capability has to be developed separately or the system has to be replaced.
Banking outreach begins only after the licence application is submitted. The business plan assumes that suitable accounts and payment rails will be available. When formal discussions finally begin, potential partners decline the proposed customer profile, transaction corridors or crypto exposure. The company is left with a regulatory submission describing services it cannot operationally deliver without changing partners, markets or product scope.
An authorised company is acquired with the assumption that its partnerships will transfer unchanged. The buyer is purchasing an existing legal entity, but the shareholders, management, customers and business plan may all be changing. Banks, card providers and payment partners may require notification, consent or renewed due diligence. Agreements may contain change-of-control rights, and some providers may no longer support the revised model.
Each of these problems begins with a reasonable-looking decision made in isolation. The difficulty appears later because another part of the project applies a different set of constraints.
Banking access requires particularly careful timing. It should not be treated as an activity that begins only after the regulator has made a final decision, but nor should the company submit immature applications to dozens of providers before its business model is stable.
A more credible process begins with architecture: identifying which accounts, rails and providers the business needs. The company can then test the market, approach institutions whose coverage and risk appetite appear compatible, and present a consistent explanation of its ownership, authorisation route, customers, funds flow and expected volumes.
Formal applications, detailed due diligence and technical design follow once the model is sufficiently developed. Account activation may still depend on licence approval, capital, contracts, testing or other conditions. Early engagement does not guarantee onboarding, but it exposes incompatibilities before the business plan becomes difficult to change.
Safeguarding is part of this process, but it should not be used as a synonym for banking access. Safeguarding concerns the protection of relevant customer funds. Banking access is broader and may include operational banking, settlement, customer account structures, payment rails, card programmes, acquiring, FX and payout partners.
Advapay’s banking-access services for fintech companies cover partner identification, business-brief preparation, applications and technical coordination. Final approval, however, remains subject to the relevant institution’s own due-diligence and risk-assessment process.
A licence, a signed software contract and an open bank account do not by themselves create an operational fintech.
Before going live, the company needs to demonstrate that the operating model described to the regulator and partners works end to end. That means testing complete transaction lifecycles rather than isolated screens or API calls.
At minimum, the company should be able to show that:
The purpose of operational-readiness testing is not to prove that the company will never experience an error. It is to prove that errors can be detected, contained, explained and corrected without losing control of customer money or regulatory obligations.
This is also the stage at which hidden inconsistencies become visible. A process described in a policy may not match the configuration of the platform. A banking partner’s cut-off times may not match the liquidity model. A customer-facing payment status may not correspond to the way the transaction is recorded internally. A manual workaround that appeared acceptable during development may create an uncontrolled accounting or compliance risk in production.
The final launch decision should therefore bring together compliance, operations, finance, technology and partner management. Go-live is not just a technical deployment. It is the point at which the company begins operating the complete regulated system.
The coordination problem changes depending on the route selected, but it does not disappear.
With an own authorisation, the company has greater control over the product, governance, technology and partner strategy. It also carries the greatest responsibility for capital, management, compliance, safeguarding, reporting and ongoing supervision. Licensing and implementation need to be coordinated from an early stage because the company itself must demonstrate that the operating model is complete.
A BaaS or sponsored model can shorten the initial route to market by allowing the fintech to use regulated services supplied by a licensed partner. The trade-off is dependency. The sponsor’s licence, risk appetite and operating rules influence the available products, customers, markets, transaction limits and pricing.
The fintech may still be responsible for parts of onboarding, customer support, first-line controls, data handling or complaints, depending on the model. Technology must reflect the division of responsibility between the fintech, the licensed provider and other suppliers. Advapay’s Banking-as-a-Service offering combines partner-provided regulated services with the core-banking and integration infrastructure required to operate the product.
An acquisition of an existing regulated company may avoid part of the lead time associated with a new application, but it creates a different set of risks. The buyer must investigate the company’s regulatory history, liabilities, reporting, governance, contracts, technology and partner relationships. Change-of-control approval may be required, and revised management or business plans may trigger further regulatory and commercial review. Advapay supports companies assessing a ready-made payment or e-money business, but the entity and its third-party relationships must still be examined against the buyer’s intended model.
The right question is therefore not simply which route is fastest. Founders should consider how much control the business requires, which responsibilities it can operate credibly, how much capital and runway are available, and which long-term dependencies it is prepared to accept.
A BaaS launch may be appropriate for testing a product or entering the market quickly, but it may constrain future expansion. An own authorisation may offer greater strategic control, but only if the company can maintain the required organisation and infrastructure. An acquisition may provide an existing regulatory foundation, but only after the underlying entity and its third-party relationships have been examined carefully.
These are the questions that most often arise when founders begin coordinating licensing, technology and partner access.
Usually, yes. The company needs enough technical clarity to explain how its proposed operations, controls, safeguarding, outsourcing and reporting will work. Full implementation does not necessarily need to be complete at submission, but delaying all technology decisions until authorisation can create significant rework and extend the period between approval and go-live.
Preliminary discussions and architecture assessment can generally begin earlier. Whether a provider will accept a formal application, issue conditional approval or open an account before authorisation depends on the institution, jurisdiction and service involved. Early engagement should be used to test compatibility, not presented as guaranteed onboarding.
It can allow an authorised EMI or PI to provide permitted services in other EEA markets through the relevant notification procedures. It does not eliminate home-state substance, passporting formalities, branch or agent requirements, consumer-law considerations, AML obligations or the need for suitable local commercial infrastructure.
No. It may reduce the time associated with obtaining a new authorisation, but the transaction still requires legal, regulatory, financial, operational and technical due diligence. Change-of-control approval, management changes, revised business plans and renewed partner reviews can materially affect the timeline.
No. It changes the way responsibilities are allocated. The licensed provider remains responsible for the regulated services it supplies, while the fintech may retain contractual and operational responsibilities relating to customers, data, support and delegated controls. The exact allocation depends on the legal and contractual structure.
The fastest credible fintech launch is not the one that forces every workstream into a simple sequence. It is the one that makes the right decisions early, runs licensing, governance, technology and partner work in parallel where appropriate, and continually checks that they still describe the same operating business.
Start with the product and funds flow. Select the licence and jurisdiction against the actual operating model. Choose technology that can implement and evidence the required controls. Test banking- and payment-partner appetite before the business plan becomes difficult to change. Then bring those elements together through integration, reconciliation and operational-readiness testing.
Advapay supports this coordination across its complete fintech launch guide, Macrobank core banking software, Banking-as-a-Service models and banking- and payment-partner onboarding.
