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. This piece walks through Regulation (EU) 2016/867 (ECB/2016/13) in the order a build team actually meets it.

1. Who reports at all

Article 3 of the Regulation fixes the actual reporting population: resident credit institutions and resident foreign branches of credit institutions, whether or not they are supervised under Directive 2013/36/EU. Each reports on an individual basis to its own national central bank (NCB); nobody reports to the ECB directly.

That definition keeps e-money institutions and payment institutions outside the ECB collection. It does not keep them outside every credit register: Article 8(3) says the Regulation is without prejudice to national reporting, and several NCBs run their AnaCredit collection inside a wider national register with its own population. A payments firm that lends should read its NCB’s national rules, not assume Article 3 settles the question — the position of payment firms differs by country.

2. Reporting agent and observed agent

The Regulation separates the entity that files from the unit whose activity is described:

Article 6(2) sets who covers whom: a reporting agent that is a legal entity reports for all observed agents that are part of it; a reporting agent that is a foreign branch reports only its own activity. Article 8(2) adds that branches outside the reporting member states are not reporting agents, but the parent must make sure they have the processes to feed the data in. Article 6(3) and 6(4) then let NCBs trim overlap: where both a legal entity and its branch are resident in reporting member states, the NCBs coordinate so the same loans are not reported twice, and an NCB may decide not to collect data on non-resident branches at all.

3. The reference period, and why it is not the month

Article 4(2) defines the reference period for a given reporting reference date as the period that starts on the last reporting reference date of the preceding quarter and ends on that given reporting reference date. Article 13(1) fixes the reference dates themselves: the last day of each month for monthly transmissions, and the last day of March, June, September and December for quarterly ones.

This matters because the threshold is tested across the whole period. Under Article 5(1), 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. For the 31 May reference date, the period runs from 31 March, so the 31 March, 30 April and 31 May positions all count. An exposure that crossed the line at end-April and fell back by end-May is still in scope for May.

4. What instruments, and which debtors

Article 4(1) brings an instrument in scope if, on any reference date in the period, it gives rise to credit risk for the observed agent, is an asset of the observed agent, is still recognised and gave rise to credit risk in the past, or is serviced by a resident observed agent under the conditions set out there. A second condition then filters hard: at least one debtor must be a legal entity or part of one.

So a loan to a natural person alone is out. Where a natural person is a co-debtor alongside a company, the instrument is in, but Annex I says no record is reported for the natural person. Sole-trader lending is the recurring grey area: whether the borrower is treated as a legal entity turns on the Regulation’s definition and national guidance, so decide the rule once, document it, and apply it consistently across periods.

5. The aggregation level is the trap

Article 5(2) is explicit: the debtor’s commitment amount is the sum of the commitment amounts for all instruments of the debtor in relation to the observed agent, on the basis of the Article 4 scope.

• Per instrument — wrong, and materially short 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 be below threshold at each observed agent and above it across the group, and the Regulation’s answer is the observed-agent figure. Once a debtor is over the line, all its in-scope instruments with that observed agent are reported, including the small ones.

6. The ten datasets, and how often each moves

Article 6(1) requires reporting on an individual basis using the templates in Annex I. The data is organised into ten datasets across two templates, each with its own granularity and frequency:

Amounts are reported in euro units; foreign-currency amounts convert at the ECB reference mid-rate on the reporting reference date. Any drawn amount goes in outstanding nominal amount and any committed undrawn amount in off-balance-sheet amount. Annex II then reduces the attribute set in four cases: non-resident observed agents, observed agents not subject to Regulation (EU) No 575/2013, fully derecognised instruments still being serviced, and instruments that started before 1 September 2018.

7. Identifiers hold the file together

The datasets link through keys, and Annex I is strict about them. A counterparty identifier must be unique per counterparty for the reporting agent and must never be reused for a different counterparty. A contract identifier must be unique per contract with the observed agent, and each instrument identifier unique within its contract — neither may be reused. Each counterparty is registered once, however many roles it takes: creditor, debtor, protection provider, originator, servicer, head office, immediate or ultimate parent.

