Business Analysis Process Model That Survives Change

The FCA reported that 97% of applications across its authorisation metric areas were determined within applicable deadlines in Q3 2025/26. That figure shifts the practical question for an applicant: rather than assuming an open-ended wait for a regulator, ask whether the application tells one complete, consistent story about the business. A business analysis process model built for authorisation should connect planned activities to permissions, risks, controls, evidence, owners and submitted answers.

Think of the application as a railway timetable. The business plan, financial forecasts, governance chart, policies and application answers are separate trains. They stay coherent only if shared junctions, such as the customer type, custody model or outsourcing arrangement, don't move without the other documents being updated. A tidy process diagram can show the route, but it can't prove that each claim has an owner, supporting evidence and approval.

The FCA's on-time determination figures in 2024/25 ranged from 98% to 99.3%, while 97.6% of UK electronic-money-institution authorisation applications met the processing target in 2024/25, compared with 90.1% in the previous year. Those results don't prove that every delay is caused by an applicant. They do make a dip in a later headline figure a reason to check file quality, not to assume regulator slippage. The FCA's Q1 2024/25 metrics covered applications received from April to June 2024 and included cryptoasset registrations under the Money Laundering, Terrorist Financing and Transfer of Funds Regulations 2017, service area A1.3.

The weak point in many process diagrams is the space between drafting and change. A responsible officer, customer segment or control can change after documents are underway, yet conventional workflows often don't show which policies, forecasts and answers must then be revisited. The FCA's Q3 2025/26 figure is useful context for that operational problem: incomplete or internally inconsistent materials can affect progression even where applications are generally being determined within deadlines. Treat the process as a dependency and impact-analysis system, not a linear checklist. For teams building repeatable workflows, practical AI workflows for project teams can help frame where automation supports coordination without taking ownership away from accountable people.

The work follows four connected jobs: scope the route, capture current and target requirements, map evidence, then control change. The result is a six-stage model a team can apply before drafting begins.

Table of Contents

• A Recommended Model for Authorisation Workflows
  • Close gates with evidence, not attendance
• Requirements Evidence and Quality Gates
  • Build the matrix around operating reality
• Who Owns Each Part of the Model
  • Put AI into the same control model
• How One Changed Fact Rewrites the Package
• A Stablecoin Use Case Walked Through the Model
  • Make the classification assumption testable
• Start With Scope Before You Draft

A Recommended Model for Authorisation Workflows

Use the six stages below as a work plan, not as a diagram to file and forget. The first step is to examine the client's planned activities, jurisdiction, existing material and open questions, then agree the work, deliverables and responsibilities. Each gate closes only when the named owner has signed the relevant artefacts and unresolved matters are recorded in a decision or evidence-gap log.

This staged approach has a useful precedent in HM Treasury's business-case process. Its Strategic Outline Case (SOC) establishes the strategic need and initial case for change; the Outline Business Case (OBC) develops and evaluates options; and the Full Business Case (FBC) confirms the preferred option, commercial approach, affordability and delivery arrangements before implementation. The Treasury approvals process requires the case to develop in phases, change as circumstances change and be reviewed before decision points.

Translate that logic into authorisation terms. The file should explain why the activity exists, which operating options were considered, and how the chosen model will work. It must also show that the proposed activity matches the permissions sought and that the business can operate it. The FCA's authorisation guidance expects the business model to be specific to the firm's activities and aligned with requested permissions. Technology descriptions should be clear about whether systems are off the shelf, modified or custom, and should include realistic readiness timelines.

Close gates with evidence, not attendance

A gate is a condition, not a meeting. A meeting can uncover a missing owner or unresolved assumption, but it doesn't close the gate until the evidence exists and the accountable person approves it. If an issue remains open, record who will resolve it and what evidence will settle it.

A changed fact should reopen the affected stage, not automatically restart the whole exercise. When a customer segment moves, for example, revisit the requirements and evidence rows that depend on customer type, then check downstream policies, forecasts and application answers. Teams can also use a relevant guide to when onboarding checks need re-verification to think through how changes to customer information affect review processes.

Requirements Evidence and Quality Gates

The working object inside the model is a requirements-to-evidence matrix. It turns a general workflow into a traceable chain from activity to permission, risk, control, evidence, owner and answer. Without that chain, the team may have a polished business plan but no reliable way to establish which document supports a particular regulatory assertion.

