Evidence Explained for Authorisation Packs

Only 17% of determined UK cryptoasset registration applications resulted in registration, and 67% were withdrawn. A file that has been sent is not the same thing as a file a supervisor can test. Evidence explained, for an authorisation pack, means every material claim carries an owner, a record, and a status of live, staged or out of scope, so a future control environment can be proved without being dressed up as something that already runs.

Table of Contents

• Why Filed Applications Still Fall Away
  • What the rest of the pack has to do
• What Counts as Sufficient Evidence
  • How each row fails in practice
  • Provenance, not just the document type
• How to Trace a Claim to a Control
  • One customer, in the interviewee's words
• Proving Controls That Are Not Live Yet
  • Four blocks for a control that starts later
  • A bad sentence and a better one
• How to Keep an Evidence Package Coherent
  • The change routine
• Pitfalls That Stretch the Statutory Clock
  • What sits under those stages
• Check the Package Before You File

Why Filed Applications Still Fall Away

The FCA's cryptoasset registration record shows how often a submitted case never becomes a registration. The FCA became the supervisor of UK cryptoasset businesses under the Money Laundering Regulations on 10 January 2020. As of 1 October 2026, it had received 427 applications and determined 393. Only 68 applications, 17% of determined cases, resulted in registration. 46, or 12%, were rejected, 14, or 4%, were refused, and 265, or 67%, were withdrawn. In the preceding 12 months, 46 applications were received and 24 were determined: 12 registered, 2 rejected and 10 withdrawn.

Say a founder files a registration pack on a Friday and treats the acknowledgement as progress. Months later the case is withdrawn because the business plan, the financial model and the financial-crime manual describe three different customer types. Nobody refused the firm on the merits. The pack could not be tested as one story. Withdrawal is the common outcome in that record, which is why early scoping and cross-document checks are commercial work, not admin.

Evidence, in one sentence, is material a supervisor can use to test a claim about the business, the customers, the controls and the resources. It is not a folder of policies.

What the rest of the pack has to do

The path from here is practical. First, what counts as sufficient for each class of document. Then how a claim is traced to a control. Then how to describe controls that are not live yet. Then how the package stays coherent when facts change. Last, the pitfalls that restart questions even when the regulator's own clock is being met.

Counsel often assemble that bundle as PDFs. PDFWix tools for lawyers are a useful way to split, label and compare those files so a version name still matches the claim it is meant to support.

Working standard: Every material claim needs an owner, a record, and a clear status of true today or planned.

What Counts as Sufficient Evidence

In UK FCA authorisation, the FCA's application guidance expects each requested permission to be linked to the actual business model, customers, products, operational processes and control framework, not to a generic policy pack. Applicants need to show they can comply with the Principles for Businesses and relevant Handbook rules, that important controlled functions are staffed, that financial information is properly prepared, and that the technology and systems supporting the activities are ready. The same guidance warns that incomplete or missing forms, inadequate financial information and unclear descriptions of activities can delay applications.

Use the table as the only sufficiency standard. A row passes when the claim maps to an owner, a process, a system or record, and a monitoring activity. It fails when the page looks finished but a supervisor cannot test it. The same owner, record and status test travels. A DFSA, FSRA or SEC reviewer will still ask who runs the control, where the record sits, and whether it operates now.

How each row fails in practice

The regulatory business plan must tie the permission to named customers, products and flows. A strategy essay with no operating detail fails that test. Governance must show the controlled functions are staffed, with time, reporting lines and decision rights. An org chart without capacity or fitness evidence does not. Financial information must show resources match the activities, through owned assumptions, projections and stress cases. A revenue figure with no owner is not a model.

Systems must show architecture, access, change control and go-live status. A vendor brochure is not current capability. Financial-crime controls must convert risks into operating AML and CTF controls, with a risk owner, frequency, retained evidence and escalation. Policy text alone fails. Outsourcing must show the firm can oversee what it does not run, including exit and concentration. Unsigned terms described as live arrangements are a contradiction. Implementation status must separate today from after authorisation, with milestones, owners, dependencies and residual risk.

Mark every row operating now, staged with a dated plan, or out of scope. Leaving status implicit is how a future intention gets read as current capability. That split also matters for threshold conditions, because resources, suitability and the ability to be supervised are tested against what exists, not against a slide.

Provenance, not just the document type

