FCA Crypto Regulatory Reporting: Preparing Your Systems, Data and Compliance Calendar

By CRYPTOVERSE Legal Consultancy

Three departments, three different answers

A crypto company is preparing its first regulatory reporting exercise.

Finance reports 12,000 customers. Operations reports 9,500. Compliance reports 10,800.

Each figure has a reasonable explanation.

Finance counts every account with a balance. Operations counts customers who completed a transaction during the period. Compliance counts customers with completed onboarding.

The problem is that nobody checked which definition the regulatory return requires.

A similar disagreement appears in trading volume. One system counts transactions, another counts both sides of each trade, and a third includes transfers between internal wallets.

The company has data. It does not yet have a reliable reporting process.

For FCA cryptoasset authorisation preparation, reporting capability should begin with agreed definitions, accountable owners and evidence that figures can be reproduced.

What regulatory reporting should an FCA crypto firm prepare for?

A crypto applicant should identify the returns and notifications applicable to its proposed business, establish reliable data sources, assign preparation and review responsibilities, and build a calendar around the relevant reporting periods and deadlines.

The FCA’s final PS26/13, Chapter 13, applies relevant SUP 16 reporting requirements to qualifying cryptoasset firms. It also establishes an iterative approach to crypto-specific baseline returns, supplementary collections and further prudential reporting development. Firms should distinguish settled requirements from templates and metrics still being developed.

The practical task is to demonstrate that the applicant can produce accurate information about its own business and submit it through the correct channel.

Start with an obligations inventory

Reporting requirements depend on the firm’s permissions, classification, activities and legal structure in case you need a crypto UK Licence.

For practical preparation, we recommend assessing these categories:

The final policy identifies existing reporting provisions covering controllers, close links, annual reports and accounts, financial crime and financial resilience, among others. It expects quarterly FIN073 Baseline Financial Resilience Report submissions from commencement, subject to the applicable provisions.

Avoid copying another firm’s calendar. Similar commercial services can involve different permissions and reporting obligations.

Separate scheduled returns from event-driven notifications

A quarterly calendar cannot capture every reporting obligation.

Scheduled returns relate to a defined reporting period. Event-driven notifications arise when something happens.

For practical implementation, maintain two connected arrangements:

• A reporting calendar for recurring submissions.
• An escalation and notification matrix for events requiring assessment.

The notification matrix should identify the trigger, decision-maker, reporting route and applicable timing.

Potential events to assess include significant operational incidents, changes in ownership or control, material business changes and concerns about financial resources. Each requires its own legal analysis.

A firm should not wait for its next periodic return before considering a time-sensitive notification.

Use the correct submission channel

The FCA describes RegData as its regulatory data collection platform, providing a tailored reporting schedule and submission records. Connect is used for applications and various notifications. Access is available through My FCA. The channel should be checked for each obligation.

For practical preparation, establish:

• Appropriate user access.
• A named administrator and deputy.
• Submission and review responsibilities.
• Access removal when personnel leave.
• Secure retention of acknowledgements.
• A process for handling submission difficulties.

Portal access is an administrative capability. The reporting framework also needs legal interpretation, reliable calculations and quality control.

Create a reporting data dictionary

A data dictionary explains what each reported figure means.

For each material field, we recommend recording:

1. The regulatory definition and relevant guidance.
2. The reporting entity and population.
3. The period or measurement date.
4. The source system.
5. The calculation and adjustments.
6. Currency and valuation conventions.
7. The data owner.
8. Review and reconciliation procedures.

For example, distinguish customers, accounts, wallet addresses and active users. They are not interchangeable.

Similarly, distinguish assets belonging to the firm from assets held for customers, and trading activity from transfers that do not represent trades.

Definitions should be consistent across the return, calculations and supporting explanation.

Trace figures back to their source

A reviewer should be able to follow a reported number from submission to underlying records.

Our recommended approach is to document the path:

Source records → extraction → adjustments → calculation → review → submitted figure.

That traceability matters when systems overlap.

For example, a custody total may depend on customer entitlement records, wallet balances, third-party records and valuation inputs. Explain how the firm avoids duplication and handles differences.

Manual adjustments should have a reason, owner and evidence. Preserve them as part of the reporting record rather than embedding unexplained changes in a spreadsheet.

Resolve crypto-specific measurement issues

UK Crypto staking for FCA Authorisation for Crypto data creates questions that should be addressed before deadlines approach.

The applicable reporting instructions should govern the answer.

Where interpretation remains uncertain, record the issue, obtain appropriate advice and establish a consistent approach. Avoid silently changing methodology between periods.

Build a calendar that includes the work before submission

A useful compliance calendar contains more than due dates.

We recommend recording:

Do not invent a single filing deadline for all crypto firms. Confirm timing against the applicable rules, instructions, accounting reference date and reporting schedule.

Set internal deadlines with enough time to investigate discrepancies.

Treat incident reporting as a separate readiness exercise

The FCA’s operational incident reporting framework has its own commencement date: 18 March 2027. Its guidance explains reporting thresholds, standard and enhanced reporting, and submission through Connect. Firms should assess applicability rather than assuming every reporting change starts with the expanded crypto regime.

For practical preparation, test whether an incident can move from detection to legal assessment and notification without unnecessary internal delay.

The people preparing a periodic return may differ from those managing an urgent security or service disruption. Both processes need deputies and clear authority.

Validate meaning as well as format

SUP 16.3 contains general reporting provisions, including requirements concerning complete and accurate information.

A portal’s validation checks can identify formatting or arithmetic problems. They may not detect a wrong population or misunderstood definition.

Our recommended review includes:

• Reconciliation with relevant accounting and operational records.
• Comparison with previous periods.
• Investigation of unusual changes.
• Checks for duplicate or omitted records.
• Review of manual adjustments.
• Confirmation that definitions remain current.

When a figure changes sharply, explain why. Genuine growth and a changed calculation method have different implications.

Prepare for corrections and evolving requirements

Reporting frameworks and business models can change.

For practical implementation, maintain a controlled process for:

• Updating definitions and templates.
• Assessing new permissions or services.
• Reviewing changes to source systems.
• Correcting discovered errors.
• Recording whether earlier submissions are affected.
• Communicating with the FCA where required.

Preserve the original submission and subsequent correction history.

A firm should also assess whether a reporting error indicates a wider records or control weakness.

Demonstrate capability during application preparation

An applicant can test reporting readiness before its first formal return.

We recommend completing a sample reporting exercise using historical, pilot or clearly labelled simulated data.

Can the team produce the figures? Can a reviewer reproduce them? Are provider records accessible? Does the approval process work when someone is absent?

A useful application evidence pack may include:

• An obligations inventory.
• A compliance calendar.
• Data definitions and source mapping.
• Reporting procedures.
• Sample calculations and review records.
• Identified gaps and remediation arrangements.

Explain honestly which capabilities are operational and which remain under development.

Returning to the opening scenario

For regulatory compliance advisory services the company agrees the definitions required for each reporting purpose.

It assigns owners, reconciles the source data and records how customer and trading figures are calculated. A sample reporting exercise exposes missing information and gives the team time to resolve it.

The next submission can be prepared from an established process, with evidence behind each material figure.

How CRYPTOVERSE can support your preparation

CRYPTOVERSE is a specialist legal and regulatory firm for UK FCA cryptoasset authorisation support.

We can help map reporting obligations, establish a compliance calendar and align data definitions, notification procedures and governance with your proposed UK services.

Contact CRYPTOVERSE to assess whether your reporting framework can produce accurate, timely and reviewable regulatory information.

FAQs