UK EMI Authorisation vs BaaS: Costs, Responsibilities and Launch Requirements

What changes between your own EMI authorisation and white-label BaaS?

Obtaining your own EMI authorisation makes your company the authorised electronic money institution for the activities within its permission. An EMI is not a bank: "EMI banking licence" is an inaccurate description. Its e-money permission does not allow it to accept bank deposits, even if customers use an account number, payment card and banking-style app.

Banking-as-a-Service, or BaaS, describes an arrangement through which a business accesses financial services and supporting infrastructure from other providers. It is not a standalone UK regulatory permission. A white-label interface supplies your branding and customer experience; the regulated services underneath it depend on the legal entities, permissions and contracts involved.

Identify the customer's contractual counterparty for each service. An EMI-backed arrangement normally involves a claim on the e-money issuer for the relevant balance. A bank-backed arrangement may provide a deposit account, but the presence of a bank somewhere in the supply chain does not itself establish that the customer holds a bank deposit. The terms must explain who owes the money and what type of balance is provided.

That distinction determines the protection to describe. E-money is subject to safeguarding rather than FSCS compensation for failure of the EMI. Safeguarding does not guarantee immediate or full repayment: if the EMI fails, returning funds may take time, and customers may receive less than their full balance. Eligible deposits with a UK-authorised bank can receive FSCS protection, subject to the scheme's rules and limits. Therefore, neither the BaaS label nor a white-label account design proves that deposit protection applies. The FCA explains these different customer-funds protections.

The routes can coexist. An authorised EMI can buy a BaaS platform, outsource technical processing and use banking or card-scheme partners. The practical choice is which regulated activities your company will undertake itself, then which infrastructure and access relationships it needs to deliver them.

Who is responsible for compliance, customer funds and operational risk?

The operating model changes who performs each control, but it does not make regulatory accountability disappear. With its own FCA authorisation, the authorised electronic money institution is the e-money issuer and normally the regulated payment service provider. Its board remains responsible for governance, financial crime systems, safeguarding, regulatory reporting, complaints and operational resilience, even where technology or operations are outsourced. In a BaaS model, the regulated bank or EMI may carry those duties for the services within its permissions, while the customer-facing business acts as an agent, distributor or technology provider. The contracts, customer terms and actual flow of funds must identify the role precisely.

Safeguarding is not the same as deposit protection. If the product is e-money, the customer's claim is against the issuer and the funds are safeguarded; the balance is not an eligible bank deposit merely because the interface looks like a current account. FSCS deposit protection can apply only where the legal product is an eligible deposit with a covered bank, building society or credit union and the eligibility conditions are met. Marketing, terms and account screens should state which entity provides the regulated service and which protection applies.

For in-scope Faster Payments APP scam claims, reimbursement costs are generally shared equally between the sending and receiving payment service providers. The responsibility matrix should distinguish these obligations from any contractual allocation of costs between a BaaS provider and the brand. The PSR's consolidated policy explains the reimbursement responsibilities. The FCA also sets out its safeguarding requirements and Consumer Duty expectations for payments firms.

A practical responsibility matrix should name an owner, approver, evidence source and escalation path for every control. It should cover onboarding, transaction monitoring, safeguarding or settlement reconciliations, fraud prevention and reimbursement, complaints, customer-outcome monitoring, incidents, regulatory returns, data protection, business continuity and wind-down. The board should test the matrix against real scenarios such as a blocked payment, provider outage, APP scam claim, customer insolvency query or suspected money laundering. In both models, unclear ownership becomes operational risk; a supplier contract is useful only if controls, information rights and escalation routes work in practice.

What does each model cost to launch and operate?

The comparison should use total cost of ownership rather than a headline authorisation fee or BaaS subscription. Direct authorisation creates a larger fixed compliance and operating base, while BaaS converts more infrastructure into setup, minimum and usage charges. Neither route is cost-free: an authorised EMI will still need banks, schemes and technology suppliers, and a BaaS client still needs its own product, finance, risk and operational staff.

For a board comparison, build at least three volume cases over three to five years. Separate one-off spend, recurring fixed cost, unit-variable cost, regulatory capital, working capital and contingency. Apply realistic drivers such as active customers, monthly transactions, KYC retries, manual reviews, chargebacks, support contacts and peak settlement exposure. Show when minimum commitments or tiered prices change the unit economics.

Commercial due diligence should also test pass-through increases, indexation, minimum contract terms, currency conversion, scheme fines, fraud losses, liability caps and the treatment of failed or reversed transactions. For direct authorisation, include the cost of remediation if the FCA or an auditor identifies weaknesses; for BaaS, include the cost of a provider restriction, delayed change request or forced migration. The lowest year-one invoice is not necessarily the lower-risk or lower-cost model. A useful decision metric is the risk-adjusted cost per active customer alongside cash runway, gross margin and the cost of maintaining a credible exit option.