Separate four kinds of material. Documentary evidence covers policies, contracts, minutes and approved financial models. System records cover configuration, access logs, alert data and management information. People evidence is the named accountable individual and what they can say in interview. Third-party attestations cover audit findings and legal opinions.

For each item, record the author, the date, the version, and whether it was written for the filing or pulled from live operation. A supervisor weighs an item by that provenance. A policy drafted last week for the application is weaker than three months of alert logs, and it should be labelled as such. Before drafts move outside the working group, run a security verification checklist for sharing tools so access rights and edit history don't become a fresh gap in the control story.

How to Trace a Claim to a Control

For UK cryptoasset registration, the FCA application form for cryptoasset businesses asks for governance arrangements and internal AML and CTF mechanisms. That includes mapping the risks of the firm's cryptoasset services, the procedures used to assess and prevent those risks, and the frequency and human resources allocated to periodic and ongoing assessments. Volume of paper doesn't answer that question. A single chain does.

Copy this chain once, and stay inside transaction monitoring.

1. Name the risk and the service. Example: a retail customer sends crypto from an unhosted wallet into a custody account, and the risk is that the source of funds can't be explained.
2. Name the risk owner. Not "Compliance". A named MLRO or deputy, with enough time to do the review.
3. Split preventive controls from detective controls. Preventive: the onboarding rule that blocks that customer type until source-of-funds evidence is in. Detective: the monitoring scenario that flags the transfer after it lands.
4. State frequency and the person assigned. Daily alert review, by a named analyst, with a weekly MLRO sample.
5. List the record retained. The scenario library, the alert, the investigation note, and the decision.
6. Set the escalation threshold and who receives it. A stated value, or a stated typology, goes to the MLRO the same day.
7. Name the review route. Monthly management information to the board risk committee, or an independent sample.

If any link is missing, the claim is not yet evidence. "Monitoring is thorough" is a sentence. The chain is the test.

One customer, in the interviewee's words

The interview test is simple. One realistic customer or transaction should move, in the person's own words, from onboarding and risk classification through monitoring, alert investigation, suspicious-activity escalation and management reporting. If they jump from "we have a policy" to "we would file a report", the middle of the chain isn't operating.

That walkthrough should match the firm's financial crime risk assessment. The risk names in the assessment, the scenarios in the monitoring pack and the words used in interview have to be the same risk, not three cousins.

Controls already operating must be separated from controls still to be built. Three responses follow, and only one of them is right for a given gap. Implement before filing when the permission can't be supervised without the control. Document a transition when the build is real, dated and owned, and the firm won't do the risky activity until then. Narrow the permission when the control depends on a vendor, a hire or a licence you don't have. Adding another policy page doesn't close the gap.

Proving Controls That Are Not Live Yet

Applicants hit one awkward question. How do you prove a future control environment without writing as if it already runs? The honest pack contains four blocks, not a thicker manual.

Four blocks for a control that starts later

Take transaction monitoring for a custody flow that will switch on only after permission. On the filing date the rule set is designed and two scenarios are written down. The alert owner is named, but the data feed is not connected, so no alert has ever been raised. That is block one: what operates today.

Block two is the milestone and owner. Daily investigation starts on a stated date, owned by the MLRO, and only after the feed vendor confirms connection. Block three is the dependencies: the feed contract, the analyst hire, the legal opinion on the customer terms, and the change window in production. Block four is the residual risk the firm will hold until go-live, and the limit it places on itself while that risk is open.

The firm will not onboard that customer type until the feed is connected and the first ten alerts have been investigated against the written scenarios.

Technology, custody, financial-crime controls and cross-border duties in crypto and digital-asset firms move quickly. The same paragraph has to say which entity, which customer and which flow the control covers. "The group will monitor transactions" is too wide. "UK entity, retail custody inflows from unhosted wallets, no other flow" can be supervised.

A bad sentence and a better one

Bad: "Monitoring is effective and alerts are investigated daily."

Better: "The rule set is designed, two scenarios are documented, and the alert owner is named. Daily investigation starts on 1 June once the feed is connected. Until that date the firm will not onboard retail customers sending crypto from unhosted wallets."

The bad sentence borrows the present tense for a control that has never run. The better one tells the supervisor what is true, what is dated, and what the firm will refuse to do in the gap. I would rather narrow a sentence than defend a tense.

If the milestone has no owner or no date, there are two choices. Build the control before submission, or narrow the permission. Don't add policy pages to cover the hole. A supervisor can ask for the alert log. A policy can't produce one.

