Regulatory Reporting Checklist 

A regulatory reporting checklist should identify which returns apply, the responsible entity and regulator, reporting basis, period, deadline, data sources, calculation rules, preparer, reviewer, approver, submission method and evidence to retain. It should also define how validation failures, late data, corrections and regulator queries are escalated. The exact legal requirements must be confirmed for each entity and jurisdiction. 

Regulatory reporting often fails at the joins between teams. Compliance may maintain the obligations register, finance may own the ledger, operations may hold transaction data, and a provider may prepare part of the return. Unless those dependencies become named actions and cut-off times, a calendar gives limited protection. 

This guide is for directors, compliance officers and finance or operations leaders in regulated financial-services and fiduciary businesses. It provides a jurisdiction-neutral operating checklist that can be adapted to prudential, statistical, conduct, transaction, client-money and other recurring returns. It does not determine whether a particular return applies or replace the relevant rulebook, completion guidance or specialist advice. 

Key takeaways 

• Confirm applicability from current primary sources. Similar entities can have different returns because of permissions, activities, thresholds, group structure or jurisdiction. 

• Give every return one accountable internal owner, even when preparation is outsourced or co-sourced. Record who prepares, reviews, approves and submits. 

• Control the full data lineage from source system to reported field. Reconcile key totals, investigate exceptions and retain evidence of judgement and approval. 

• Treat portal acceptance as part of submission. Save the final file, confirmation, timestamp and validation output. 

• Plan for errors and disruption. A useful checklist states who decides whether to notify, correct or resubmit, and how missed or at-risk deadlines are escalated. 

1. Confirm applicability and obligations 

Start with the legal entity, not the template. Record the entity name and identifier, regulator, jurisdiction, permissions or registration category, reporting period and basis of preparation. Then identify the rule, code, notice or other primary source that creates the obligation and the current completion guidance that explains the return. 

Applicability can depend on factors such as regulated activities, prudential category, assets or transaction volumes, client types, group relationships and whether reporting is solo or consolidated. It may also change after a new permission, product, acquisition, restructuring or threshold breach. The obligations register should therefore show the reason a return applies, not merely its name. 

This distinction matters because regulatory frameworks are specific. For example, the UK Financial Conduct Authority’s SUP 16 reporting requirements apply according to the categories and activities set out in that chapter, with different data items, frequencies and due dates. In Jersey, the JFSC’s prudential reporting page for Jersey incorporated banks states that those banks submit their prudential returns by the twentieth working day after the reporting date. Neither example establishes a deadline for a different firm or jurisdiction. 

The internal owner should monitor regulator updates and assess changes against the register. Preserve the source version or link, effective date, interpretation, reviewer and approval. If applicability is uncertain, escalate before production to appropriately qualified legal, regulatory or tax advisers. Do not make an unsupported classification decision under deadline pressure. 

2. Build a calendar with clear ownership 

A reporting calendar should work backwards from the regulatory deadline. Include internal cut-offs for source data, first draft, validation, review, approval and submission, with enough time to resolve exceptions. Adjust for local holidays, portal availability and interdependent returns rather than assuming the statutory date is the only date that matters. 

Assign one accountable internal owner for each return. A practical responsibility model distinguishes: 

• Preparer: assembles data, performs calculations, completes the template and records open points. 

• Reviewer: challenges completeness, reconciliations, movements, judgements and compliance with the instructions. 

• Approver: provides the formal internal sign-off required by the entity’s policy or the applicable rules. 

• Submitter: uses the authorised channel, confirms acceptance and stores submission evidence. 

• Escalation owner: decides how to handle material errors, unavailable data, control failures and deadline risk. 

Segregation should reflect the size and risk of the organisation. Where a small team cannot separate every role, document compensating review by a director or another suitably competent person. Delegating preparation to a service provider does not by itself transfer the regulated entity’s obligations or internal accountability. 

The calendar should include access-renewal dates, certificate expiry, staff leave, provider dependencies and a named deputy. Run an access check before each period end. A complete return that the team cannot submit is still late. 

3. Control data sourcing and lineage 