What must be ready before launch, and what determines the timeline?

A launch date should be the output of an evidence-based readiness plan, not a marketing deadline. Both routes require a defined product and regulatory perimeter, an approved customer journey, functioning controls and tested technology. The difference is whether the firm must first secure and operationalise its own FCA authorisation or satisfy a BaaS provider's onboarding and programme approval process. For direct authorisation, the essential arrangements and controls must be ready to meet applicable requirements from the date of authorisation, even if commercial launch occurs later. The FCA's readiness expectations should therefore inform the preparation plan.

• Product and legal design: define the customer, services, jurisdictions, payment flows, fees, limits, contracting entities and whether balances are e-money or bank deposits. Terms, privacy notices and financial promotions must match the legal model. UK authorisation does not provide EEA passporting rights; serving overseas markets requires a separate assessment of local regulatory requirements and any permissions needed. The FCA explains the implications of the end of passporting.
• Governance and financial crime: appoint accountable owners, document risk appetite, KYC and KYB standards, sanctions screening, transaction monitoring, fraud controls, escalation, suspicious activity reporting and management information.
• Funds and finance: map every movement from receipt to settlement, establish safeguarding or deposit arrangements, design reconciliations, confirm capital and liquidity, and prepare forecasts, stress cases and a wind-down approach.
• Technology and operations: complete API, ledger and webhook integration; test permissions, duplicates, reversals and cut-off times; prepare customer support, complaints, incident response, cyber security, business continuity and recovery.
• Third parties and exit: complete due diligence on banks, schemes, identity providers, cloud services and processors. Contracts should provide service levels, information and audit rights, change control, data access, termination assistance and an executable migration route.

The critical path is usually set by the slowest external approval or unresolved control gap. For direct authorisation, completeness of the FCA application matters: the Electronic Money Regulations provide a three-month determination period for a complete application and up to 12 months for an incomplete one, but those are determination limits rather than promised launch dates. Questions, remediation, capital evidence, safeguarding accounts and partner approvals can extend the programme. For BaaS, due diligence may move faster, but approval can still depend on the provider, its bank or scheme partners and their risk committees.

Complexity adds time. New or higher-risk customer segments, cross-border flows, cards, cash access, credit features, multiple currencies, bespoke compliance logic and legacy migrations create more policy, contracting and test work. Weak ownership data, generic policies, inconsistent forecasts or unclear funds flows cause avoidable rework. Capacity also matters: a provider's sales timetable is not the same as its compliance, implementation or production capacity.

Use gated acceptance criteria. Design is ready when the perimeter and funds flow are signed off; control readiness requires approved policies, trained staff and test evidence; technical readiness requires end-to-end reconciliation, failure and recovery tests; operational readiness requires support, complaints and incident rehearsals. Go live only after open risks have named owners and tolerances, customer disclosures are accurate, production access is controlled and both the regulated entity and dependent partners have issued the necessary approvals.

Launching with your own EMI authorisation

Direct launch begins with the legal entity and operating model, not the FCA form. An AEMI applicant needs suitable controllers and managers, a UK establishment that meets the applicable conditions, robust governance, adequate capital and a programme of operations that explains exactly how e-money and payment services will work. The application should be internally consistent across the business plan, customer journey, funds-flow diagrams, financial forecasts and policies.

The evidence pack normally covers the €350,000 minimum initial capital and the ongoing own-funds calculation; safeguarding arrangements; AML and sanctions controls; security and incident management; complaints; outsourcing; business continuity; wind-down; and the use of agents or distributors. Policies should be tailored to the proposed volumes, customers and technology. Named owners must be able to explain how controls operate and produce records, rather than relying on generic templates or an adviser.

1. Prepare and challenge: complete controller and manager checks, stress-test forecasts, validate the regulatory perimeter and run a board-level review of capital, safeguarding, operational risk and wind-down assumptions.
2. Submit and respond: file through FCA Connect with the correct non-refundable fee and complete supporting material. The statutory clock is three months for a complete application and up to 12 months for an incomplete application; information requests and remediation should be planned into the project.
3. Build in parallel: secure safeguarding accounts and required acknowledgements, banking and scheme relationships, and production suppliers. Configure the ledger, customer due diligence, monitoring, reporting, reconciliations, access controls and audit trail.
4. Prove readiness: test end-to-end funding, redemption, payments, reversals, failed settlements, safeguarding calculations, complaints and incidents. Train staff, approve customer terms and establish management information and escalation.

FCA authorisation is only one launch gate. The firm may still require bank accounts, payment rail or card scheme sponsorship, vendor approval and operational testing. Any agents must be governed and registered where required, and outsourcing does not transfer the EMI's accountability. Conditions or requirements attached to the authorisation must be satisfied before the corresponding activity starts.

