CRR3 Reporting: Re-Plumbing COREP for the Output Floor and Revised Risk-Weight Calculations

CRR3 arrived as a reporting change and got handled by reporting teams. That is the first mistake. The output floor and the revised risk weights are not new templates to populate; they are a different way of calculating the numbers that go into them.

Most CRR3 programmes I have seen were scoped by someone reading the EBA’s reporting taxonomy and counting the changed cells in COREP. That framing produces a mapping exercise: new rows, new columns, a few renamed data points, some validation rules to update. It is comforting because it fits inside the regulatory-reporting function and touches nothing upstream. It is also wrong. Regulation (EU) 2024/1623 — CRR3 — has applied since 1 January 2025, and what it changed is the calculation of credit, market and operational risk-weighted assets, plus the introduction of an output floor that constrains the whole result. The templates moved because the arithmetic underneath them moved. Bolt the new templates onto the old arithmetic and you get reporting that does not tie out.

The output floor is a second calculation, not a cap

The output floor is the change that breaks the mapping mindset most cleanly. For a bank using internal models, total risk-weighted assets can no longer fall below 72.5% of the RWAs that the same exposures would produce under the standardised approaches. That is a floor on the aggregate, phased in: it starts at 50% in 2025 and rises in annual steps — 55%, 60%, 65%, 70% — to reach 72.5% in 2030.

Read that operationally and the consequence is stark. To report the floor, an internal-models bank now has to run the standardised approach across its entire book in parallel with its models, every reporting period, and compare the two. Firms that spent a decade building IRB models to optimise capital away from the standardised numbers now have to reproduce those standardised numbers in full, at the same granularity, on the same data. Many never kept a production-grade standardised calculation for portfolios they modelled internally. The floor does not tweak a template; it demands a calculation the bank may have stopped performing years ago, and it demands it tie back to the modelled figure exposure by exposure.

Revised risk weights mean revised source data

The credit-risk changes compound the problem because the revised standardised approach is hungrier for data than the one it replaces. More granular treatment of exposures to unrated corporates, a look-through for equity and subordinated debt, revised treatment of real estate that turns on loan-to-value bands and whether repayment depends materially on cash flows the property generates, and tighter conditions on which off-balance-sheet items attract which credit conversion factor — each of these needs an attribute the old calculation may never have captured.

The failure mode is predictable. The calculation engine asks for a field — property valuation basis, LTV at a defined date, whether an exposure is to an SME, the currency-matching status of a retail loan — and the source system does not hold it, or holds it inconsistently across booking locations. Reporting teams then paper over the gap with a default assumption, usually the most conservative one, and the RWA number inflates for a reason nobody can explain to the board. The problem is not in COREP. It is three systems upstream, in a data model that was never asked to carry these attributes.

Operational risk: one method, and it needs clean history

Operational risk is where the calculation change is most absolute. CRR3 replaces the previous menu of approaches — the basic indicator, the standardised, and internal advanced measurement — with a single new standardised method driven by a business indicator derived from the income statement. There is no longer a modelling option to hide behind. Every in-scope firm computes operational-risk RWAs the same way, from the same accounting inputs, and the calculation reaches back over several years of financial data.

That backward reach is the trap. The business indicator is built from components of the profit-and-loss account, averaged over a multi-year window, and the definitions do not map one-to-one onto the general-ledger lines a firm reports for statutory accounts. If nobody has reconstructed those components on the CRR3 basis for the historical years the calculation requires, the operational-risk number is either wrong or unauditable. This is not a reporting task. It is a finance-data reconciliation task that happens to feed a reporting template.

Market risk moved the goalposts, then moved the date

Market risk is the one piece where time is on your side, and only because the Commission granted it. The fundamental review of the trading book — FRTB, the revised market-risk framework with its sensitivities-based standardised method and internal-model approach — has been postponed, and postponed again: a delegated regulation adopted in June 2025 moved the application of the own-funds requirements for market risk to 1 January 2027, a year later than the previous 2026 date.

The postponement is a scheduling gift, not a reprieve. FRTB is a far larger calculation-engine build than anything on the credit or operational side, and treating 2027 as distant is how firms arrive at 2026 with a data model that cannot produce the sensitivities the standardised method consumes. If you have trading-book exposures, the market-risk stream should be running now on its own track; I have set out the shape of that build in preparing for the 1 January 2027 market-risk go-live.

What the fix actually is

The through-line across all four risk types is the same: CRR3 is a calculation and data problem wearing the costume of a reporting problem. The work that matters sits below COREP, in the RWA engine and the source data that feeds it. Three things earn their place at the front of the programme.

1. Stand up a production-grade standardised-approach calculation across the full book, for internal-models firms, because the output floor makes it a permanent parallel run rather than a one-off.
2. Trace every new or redefined input attribute back to a source system and fix it there, not with a conservative default in the reporting layer that inflates capital for reasons you cannot defend.
3. Reconstruct the operational-risk business-indicator components on the CRR3 basis for the historical years the calculation reaches, and reconcile them to the statutory accounts so the number is auditable.

None of this is visible if you scope the programme from the template outwards. It is only visible if you scope it from the calculation inwards — and that is a decision about where the work is owned. Handed to reporting, CRR3 becomes a mapping exercise that fails silently at reconciliation. Owned by the function that controls the RWA engine and the source data, it becomes what it actually is: an engineering change with a reporting output. The supervisor will read the output. The board should be asking about the engine, which is the same discipline that makes board-level risk reporting survive scrutiny — and the same reason a control a regulator inspects, whether an RWA engine or the logging estate under DORA in steady state, has to be built to be reconstructed on demand, not just to produce a number.

If your CRR3 numbers do not tie out this quarter, the defect is almost never in the template. It is in the calculation you stopped performing, or the field you never captured.