By: Money Navigator Research Team
Last Reviewed: 24/01/2026
FACT CHECKED
Quick Summary
Many app-based business “accounts” are not bank accounts in the legal sense. Some are provided by banks (deposit-taking firms regulated by the PRA and FCA), while others are provided by e-money institutions (EMIs) or payment institutions regulated by the FCA.
The quickest way to tell is to identify the legal entity behind the app and check its status and permissions on the FCA Register.
This matters because bank deposits and e-money balances work differently (including how safeguarding and FSCS cover apply).
This article is educational and not financial advice.
Are app-based business accounts always “banks”?
Not necessarily. A modern business finance app can be one of several structures:
Bank account: the provider is a bank (deposit-taker). The FCA Register entry typically shows the firm is authorised by the PRA and regulated by the FCA.
E-money account: the provider issues e-money and holds customer funds under safeguarding rules (not deposit-taking).
Payment account without e-money: the provider offers payment services (for example, money transmission) and may safeguard certain funds under payment-services rules, depending on the product.
The FCA flags this confusion directly in its consumer guidance on using payment service providers, including that the FCA Register can show whether a provider is a bank or a non-bank payment provider, and that brand names may differ from the authorised firm name: FCA guidance on using payment service providers.
For the safeguarding angle (and how it differs from bank deposits), these internal guides provide the deeper mechanics:
Why provider status matters
1) “Account” in the app doesn’t always mean “deposit”
Banks take deposits; e-money firms issue e-money and safeguard relevant funds. The practical user experience can look similar (sort code/account number, cards, transfers), but the underlying legal structure can be different.
2) “Cover” depends on the product and the firm type
FSCS publishes product-by-product limits and eligibility rules for compensation, including the deposit limit for banks, building societies and credit unions: FSCS compensation limits and eligibility (what we cover).
That same FSCS page is useful because it anchors what “deposit” means in practice: the limit applies to eligible deposits held with UK-authorised deposit-takers, not to e-money balances.
3) Brand names can be misleading
Apps often market a consumer-facing brand while the regulated entity is a different company in the group (or a partner). The FCA explicitly notes this brand-name mismatch risk in its consumer payment provider guidance: How to identify a non-bank payment provider on the FCA Register.
The FCA Register: what it is and what it can tell you
The FCA describes the Financial Services Register as the public record of firms and individuals that are (or have been) authorised by the FCA or PRA: FCA page explaining the Financial Services Register.
The FCA also publishes a detailed handbook document explaining that the Register includes firms registered under, among other regimes, the Payment Services and Electronic Money regulations: FCA Register Extract Service handbook (PDF).
To search, the FCA’s Register front-end sits here: FCA Register search.
How to check whether the provider is a bank or an e-money/payment firm (step-by-step)
Step 1: Identify the legal entity behind the app brand
The FCA notes that brand names are not always what appears on the Register, and the underlying company name is often in the website footer or terms: FCA guidance on payment providers and brand names.
What to capture (for accurate matching):
the legal company name
the Firm Reference Number (FRN) if it’s shown (often in legal/terms pages)
any named partner bank or regulated entity (sometimes disclosed as the “provider of e-money” or “account is provided by…”)
Step 2: Search the FCA Register by firm name (or FRN)
Use the FCA Register search: FCA Register search.
If two firms have similar names, the FRN is the cleaner identifier. The FCA’s agent-related guidance also highlights using reference numbers and checking authorisation/registration on the Register: FCA guidance referencing agents and Register checks.
Step 3: Read the firm’s “status” first
The FCA explains how status labels (including firms that are no longer authorised or revoked) should be interpreted in its consumer guidance on authorisation checks: FCA: how to check a firm is authorised.
In practice, the key question is: is the firm currently authorised/registered for the activity the app is offering? (For example, deposit-taking vs issuing e-money vs providing payment services.)
Step 4: Look for regulator and firm type signals
Typical patterns on the Register:
Bank (deposit-taker): often shown as PRA-authorised (with FCA regulation alongside).
Non-bank payment provider: the Register may describe it as an EMI or payment institution.
To cross-check deposit-takers at a high level, the Bank of England publishes PRA-regulated firm lists and explains their update cadence: Bank of England: which firms the PRA regulates.
Step 5: Check what the firm is permitted to do (permissions/activities)
This is where “bank vs e-money” becomes concrete. The FCA’s firms section groups information for electronic money and payment institutions and links into its approach documents and regulatory framework: FCA overview: electronic money and payment institutions.
Step 6: Consider whether the app is an “agent” of another regulated firm
Some apps operate as agents of an authorised/registered payment institution rather than being the principal firm themselves. The FCA explains that principal firms must register their agents and that the Register can be used to check both the payment institution and its agents: FCA guidance on agents of UK payment institutions.
Practical reading: if the brand doesn’t clearly appear as an authorised firm, it may still appear as an agent entry connected to a principal firm (the regulated entity).
Summary table
| Scenario | Outcome | Practical impact |
|---|---|---|
| App is a bank (deposit-taker) | Register indicates PRA-authorised bank status | Deposit rules and FSCS deposit cover may be relevant (subject to eligibility) |
| App is an e-money firm (EMI) | Register indicates e-money permissions/registration | Balances are structured as e-money; safeguarding mechanics become the key question |
| App is a payment institution (not an EMI) | Register indicates payment services permissions/registration | The product may be a payments account/service; safeguarding depends on the service design |
| Brand name differs from legal entity | Search results don’t match the app name | The check needs the underlying company name/FRN |
| App is an agent of a payment institution | Agent relationship exists under a principal firm | The principal firm’s permissions matter; agent status affects who is responsible for compliance |
| Firm shows “no longer authorised”/revoked | Authorisation has been cancelled | The Register indicates the firm is not currently authorised for regulated activity |
Interpreting what you find: common outcomes
If the Register shows a bank
Bank entries frequently show PRA authorisation and FCA regulation. For a second reference point, the Bank of England explains that it publishes monthly lists of PRA-regulated banks and similar firms: Bank of England: PRA-regulated firms lists.
If the Register shows an e-money institution
The account may still have UK sort code/account details and support transfers, but the balance is typically e-money rather than a deposit. For the operational mechanics, these internal guides expand on what safeguarding means in day-to-day terms:
If the Register shows a payment institution (including “small” payment institution)
Payment institutions can provide payment services under the FCA regime. The FCA’s payment and e-money firm pages set out the regulatory categories and the broader framework: FCA overview: e-money and payment institutions.
Scenario table
| Scenario-level | Process-level | Outcome-level |
|---|---|---|
| Bank-provided app account | Check FCA Register entry for PRA-authorised bank status and relevant activities | Treated as a bank account; deposit framework applies to eligible deposits |
| EMI-provided app account | Check FCA Register entry for EMI status/permissions | Treated as e-money; safeguarding is the key customer-funds mechanism |
| Payment institution account/service | Check FCA Register entry for payment-services permissions | Payments service; safeguarding depends on service structure and timing of funds |
| White-label/brand mismatch | Identify legal entity name/FRN, then search the Register | Brand may not appear as the authorised firm name |
| Agent model | Identify principal firm and agent relationship via FCA guidance | Permissions sit with the principal firm; agent status is a separate check |
| Status not current | Review “no longer authorised” or revoked labels per FCA guidance | Not authorised for regulated activity at present |
Compare Business Bank Accounts
App-first accounts can be banks or non-bank payment providers, but they’re not interchangeable in how they’re structured behind the scenes. A bank account is tied to deposit-taking; e-money and payment accounts are tied to the FCA’s payment/e-money regimes and safeguarding concepts.
For broader context on business bank accounts (features, fees and comparison framing), see our hub: Business bank accounts. For the “bank vs e-money” customer-funds comparison, this internal explainer stays focused on the mechanism rather than features: Safeguarding vs deposit cover: EMI vs bank differences.
Frequently Asked Questions
No. An app interface doesn’t determine whether the underlying product is a bank account. Some app-based providers are banks (deposit-takers), while others are EMIs or payment institutions regulated under the FCA’s payment and e-money regimes.
The FCA explicitly addresses this in its consumer guidance on using payment service providers, including that the FCA Register can indicate whether a provider is a bank or a non-bank payment provider: FCA guidance on using payment service providers.
An EMI is a firm authorised/registered to issue electronic money and provide certain payment services. In practice, it often means the “balance” in the app is structured as e-money rather than as a bank deposit.
The FCA groups this regime under its e-money and payment institutions section, which links into the relevant regulatory framework and approach materials: FCA overview: electronic money and payment institutions.
An EMI issues e-money; a payment institution provides payment services (and may or may not issue e-money depending on permissions). Some payment institutions are “small” payment institutions under the FCA framework.
From a user’s perspective, the difference can show up in how balances are legally structured and how customer funds are handled. The FCA Register and the FCA’s e-money/payment institutions pages are the official starting points for identifying the category: FCA Register and FCA overview: electronic money and payment institutions.
The FCA notes that brand names may not match the authorised firm name on the Register, and the underlying company name is often shown on the provider’s website or in its terms: FCA guidance on brand names vs authorised firms.
In practice, the legal entity name is often displayed in the website footer, legal section, or account terms as the “provider” of the account/e-money/payment services.
An FRN is a Firm Reference Number used to identify firms on the FCA Register. It’s a cleaner identifier than a brand name because firms can have similar names or multiple trading names.
The FCA references using the Register and reference numbers when checking payment institutions and their agents: FCA guidance referencing Register checks and reference numbers.
The FCA explains that these labels mean the firm’s authorisation has been cancelled and the firm is not currently authorised for regulated activity: FCA: how to check a firm is authorised.
This matters because an account/service offered today should align with a firm’s current status and permissions, not only historic status.
A bank typically appears as PRA-authorised (with FCA regulation alongside) on the Register record. That regulator split is a useful signal that the firm is a deposit-taker rather than a non-bank payment provider.
For additional context, the Bank of England explains it regulates banks and publishes updated lists of PRA-regulated firms: Bank of England: which firms the PRA regulates.
In some models, the consumer-facing brand is an agent of a principal firm (the authorised/registered payment institution).
The FCA describes that principal firms must register details of their agents and that the Register can be used to check both the payment institution and its agents: FCA guidance on agents of UK payment institutions.
This can explain why searching the brand name alone sometimes fails: the regulated permissions sit with the principal firm, while the brand may appear as an agent entry.
FSCS publishes eligibility and compensation limits by product type, including deposits at banks, building societies and credit unions (with limits depending on timing and eligibility): FSCS compensation limits and eligibility (what we cover).
Whether FSCS cover applies depends on what the product is (deposit vs e-money) and who the regulated firm is. The FCA Register check is therefore a practical first step in working out which regime is relevant.
For e-money firms, the process is usually driven by safeguarding arrangements and the insolvency process rather than deposit repayment mechanics. Timing can vary depending on reconciliation, claims, and how safeguarding is structured.
For the typical access steps and delays during provider failure, these internal guides focus specifically on what happens next and what can slow access:
The recurring failure point isn’t usually regulation itself – it’s identity. The app’s brand, the regulated entity on the FCA Register, and the operational partner (bank, processor, programme manager) can be three different names.
The FCA flags this brand-name mismatch directly, and that’s why the cleanest workflow is:
- Identify the legal entity
- Confirm the Register status
- Read the permissions/activities
- Then interpret what that implies about how the “account” is structured in practice
Sources & References
Related Content