Article 9 requires counterparties to be identified by LEI where one exists, otherwise by a national identifier as set out in Annex IV. An identifier that changes between submissions breaks the history for that record even where every attribute is correct — which is why a core-system migration is the most dangerous event in an AnaCredit programme. The data model has to be built first and the file second.

8. Deadlines are set nationally — with an ECB backstop

Article 13(2) leaves it to each NCB to decide when and how often it receives data from reporting agents. What the Regulation fixes is the NCB’s own deadline to the ECB: for resident observed agents, monthly data by close of business on the 30th working day after month-end; for non-resident branches, the 35th working day. Quarterly data is tied to the supervisory remittance dates. Your NCB’s deadline sits inside those windows, with time left for its own validation, so the effective internal deadline is materially earlier.

Annex V sets the minimum standards the NCB checks you against: timely transmission in the NCB’s technical format with named contact persons; accuracy, including consistency across frequencies and no structural gaps; compliance with the Regulation’s definitions; the ability to explain breaks against previous periods; and a revisions policy followed, with explanatory notes for irregular revisions. Article 16 lets NCBs grant derogations to small reporting agents, capped so that derogated agents together hold no more than 2% of the national loan stock.

9. Three scenarios from a build

Scenario 1 — the facility that peaked mid-quarter. Facts: a corporate client draws EUR 30,000 on a revolving line at end-April and repays to EUR 8,000 by end-May. Rule: Article 5(1) tests every reference date in the period from 31 March. What the team does: the population engine stores the commitment amount at each month-end and tests the maximum across the window, not only the current date. Outcome: the debtor is reported for May and June; it drops out only when no reference date in the rolling window reaches EUR 25,000.

Scenario 2 — the debtor split across two branches. Facts: a company owes EUR 15,000 to the head office and EUR 15,000 to a branch in another reporting member state. Rule: Article 5(2) aggregates in relation to each observed agent. What the team does: tests the head office and the branch separately; each is EUR 15,000. Outcome: nothing is reported for either, even though group exposure is EUR 30,000. Teams that aggregate at group level over-report here; the NCB’s plausibility checks will not flag it, because every record is well formed.

Scenario 3 — the core-banking migration. Facts: a lender moves loans to a new core system that assigns fresh contract numbers. Rule: Annex I forbids reuse and requires stable identifiers per contract and instrument; Annex V requires breaks to be explained. What the team does: keeps the old AnaCredit contract and instrument identifiers in a mapping table and reports them unchanged, rather than letting the new numbers flow through. Outcome: history is preserved. Had the new numbers gone through, every migrated loan would appear to end and a new one begin, and the NCB would ask for an explanation of the break.

10. The build order that works

Institutions often start by mapping the amount fields, because those are what gets reported. The amounts are the easy part and almost always available. The difficulty is in the agent structure, the population logic, the identifiers and counterparty reference data, where most rejections originate in practice.

Work in the order the Regulation implies. First the reporting and observed agent structure, because it defines who is in the file. Then the population, applying the EUR 25,000 test per debtor and observed agent across the reference period. Then identifiers. Then counterparty reference data, with LEI and national identifiers reconciled to the NCB’s register. Amounts last. Where an NCB has built its collection on an existing credit register, the national layer adds its own attributes and validation, so the national implementation is a second specification to read, not a formatting detail.

11. What to do, today

• Write down the agent map: each reporting agent, each observed agent, and which NCB receives what.
• Store month-end commitment amounts per debtor and observed agent, so the rolling threshold test is reproducible.
• Freeze identifier rules before any system change, with a mapping table owned by the reporting team.
• Get the NCB’s calendar and technical specification, not just the Regulation, and set internal cut-offs back from it.
• Keep a break log so every period-on-period change can be explained on request.

FAQ

Related: The AnaCredit data model · What is a reporting agent · AnaCredit phases · NACE Rev. 2.1 — the activity-code migration