The operating answer
The FCA requires a supported application, not a promise to design the business after authorisation. Build a traceable account of the proposed services, resources, controls and responsible people. Application readiness is different from permission to operate. [FCA]
The workflow below is our editorial synthesis. Regulatory statements link to primary sources. Examples are hypothetical, and applicability requires a firm-specific assessment.
Prepare a coherent application, not a pile of policies
Create a simple cross-reference between the programme of operations, financial model, governance chart and control descriptions. A product mentioned in the business plan should appear in the activity map. A team named as a control owner should exist in the resource plan. An outsourcing dependency should have a corresponding explanation in the operating model.
The FCA's PI guidance identifies supporting material including the business plan, financial information, people, qualifying holdings, capital, governance, safeguarding where applicable and other operating arrangements. Use the current list as the completeness baseline. [FCA]
The editorial checklist below organises the work around consistency. It is not a replacement application form. Follow the actual application instructions for the submission, and record why any requirement is not applicable rather than leaving a blank that can be mistaken for an omission.
The programme of operations is the spine
Describe each proposed service separately. Identify the target customer, geography, distribution model, transaction journey and legal entity. Be specific about what will be available at launch and what belongs to a later phase.
A staged product roadmap is not inherently a problem, but the assumptions must be visible. Mark permissions, partnerships, systems and recruitment that are not yet in place. The reviewer needs to understand which version of the business is being presented and which dependencies remain unresolved.
Use one vocabulary across documents. If “wallet”, “payment account” and “stored balance” are used differently by product, legal and finance, reconcile those differences before submission. Consistent naming reduces the risk that two documents describe incompatible models while appearing superficially aligned.
Capital is an analysis, not a badge
Build the capital analysis from the applicable route and services, rather than copying a figure from another firm's application. Explain the assumptions, the source of funding and the relationship between regulatory capital, operating cash and other financial resources.
Use a financial model that connects transaction volumes, fees, operating costs and headcount. Include a scenario in which the business develops more slowly than expected. An optimistic revenue line does not explain how the firm would fund its controls if that revenue fails to arrive.
Where the figures depend on an uncertain partner price or uncommitted funding, flag it. The purpose of the model is to make financial dependencies visible, not to make the application look finished. Keep the source and owner for each important assumption so that changes can be assessed across the file.
Name the people who run the controls
A governance diagram should show who decides, who operates a process and who reviews it. Connect the named roles to relevant competence and capacity. Avoid describing several full-time responsibilities as if one person can perform them all without trade-offs.
For each key control, identify a substitute. This is an editorial continuity check: who can perform the task if its usual owner is absent, and what evidence would they need? A process that relies on one person's undocumented knowledge is not well explained by a polished organisation chart.
Where work is outsourced, name the retained oversight responsibility inside the firm. The provider's service description does not answer how the firm will know that the service is operating as expected, how exceptions are escalated or how a change would be approved.
Demonstrate the process with a worked example
Take one proposed customer journey through onboarding, instruction, processing, reconciliation and support. Identify the records generated at each step. Then run an exception such as a failed payout or a disputed customer instruction.
Use clearly labelled synthetic data, not real customer information in an uncontrolled working document. The demonstration should show the process, the control decision and the retained record. Screenshots are useful only when they are connected to an explanation of what the reviewer is seeing.
Do not describe a test environment as an operating production control. Distinguish a designed process, a configured system, a completed test and a control already operating. Those are different evidence states and should not be compressed into the word “implemented”.
Check the safeguarding and wind-down dependencies
The application file should explain safeguarding where applicable and the governance and wind-down arrangements requested by the FCA. The firm's route and activities determine the relevant requirements. The current payments and e-money material should be used for the detailed assessment. [FCA]
A useful working test is whether the financial and operating models remain compatible in a wind-down scenario. Which contracts remain necessary? Which people are needed? What records must remain accessible? How are customer obligations identified?
Record assumptions that depend on third parties. A termination clause, service continuity arrangement or access condition may affect what the plan can actually deliver. Review the signed documentation rather than relying only on a sales conversation or an implementation slide.
Run an application consistency review
Ask a reviewer who did not draft the file to trace one product across every relevant document. Give them a fixed question: can they identify the proposed service, accountable owner, financial assumption, control and evidence without an oral explanation?
When an inconsistency is found, identify the source of truth and update every affected document. A correction in the business plan that is not reflected in the financial model can create a new problem. Maintain a change log with the decision, documents changed and reviewer.
Before submission, check that the files open, links resolve, versions are labelled and confidential material is shared through the intended channel. These are basic controls, but they are part of presenting a usable submission rather than merely assembling its components.
Use questions and follow-ups as a controlled workstream
After submission, keep an index of questions, owners, due dates and responses. Preserve the exact wording of the regulator's question before writing a response. A broad answer to a different question is not made more useful by adding more attachments.
A response should distinguish a clarification of existing information from a change to the business model. If something has changed, identify the related documents and explain the change clearly. Do not let the submission and the current operating plan drift apart silently.
No checklist on this site predicts approval or guarantees a timetable. The result is a better organised application file. The FCA makes the authorisation decision, and the firm remains responsible for the accuracy and completeness of what it submits.
| File component | Consistency test | Working output |
|---|---|---|
| Programme of operations | Do all products match the activity map? | Service inventory |
| Financial model | Do resources support the planned controls? | Assumptions log |
| Governance | Do roles have owners and capacity? | Responsibility map |
| Control descriptions | Can a sample demonstrate the process? | Test record |
| Submission | Do all documents describe the same version? | Version manifest |
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.
Does completing the checklist mean an application is ready?
It means the listed editorial checks have been recorded. It is not a regulatory readiness assessment or an approval prediction.
Can the same policy pack be reused for every API?
A useful application must reflect the actual activities, systems, people, resources and dependencies of the applicant.
Does this site provide an authorisation timetable?
No fixed approval timetable is promised. Use the FCA’s current process guidance and the status of the actual application.
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 institution applicantsApplication guidance · source reviewed 12 November 2026
- FCA: Apply to become an e-money or payment institutionApplication guidance · source reviewed 12 November 2026
- FCA: How to apply for authorisation or registrationApplication guidance · source reviewed 12 November 2026
- FCA: Payments and e-money: key publications and current Approach DocumentSource library · source reviewed 12 November 2026