AI in regulatory reporting: Why a detector and not a calculator?

Editorially reviewed: 22 October 2026 · Legal status checked up to: 22 October 2026. Time-bound statements are dated; legal acts that are announced but not yet published are marked as such.

For whom: Banks (SI) Banks (LSI) Reporting service providers The examples come from bank regulatory reporting (AnaCredit, FINREP, COREP, VERA); the control questions apply to insurers as well.

AI does not calculate the report – that is our advisory position, not a legal prohibition. The reported value remains deterministic, rule-based and reproducible. AI works upstream – on data quality – and downstream – on analysis, explanation and commentary. Not in the calculation chain. Everything on this page follows from that red line.

What does the starting point look like in numbers?

• Around 20 % lower reporting costs since 2021. The EBA's cost-of-compliance study of June 2021 (mandate from Art. 430(8) CRR) led to 25 recommendations with 15 to 24 % savings potential; in its 2025 report on the efficiency of the framework the EBA notes that reporting costs have fallen by around 20 % since. The often-quoted billion figure is not a European number but one vendor's global cost estimate for a large internationally active bank.
• 88 attributes. AnaCredit collects, loan by loan, 88 credit, credit risk and accounting attributes plus identifiers, mostly monthly, from EUR 25,000. The ECB runs validation and plausibility checks on them – the latter expressly to identify data that is probably wrong. Supervisors have long been working with probabilities while institutions still check in binary.
• Rules corrected four times a year. The EBA publishes quarterly packages deactivating validation rules because they are substantively incorrect or cause IT problems. The entire quality assurance rests on a rulebook its own author corrects regularly.
• One Basic Cube. Austria's common reporting data model derives the Smart Cubes – BWG, DevG, ECB regulations, EBA ITS – from one uniform granular data set. That is ahead of the rest of Europe and has a consequence: an error in a derivation rule produces a Smart Cube that is entirely consistent in itself. All validation rules green. And still wrong.

Which blind spots do validation rules have?

This refers to the EBA validation rules and the institution's internal checks applied to reports before submission. They test defined business and technical relationships – and only those that someone formulated as a rule beforehand. The ECB itself goes further for AnaCredit: its plausibility checks compare across several reference dates and against other data sets. Internally, however, three systematic gaps remain that rule-based controls do not close; statistical methods and AI complement them, they do not replace them.

Supervisors are working on precisely these gaps – and say so publicly. In 2022 the Banca d’Italia published a methodology in which stacked machine-learning models find anomalies in AnaCredit by reconciling against balance sheet statistics and FINREP (QEF No 689); ECB statistics lists anomaly detection in AnaCredit as a machine-learning use case. For Austria: on 15 December 2025 the OeNB and FMA declared the dialogue with banks on concrete AI applications and the evaluation of AI in supervision priorities for 2026. What is documented is that a supervisory approach is in development – not that the OeNB or FMA already use AI to examine reporting data.

Where can AI help in regulatory reporting?

In six places, from cross-report reconciliation through drift detection and silent defaults to variance narratives; AI delivers candidates, not reported values.

Form-based reports: How many have a Basic Cube reconciliation?

Only 3 of 13. Everything said so far presupposes granular data. Form-based reports are the reverse: few figures, each the result of an aggregation or manual collection. The VERA – the asset, income and risk statement under section 74(1) and (6) BWG – is the best Austrian example. Unconsolidated it consists of thirteen reports; for exactly three the OeNB refers to derivations from the Basic Cube (business structure data, covered deposits, private residential real estate financing). For the remaining ten that reference is missing – income statement, hidden reserves, remuneration reports, complaints handling, funding plans and planning data come from the general ledger, HR, complaints management and controlling. Where a documented derivation exists, the report can be reconstructed from below. Where no published standard derivation exists, the institution must document provenance and calculation itself – general ledger evidence, controlled business calculations and sign-offs are then the proof, and they are missing more often than business units assume. (Count based on the OeNB VERA reporting requirements, unconsolidated, as of 22 September 2025; verify against the current collections before use.) Three classes with three examination strategies follow – reconstruction, time-series and relationship analysis, history and consistency analysis – and four steps that require no AI: lineage inventory, control intensity by class, logging of overrides, machine-readable reporting guidelines.

The red line: Why does generative calculation not belong in the reporting chain?

The line separates three things: approved business calculation rules that produce the report; validated and versioned models used in risk measurement and data quality; and uncontrolled generative calculation, which has no place in the reporting chain. Versioned classical models are reproducible – the point is that they deliver candidates, not reported values.

