Do You Need FCA Authorisation for a UK White-Label Banking App?

A white-label app does not automatically need its own FCA authorisation, but a partner's licence is not a blanket exemption. Let's examine the activities, roles and launch checks UK founders and CFOs must assess before committing budget.

On this page

In brief

  • FCA requirements depend on the app company's actual activities, contracts and funds flow rather than its branding or access to an authorised provider's API.
  • A partner-led launch needs a documented role as an appropriate technical supplier, registered payment-services agent or e-money distributor within the provider's scope.
  • Agent status does not confer an independent licence, and e-money distribution does not authorise the distributor to issue e-money or provide separate payment services.
  • Providing regulated services independently requires the applicable authorisation or registration, while avoiding possession of funds does not automatically exclude account information or payment initiation services.
  • Launch readiness requires verified permissions, accurate disclosures, allocated responsibilities and tested financial, security and recovery controls.

Which Activities Bring Your App Within the Regulatory Perimeter?

The regulatory perimeter depends on the services your company provides and its legal responsibilities, rather than the app's branding. There is no standalone UK ""white-label banking licence"". Assess payment services under the Payment Services Regulations 2017 (PSRs), e-money issuance under the Electronic Money Regulations 2011 (EMRs), and deposit-taking under the separate banking authorisation framework.

Start by mapping each customer journey to the legal entity responsible. Identify who contracts with the customer for the financial service, operates the payment account, receives and holds customer funds, executes transfers, and issues any e-money. Check both contractual obligations and actual operations: a branded interface or an outsourced API does not, by itself, establish which company provides the regulated service.

Schedule 1, Part 1 of the PSRs identifies the following payment services when carried on as a regular occupation or business activity, subject to the exclusions in Part 2. Use these categories to assess the proposed app's functionality.

Proposed activity

Payment service to assess

Enabling cash deposits or withdrawals and operating the associated payment account.

Services under Schedule 1, paragraphs 1(a) and 1(b).

Executing bank transfers, standing orders, direct debits or card payments.

Execution of payment transactions under paragraph 1(c), or paragraph 1(d) where a credit line covers the funds.

Issuing payment cards or other payment instruments, or contracting with merchants to accept and process payments.

Issuing payment instruments or acquiring payment transactions under paragraph 1(e).

Receiving money to transfer it to a recipient without opening payment accounts for the payer or recipient.

Money remittance under paragraph 1(f).

Initiating an online payment order, at the user's request, from an account held with another payment service provider.

Payment initiation services under paragraph 1(g).

Providing consolidated online information about one or more payment accounts the user holds with other providers.

Account information services under paragraph 1(h).

Never holding customer funds is not enough to remain outside regulation. Payment initiation and account information services can fall within the PSRs without the app company possessing the money. The technical service provider exclusion can cover supporting activities such as data processing, authentication and IT infrastructure where its conditions are met, including never possessing the funds being transferred. It expressly excludes payment initiation and account information services. Providing those services must therefore be distinguished from supplying technical support to their regulated provider, as explained in the FCA's payment-services perimeter guidance.

Other exclusions are narrowly defined. The limited-network exclusion may cover qualifying restricted-use instruments, but should not be assumed to cover a general-purpose payment app; relevant transactions exceeding €1 million in any 12-month period trigger FCA notification. For marketplace models, the commercial-agent exclusion requires authority to negotiate or conclude sales for either the payer or the payee, not both. Simply processing payments is insufficient, and this exclusion is distinct from registration as a payment-services agent.

A stored-value wallet also requires a separate e-money assessment. Broadly, e-money is electronically stored monetary value that represents a claim against its issuer, is issued when funds are received for making payments, and is accepted by someone other than the issuer, subject to statutory exclusions. Identify which entity owes that value to the customer. Issuance falls under the EMRs; payment transactions using the balance may also fall under the PSRs. A wallet label alone does not determine the classification. The FCA's e-money perimeter guidance explains the relevant definitions and exclusions.

Deposit-taking is a distinct activity. Holding funds for payments or issuing e-money does not automatically make a company a bank. If your app company itself carries on regulated deposit-taking, it needs the relevant banking authorisation from the Prudential Regulation Authority (PRA), with FCA consent. Payment institution or electronic money institution status does not confer permission to accept deposits.