For each reported field or coherent data block, identify the system of record, data owner, extraction method, cut-off and transformation. Common sources include the general ledger, portfolio or administration systems, customer or investor registers, payment records, risk engines, spreadsheets and information supplied by group companies or third parties. 

Create a data lineage record showing how source data becomes the final reported value. It should identify manual adjustments, mappings, currency conversions, eliminations, estimates and consolidation steps. Store the extract or a reproducible query, the version used, control totals and evidence that late changes were captured. 

Data quality tests should cover completeness, accuracy, consistency, validity and timeliness. The Basel Committee’s risk data aggregation and reporting principles describe reconciliation, validation, documented expert judgement and controls over manual workarounds. Those principles were designed for banks within their stated scope, but the control ideas can inform a proportionate reporting process elsewhere; they are not universal legal requirements. 

Late or incomplete inputs need a defined response. The preparer should log the affected field, source owner, amount or population at risk, expected delivery time and possible impact. The reporting owner then decides whether to wait, use a permitted estimate, submit with an explanation, seek an extension or escalate for specialist advice. The available options must come from the applicable regime, not from a generic checklist. 

4. Perform calculations and regulatory data validation 

Use the regulator’s current taxonomy, template, instructions and validation rules for the relevant period. Keep calculation logic version-controlled and trace each material figure to source records. Where a return uses a different basis from the statutory accounts or management reporting, document the bridge rather than relying on an unexplained reconciling item. 

A robust validation sequence normally includes: 

1. Format checks: mandatory fields, identifiers, dates, units, signs, decimals and permitted values. 

2. Internal arithmetic: totals, subtotals, ratios and cross-field relationships. 

3. Source reconciliation: agreement to ledgers, registers, subledgers or other approved control totals. 

4. Cross-return checks: consistency with related submissions for the same period, allowing for documented basis differences. 

5. Movement analysis: comparison with the previous period, budget or risk thresholds, with explanations for significant changes. 

6. Reasonableness review: assessment of whether the output is plausible in the context of business activity and known events. 

Validation rules themselves change. In June 2026, the European Banking Authority updated supervisory-reporting validation rules, including changes to active status and severity. That update concerns reporting under the relevant EBA frameworks, but it illustrates why a team should record the taxonomy and validation-rule version used for each submission. 

Do not clear a warning merely to obtain a technically valid file. Record the cause, evidence, decision and reviewer. If a rule fails because the business facts and reporting instruction genuinely conflict, follow the regulator’s prescribed query or escalation route. Retain both the original exception and the final resolution. 

5. Review and sign off the return 

The review pack should allow a competent reviewer to understand the return without reconstructing the process. It should contain the draft return, source reconciliations, validation output, movement commentary, open exceptions, material judgements, applicable guidance, prior-period comparison and evidence of data-owner confirmations. 

Use a review checklist that requires an explicit response rather than a row of untimed initials. Record the reviewer, date, questions raised, preparer’s response and closure evidence. High-risk fields, regulatory ratios and manual adjustments may need enhanced review. Low-risk, unchanged fields may justify a lighter procedure, provided the rationale is documented. 

Approval is a decision, not the absence of comments. The approver should see unresolved items and understand their possible effect on completeness, accuracy and timeliness. The sign-off should state the version approved and confirm that the approver had the required authority. Where the regulator requires a certificate, director approval or other prescribed attestation, follow that wording and process exactly. 

Jersey provides a sector-specific illustration. The JFSC’s Deposit-taking Business Code provisions on prudential returns require Jersey incorporated banks within that code’s scope to have robust, documented production processes and to establish responsibility for sign-off and oversight. Other organisations should confirm their own applicable requirements rather than treating this as a general Jersey rule. 

6. Submit and retain evidence 

Before submission, confirm the reporting entity, period, return type, file version and destination. Check that the submitter’s authority and portal credentials are current. If a maker-checker workflow exists in the portal, include both actions in the calendar. 

Submission is complete only when the applicable channel has accepted the return. A file uploaded locally, saved in draft or rejected by a validation gateway may not count. Capture the portal receipt or acceptance message, reference number and timestamp. Where the rules define a different point of completion, document that requirement. 