• Reproducibility. A report must be reproducible years later with an identical result. A model with drift, retraining and version states cannot guarantee that without strict version control.
• Auditability. Internal audit, the external auditor and on-site inspections must be able to trace the path from individual transaction to reporting position. In a process with this density of responsibility, AI must not be a black box.
• Data quality. Good AI on bad data produces confident-sounding errors – in regulatory reporting the most expensive error type, because it passes every plausibility check.

Which regime actually applies to reporting AI?

An AI that detects AnaCredit anomalies is not a high-risk system under Annex III of the AI Act. In the financial context Annex III point 5 covers only creditworthiness assessment of natural persons and risk assessment in life and health insurance. The classification must nevertheless be documented per use case on the basis of the intended purpose. The conclusion “then the AI Act does not concern us” is wrong all the same – from three directions: the obligation to take AI literacy measures under Art. 4 has applied since February 2025 (framed by the Omnibus as a duty to promote), the transparency obligations under Art. 50 have applied since 2 August 2026 where one of their triggers is met – for instance AI interacting with persons or AI-generated text – and the sanction powers apply from the same date. The Digital Omnibus (Regulation (EU) 2026/1744, in force since 27 July 2026) postponed the high-risk obligations for Annex III systems to 2 December 2027 – institutions with retail credit scoring therefore run two calendars: one for reporting AI outside Annex III, one for the lending business inside it.

Where the pressure actually comes from: DORA assigns AI to ICT risk management; under Art. 5(2) the management body bears overall responsibility. BaFin's guidance of December 2025 – not binding in Austria, but currently the most detailed German-language interpretation – emphasises operation and decommissioning: uncontrolled de-installation, outdated model versions and insufficiently secured training data count as significant ICT risks. And the ECB guide on risk data aggregation requires the BCBS 239 principles to be applied to all regulatory reports – directly for significant institutions, for Austrian LSIs via the LSI SREP and from 2027 via EBA/GL/2026/06 as the examination benchmark.

What does the data glossary not answer?

Six questions that an existing data quality framework does not answer and that must be decided before any productive use – they belong to data protection, banking secrecy, model governance and ICT risk, not to data architecture:

• Which data may go to which model? Reporting data contain personal and banking-secrecy-relevant content; release per data class and model, not across the board.
• Who approves the use? A named owner per use case and model output; inventory as an ICT asset with exit and decommissioning path (DORA).
• Are inputs used for training? Exclude contractually or prevent technically – the first question for external models.
• What rights does an agent have? Read, propose, write: in our view, write access to reporting chains is excluded.
• How are model changes, false alarms and prompt injection handled? Versioning, false-alarm rate as a metric, protection against manipulated inputs from documents.
• What happens in an outage? The report must be produced on time without the model – otherwise it is part of the calculation chain.

How can an AI use case be classified in ten minutes?

Five questions about a concrete AI use case in your own reporting process:

1. Does the system intervene in the calculation of the reporting position – yes or no?
2. Are personal creditworthiness decisions (Annex III point 5(b)) or – for insurers – risk assessment and pricing in life and health insurance (point 5(c)) affected – yes or no? (Annex III test)
3. Is the system inventoried as an ICT asset, including exit and decommissioning path? (DORA)
4. Is the effect on the data quality of regulatory reporting documented? (RDARR)
5. Is there a named human owner for every model output? (all three)

Where is regulatory reporting heading?

Towards granularity. The ECB's Integrated Reporting Framework consolidates the statistical reporting requirements of euro area banks; the pilot is planned for the second quarter of 2030, reporting operations for 2031. The more granular and better reconciled the data base, the more reliably models can be applied to it. For Austria this is a remarkable starting position: the Basic Cube is structurally exactly what Europe is heading for in 2031. That is a head start – provided it is used analytically and not merely as a reporting machine.

Frequently asked questions

Is an AI for data quality checks in regulatory reporting a high-risk system?

No. In the financial context, Annex III point 5 of the AI Act covers only creditworthiness assessment of natural persons and risk assessment in life and health insurance. Data quality checking in regulatory reporting falls under none of these. Art. 4 (AI literacy) and Art. 50 (transparency) apply nonetheless.

May AI calculate the report?

Legally it is not prohibited; in our view it should not – for reasons of reproducibility and auditability. A report must be reproducible identically years later; a model with drift and retraining does not guarantee that without strict version control. AI belongs before and after the calculation chain.

Where should an institution start?

With silent defaults: a constancy and entropy analysis over time needs hardly any machine learning, delivers the fastest measurable benefit and makes visible what nobody checks today because no rule exists for it.

What governance does a reporting AI need?

At its core the same as RDARR: data quality metrics, lineage, documented responsibilities, escalation paths – applied to the AI use case, plus inventory as an ICT asset under DORA with exit and decommissioning path. Added to that are the documented classification under the AI Act, data protection and banking secrecy in data release, version and model-change control, and the safeguarding of external models.