AnaCredit — how a submission is actually built
AnaCredit is the most granular collection most institutions will ever build, and almost everything that goes wrong with it is decided before a single amount is calculated. Who files, on behalf of which unit, over what period, above what aggregated threshold — those four decisions define the population, and a mistake in any of them produces a file that validates cleanly and covers the wrong set of loans.
1. Reporting agent and observed agent
Regulation (EU) 2016/867 separates the entity that files from the unit whose activity is described:
| Role | Definition |
|---|---|
| Reporting agent | Either a legal entity or a foreign branch that is resident in a reporting member state and subject to the ECB’s reporting requirements under the Regulation |
| Observed agent | The institutional unit whose activity as creditor or servicer is reported by the reporting agent — either a unit resident in the same country as the reporting agent of which it forms part, a foreign branch resident in a reporting member state, or a foreign branch not resident in a reporting member state |
2. The reference period, and why it is not the month
For a given reporting reference date, the reference period is defined as the period that starts on the last reporting reference date of the quarter preceding that reporting reference date and ends on that given reporting reference date.
This matters because the threshold is tested across it. Under Article 5, credit data is reported where the debtor’s commitment amount is equal to or larger than EUR 25,000 on any reporting reference date within the reference period. An exposure that peaked mid-period and fell away before month end is in scope — and a population built by testing only at the reference date will be short, with nothing in the file to indicate it.
3. The aggregation level is the trap
Article 5(2) is explicit: the debtor’s commitment amount is calculated as the sum of the commitment amounts for all instruments of the debtor in relation to the observed agent, on the basis of the scope of Article 4.
Three levels are available and only one is correct:
- Per instrument — wrong, and produces a materially short population where a debtor holds several small facilities;
- Group-wide across the whole reporting agent — wrong in the other direction;
- Per debtor, in relation to the observed agent — correct.
A debtor can therefore be below threshold at each observed agent individually and above it in aggregate across the group, and the Regulation’s answer is the observed-agent figure. This is the single most consequential mapping decision in an AnaCredit build.
4. Individual basis, and the templates
Article 6 requires reporting agents to report credit data on an individual basis in accordance with the templates in Annex I. Granular, loan-by-loan reporting is the design, not an option — which is what makes AnaCredit an architectural project rather than a reporting one.
The practical consequence is that the data model has to be built first and the file second. The datasets are linked by identifiers, and identifier discipline — for counterparties, contracts and instruments — is what determines whether the linked structure holds together across periods. An identifier that changes between submissions breaks the history for that record even where every attribute is correct.
5. The build order that works
Facts: an institution begins an AnaCredit implementation by mapping the amount fields, on the reasonable-sounding basis that those are what gets reported.
What goes wrong: the amounts are the easy part and almost always available. The difficulty is in the counterparty attributes, the identifiers and the population logic — and by the time those are addressed, the mapping has been built around a population that is already wrong.
What the practitioner does: works in the order the Regulation implies. First establish the reporting and observed agent structure, because it defines who is in the file. Then the population, applying the EUR 25,000 test at debtor level in relation to each observed agent, across the reference period. Then identifiers, since they hold the datasets together. Then counterparty reference data, which is the largest single source of rejections. Amounts last.
Where the national central bank has built its collection on an existing credit register — as several have — the national layer adds its own attributes and its own validation on top, so the national implementation is a second specification to read rather than a formatting detail.
FAQ
At what level is the EUR 25,000 threshold applied?
Per debtor, aggregated across all in-scope instruments in relation to the observed agent — not per instrument and not group-wide.
When is the threshold tested?
On any reporting reference date within the reference period, which runs from the last reporting reference date of the preceding quarter to the given reference date.
What should be built first?
The agent structure and the population logic, then identifiers and counterparty reference data. Amounts are the easiest part and should not drive the design.
Related: The AnaCredit data model · What is a reporting agent · AnaCredit phases
