Chapter 084: Reporting Technology

Section 17: Regulatory Reporting Foundations and Delivery · Chapter 084 of 100

A fictional reporting platform has300mapped points fed by12engines across4systems. Those counts are illustrative, not the official size of a COREP template. Reporting technology coordinates approved calculations, DPM/taxonomy mappings, validations, filing and evidence through each version change.

1. Chapter opening

COREP families: own funds (composition, deductions, buffers), adequacy (ratios, MDA), credit risk (SA/IRB exposures, RWA, mitigation), market risk, operational risk, leverage, large exposures, liquidity (LCR/NSFR in some remits — verify). Each cell maps from engines (RWA, capital, liquidity) through DPM-versioned mappings into XBRL, gated by EBA validation rules plus internal plausibility and cross-return checks. This chapter runs the factory. The DPM (Data Point Model) is the EBA's canonical definition of every data point in regulatory reporting — each COREP cell has a unique DPM identifier, dimension set, and version history. Understanding DPM structure is essential because taxonomy upgrades change dimension assignments, add new data points, and retire obsolete ones — all of which affect mapping logic and validation rules. XBRL (eXtensible Business Reporting Language) is the delivery format: the taxonomy defines the XBRL tags, the DPM defines the semantics, and the filing instance document carries the actual numbers. Every cell must trace from source system through DPM mapping to XBRL tag to validation rule to filed document — this end-to-end lineage is what supervisors examine.

2. Learning objectives

1. List COREP template families with source engines each.
2. Explain DPM taxonomy structure (dimensions, metrics, versions) at working level.
3. Operate mapping layers (engine output → DPM cell) with version control.
4. Run validation (EBA rules + plausibility + FINREP cross-checks).
5. Manage taxonomy upgrades with regression and parallel runs.

3. Business context

COREP supports prudential assessment alongside other supervisory evidence; SREP is not calculated solely from submitted cells. Pillar3 uses its own public definitions and bridges. Govern taxonomy applicability, engine-to-point lineage, mapping tests and actual deadlines. No unsupported ranking of finding themes or automatic bank-wide filing block is asserted.

Taxonomy changes need impact analysis, mapping updates, validation-rule review and testing before the first applicable reference date. Budgets depend on affected data points and systems; no universal annual release cadence or 40-60% saving is established here. Late or incorrect returns are handled under the authority's reporting and enforcement rules. Capital-distribution restrictions are not an automatic consequence of an XBRL mapping error.

A reviewer must be able to trace a reported data point to the contributing records, transformations and calculation versions. Versioned documentation can support that evidence; a particular storage technology is not itself a regulatory compliance requirement. Test whether evidence can be retrieved and reproduced within the actual request deadline.

4. Finance and accounting view

4.1 Mapping mechanics (fictional own-funds cell)

CET1 cell: capital engine outputs 7,050 with deduction schedule; mapping assigns to DPM metric/dimension set per taxonomy version; validation checks composition arithmetic (CET1 + AT1 + T2 = Total; deductions footed); plausibility compares to prior quarter with threshold explanations (buffer-driven moves flagged). Credit-risk cells consume RWA engine class totals; FINREP bridge proves exposure consistency (scope/measure differences documented per cell-block).

Separate template coordinates, data-point semantics and machine identifiers. C 01.00 is an example own-funds template designation, while a column code such as c 0010 is not a universal CET1 DPM identifier. For a fictional internal mapping key CET1_TOTAL, the engine outputs 7,050m; the mapping attaches the prescribed metric, dimensions, reporting entity, period and unit from the chosen taxonomy. Use official release artefacts to resolve the actual cell coordinates, identifiers and permitted context; do not copy fictional codes into a filing.

The mapping layer must handle scope differences between engine outputs and DPM requirements. For example, the capital engine may produce consolidated figures, while DPM requires entity-level granularity for certain templates. The mapping must apply aggregation rules, handle currency translation, and document any scope adjustments. Each mapping decision must be traceable: the mapping record states which engine output feeds which DPM cell, under which taxonomy version, with which aggregation or translation logic.

4.2 Version and validation governance

Taxonomy version locked per cycle; upgrade path (impact analysis → mapping patches → parallel run vs prior version → sign-off → cutover); validation rules versioned alongside; custom internal rules (plausibility, cross-return) maintained in the same repository. Filing blocked on red with governed warning disposition.

Version governance requires discipline at every stage. During impact analysis, the team compares old and new taxonomy structures, identifying added, removed, and changed data points. This produces a change register with ownership and impact assessment. Mapping patches are developed against the new taxonomy, tested in a sandbox environment, and reviewed by a second person (no single-person mapping changes). Parallel run compares old-version and new-version outputs on identical frozen data, with every difference explained and attributed. Cutover is signed by the mapping owner, the validation owner, and the filing owner — three-person control preventing unilateral changes. After cutover, the old taxonomy version is archived (not deleted) for audit trail completeness.