Retain a final evidence pack containing: 

• The submitted file or rendered return and a file hash or other version identifier where appropriate.

• Source extracts, reconciliations, mappings and calculation files.

• Validation results, exception logs and movement explanations.

• Preparation, review and approval evidence.

• Submission confirmation and correspondence with the regulator.

• The applicable instructions, taxonomy and rule version.

• Records of any later correction, resubmission or query. 

Set the retention period according to the relevant legal, regulatory and records-management requirements. Access should be restricted, but the pack must remain retrievable for authorised internal review, audit or regulatory enquiry. Test restoration of archived files rather than assuming that a folder path proves recoverability. 

7. Handle corrections and regulator queries 

When an error is identified, preserve the submitted version and open an incident record. Assess which entities, periods, fields and related returns are affected; quantify the difference; and determine whether a notification, correction or resubmission is required. Assign an owner and deadline for the decision. 

Requirements vary. Under FCA SUP 15.6, a firm within scope must take reasonable steps to ensure information given to the FCA is accurate and complete and must notify the FCA immediately if it becomes aware that information provided was or may have been false, misleading, incomplete or inaccurate, or materially changed. The notification requirements include details, an explanation and the correct information, subject to the rule where the correct information is not immediately available. This is a UK FCA example, not a universal correction procedure. 

A regulator query should enter the same controlled workflow as a return. Log the request, due date, accountable owner, information supplied, review and approval. Reconcile the response to the original submission and explain any difference. Keep communication factual, complete and within the authority of the respondent; escalate interpretations or potentially material errors to the appropriate internal and specialist owners. 

After correction, investigate the root cause. A formula error may point to weak spreadsheet change control; a missing entity may indicate an incomplete obligations register; and an unexplained movement may expose poor source-data ownership. Correcting the field without repairing the process leaves the next reporting cycle exposed to the same failure. 

8. Review the process after submission 

Hold a short post-submission review while the evidence is fresh. Compare planned and actual dates, list late inputs and review points, record portal or validation issues, and identify any manual workarounds. Track actions to named owners with due dates before the next reporting cycle. 

Useful management information includes on-time submission, first-time technical acceptance, late source inputs, validation exceptions, post-submission corrections, unresolved review points and hours of manual adjustment. Metrics should prompt investigation rather than reward superficial closure. For example, a low exception count may reflect strong data quality or tests that are too weak. 

Review the whole control design after a rule change, system migration, new product, acquisition, provider change, recurring error or significant staffing change. Test business continuity by confirming that a deputy can obtain the source data, complete the process and submit through the approved channel. 

Practical regulatory reporting checklist 

The following framework is recommended control practice. Adapt it to the entity’s applicable rules, risk assessment and internal governance. 

How outsourced or co-sourced support should be governed 

External support can add operational capacity for data preparation, reconciliations, calculation files, validation, review-pack assembly, workflow tracking and remediation projects. The agreed scope should state inputs, outputs, cut-offs, systems access, control responsibilities, evidence standards, confidentiality, issue escalation, business continuity and hand-back arrangements. 

The client should retain an accountable owner, adequate knowledge to challenge the work and authority over approval and regulatory communication. The responsibility matrix must also cover subcontractors and other dependencies. Service levels should measure completeness, quality and issue resolution as well as delivery time. 

We provides Compliance Support, Operational Finance Outsourcing and specialist project support for funds and finance businesses. Where relevant, this can provide additional execution capacity within a client’s systems and controls. The responsible entity and its qualified advisers should continue to determine applicable obligations, interpretations, approvals and communications with the regulator. 

Make the checklist part of the control environment 

A useful checklist connects the obligation to the data, the people and the evidence. It gives the board and accountable managers visibility over what remains unresolved before submission, and it makes correction and improvement part of the process rather than an improvised response. 

The next step is to test one material return against the framework: verify why it applies, trace several key fields to source, inspect the latest review evidence and confirm that a deputy can complete the submission. The gaps found in that exercise will show whether the priority is clearer ownership, stronger data controls, process remediation or additional execution capacity. 

Frequently asked questions