The FCA's application guidance makes the connection practical: the business model must fit the activities and permissions requested, and systems must be ready for those activities. Record at least the requirement or permission, business capability, process step, risk, control objective, control owner, system or data dependency, supporting document, source version, status and approval.

Build the matrix around operating reality

Mark whether each item describes the current state or a target state. If a control or system still needs to be established, record transition dependencies and acceptance criteria for readiness rather than describing the future arrangement as if it already operates. This matters particularly where a system is being configured, modified or built: unclear descriptions and unrealistic timelines weaken the account of how the business will function.

Keep key data objects controlled across the file: permissions, legal entities, products, customer types, jurisdictions, transaction flows, financial forecasts, governance roles and system capabilities. Apply consistent validation rules. Use a controlled vocabulary for regulated activities; check that named senior managers match their accountability statements; reconcile forecast volumes to operational capacity; and make policy versions effective from clear dates.

The UK Government Data Quality Framework defines fitness for purpose through accuracy, validity, consistency and timeliness. Its data quality guidance recommends assessing quality through the data lifecycle, not only at the end. In an application, that means checking for stale records and contradictions at each review gate, as well as confirming completeness and evidence coverage.

At each gate, track completeness, contradiction rate, stale-record rate and evidence-coverage percentage. Don't invent targets where none have been agreed. Require final sign-off only when critical defects are at zero. For a practical explanation of how supporting material strengthens an application, see evidence in regulatory applications.

Operating rule: Every material regulatory assertion needs an accountable owner, documentary evidence and a defined validation test. Unresolved items stay on a decision or evidence-gap log.

If an application includes AI-enabled processes, an inventory of systems and dependencies can help analysts make that part of the evidence chain explicit. An AI bill of materials guide offers a useful way to consider what components and dependencies to record.

Who Owns Each Part of the Model

A matrix without named owners becomes an analyst's private spreadsheet. Assign responsibility for the underlying facts to the people who can confirm them, and let the analyst coordinate the record rather than approve facts on someone else's behalf.

The business owner should confirm how services will operate. Compliance should own the permissions map and distinguish existing arrangements from controls still to be built. Finance should reconcile figures with the written account, including the relationship between forecast volumes and operational capacity. Technology should describe systems, dependencies and a realistic readiness path. Each senior manager should be ready to explain the responsibilities attached to their name. For UK firms applying the Senior Managers Regime, the FCA Senior Managers Regime overview is relevant when mapping accountabilities.

Put AI into the same control model

AI is an operating-model question, not a separate technology appendix. The Bank of England and FCA found that 75% of surveyed firms were already using AI, with a further 10% planning adoption within three years. 55% of reported AI use cases involved some autonomous decision-making, while 2% were fully autonomous, according to their report on AI, DLT and quantum computing.

The same source reports that 26% of firms had no or limited controls ensuring AI systems complied with laws and regulations. It also reports that 48% were already using agentic AI and a further 16% planned adoption within six months. Those findings make a clear case for recording AI evidence in the matrix: use-case materiality, decision authority, affected customers, control owner, human override, data lineage, validation evidence, monitoring metric, incident escalation and regulatory-change impact.

Start with use cases that influence financial-crime decisions, customer support or internal processes. Ask who reviews the output, what happens when the system is wrong, and who can pause or override it. Interview preparation should then test the named owners' ability to explain the arrangement. Focused rehearsal can expose questions that still need work before an applicable interview, rather than leaving managers to discover gaps when asked to account for their controls.

How One Changed Fact Rewrites the Package

A change made after drafting starts should trigger a traceable impact review. The second step of an authorisation service should bring the business plan, financial information, policies and application answers together, review the documents, resolve findings and revisit affected material when facts change. Use this procedure whenever an assumption moves:

1. Record the change. Capture the old value, new value, date and person who authorised it.
2. Classify the fact. Mark it as a customer segment, product, jurisdiction, outsourcing arrangement, responsible individual, control, system or financial assumption.
3. Search the matrix. Find every row that names or depends on that object.
4. List affected artefacts. Include the business plan, financial model, policies, procedures, organisational description, application answers, evidence register and interview narrative.
5. Specify the edit. For each artefact, record whether it needs new wording, a changed figure, a new owner or a version note.
6. Reopen affected gates. Recheck only the conditions the change may have invalidated, not the whole project by default.
7. Obtain fresh approval. Store the signed impact log with the package.