This activity map establishes what needs regulatory coverage. The next question is which services your company will provide itself and which an authorised provider will supply under the proposed operating model.

When Can You Launch Through an Authorised Provider?

You can launch a branded app through an authorised provider when the proposed activities fit that provider's permissions and your business has a lawful, documented role in delivering them. A commercial agreement or access to an API is not enough. Identify who supplies the financial service, who contracts with the customer and what your company actually does at each stage of the payment journey.

There are several possible arrangements, with different boundaries:

Your role

What the arrangement can support

Boundary to verify

Technical or outsourced service provider

Supplying software, interfaces or operational support to the regulated firm.

The activities must genuinely remain within that role; the contract label does not decide the regulatory perimeter.

Payment-services agent

Providing agreed payment services on behalf of a payment institution or EMI.

The principal must obtain FCA registration of the agent before those services begin, and the activities must fit its permitted scope.

E-money distributor

Distributing or redeeming e-money on behalf of an EMI.

This role alone does not require FCA registration as a payment-services agent. It does not permit e-money issuance; providing payment services as well requires the appropriate regulatory arrangement.

The FCA's May 2026 Approach Document explains that an EMI cannot issue e-money through an agent or distributor, and that principals remain responsible for their agents' acts and omissions. The issuing institution must therefore remain identifiable behind the branded experience. An agency arrangement is not a transferable licence for unrelated services.

For example, a branded payment-account app might display balances and collect customer instructions while an EMI issues the e-money and executes the agreed payment services. If the app company provides payment services as the EMI's agent, it must be registered before doing so. If it only supplies technology supporting the EMI's own service, a different analysis applies. Screen branding, customer support or collecting onboarding information alone cannot settle that distinction.

For a bank-partner model, the appropriately authorised bank must provide the deposit account and remain responsible for the deposits. The app company's own activities still require a separate perimeter assessment; the bank's authorisation does not automatically cover them.

Do not rely solely on the fact that your company never holds customer funds. The technical-services exclusion has conditions and does not include account information or payment initiation services themselves, as the FCA's payment-services perimeter guidance explains. Assess who provides those services to the user rather than assuming that routing instructions are always unregulated.

The principal must also perform appropriate due diligence, assess agent management and maintain effective controls and ongoing oversight. Where Consumer Duty applies, this includes monitoring communications, support and customer outcomes delivered through agents and distributors, as highlighted in the FCA's payments Consumer Duty review. Contractual allocation alone is insufficient.

Before treating the partnership as a viable launch route, obtain written agreement on the customer contract, funds flow, permitted activities and decision rights. Allocate onboarding, monitoring, complaints, payment restrictions and evidence retention to named parties. Verify the exact principal, its permissions and restrictions, and any required agent registration on the Financial Services Register. The partnership works only when the legal structure, actual customer journey and operating responsibilities describe the same service.

When Must Your Company Obtain FCA Authorisation or Registration?

Your company needs its own regulatory route where it provides an in-scope service in its own right and cannot rely on an applicable exemption, exclusion or properly structured principal arrangement. The assessment follows the actual contracts and activities, not whether the app is described as white-label or whether a supplier has an FCA reference number.

Proposed activity

Route to assess

Providing payment services as your business

PI authorisation, or small-PI registration where all conditions are met, unless another valid status or exclusion applies.

Issuing e-money as the entity owing its value to the customer

Authorised EMI status or qualifying small-EMI registration.

Providing only account information services

Registration as an account information service provider, subject to the applicable requirements.

Providing payment initiation services

Authorisation covering that service or a valid arrangement with an appropriately permitted principal.

Accepting deposits yourself

Bank authorisation through the PRA with FCA consent, rather than a PI or EMI permission.

The FCA application guidance distinguishes these routes. Small-institution regimes are conditional registrations, not blanket exemptions for early-stage businesses. Relevant limits, activities, management and establishment conditions must all be satisfied; small PIs and small EMIs cannot provide account information or payment initiation services under those registrations.

For small-PI registration, average monthly payment transactions must not exceed €3 million over the preceding 12 months, with projections used for new businesses. For small-EMI registration, average outstanding e-money must not exceed €5 million, while payment transactions unrelated to e-money issuance are subject to a separate €3 million monthly-average limit over 12 months. Outstanding e-money measures the value remaining in circulation, not revenue or payment turnover.

