EU Payment License Types Explained: EMI vs PI vs Agent Model for Platforms

How EMI, PI and agent models differ#

An electronic money institution (EMI) can issue electronic money and provide authorised payment services. A payment institution (PI) provides payment services but cannot issue electronic money under its PI authorisation. A registered payment-services agent acts for a regulated principal within an agreed scope. Choose the route by examining the claim the customer holds, who receives and controls funds, and what payment activities each entity performs.

This comparison uses PSD2, the Electronic Money Directive and national regulator guidance. National implementation and the exact product facts still matter. VAT registration does not establish payment-service authority. Before committing a launch, confirm the applicable legislation and any transition arrangements with the home regulator.

The PI figures are initial-capital floors, not a complete launch budget: €20,000 for money remittance only, €50,000 for payment initiation, and €125,000 for services in PSD2 Annex I points 1–5. Account-information-only registration is a separate case. The Central Bank of Ireland's application guidance explains these categories and why required own funds can exceed initial capital.

Start with your platform money flow and control points#

Separate seller settlement, contractor payouts and creator withdrawals before choosing a licence. They may share an interface while having different payers, beneficiaries, contracts and regulated providers. A balance label or an IBAN is insufficient to classify the product.

• Collection: identify the payer, contractual payee, account holder and regulated collector. Does the platform receive funds or only transmit instructions?
• Holding: identify whose claim is recorded, who owes repayment, what the funds can be used for and who safeguards them.
• Conversion: identify the entity executing FX, the quote, fees and when conversion becomes final.
• Payout: identify who accepts the payment order, executes it and handles a return or rejected beneficiary.
• Exceptions: map disputes, refunds, chargebacks, sanctions holds, reconciliation breaks and provider failure.

A worked example: seller settlement versus a reusable wallet#

Suppose a marketplace records €100 owed to a seller after a sale. In model A, an authorised provider collects the buyer payment and settles the seller under its payment-service agreement; the platform displays the receivable and submits approved instructions. In model B, the seller receives €100 of value as a claim on an issuer and can use that value to pay unrelated merchants before redeeming the remainder. Model B introduces an electronic-money question that the settlement display alone does not establish.

These are illustrative fact patterns, not automatic legal classifications. For each, check the actual contracts, acceptance network, repayment obligation and control of funds. If the platform itself performs a payment service in model A, merely connecting to a provider does not settle whether it needs agent registration or its own authorisation. If an EMI issues value in model B, identify the EMI as issuer rather than calling the platform an issuer under an agent contract.

Match contracts to operating reality#

• Compare the customer terms, provider agreement, funds-flow diagram and production instructions.
• Name the legal entity and owner for every regulated activity and exception.
• Keep open questions attached to the affected feature or market; do not mark the whole launch approved while those questions remain unresolved.
• Make product changes reopen the scope memo when funds access, redemption, customer rights or countries change.

When an EMI route is justified#

Electronic money is electronically stored monetary value represented by a claim on the issuer, issued on receipt of funds for payment transactions and accepted by someone other than that issuer. The Central Bank's EMI explanation sets out this definition. A reusable third-party payment wallet warrants examination against it; a payment account or delayed settlement does not become e-money solely because funds remain there.

Own EMI authorisation makes sense to investigate when issuing e-money is central to the product and the business can sustain the required capital, safeguarding, compliance, governance and supervision. Partnering with an EMI can instead place issuance with that partner, but the platform's other activities still need a defined legal and contractual basis.

An EMI is not a bank simply because it offers a wallet or an IBAN. Safeguarding and deposit insurance are different protections. The Central Bank's comparison distinguishes payment and e-money institutions from banks for this purpose. Describe the protection that applies to the actual provider and product.

When a PI route fits better#

A PI route is worth investigating when the business provides specified payment services without issuing e-money. Examples include executing transfers, acquiring transactions and money remittance. Authorisation is service-specific: a remittance permission is not permission for every payment activity.

PSD2 Article 18 limits payment accounts held by PIs to accounts used exclusively for payment transactions and distinguishes payment-service funds from deposits and e-money. Map the proposed account's purpose rather than treating any temporary holding of funds as either prohibited or automatically an EMI product.

A PI application needs more than the correct capital line. The EBA authorisation guidelines cover information about the programme of operations, business plan, governance and controls. Build those around the real transaction and exception paths.

Small EMI and Small PI routes are national waivers#

