The operating answer
An API, an SPI and an EMI are not interchangeable labels for the same business. Describe the activity, who contracts with the customer and what happens to funds before deciding which authorisation or registration route to investigate. [FCA]
The workflow below is our editorial synthesis. Regulatory statements link to primary sources. Examples are hypothetical, and applicability requires a firm-specific assessment.
Start with a transaction, not the company pitch
A company description might say that a product “moves money for businesses”. That phrase leaves unanswered who holds the account, who receives the instruction, which entity owes money to the customer and whether an amount is being issued as e-money. Those are more useful starting questions for a perimeter review than the name of the app.
Pick a representative transaction and write down its steps in ordinary language. Identify the payer, payee, contracting entity, payment account and other participants. Mark each place where an instruction, an account entry or actual funds change hands. Keep the commercial contract beside the diagram.
Next, list the variants. A domestic transfer, an international payout and a stored balance may look similar in a dashboard but differ in the underlying arrangement. Do not let the simplest product journey stand in for every service the company provides.
Separate entity, activity and distribution
Keep three columns in the perimeter file. The first identifies the legal entity. The second describes what that entity actually does. The third explains how the service reaches the customer, including agents, distributors, outsourcing and partnerships.
This prevents a recurring analytical mistake: treating the status of one company in a group as if it automatically covered every other company using the same brand. It also makes acquisition or restructuring projects easier to review because the mapping is attached to activities rather than to marketing labels.
Where the model relies on another firm, identify the responsibility boundary in the contract and in the real operating process. A service agreement may allocate tasks; it does not make an unanswered perimeter question disappear. Put any legal conclusion into a dated record, with its assumptions and the evidence considered.
What the institutional categories tell you
The FCA distinguishes authorisation as an authorised payment institution from registration as a small payment institution. Its PI applicant guidance gives the relevant SPI conditions, including the average monthly transaction threshold and restrictions concerning account information and payment initiation services. Treat the full criteria as the test, not just a turnover number. [FCA]
An e-money model needs its own analysis. Issuing electronic money and providing a payment service are related but distinct concepts. The FCA's current application material and Approach Document are the source trail for that work. [FCA]
For internal discussion, use a comparison sheet that captures activity, customer relationship, funds treatment, proposed status and unresolved questions. Avoid scores that claim one status is “better”. The useful answer is which route fits the service and which obligations follow.
Test the story against the contracts
Review what customers are actually promised. The app interface, terms, settlement schedule, merchant agreement and partner contract should describe compatible arrangements. Where they do not, create an issue rather than choosing the document with the most convenient wording.
Take a returned payment as a second test case. Who owes the refund? Where does the amount wait while an investigation is open? Who can instruct the provider? These questions often expose responsibility boundaries more clearly than a successful straight-through payment.
Keep the review proportionate but specific. A one-page money-flow diagram with named accounts and entities can be more useful than a lengthy policy that never identifies where the money goes. The diagram should show exceptions and manual interventions as well as the normal path.
Translate scope into an operating register
After the perimeter decision, create an obligation register. Each row should have the activity, the source provision, the owner, the operating control and the evidence that shows the control was performed. Where the rule is not applicable, preserve the reason rather than deleting the row without explanation.
The FCA's payments and e-money source library points to its current Approach Document. It is a better starting point for a revision check than a downloaded copy with no visible edition. Keep the version and review date in the register so another person can repeat the research. [FCA]
The register should also contain change triggers. A new country, an additional payment service, a revised customer contract or a change to a partner may make an old analysis unreliable. Give someone responsibility for deciding whether the perimeter file needs to be reopened.
Do not confuse a register check with legal analysis
A public register check helps establish the status and permissions recorded for a particular entity. It does not independently describe every product flow in your business. Use it as one evidence item in the review, not as the conclusion.
Save the exact entity name and reference number alongside the time of the check. If a trading name appears on the customer-facing service, explain how it connects to the legal entity. Where the service depends on an agent or representative arrangement, record the principal and the relevant limitations.
If the records, contract and actual process do not match, stop short of an approval label. Assign the discrepancy to the right owner. The site's register worksheet is designed to make gaps visible; it does not verify a firm or grant permission.
A small operating test before launch
Walk a transaction through the proposed process with finance, operations and compliance in the same room. Ask each team to identify its hand-off, input and output. Write down where explanations differ. Those differences should be resolved before the operating model is treated as complete.
Then repeat the exercise for a failed instruction and a provider outage. The point is not to manufacture an exhaustive catalogue of every possible event. It is to check that the responsibility boundary remains intelligible when the service does not work normally.
Close the session with a short list of decisions, missing evidence and owners. An unresolved issue should have a proposed next action. “Legal to confirm” without a defined question does not help the reviewer understand what is actually uncertain.
What a useful conclusion looks like
The output is a documented activity map, not a generic declaration that the company is regulated. It identifies the entity, the services examined, the contracts relied upon, the source versions used and any limits to the analysis.
For a launch approval, distinguish the parts already operating from those still proposed. A future partner contract, an unfinished system integration or a permission not yet obtained should not appear as a completed control. Keep an explicit dependency list and a change log.
This playbook is an editorial framework for organising the work. It is not a determination of a regulatory perimeter, an application decision or legal advice. A qualified reviewer should resolve the activity-specific conclusions before the business relies on them.
| Question | Record to examine | Unresolved issue to capture |
|---|---|---|
| Who contracts? | Customer terms | Brand and entity mismatch |
| Who receives funds? | Account and provider agreements | Unknown legal holder |
| What is the service? | Transaction map | Payment / e-money boundary |
| How is it distributed? | Agent and outsourcing arrangements | Unclear responsibilities |
Working checklist
Progress is saved only in this browser when local storage is available. Ticks record your work; they are not a compliance score.
Method, assumptions and limits
We use official sources for regulatory facts and label our suggested workflows as editorial methods. Illustrative examples are hypothetical. The content does not establish the position of any individual firm and is not a prescribed regulator template.
Source review date: 12 November 2026. No automatic monitoring is running. Check the underlying document, applicable entity, activity and jurisdiction before using this material.
Read the full methodologyQuestions, answered.
Can a company choose SPI status only because it is small?
No. The full conditions and service restrictions matter. Use the FCA applicant guidance and assess the actual activity.
Does a partner’s authorisation cover our business automatically?
No blanket conclusion follows from a commercial partnership. The legal role and distribution model need a separate assessment.
Is an obligation register required in this exact format?
This format is an editorial working aid. It is not an FCA-prescribed form.
Sources & scope
Primary sources used for this research edition. Document dates and commencement dates are different fields. Recheck the issuing authority before acting.
- FCA: Payment Services Regulations and Electronic Money RegulationsRegulatory overview · source reviewed 12 November 2026
- FCA: Apply to become an e-money or payment institutionApplication guidance · source reviewed 12 November 2026
- FCA: Payment institution applicantsApplication guidance · source reviewed 12 November 2026
- FCA: Payments and e-money: key publications and current Approach DocumentSource library · source reviewed 12 November 2026