COREDO – EU Legal & Compliance Services Expert legal consulting, financial licensing (EMI, PSP, CASP under MiCA), and AML/CFT compliance across the European Union. Headquartered in Prague, we provide seamless regulatory solutions in Germany, Poland, Lithuania, and all 27 EU member states.
Pavel Kos
10.03.2026 | 6 min read
Updated: 10.03.2026
Since 2016 I have led COREDO as a platform of expert solutions at the intersection of law, finance and technology. During this time the COREDO team has completed dozens of projects in the EU, the Czech Republic, Slovakia, Cyprus, Estonia, the United Kingdom, Singapore and Dubai: from company formation and licensing of EU payment services to building AML functions and scaling into new markets. I know well the needs of entrepreneurs and CFOs: they need a reliable partner who speaks the language of business, not regulator formulas, and who can guide the client through the details of PSD2, AMLD5/AMLD6 and NCA requirements for an operational launch.
This article is a practical guide. I will systematically examine the classification of payment services in the EU, the different types of licences (EMI/PI/SPI), requirements for the business model and technical architecture, AML/KYC/KYB practices and nuances of scaling. Along the way I will provide examples of how solutions developed at COREDO helped clients speed up Licensing, set up SCA and transaction monitoring, and confidently pass Q&A with the EU payment services regulator.
How to think about the payments business in the EU
Regulation in the EU follows the logic “function: risk – control”. The PSD2 directive and the classification of payments provide a framework where each function (payment initiation, account information, issuance of electronic money) brings with it a set of organizational, technological and AML requirements. It is important from day one to separate the boundaries between banking activity (accepting deposits, lending from own funds) and PSP services in order to demonstrate the absence of banking activity when applying for a license.
The market is currently living on expectations of PSD3 and the changes it will bring. COREDO’s practice confirms: those who rebuild processes in advance for stronger SCA, open APIs and risk-oriented AML reduce the cost of compliance and accelerate time-to-market. At the same time the basic principle remains the same: clearly describe the product, transaction flows, the parties’ roles and the boundaries of responsibility.
Classification of payments under PSD2
When it comes to classifying payment services in the EU, the key fork is which services you provide and how the money moves. Types of payment services under PSD2 include, in particular, payment initiation service (PIS) and account information service (AIS).
Payment initiation service (PIS) is the initiation of a payment from the payer’s account at a bank via an Open Banking API; the provider does not hold funds but takes on authentication, creation of the payment order and status confirmation.
Account information service (AIS): access to aggregated information on a client’s accounts with their consent, without initiating transfers.
Merchant acquiring vs payment initiation – a frequent question in applications. Acquiring is the acceptance of card payments on behalf of a merchant (involving an acquiring bank, card schemes and, often, BIN sponsorship), whereas PIS is the initiation of a bank transfer via an open API. These models have different flow logic, different degrees of dependence on card standards and different risk profiles. A proper legal description separates the funds flows and determines whether licensing of payment services in the EU in the form of PI/EMI is required or an agency model is sufficient.
A separate layer: how to classify the issuance of electronic money. If you hold client funds with an obligation to redeem at face value and issue e-money, this concerns an Electronic Money Institution (EMI) license. How to classify mobile wallets under PSD2? If a wallet only initiates payments without holding funds, it’s closer to PIS. If prepaid client funds are reflected on the provider’s balance sheet, it’s e-money with safeguarding and capital requirements.
Forms of PI, EMI and SPI licenses and regulators
Licensing is not just a “checkbox” for launch, but a scaling strategy. In the EU there are hierarchies: Payment Institution (PI) authorization for a wide range of payment services, Electronic Money Institution (EMI) for e-money and extended wallet and card functionality, and Small Payment Institution (SPI) registration for models with limited transaction volumes. The right choice saves capital and shortens time-to-market.
EU regulators (NCA, EBA, ECB) set the framework: local NCAs issue authorisations, the EBA issues guidelines and Q&A, and the ECB influences payment infrastructure and supervisory practices in the euro area. What do NCAs look at when classifying a service? Flow transparency, segregation of funds, management competencies, the AML control environment and the realism of the business plan. Our experience at COREDO has shown that proactive dialogue with the NCA, demonstrating a well-thought risk-based approach, significantly reduces the number of rounds of comments.
EMI license in the EU: what the regulator expects
Electronic Money Institution (EMI) — a choice for providers that hold customer funds, issue e-money and issue cards together with a BIN sponsor and issuer processor. For the EMI license business plan it is important to include detailed economics: revenue sources (revenue streams: MDR, interchange, FX spread, subscriptions), cost structure, compliance cost modelling and unit-economics metrics. The regulator expects evidence of not crossing banking boundaries: no deposits and no lending funded by customer funds.
The COREDO team usually compiles an EMI dossier focused on safeguarding, protected account agreements, reconciliation policies and stress scenarios. When the EU payment services regulator sees a logical liquidity management architecture, a clear audit trail and mature CDD/EDD procedures, the discussion moves from “can we” to “how and when”. This accelerates passporting of the payment license to other EU countries after obtaining the primary authorisation.
PI and SPI: thresholds and scenarios
Payment Institution (PI) authorization — the workhorse for PIS/AIS, money remittance, acquiring without holding funds on its own account as e-money. The registration threshold and the criteria authorization vs registration depend on volumes: for early stages SPI is sometimes sufficient, but without passporting rights and with limits on monthly turnover. When is registration as a Small Payment Institution required? When the model is narrow in risk and scale, you are testing demand and want a quick go-to-market with a subsequent upgrade to PI.
At the PI authorization stage we often prepare the package in a cascade: first SPI for early market validation, then PI, with a prepared tech architecture that is easier to scale. This route reduces burn rate and allows practical validation of product hypotheses and SCA processes before moving to a full-scale PI.
Choosing a PSP jurisdiction in Europe and Asia
Registering a payment company in the EU is a balance between timelines, capital requirements, availability of an IBAN/SEPA issuer and the regulator’s openness to innovation. For some purposes markets with a strong SEPA infrastructure and mature NCAs are suitable, for others jurisdictions with a fast administrative cycle. Registering a payment institution outside the EU, for example in Singapore or Dubai, will require consideration of MAS rules or local central bank rules on Stored Value Facilities and licences for payment services.
In Asia we often use regulator sandbox programs and testing for pilots with Open Banking APIs or local equivalents. This provides arguments for subsequent full authorisation: we tested SCA, ran TPS load testing, and collected metrics on chargebacks and declines. The solution developed at COREDO usually includes a comparative jurisdiction matrix assessing passporting of financial licenses, availability of BIN sponsorship and the required policies on outsourcing compliance and third‑party risk.
Description of the business model for the EU regulator
The regulator needs a “transparent box”, not a “black box”. In the “how to describe your business for the EU regulator” section we use a modular business model canvas structure for the payments business, where the roles of merchants, end users, partner banks and KYC providers form a clear value chain. The business model for a payment licence should clarify who initiates the payment, who holds the funds, where risk arises, and who applies control.
How to describe the fee model and revenue sources for the regulator? Directly and precisely: merchant discount rate, interchange income, FX spread, subscription fees for accounting, API fees. It is important to show how the MDR is split between the acquirer and the provider, how net settlement is formed, and what SLAs exist with the acquiring bank. Which ROI metrics are important for a payments startup? GMV, net revenue, LTV/CAC, average ticket size, approval rate, chargeback ratio and cost-to-serve by segment.
Transaction flows and schemes
How to describe the transaction flow for a payment institution licence? We build technical payment flow diagrams for the regulator based on ISO 20022 and payment formats, explain conversion to SEPA credit transfer and SEPA Instant, and show where EMV 3‑D Secure authorization occurs and where SCA is applied. For cross-border scenarios we record how SWIFT and GPI are used for cross-border transfers and which correspondent banks are involved.
The API description and usage scenarios for auditors include Open Banking API standards, endpoint structure, authentication schemes, idempotency and retry policy. Questions about scaling transaction processing and high load are addressed with figures for TPS, latency, auto-scaling and degradation scenarios. The COREDO team also documents transaction data mapping and the audit trail: who and when created, modified and confirmed entities so that the auditor can easily trace the lifecycle of an operation.
SCA Security: requirements and practice
SCA and payment security requirements are not just a checklist but the foundation of trust. We explain how EMV 3‑D Secure is applied for cards, how Strong Customer Authentication (SCA) requirements are implemented in PIS/AIS under PSD2, where the tokenized PAN is stored and how PCI DSS and card data tokenization are complied with. Privacy by design and GDPR compliance are described through data minimization, pseudonymization and clear retention policies.
Integration of AML into CI/CD and compliance-by-design: our standard for fintech projects. Every change to risk rules goes through a test environment, a fintech sandbox and pilot projects with control of the impact on false positives/false negatives. This approach convinces the NCA that security and compliance are part of the architecture, not an “overlay” on top.
AML/CTF and KYC/KYB for PSP
AML requirements for PSPs in the EU are built on AML/CTF directives (AMLD5, AMLD6) and the recommendations of FATF, including the travel rule for transfers with sender and recipient identification. KYC/KYB specifics for a multi-jurisdictional PSP concern the standardization of CDD and EDD procedures: for individuals — ID document, address, selfie/video KYC; for companies — incorporation documents, verification of UBOs and beneficial owners, and source-of-funds controls. PEP and sanctions screening must cover local and international lists with regular updates.
Practices for building transaction monitoring for the applicant rely on a risk-based approach to transaction control. We implement a rules engine with segmented limits, velocity rules, geo-risk profiling and behavioral analytics. Suspicious Activity Report (SAR) practice is documented: escalation criteria, timelines, content, and evidence retention. AML procedures for multi-currency operations take FX and conversion into account: sources of rates, margin, and sanctions and exotic currency risks are recorded.
Errors and how to respond to NCA comments
Non-obvious errors in the business model description when submitting an application are often related to mistaking acquiring for PIS or mixing e-money with agency schemes. What do NCAs pay attention to when classifying a service? To the absence of gaps between the legal description and the actual technical implementation, to the correctness of the customer agreement and disclosures. How to prepare responses to regulator comments on service classification and the PSD2 payment services directive? We prepare a matrix-of-concerns: we link each comment to a policy paragraph, a correction in the scheme flow and an update to the SLA with partners.
COREDO’s practice confirms that an open tone and willingness to provide additional evidence (SCA log files, load test protocols, GDPR DPIA reports) build trust and shorten the question/answer cycle. As a result, the dialogue with the regulator turns from an inspection into a joint calibration of the model.
Acquiring, Cards and Partnerships
The structure of the agreement with the acquirer for a licensed PSP is a separate artifact in the dossier. It describes the merchant discount rate and fee scheme, responsibility for chargeback management and dispute resolution, settlement timelines, rights to withhold funds and rolling reserve. We record the interaction with the acquiring bank and the acquiring process so that the regulator clearly sees the allocation of risks.
If the product includes cards, we disclose the roles of the issuer, issuer processor, BIN sponsorship, and how to describe interaction with card schemes and the BIN sponsor. For aggregator models, payment aggregator and white-label solutions, as well as the payment facilitator (PayFac) model with submerchants and KYB processes. Outsourcing compliance and third-party risk are covered by separate policies: Due Diligence of providers, audit rights, subcontractor control and incident response plans.
Scaling passporting for cross-border
How to scale a PSP to EU and CIS markets? First – passporting of the payment license to other EU countries, then: partnerships and local registrations where passporting is not applicable. Features of classifying cross-border money transfers require a precise description of corridors, correspondent relationships, limits and sanctions profiles. How to account for FX and conversion in the payment service description? We document pricing, sources of rates, deviation controls and disclosures for the client.
Regulatory sandboxes, regulators’ sandbox programs and testing help prove the platform’s resilience under high load. Questions about scaling transaction processing and high load are addressed with a capacity management plan: TPS targets, horizontal scaling, backup data centers and RTO/RPO. For SEPA we specify time to finality, for SWIFT, GPI status and SLA for tracking.
Document package: what’s mandatory
What documents are required to apply for a payment institution license? Corporate documents, descriptions of services and flows, a business plan and financial model, AML policies/KYC/KYB, IT security and SCA, agreements with banks/processors, safeguarding plans, CVs of management and control functions. What information about ultimate beneficiaries is required for the application? Full ownership chain, supporting documents, proof of funds, addresses and identification.
How should the technical architecture description of the payment solution be prepared for the regulator? Application layers, security perimeters, networks, encryption, HSM, secret management, access logs and monitoring. API documentation and specifications for the regulator include authorization schemes, error codes, timings and evidence of compatibility with Open Banking API standards. For GDPR we attach a DPIA, records of data processing and privacy by design.
COREDO case studies: how the approach works
In a project for a payment provider in Europe with a wallet-and-cards model, the COREDO team classified the product as an EMI issuing e-money and cards through a BIN sponsor. We configured SCA based on EMV 3-D Secure, developed transaction monitoring rules and demonstrated to the NCA the safeguarding and reconciliation scheme. The regulator approved the model after one round of clarifications, and the client quickly launched passporting of the payment license across the EU.
In another case the client operated as a payment facilitator with merchant aggregation, split payments and a white-label solution. Our lawyers structured the agreement with the acquirer, defined the MDR allocation and liability for chargebacks, and engineers prepared technical diagrams of payment flows for the regulator. COREDO’s practice confirmed: clear KYB of sub-merchants and transparent hold/release logic for funds reduce NCA findings to a minimum.
The third example is a cross-border platform between the EU and Asia using SEPA Instant within the EU and SWIFT GPI for interregional transfers. We described the specifics of classifying cross-border money transfers, accounted for the travel rule and sanctions screening, and also disclosed FX processes and margin. After the sandbox pilot the client scaled TPS while maintaining stable SAR procedures and a low level of false positives.
How COREDO Works
The journey begins with a diagnostic session: product, flow, risks, choice: registering a payment company in the EU or an Asian license. Then – a map of jurisdictions with the criteria “EU payment services regulator”, timelines, capital, passporting, availability of partners for issuing/acquiring. In the third stage the COREDO team designs a business plan, revenue model, assessment of the cost of PSD2 and AML compliance and ROI metrics for payment platforms (LTV/CAC, GMV, margin and cost-to-serve).
Next we prepare the technical package: SCA, PCI DSS, Open Banking API, ISO 20022, SEPA/SEPA instant, SWIFT GPI, TPS schemes and fault tolerance. In parallel we develop AML/CTF: KYC/KYB, CDD/EDD, PEP/sanctions, risk-based approach and rules engine. Then: submission, responses to comments, demonstration of evidence and, if necessary, iterations in a sandbox for fintech and pilot projects.
After authorization, a “live compliance” mode is crucial: transaction monitoring systems, policy updates as new EBA guidelines and PSD3 trends, expectations and changes are released, and support for passporting financial licenses. Our support includes team training, audit readiness tests and regular auditing of data trails (audit trail) and privacy by design.
Conclusions
Licensing payment services: it’s not about “passing a check”, it’s about creating a scalable and manageable model where compliance strengthens the business. Over years of practice I have become convinced: when an entrepreneur accurately defines the service classification under PSD2, chooses the appropriate license (PI, EMI or SPI), establishes transparent flows and builds AML/KYC properly, the dialogue with the regulator becomes productive and predictable. The result is time savings, a clear cost of compliance and readiness to grow in the EU, Asia and the CIS.
If you are planning to register a payment company in the EU, license EU payment services, or build a payment provider in Europe with expansion into new markets, the COREDO team is ready to get involved. We will help describe the business for the EU regulator, prepare technical and AML packages, set up SCA and transaction monitoring and support passporting to other countries. This kind of partnership provides confidence at every next step and turns complex regulation into a sustainable competitive advantage.