Suppose the person responsible for safeguarding changes. The governance chart, accountability statement and policy owner must be updated. If that person also approves financial promotions, the approval arrangements and related evidence must change too. The interview brief must name the replacement and reflect the revised responsibilities. Don't assume a first sign-off remains valid after the underlying fact changes.

That discipline is consistent with the staged approach in HM Treasury's business-case process: assumptions and evidence are tested progressively, and the case is reviewed as circumstances change. The same principle matters when teams bring together the business plan, financial information, policies and application answers, resolve review findings and revisit affected documents after a fact moves.

The UK Government Major Projects Portfolio illustrates why teams need continuous review rather than optimistic sign-off. At the end of March 2025, 213 projects had published Delivery Confidence Assessment ratings; 14% were Green, 63% Amber, 15% Red and 8% exempt. The NISTA annual report describes Amber projects as feasible but requiring management attention, while Red projects had major issues that did not appear manageable or resolvable at that stage. For an authorisation file, end the impact log by answering one question: which artefacts, controls, owners and answers were revisited, and where is the sign-off?

A Stablecoin Use Case Walked Through the Model

Start with classification, not policy drafting. A sterling stablecoin proposition needs an activity map that distinguishes a coin used to buy and sell cryptoassets from a coin that could become widely used for payments or other systemic purposes. The Bank of England's proposed regime covers systemic sterling stablecoins, while stablecoins used for non-systemic purposes such as buying and selling cryptoassets would generally fall under FCA supervision. The Bank of England's consultation announcement sets out the proposed distinction.

The proposal includes temporary holding limits of £20,000 per coin for individuals and £10 million for businesses, with an exemptions regime allowing the largest businesses to hold more where required. It would also permit systemic issuers to hold up to 60% of backing assets in short-term UK government debt. Keep those proposed thresholds beside the business-plan assumptions, not buried in an appendix.

Make the classification assumption testable

The evidence register should capture intended use, user base, payment function, scale, reserve composition, safeguarding or reserve policy, and governance. Those facts help determine which regulatory route and operating arrangements the business is proposing. If the firm expects business-user balances above £10 million, or shifts from crypto trading towards everyday payments, record that as a change event. Reopen the regulator hypothesis, financial assumptions, reserve policy and answers describing the use case.

Intended use, scale, payment function, reserve mix and user base can change both the supervisor and the prudential constraints.

A custody or outsourcing change may not alter the regulator, but it can still change control owners, system descriptions and the financial capacity the firm needs to support its operations. The impact log should identify those connected documents rather than treating the change as a narrow contract update.

For a more detailed UK context, use Glentorion's overview of UK stablecoin regulation. After the exercise, write down three things: the classification assumption, the evidence supporting it and the trigger that would force the team to re-scope.

Start With Scope Before You Draft

The first working session should settle the business activity before anyone rewrites a policy. Ask, in order: which activity and market are being entered; what material already exists; which questions are blocking preparation; and what professional help, if any, is required. Those answers become a permissions shortlist, an open-question log and an agreed set of deliverables with responsibilities.

The Discovery Call covers the activity and market the client wants to enter, the client's current stage and available material, the questions holding preparation back, and the scope of professional help needed. A team can use the same questions internally. If financial-crime controls are part of the proposed model, a financial-crime risk assessment guide can help frame what the business needs to understand before it writes procedures.

Don't start in the drafting tool. A policy written before the activity, customer and jurisdiction are fixed is likely to need revision when a core fact moves. If no one can own a critical data object, such as a forecast assumption or system capability, assign an owner before producing another template. The scope gate should close only when the deliverables and responsibilities are agreed, every matrix row has an owner, and the team knows which change would force a re-scope.

---

Glentorion combines regulatory consultants with software, systems and AI engineers to scope, prepare and review authorisation applications, connect evidence to the business model, and prepare management teams for regulator interviews. If you're planning a UK financial-services or crypto application, visit Glentorion to discuss the route, deliverables and responsibilities before drafting begins.