Balances issued as e-money remain e-money; an account number, card or banking-style interface does not turn them into bank deposits. Customer communications should name the issuer, explain safeguarding and avoid implying FSCS deposit protection for the e-money balance. A controlled pilot with low limits and close reconciliation can expose defects before scale, but the board should approve the pilot as a real regulated service with full controls, not as an exemption from them.

Launching through a BaaS provider

A BaaS launch starts by identifying the regulated product beneath the white-label interface. Confirm whether the provider is a bank, an authorised EMI, or a technology platform relying on another regulated entity. Check the relevant public registers, permissions, customer contracting party and the proposed role of the brand. The answer determines who issues e-money or accepts deposits, who executes payments, and whether the balance is safeguarded e-money or an eligible bank deposit.

Provider selection should test more than API coverage. Review ownership and financial resilience, regulatory history, safeguarding or deposit structure, scheme and banking dependencies, financial-crime controls, operational resilience, incident handling, data locations, subcontractors, audit evidence and exit capability. Ask which approvals are controlled by the provider and which require a partner bank, card scheme or separate risk committee. A credible timeline identifies each decision-maker.

1. Programme onboarding: provide controller and business information, forecasts, target customers, jurisdictions, use cases, prohibited sectors, funds flows and expected transaction patterns. Resolve gaps between the product plan and the provider's risk appetite.
2. Legal role and registration: confirm and document the brand's legal role as a launch gate. If it will provide payment services as an EMI's agent, the principal must register it on the Financial Services Register before those services begin. Distributor status alone permits distribution and redemption of e-money, not the provision of payment services. Neither an agent nor a distributor may issue e-money on the EMI's behalf. See the FCA's guidance on agents and distributors.
3. Control design: agree a detailed responsibility matrix for KYC and KYB, sanctions, monitoring, manual reviews, fraud, complaints, safeguarding or settlement reconciliation, customer communications, incidents and regulatory requests.
4. Contract and disclosures: document service levels, fees, liability, change control, data rights, audit and regulator access, suspension triggers, termination, migration support and treatment of customers and funds on exit. Terms must name the regulated provider and accurately describe protection.
5. Integration and testing: build against the sandbox, then test production credentials, webhooks, idempotency, ledger postings, reversals, cut-offs, limits, manual queues, reconciliations, support handoffs, outages and recovery.

The customer-facing firm still needs competent product, operations, finance, security and compliance oversight. It may perform first-line checks or support, and it remains responsible for its own application, marketing, data handling and any obligations allocated to it. The regulated provider retains the duties that law and regulation place on it; a contract can allocate work and liability between the parties but cannot erase those duties.

Do not announce a date from a commercial proposal alone. Go-live approval may depend on completed KYB, signed terms, accepted policies and journeys, bank or scheme approval, passed testing, trained operations and a reconciled pilot. The brand's legal role must be confirmed and any required agent registration completed before the relevant services begin. Build contingency for enhanced due diligence, requested product changes and partner capacity. Before launch, obtain a production approval record, verified escalation contacts, access to customer and transaction data, and a tested exit plan so that dependency on the provider is understood rather than hidden.

Which route fits your fintech—and when should you reconsider?

Choose the route that fits the product's regulatory substance, scale and control requirements, not the label used in a sales deck. Own EMI authorisation can suit a business that wants to be the issuer, can fund capital and a permanent control environment, and expects enough scale or product differentiation to justify the fixed cost. BaaS can suit a narrower proposition that values earlier market entry and is willing to operate within a regulated provider's permissions, risk appetite, roadmap and commercial terms.

The models are not mutually exclusive. An authorised EMI may buy a ledger, compliance tooling, cards or payment connectivity, while a BaaS client may later seek authorisation. A staged strategy can therefore use BaaS to validate demand and build operating evidence, provided the contracts, data model and customer journey do not make migration impracticable. Conversely, authorisation should not be pursued merely to remove provider fees: it creates continuing regulatory accountability and does not remove the need for banks or schemes.

Reconsider the route when facts change. Triggers include volumes crossing a contractual tier, minimum fees eroding margin, new customer types or jurisdictions falling outside risk appetite, repeated approval delays, provider outages, poor reconciliation, rising complaints, a change of bank or scheme sponsor, altered safeguarding or capital requirements, or a provider restricting or ending the programme. For an authorised EMI, reconsider build-versus-buy choices when control functions are stretched, concentration grows or remediation consumes management capacity.

The board should review a three-to-five-year, risk-adjusted case at least at major funding, product and contract milestones. Compare cash cost, regulatory capital, working capital, launch probability, downside exposure and exit cost. Record who contracts with the customer, how money is protected, which entity can stop service, who owns the data and how customers would be moved if a partner fails. The right route is the one the business can operate safely through growth, stress and exit - not simply the one that appears quickest or cheapest at signing.