Validation governance extends beyond EBA rules. Internal rules — plausibility checks, cross-return consistency, historical trend monitoring — are maintained in the same repository as EBA rules, with the same versioning and testing discipline. Warning dispositions require documented rationale and approval: waving a warning without evidence is a governance finding. Blocking validations require correction or the authority’s documented applicable treatment for known/deactivated rules; an internal reviewer cannot silently waive a genuine filing error.

4.3 Deep dive: mapping regression at scale and engine-version governance

Mapping regression suites prove taxonomy upgrades change only intended cells: full-return cell-level diff (old vs new version on identical frozen inputs), attributed differences (each delta classified: intended taxonomy change / mapping fix / engine change / unexplained — zero unexplained permitted), threshold alerting (deltas above materiality auto-escalate to mapping owners with evidence demands), and sign-off packs (regression report + attribution + owner approvals = cutover gate). Regression runs on production-scale data (samples miss tail cells where errors hide), with historical reruns (prior quarters re-filed in test to prove comparability logic). Vendor mapping content (engine-embedded DPM logic) regression-tested identically — vendor upgrades are taxonomy changes with third-party risk.

A regression suite compares facts by their semantic keys and dimensions, matching unchanged points and separately listing additions, removals and definition changes. For a fictional upgrade, CET1_TOTAL remains unchanged, a new deduction fact is 120m and a reclassification moves 80m between categories without changing the total. Internal keys are illustrative, not official DPM codes. Explain every material difference before acceptance.

Engine-version governance (RWA/capital/liquidity calculators evolve constantly): version registry (model + rulebook + parameter versions per cycle), change impact pre-analysis (which cells move, by how much, vs attribution expectations), parallel execution on material changes (old vs new engine, differences explained before cutover), and rollback-tested deployments (prior version restorable within SLA). Supervisors request version histories with submissions — undocumented engine changes can indicate a control deficiency; assess severity, materiality and the applicable supervisory requirement. Delivering Accounting and Reporting Change connects rule paragraph, approved engine version and reported cell, supported by Finance Data Governance and BCBS 239.

Preserve a version manifest for each filing: source snapshot, rule/model/parameter versions, mappings, taxonomy, validation rules and approvals. Evidence must remain retrievable for the required retention period and reproducible on frozen inputs. A governed spreadsheet or document register can be valid evidence; the control objective is completeness, access, integrity and re-performance, not a mandatory storage technology.

5. Product and customer impact

Prudential reporting requires product-to-exposure and off-balance-sheet mappings before a new product is booked. A revolving commitment's credit conversion factor follows its category, cancellation terms and applicable rule vintage; 75% is not a generic standardised commitment factor. Under the final Basel standard, ordinary commitments generally receive 40%, with separate categories such as unconditionally cancellable commitments and trade instruments. Domestic implementation may differ. Basel credit framework.

6. Regulatory and supervisory view

EBA DPM/XBRL framework (ITS versions, filing calendars — verify current release); national gateway overlays; validation-rule breaches need disposition evidence; resubmission procedures with change logs. Supervisors sample engine-to-cell lineage live; persistent mapping findings escalate to data-programme orders. The supervisory expectation is not merely that filings are correct, but that the process producing them is demonstrably controlled. This means supervisors want to see: version manifests, regression reports, validation logs, warning dispositions, and lineage queries — retrievable within the actual request deadline and the bank’s risk-appropriate service levels. Banks that can produce this evidence quickly signal process maturity; those that take weeks signal process fragility.

7. Systems and data view

COREP stack: engine outputs (frozen) → mapping layer (versioned DPM) → XBRL generator → validation (EBA + custom) → gateway → receipts → query/correction tracker → archive. Controls: version lockdown, mapping regression, validation gates, receipt reconciliation, lineage catalogue queryable per cell. The system architecture must support parallel versions — during upgrade periods, both old and new taxonomy versions must be operable simultaneously. The archive must store all layers: frozen engine outputs, mapping versions, XBRL instance documents, validation logs, and filed documents. Retrieval must be fast — lineage retrieval meets actual supervisory requests and approved internal service levels; there is no universal hours-only deadline. The lineage catalogue is the central nervous system: it connects every COREP cell to its source engine, mapping rule, taxonomy version, and validation result. Without it, the filing process is opaque and unexaminable.

8. End to end process

1. Freeze engine outputs post-close. 2. Map per locked taxonomy. 3. Generate XBRL. 4. Validate (rules + plausibility + cross-return). 5. Attest, file, receipt-check. 6. Handle queries; correct with lineage fixes. 7. Archive all layers.