How to Keep an Evidence Package Coherent

Treat the package as one narrative stored in many files. More documents often create the next question, because an uncoordinated annex contradicts the plan it was meant to support.

Keep a single evidence register, and make someone maintain it. The columns that matter are few.

• Claim: the sentence a supervisor might test, written once.
• Source document and version: file name, version, date.
• Owner: the person who can explain it, not the team name.
• Status: live, staged, or out of scope.
• Record location: where the underlying log, minute or model sits.
• Last consistency check: the date someone compared it with the other two places the fact appears.

Provenance is a matching exercise. A figure in the financial projections, a control in the compliance manual and a sentence in the business plan should cite the same assumption and the same date. If the plan says 40,000 active customers in year two and the model says 12,000, you don't have a range. You have a contradiction.

The change routine

1. Freeze a version when a section goes for review. Later edits start a new version, they don't overwrite the frozen file.
2. Log the decision that changed a fact, including who decided it and why.
3. List every document that sentence touches before you edit one of them.
4. Re-read the regulatory business plan against the policies after each material change, not only at the end.
5. Separate current from to-be in the file name or a status flag, not only in a footnote nobody sees.
6. Keep the interview pack on the filed versions, so management don't describe a newer process than the one submitted.

An anti-money laundering audit of the pack, done before filing, is the right moment to run that comparison. The auditor is looking for the same break a supervisor will find: a control named in the manual that the register still marks as staged.

Pick three claims at random. If owner, number and status don't match across the plan, the policy and the financials, the package isn't coherent yet.

Pitfalls That Stretch the Statutory Clock

A regulator can meet its timetable while the firm still waits. Meeting a service standard is not the same as a fast decision.

The FCA's operating service metrics state that a new FSMA Part 4A application must generally be determined within six months when complete, or within 12 months when incomplete. In 2025/26 Q3, 97% of applications across metric areas were determined within the new deadlines and 99.4% within existing statutory deadlines. Routes diverge. Payment-service authorisations were at 93.5% in 2025/26, down from 98% in 2024/25, with two of 31 cases missing the deadline. Electronic-money providers were at 95.7%, with two of 46 cases missing it. Headline service levels are a poor planning assumption.

What sits under those stages

Quality failures, not the calendar, are what stretch the wait. In 2025/26 the FCA's authorisation outcome metrics show 185 new-firm applications rejected because they did not contain the minimum information requested, while 389 were withdrawn and six were formally refused. Two refusals followed applicants not responding to information requests. Others involved inadequate senior-management competence, capacity or fitness, ineffective supervision, or broader shortcomings.

The FCA application process is therefore a sequence of evidence states, not a single submission date. Filing starts an index. Completeness is the minimum information, present and consistent. An information request needs one controlled answer, one owner and a decision log, not a fresh pile of policies. A change after filing needs an impact check before any document is swapped. Determination should leave a record of what was assessed and what remains staged.

I wouldn't plan a launch date off a published service percentage. The fix is a live register, controlled answers, a decision log and a change-impact check, so a new fact doesn't contradict the filed pack. More documents are not the remedy when the narrative already conflicts.

Check the Package Before You File

Pick the one permission you most want. Walk a single customer journey against the sufficiency table, and test six links in order.

1. Business-plan claim. The customer, the product and the flow are named, not implied.
2. Named owner. A person, with time and decision rights, not a department.
3. Financial assumption. The same number, the same date, in the plan and the model.
4. System status. Live, or staged with architecture and a go-live flag. Not a brochure.
5. Financial-crime chain. Risk, preventive and detective controls, frequency, record, escalation.
6. Outsourcing oversight. Contract, cadence, exit and concentration, or a clear statement that nothing is outsourced.

Mark each link operating now, staged with a dated milestone, or out of scope. If any link is missing, or is written as live while it is still a milestone, don't file that scope.

Three options remain. Narrow the permission. Date the milestone and name the owner. Or build the control before submission. Record the decision in the evidence register so the same status appears in the plan, the policy and the financials.

Leave this week's internal review with an owner for every open gap, and a recorded decision on whether the scope stays as drafted. Filing a larger pack without that decision is how complete-looking applications become withdrawals.

---

Glentorion helps financial and crypto firms turn a business plan into an authorisation pack where each claim has an owner, a record and an honest status of live, staged or out of scope. That work covers scoping, package review, cross-document consistency and interview preparation for the route you are filing. If you want that standard applied to a live application, visit Glentorion.