How to test a COREP reporting system

COREP reporting system testing checks that a bank’s Common Reporting (COREP) process produces complete, accurate and valid prudential returns from source data through to submission. It covers data mapping, calculations, reporting rules, validations, output generation and operational controls. Tests should use the applicable reporting requirements and system configuration for the entity and reporting date.

How to test a COREP reporting system

Start with approved reporting requirements, the applicable template and validation specifications, and documented interpretations of the rules. Record the reporting entity, consolidation perimeter, reporting date, currency, units and relevant configuration. These details affect expected results, so tests that omit them can pass while checking the wrong reporting basis.

Trace each material reported value back to its source and transformation. Map data lineage across the general ledger, subledgers, risk systems and other contributing applications. Check identifiers, data types, signs, units, currency conversion, rounding and treatment of missing or duplicated records. Reconcile input totals and report-level totals to trusted control figures, with documented explanations for legitimate differences.

Test calculations against independently prepared expected results. Include ordinary cases and boundary conditions, such as zero values, negative values where permitted, thresholds, missing inputs and amounts close to a rounding boundary. Where a calculation depends on a configurable rule, verify both the rule and the configuration effective for the reporting date. Keep the expected result separate from the application logic to reduce the risk of repeating the same defect in the test oracle.

Validate rules, integrations and output

Exercise validation at each relevant layer: source-data checks, business rules, cross-field and cross-template consistency, output-format checks, and validations returned by the receiving authority or submission channel where available. Confirm that valid reports pass and that invalid data produces an actionable error, without silently dropping or altering values. A structurally valid file can still contain incorrect regulatory data, so format checks alone are insufficient.

Test interfaces between source systems and the reporting application for missing, late, duplicated, out-of-order or malformed data. Check how the process handles partial batch failures, retries and reruns. A rerun should not duplicate records or leave a mixture of old and new results. Verify that the generated output matches the approved schema or taxonomy version used by the reporting process. Where the jurisdiction and reporting route use eXtensible Business Reporting Language (XBRL), validate the instance against the relevant taxonomy and applicable rules.

Include operational and access-control checks. Confirm that only authorised roles can change reporting parameters, approve a return or submit it. Check that the system records who ran, reviewed and approved each report, along with the relevant inputs, configuration, output and validation results. Protect test data and evidence according to the bank’s controls; use masked or synthetic data where production records are not authorised for testing.

Build a practical test case

For a simple illustrative mapping, assume an approved rule says a report field takes a booked balance after a specified adjustment. Provide a source balance of 1,250,000 and an adjustment of 50,000. The expected field value is 1,200,000. Check the source records, adjustment rule, arithmetic, currency and unit, destination field, generated output and reconciliation. Then vary the adjustment, remove a required source value and rerun the process to check the expected result and error handling. This example illustrates test design only; actual values and rules must come from the bank’s approved reporting requirements.

Verify changes and release readiness

When a rule, mapping, source interface, template or taxonomy changes, identify affected reports and rerun relevant regression tests. Compare the new output with approved expected results and investigate every unexplained difference. Keep traceability from each requirement and reporting rule to its test, result and defect where applicable.

A release should have evidence that material calculations and validations passed, reconciliations are explained, access and approval controls work, and output generation and submission steps were exercised in a representative environment. Record environment versions and configuration alongside the results. Environment drift, stale reference data or mismatched rule versions can make otherwise repeatable tests unreliable, so verify these dependencies before execution.