Obtaining the selected status requires an application supported by a business plan, governance and financial-crime controls, applicable capital and safeguarding arrangements, and evidence of operational readiness. AIS/PIS applicants must also have the required professional indemnity insurance or comparable guarantee. Budget for implementing and maintaining these arrangements, as well as preparing the application.

Never holding customer money is not sufficient to establish that an app is unregulated. Account information and payment initiation can be regulated without your business possessing funds. Likewise, an API connection to a licensed institution does not settle who provides the service to the customer.

A registered agent acts for its principal within an agreed scope; it does not acquire an independent licence to offer additional services. An e-money distributor cannot independently become the issuer merely by changing the branding or customer contract. Assess any new lending, investment or cryptoasset function separately.

Review the perimeter again when the operating model changes: taking over customer contracts, adding new flows, controlling execution or moving from referral to service provision can alter the analysis. Document the conclusion and obtain the necessary permission or registration before commencing the relevant activity. An application in progress is not permission to launch, and a supplier's commercial approval cannot replace the required regulatory status.

What Must Be in Place Before Launch?

Before a white-label app handles live customer activity, the implemented service should match the approved legal and operating model. Keep a launch evidence pack showing the funds flow, customer contracts, relevant permissions and the responsibilities accepted by each party. A working sandbox or signed software agreement is not sufficient.

  1. Confirm the perimeter. Identify who operates accounts, executes payments and issues e-money, and document your company's role for each function.
  2. Verify status. Check legal names, permissions, restrictions and any required agent registration on the Financial Services Register, including the effective scope before launch.
  3. Approve customer documents and outcomes. Ensure terms, fees, privacy information and support scripts identify the actual provider and explain the product accurately. Where Consumer Duty applies, define the target market, assess product suitability and fair value, test customer understanding, support vulnerable customers and establish outcome monitoring.
  4. Assign operational ownership. Name the teams handling customer acceptance, sanctions alerts, monitoring, complaints, fraud, refunds and regulatory escalation. Document risk-based customer due diligence, enhanced checks, ongoing monitoring, suspicious-activity escalation and reporting, record retention and staff training.
  5. Prove financial controls. Test complete payments, safe retries, failed transactions, statements and reconciliation, with approved treatment of exceptions.

Where safeguarding applies, identify the responsible institution and the records your company must supply. The FCA safeguarding requirements include the supplementary regime effective from 7 May 2026, with applicable reconciliation, resolution-pack, audit and monthly reporting obligations. Safeguarding is mandatory for relevant funds held by authorised PIs and for funds received in exchange for e-money by authorised and small EMIs; small PIs can opt in. Explain safeguarding separately from eligible-deposit FSCS protection and avoid implying that the app itself is a bank.

Security readiness should cover individual access, approval limits, protected credentials, audit trails and incident response. Test strong customer authentication in the relevant customer journeys and document any exemptions used. Establish data-protection roles and access rights for each processing activity. Test recovery from a provider outage and confirm that restored records reconcile to transactions already executed externally.

For qualifying Faster Payments and CHAPS transfers, agree who handles APP scam reimbursement, including claims, evidence, deadlines and funding. For payment-service and e-money complaints covered by the FCA complaint rules, plan for a final response within 15 business days. Qualifying exceptional circumstances permit a holding response within that period and a final response within 35 business days. Explain eligible customers' rights to refer complaints to the Financial Ombudsman Service.

Agree contractual service levels, change notices, record access, liability allocation and exit assistance. Price the staff and exception handling needed to deliver those commitments; a promise that compliance is included may exclude first-line support or complex investigations.

Use named approvals from finance, product, technology, operations and compliance or legal. Unresolved permission issues, unexplained balances or unsupported essential features should block release. Begin with a controlled cohort and limits, monitor customer outcomes and retain authority to pause new activity.

Keep the evidence current after launch. New features, customer groups, jurisdictions or counterparties should trigger a documented review before they are enabled, so the app does not gradually move beyond its approved arrangement.

Independent research

Ask AI whether Framnex fits your business.

Research Framnex with your preferred AI assistant and see where the platform may fit your client base, product and launch model.

The prompt will be prefilled. Review it before sending.

Next stepTurn your UK product requirements into a practical implementation plan.Discuss the infrastructure, partners and operating model for your use case.Book a discovery call