Each step has a defined owner and a defined gate: engine freeze is owned by the engine team and gated by a freeze confirmation; mapping is owned by the mapping team and gated by regression sign-off; validation is owned by the validation team and gated by red-block/no-red-pass logic; filing is owned by the filing team and gated by receipt confirmation. No step proceeds without its gate being satisfied — this is the operational expression of the versioning discipline that keeps 300 cells honest.

9. Controls and risks

10. Practical examples

A — Parallel-run catch (fictional): a taxonomy comparison identifies40changed points. Review whether dimensions changed intentionally or were mapped incorrectly, retain old/new semantic keys, correct defects and rerun. An assumed120person-hours is this scenario’s effort, not a benchmark; unchanged totals alone do not prove changed dimensions are correct.

B — Cross-return break (fictional): an unexplained2bn difference remains after an accounting/prudential scope and measurement bridge. Investigation finds the same guarantee record inserted twice into the credit-exposure aggregate. A separate memorandum register is not itself a duplicate: exposure, nominal, allowance and accounting balances legitimately differ. Remove the duplicated aggregate membership, preserve the valid memorandum record and test the affected populations and periods.

10.3 Worked example: engine-version change with explained filing impact (fictional)

RWA engine v 4.2 → v 4.3 (mitigation haircut tables updated per rule change): pre-analysis predicts −80m RWA on collateralised book; parallel run on frozen Q3 inputs shows −82m (2m unexplained → investigation: two products newly eligible under revised definitions, correctly captured — explained, documented as an intended legal-definition/method change under the applicable attribution policy, rather than assuming every rule change is a model improvement); sign-off with version manifest (v 4.3 + rulebook reference + test pack); Q4 filing on v 4.3 with the Pillar3bridge using the applicable template’s prescribed attribution category. Supervisory query arrives (predictably) — answered in 48 hours from the version pack with re-performance instructions. Total cycle: 3 weeks from rule publication to filed compliance. Contrast (unversioned peer): same rule change discovered at validation-failure stage, 6-week delay, late filing with findings. Version discipline is filing-speed infrastructure.

The worked calculation: pre-analysis estimated −80m based on aggregate collateral book and new haircut percentages. Parallel run on frozen Q3 exposures (8.2bn collateralised book) produced −82m. The 2m difference was traced to two products — a specific guarantees portfolio and a derivatives collateral pool — that became eligible for mitigation recognition under the revised definitions. These products had previously been excluded from the haircut table but were now included, correctly increasing mitigation by 2m. The version manifest recorded: engine v 4.3, fictional rule-change reference, with the actual legal citation required in a live implementation, haircut table version 2025-Q3, parallel run date, regression report reference, and owner approvals. The Pillar 3 walk explained: "RWA decreased 82m due to methodology update (engine v 4.3) — 80m from revised haircuts, 2m from expanded eligibility." Supervisors received the query response with the full version pack, re-performance instructions, and regression report — the query was closed within 48 hours.

11. Diagrams

Figure 1. Reporting technology pipeline. Figure 2. Validation categories. Figure 3. Trace a reported data point.

12. Tables

Table 1 — COREP families (headline)

Table 2 — Upgrade checklist

13. Illustrative banking case study

An uncontrolled mapping update (fictional). A vendor release changes data-point mappings automatically. Internal warnings identify shifted exposure categories, but the team files without explaining them. The control repair pins versions, compares outputs on frozen inputs and requires approval before promoting mappings. The taxonomy generator creates filing facts; it must not silently alter source classification or the RWA engine's methodology.

14. BA, developer, tester and operations guidance

• BA: Specify mappings per cell-block with taxonomy version and bridge logic.
• Developer: Version everything; block on red; catalogue lineage per cell.
• Tester: Upgrade regression; cross-return consistency; resubmission integrity.
• Operations: Lock versions per cycle; calendar upgrades as programmes.

15. Common mistakes

1. Auto-updating taxonomies without regression.
2. Engine outputs filed without mapping review.
3. Warnings waved without rationale.
4. Lineage incomplete or irreproducible, regardless of storage medium.
5. Cross-return bridges skipped under pressure.
6. Parallel runs on sample data instead of production-scale data.
7. Uncontrolled version evidence with no complete, searchable approved manifest; a governed register can be a repository, tool or controlled document.
8. Vendor mapping content trusted without independent regression testing.

16. Key takeaways

1. COREP = engines → versioned DPM mappings → validated XBRL → receipted filing.
2. Law sets reporting obligations; technical taxonomy releases implement them and require controlled upgrade testing.
3. Every cell needs engine lineage, queryable live.
4. Cross-return bridges prove consistency.
5. Validation gates (no pass, no submit) protect the franchise.

17. References and verification notes

• EBA reporting frameworks: release-specific DPM, taxonomy, validation and filing materials.
• Basel credit framework: exposure and CCF definitions; national law supplies enforceable local rules.
• Family descriptions are headline simplifications.