PSD2 Article 32 permits a national small-PI waiver for eligible services with an average monthly transaction-value ceiling no higher than €3 million over the preceding 12 months, including relevant agents. The EMD2 Article 9 ceiling for a small-EMI waiver is average outstanding e-money no higher than €5 million. Member States can set lower limits and impose conditions; not every country implements both routes.

Neither waiver carries the standard cross-border passport of a fully authorised institution. A small route can therefore fit a genuinely domestic model yet fail a multi-country roadmap. Do not confuse transaction throughput with outstanding e-money: €2 million paid out in a month and €2 million held as average issued value measure different things.

For a concrete national difference, Ireland's authorisation page states that Ireland has no small-PI regime. This alone invalidates a generic plan to register a small PI in any EU country. Check the current national limits, capital, eligible activities and transition obligations before choosing a waiver.

• Confirm that the route exists in the intended home state.
• Calculate the relevant metric from the full business population, not a convenient subset.
• Model growth and the point at which eligibility would be lost.
• Create an authorisation or partner transition plan before that point.
• Keep expansion countries outside approved scope until the required route is established.

Agent model boundaries your legal team must pin down#

A payment-services agent acts on behalf of an authorised institution. Under PSD2 Article 19, agent information and controls go through the principal's regulator, and the agent may begin payment services after entry in the register. Under Article 20 the institution remains fully liable for its agents' acts. That liability does not remove the platform's contractual duties or excuse weak controls.

An EMI can provide payment services through agents. It cannot issue electronic money through agents; EMD2 distinguishes issuance from distribution and redemption through persons acting on its behalf. An e-money distributor and a payment-services agent are therefore different roles. The EBA's distributor Q&A explains the distribution provision.

Do not confuse a registered payment-services agent with PSD2's commercial-agent exclusion. The latter concerns qualifying negotiation or conclusion of sales on behalf of only the payer or only the payee. A platform's label or a clause saying 'agent' cannot establish either route.

A launch checkpoint with real evidence#

• Obtain the principal's exact legal name, regulator, authorisation and permitted services.
• Confirm the platform's registered role and the countries and activities it covers.
• Align production UX, accepted terms and support scripts with those roles.
• Assign responsibility for customer due diligence, monitoring, complaints, safeguarding information and incidents.
• Agree return handling, data access and an orderly exit plan if the principal stops providing the service.

Choosing a home regulator and verifying registers#

National competent authorities grant authorisations and maintain national registers. The EBA central register aggregates information supplied by those authorities; the EBA does not grant a platform's licence. The EBA register guidance also says inclusion does not itself confer legal status and omission does not invalidate an authorisation.

Register-check procedure#

• Find the principal in its home national register using legal name and registration number.
• Confirm the entity category, current status, exact payment services and restrictions.
• Check relevant agent entries and cross-border coverage for the intended market and mode of operation.
• Cross-check the EBA register; investigate discrepancies with the principal and authority.
• Save the dated extract, URL, checker and conclusion, including what the register does not prove.

A register match does not prove that every API product, currency or proposed delegation is covered. Match the entry to the signed agreement and actual activity. Resolve an ambiguous agent-services entry rather than assuming it inherits every service of the principal.

For fully authorised institutions, passporting uses home/host notification procedures for the intended services and arrangement. It is not an automatic approval of every launch. Ireland's EMI passporting guidance distinguishes branches, agents/distributors and cross-border service provision.

Build the pre-launch evidence pack and approval log#

Follow a clear sequence: draft the facts, obtain legal assessment, review operational risks, record the decision and approve only the covered launch scope. Keep unresolved dissent visible. Application-processing periods that start with a complete file do not justify promising a fixed time from the first enquiry.

Translate the approved model into onboarding, payment-release and exception procedures. For related operating questions, see building a payout network and Gruv Docs. The legal model and the operational implementation need to describe the same parties and actions.

Set post-launch monitoring and escalation ownership#

These are operating-control suggestions; the exact mandatory cadence comes from the applicable law, regulator and principal arrangement. Link incidents to the approved product and control version. If a transfer's status is unknown, retrieve and reconcile it before initiating a replacement; a new provider route is not proof that the first transfer failed.

Common failure modes#

Conclusion#

Start with the actual flow of money and the customer's claim. Compare EMI issuance, PI payment services and the agent's defined role, then test capital, safeguarding, registration and cross-border requirements against the planned countries. Keep the approved scope linked to production controls and revisit it when the product changes. To discuss the operating workflow that follows that decision, contact Gruv.