Launching on someone else's licence: what EMI-as-a-Service really covers

A fintech or business that wants to offer regulated payment or e-money services faces a choice: apply for its own FCA authorisation, or operate as an agent or partner of an already-authorised Electronic Money Institution. The second path is often described as EMI-as-a-Service. This article explains what it typically covers, what questions to ask, and what it does not do.

What the licence actually provides

An FCA-authorised EMI holds a regulatory permission to issue electronic money and provide payment services under the Electronic Money Regulations 2011 (EMRs) and the Payment Services Regulations 2017 (PSRs). That authorisation covers specific activities: issuing e-money, executing payment transactions, and related services enumerated in the regulations.

When a business operates under an EMI's umbrella, it is typically structured as an EMD agent (Electronic Money Directive agent) or a distributor. In this structure, the EMI retains regulatory responsibility. The agent carries out activity in the name of, and on behalf of, the principal EMI. The EMI must register the agent with the FCA, and the agent's activities must fall within the scope of the EMI's authorisation.

What EMI-as-a-Service infrastructure typically includes

The practical content of an EMIaaS arrangement varies by provider. Commonly it includes:

• Safeguarding: client funds held by the partner are safeguarded under the EMI's regulatory framework, in segregated accounts at a qualifying credit institution. The EMI's safeguarding obligations extend to the partner's client funds.
• Payment rails access: the partner accesses payment infrastructure (SWIFT, SEPA, FPS, CHAPS) through the EMI's connectivity, rather than needing direct membership or sponsorship arrangements.
• API access: most EMIaaS propositions offer an API layer through which the partner can initiate payments, query balances, and access transaction data programmatically.
• Compliance infrastructure: AML/KYC screening, transaction monitoring, and sanctions checking are typically run by or through the EMI, though the partner may also have its own obligations depending on the arrangement structure.

What it does not cover

EMI-as-a-Service is not a blank licence. The activities the partner can carry out are limited to those within the EMI's own authorisation. If the partner wants to provide services not covered by the EMI's permissions, those require either a separate application to the FCA or a restructuring of the arrangement.

The partner also retains obligations of its own. Depending on the structure, it may need to register with the FCA as an agent, carry out its own customer due diligence (with the EMI setting the standards), and comply with applicable consumer duty or conduct requirements. Taking legal and compliance advice on the specific structure is important before building product on an EMIaaS foundation.

Questions to ask before you build

For a fintech evaluating an EMIaaS partner, some practical questions include:

• What is the scope of the EMI's FCA authorisation, and does it cover the activities you intend to offer?
• How is safeguarding structured for your clients' funds specifically?
• What is the API's capability set: can it support the payment volumes, currencies and corridors you need?
• What are the compliance obligations that fall to you as the agent, and what does the EMI cover?
• What does the service level agreement look like for payment processing and support?
• What happens if the EMI's authorisation is modified or withdrawn?

The speed-to-market argument

The most commonly cited advantage of EMIaaS is speed. Obtaining an FCA authorisation directly typically takes 12 to 18 months under the current FCA timeline. Operating under an existing licence, as an agent, can allow a business to go live considerably faster while the regulatory application (if it chooses to file one) is in progress, or indefinitely if the scale does not justify direct authorisation.

The trade-off is that the partner is operationally and contractually dependent on the EMI. The terms of that dependency, including termination provisions, data ownership, and what happens to client funds and records if the relationship ends, are among the most important things to understand before signing.

DigiDoe's EMI-as-a-Service proposition is described on the EMI-as-a-Service page. Specific terms and scope are subject to individual commercial and compliance assessment. Nothing in this article is a representation of what any specific arrangement will cover. This article is educational, not legal or regulatory advice.