AnaCredit v1.0.15: BCL Swaps the NUTS 3 Code List for January 2027

On 1 October 2026 the Banque centrale du Luxembourg (BCL) published version 1.0.15 of its AnaCredit technical specifications together with a new SDMX schema package, and its reporting instructions page states that the AnaCredit v1.0.15 schemas are mandatory from reference date January 2027 (included) onwards. Credit institutions and foreign branches resident in Luxembourg therefore send their first v1.0.15 messages for the 31 January 2027 reference date. The December 2026 files they submit in January 2027, and every later correction to a reference date from July to December 2026, stay on v1.0.14.

The release is narrow. A file-by-file comparison of the two published packages shows that the four survey schemas differ only in their version labels, that the cube structure and facets workbooks have identical cell content, and that the substance is a replaced NUTS 3 code list, which the BCL’s own difference file labels as updates for NUTS 2027, plus a newly documented set of feedback schemas. That narrow scope still carries file-rejection risk: the version number sits inside every XML namespace, the BCL validation rule TR0210 rejects a file whose schema version does not match its reference date, and a counterparty or collateral record that still carries one of the 48 withdrawn region codes fails schema validation at the transmission channel.

Related reading: AnaCredit Reporting in Germany: Bundesbank Credit Data and Deadlines

AnaCredit v1.0.15 dates: which schema belongs to which reference date

• 5 May 2026: the BCL publishes the v1.0.14 package (technical specifications, schemas, cube structure, facets, subdomains).
• 1 October 2026: the BCL publishes the v1.0.15 package, with a revision-marked PDF and an updated list of SDMX schemas by reference date.
• Reference dates July 2026 to December 2026 (included): v1.0.14 is mandatory.
• Reference date January 2027 (included) onwards: v1.0.15 is mandatory.
• 1 January 2027: Eurostat’s NUTS 2027 classification takes effect, under Commission Delegated Regulation (EU) 2026/195.
• 15th working day after the end of the reference period: the BCL deadline for the monthly datasets, and for the quarterly accounting dataset after quarter end. The first quarterly accounting file on v1.0.15 is the one for 31 March 2027.

The switch is keyed to the reference date of the data. The BCL’s workbook listing SDMX schemas by reference date opens with the statement that submissions and resubmissions have to follow the schema version defined for each reference date, and it maps 202607 to 202612 to version 1.0.14 and 202701 onwards to version 1.0.15. Section 3.2.4 of the BCL reporting instructions (version 4.6, 23 October 2025) applies the same rule to corrections: the reports triggering errors are resent as full replacement, “always using the version of the SDMX schemas valid at the reference date”. Reference periods before April 2023 are the stated exception and go in schema version 1.0.7.

January 2027 is the month where both versions run side by side. The monthly files for 31 December 2026 and the quarterly accounting file for the fourth quarter of 2026 both fall due in January and both use v1.0.14, while the build for the 31 January 2027 files has to be ready on v1.0.15 a few weeks later. The BCL notes in its instructions that its reporting deadlines are provisional and that it publishes a calendar of remittance dates.

The v1.0.14 to v1.0.15 delta, file by file

The BCL ships each version as a zip containing the collection schemas, documentation workbooks, example files and a folder of difference files. Comparing the v1.0.14 and v1.0.15 schema files with the version strings normalised, and the workbooks cell by cell, gives this picture:

The BCL’s packaging tells the same story. The v1.0.14 zip carried three difference workbooks against v1.0.13, one each for cube structures, facets and subdomains. The v1.0.15 zip carries two, both for subdomains, one of them restricted to codes in NUTS3_ANCRDT_CLLCTN, and the summary sheet of the full subdomain workbook lists NUTS3_ANCRDT_CLLCTN as the only changed subdomain, with the comment “Updates for NUTS 2027”. Nothing in the release touches the cube definitions, so no attribute is added, removed or retyped.

The version number does reach every message all the same. Each of the eight collection schemas declares a target namespace with the version embedded, for example http://www.bcl.lu/rf/sdmx-ml/LU_ANCRDT/v1_0_15/BCL_ANCRDT_T1_REF, the survey schemas import the constraint and format schemas by versioned file name, and section 4.2 of the specifications requires all schema files to sit in the same directory. An XML writer with the v1_0_14 namespace hard-coded produces a file that is well formed, structurally identical to a valid one, and still the wrong file for a 2027 reference date.

The revision-marked PDF is the wrong diff to work from

The BCL also publishes the specifications with revision marks, and a team scoping the change could reasonably start there. The markup in the v1.0.15 redline is drawn against an older baseline: the deleted text in the margin includes file suffixes ending in 1_0_11 and footer text showing a July 2024 date, and the v1.0.14 redline carries the same older footer deletions. Wording shown as removed in the v1.0.15 redline, such as the references to DICO, the BCL’s extension of the ECB Single Data Dictionary, had already gone from the clean v1.0.14 document. Against the clean v1.0.14 text, the edits I can find are the version numbers in titles, footers and file names, the new section 4.2.4 on merged feedbacks, and the annex line that now points to the differences between version 1.0.14 and version 1.0.15. One small inconsistency remains in the clean PDF: its contents page still numbers the SDMX-ML 2.1 section as 4.2.4, while the body numbers it 4.2.5.

Inside NUTS3_ANCRDT_CLLCTN: 48 codes out, 54 in

NUTS, the EU nomenclature of territorial units for statistics, rests on Regulation (EC) No 1059/2003, and the Commission revises its annexes by delegated regulation. Eurostat’s history page lists NUTS 2024 (Regulation (EU) 2023/674) as applicable for data transmission in 2024 to 2026 and NUTS 2027 (Regulation (EU) 2026/195) as applicable from 2027. Its overview page gives 1,165 NUTS 3 regions for NUTS 2024 and 1,170 for NUTS 2027. The BCL list matches both: v1.0.14 holds 1,165 regional codes plus 26 Extra-Regio codes, and v1.0.15 holds 1,170 regional codes plus 27 Extra-Regio codes.

The code changes are concentrated in six countries:

Two kinds of change sit in that table and they need different handling. In Belgium, Bulgaria and the three Thuringian districts the region names survive under new codes. The BCL file presents each one as a removal plus an addition, supplies no mapping and gives no reason for any individual recoding, so a surviving name does not prove a surviving boundary. Main-Kinzig-Kreis, the four Sardinian codes and PL613 are splits or redraws, and the BCL file gives no crosswalk for them, so the counterparty’s address is the safe basis for the new code. A counterparty registered in Hanau and one registered elsewhere in the Main-Kinzig-Kreis both carried DE719 under v1.0.14 and land on different codes from January 2027.

Zwijndrecht shows why the name-matched group needs a check too. A Flemish decree of 19 April 2024 merged Beveren, Kruibeke and Zwijndrecht into Beveren-Kruibeke-Zwijndrecht on 1 January 2025, placed the new municipality in the province of East Flanders and changed the provincial boundary with Antwerp. In the NUTS 2027 annex, BE261, BE262 and BE263 all sit under BE26 Prov. Antwerpen, so a name-based mapping of a Zwijndrecht counterparty from its old province of Antwerp code to the BE26 code of the same name would place it in the wrong province. For the other recoded Belgian, Bulgarian and Thuringian regions, neither the BCL file nor its labels show whether a boundary moved, and a name match is only a starting point to test against each counterparty’s municipality.

The release also rewrites 141 labels on codes that keep their value. The 52 Greek labels move from transliteration to Greek script, Polish and Romanian labels gain their diacritics, Gipuzkoa and Bizkaia replace the Spanish forms of those province names, and 15 labels, 12 French and 3 Irish, now end with a trailing space. None of this reaches the XML, which carries the code only. It does break any lookup that derives the code from a region name, and a name match that worked on the v1.0.14 workbook can silently fail on the v1.0.15 one.

Where the NUTS 3 code sits in BCL AnaCredit files

Two attributes in the BCL schemas take their values from NUTS3_ANCRDT_CLLCTN:

• TRRTRL_UNT, “Territorial unit”, in the counterparty reference cube BCL_ANCRDT_ENTTY_C (table 1, survey BCL_ANCRDT_T1_REF, file prefix ANTREF);
• RECL_TRRTRL_UNT, documented as the region where the collateral is located, in the protection received cube BCL_ANCRDT_PRTCTN_RCVD_C (table 7, survey BCL_ANCRDT_T2M, file prefix ANTT2M), next to RECL_CNTRY and RECL_PSTL_CD.

Both are typed against the enumeration, so an unknown code fails the XSD check. The BCL instructions state that the e-file and SOFIE channels check each file for XSD compliance before it reaches the BCL and reject a file that is not XSD valid. The postal code attributes, PSTL_CD and RECL_PSTL_CD, are free-text strings of up to 255 characters and are untouched by the code list change.

The ECB’s AnaCredit Reporting Manual, Part II (May 2019 edition), explains why postal codes matter here. For the counterparty’s county or administrative division (section 12.4.11) and for real estate collateral location (section 9.4.7), it describes NUTS 3 as derived centrally by the ECB from postal codes. Which of the two attributes a given record is expected to carry is a completeness question for the BCL’s validation rules, and the BCL rule NA0090 adds that “The attribute Address: county/administrative must not be reported as Non-applicable.” Teams that change how they populate TRRTRL_UNT to sidestep the recoding should check the completeness rules first.

The full-snapshot design raises the stakes. Each BCL AnaCredit message carries a FULL_REPLACEMENT submission type and the full snapshot of all records for the survey and reference date, so the 31 January 2027 counterparty reference file republishes every counterparty in the book. If TRRTRL_UNT is populated, a single counterparty still coded BE211 or DE719 is enough for the channel to reject the whole ANTREF file, and the same holds for protection received records in the ANTT2M file. Real estate collateral located in the recoded regions is the second place to look, after the counterparty master. For the CSSF’s separate real estate lending collection, see our guide to ESPREP-RES real estate lending reporting in Luxembourg.

A book of mostly Luxembourg borrowers still carries some exposure. LU000 remains the only regional NUTS 3 code for Luxembourg in the list, so domestic counterparties keep their value. The exposure sits in the cross-border tail: counterparties, parent undertakings and collateral located in the recoded regions.

Corrections and historical data under two code lists

The ECB Manual, Part II, section 2.4, sets the general rule for external code lists such as NUTS. Data are reported with the codes valid at the reporting reference date, data reported after an amendment use the new classification, and reporting agents are generally not required to update historical data when a new classification arrives. Its Example 1, which illustrates the principle with a currency split, makes the correction case explicit: a backward correction uses the code that was valid on the original reference date, even when that code no longer exists at the time of the correction.

Read together with the BCL’s reference-date rule for schemas, the result is a pair of code lists that both stay live. A correction in March 2027 to the 30 November 2026 counterparty file goes in under v1.0.14 with the old Belgian or Bulgarian code, and the v1.0.14 enumeration would reject BE261 or BG521 if a remapped value leaked into that resubmission. From the 31 January 2027 reference date onwards, the v1.0.15 enumeration rejects the old values. A counterparty master that stores only the current NUTS code, overwritten in place, cannot serve both cases.

Nothing in section 2.4 asks for 2026 data to be restated with NUTS 2027 codes. The Manual’s own illustration has reporting agents send an additional counterparty record as of the date the new classification takes effect, for affected counterparties only. Under the BCL’s monthly full snapshot the January 2027 ANTREF file carries every counterparty anyway, so the practical effect is the same.

Namespaces, sample files and rule TR0210

The BCL validation rules workbook, dated 29 July 2026 on the reporting instructions page, contains two file-level checks that bite on a version switch. TR0010, “Wrong schemas”, and TR0210, “Check that the schema version in the SDMX header is expected for the given reference date”, both carry the impact “File rejected”. The workbook listed next to the v1.0.15 package is still that 29 July 2026 edition, and it shows no start or end date for either check.

The example files in the v1.0.15 zip need care. The three samples, ANTREF_202701_LUB05665_BCL001.xml, ANTT1M_202701_LUB05665_LUB05665_BCL001.xml and ANTT2Q_202701_LUB05665_LUB05665_BCL001.xml, carry January 2027 reference dates but still declare the v1_0_14 namespace and point their schemaLocation at the v1_0_14 schema files. I read this as a sample that was updated for its dates and not for its version, and the safer course is to treat the v1.0.15 XSDs as the reference and the samples as illustrations only. A team that clones the sample header into its generator would carry the old namespace into a 2027 file.

Everything else about the message stays as it was: the root element StructureSpecificData, one SDMX header, one technical header dataset (BCL_ANCRDT_REF_HDR_C for counterparty reference data, BCL_ANCRDT_HDR_C for credit data), then one dataset per AnaCredit table with the action “Replace”. File names still follow [Prefix]_[Period]_[ReportingAgentCode]_[messageID] for ANTREF and add the observed agent code for ANTT1M, ANTT2M and ANTT2Q, and a zip may contain only one XML file with the same name. Section 5.1 of the specifications requires the message ID to be unique for each survey, reporting agent (observed agent for credit data) and reference date, and the BCL validation rule TR0130 rejects a file whose message ID is not unique. Teams that also run XBRL pipelines will recognise the version discipline from our note on the EBA’s supervisory reporting validation rules update.

The merged-feedback schemas in section 4.2.4

Section 4.2.4 of the v1.0.15 specifications, “XML schemas for the merged feedbacks”, lists five files: BCL_ANCRDT_REF_FDBCK_ACMD_v1_1_0.xsd, described as the schema for the merged feedbacks, and four supporting schemas at version 1_0_3 (BCL_LU_ANCRDT_D_CONSTRAINTS, ECB_LU_ANCRDT_D_CONSTRAINTS, BCL_LU_ANCRDT_D_FORMATS and ECB_LU_ANCRDT_D_FORMATS). The v1.0.14 specifications had no such section and its zip had no feedback folder.

The feedback schema has its own namespace, ending in v1_1_0/BCL_DATA_FDB, and its own version numbers, 1_1_0 and 1_0_3, separate from the 1_0_15 collection schemas. It defines a header with the original file name, reporting agent, observed agent, survey and reference date, a status of either FULL_VALIDATION or PARTIAL_VALIDATION, and error records carrying a validation identifier, description, error type, key and value. That lines up with the BCL instructions, which describe a technical feedback after the technical checks, a business feedback per survey, and a limit of 10,000 errors shown per feedback.

For a team that parses BCL feedback automatically, the format now appears inside the technical specifications, where v1.0.14 did not list it. Whether the feedback files actually delivered have changed format is a separate question, which the specification does not answer.

What v1.0.15 leaves exactly as it was

The reporting perimeter has not moved. Under the BCL instructions, the legal basis remains Regulation (EU) 2016/867 of the European Central Bank (ECB/2016/13), transposed in Luxembourg by BCL circular 2017/240, and the reporting population remains all credit institutions and foreign branches resident in Luxembourg, subject to derogations coordinated between national central banks for branches. The ten AnaCredit tables keep their survey mapping: the counterparty reference table in BCL_ANCRDT_T1_REF; instrument, financial, counterparty-instrument and joint liabilities in BCL_ANCRDT_T1M; protection received, instrument-protection, counterparty risk and counterparty default in BCL_ANCRDT_T2M; accounting in BCL_ANCRDT_T2Q.

The timing rules are also untouched. Datasets 1 to 5 and 7 to 10 go to the BCL monthly by the 15th working day after the end of the reference period, and dataset 6, accounting, goes quarterly by the 15th working day after the quarter, which the instructions explain leaves time to correct discrepancies found in the comparisons with the S 1.1 and S 1.5 statistical returns and with FINREP reporting. The null explanatory value conventions in section 5.4 of the specifications are unchanged too: “Not applicable” is NEVS value 0, “Not required” is -5, a reported field never carries its NEVS, and a record whose fields are all null or not applicable, and which no other record references, is omitted.

The counterparty identification logic in chapter 6 is also unchanged. The LEI is reported where one has been assigned, a national identifier is provided with its type, the *_NOTAP_CD cases omit the identifier type and set IS_ENTTY_CD_NTNL_NA to true, and CY_OTHER_CD and GEN_OTHER_CD go through TYP_ENTTY_CD_OTHR and ENTTY_CD_OTHR. A reporting team that reads v1.0.15 as a methodology release will look for business-rule changes that are not in it.

A build sequence for the January 2027 reference date

1. Store the v1.0.15 schema set alongside v1.0.14 and select by reference date: 202701 onwards on v1.0.15, 202607 to 202612 on v1.0.14, and earlier periods on the versions in the BCL’s list, with v1.0.7 for anything before April 2023.
2. Replace every hard-coded v1_0_14 namespace and schemaLocation in the XML generator with a value driven by the reference date, and keep all schema files for one version in one directory.
3. Build the NUTS crosswalk in two parts: name-based renumbering for the 11 Belgian, 28 Bulgarian and 3 Thuringian codes, and an address or postal code lookup for DE719, ITG2D, ITG2E, ITG2F, ITG2H and PL613. Test every name match against the counterparty’s municipality, because a surviving name can hide a boundary move such as Zwijndrecht’s.
4. Scan the counterparty master and the real estate protection records for the 48 withdrawn codes, and size the population before deciding how much of the remapping can be automated.
5. Version the stored NUTS code by validity date so that corrections to 2026 reference dates keep the old value.
6. Validate a dry-run ANTREF and ANTT2M file for 31 January 2027 against the v1.0.15 XSDs before the month closes, and confirm that the namespace in the header matches the version.
7. If BCL feedback is parsed automatically, test the parser against BCL_ANCRDT_REF_FDBCK_ACMD_v1_1_0.xsd and its four supporting schemas.

Frequently Asked Questions

A manual emergency correction for the 31 December 2026 reference date goes out in February 2027. Does the emergency flag change the version rule?

No exception appears in the sources. IS_EMRGNCY_CRRCTN is an optional attribute of the technical header dataset, set to true for a manual emergency correction and assumed false when absent, and the submission type stays FULL_REPLACEMENT. Neither the instructions nor the list of schemas by reference date carves emergency corrections out of the reference-date rule, so an emergency correction for the December 2026 reference date still goes in under v1.0.14 as a full replacement.

The quarterly accounting file has no NUTS attribute. Does BCL_ANCRDT_T2Q need v1.0.15 at all?

Yes, from the 31 March 2027 reference date. The ANTT2Q file still declares a versioned namespace, and TR0210 checks the schema version against the reference date for every survey. The fourth-quarter 2026 accounting file, due in January 2027, stays on v1.0.14.

Do Polish counterparties need the new PL61A and PL61B codes?

Possibly not at all. The ECB Manual expects the county or administrative division only for counterparties resident in a reporting Member State, with “not required” reported for others, and uses the NUTS 3 code for real estate collateral located in a reporting Member State, falling back to the ISO country code elsewhere. The BCL’s list of reporting Member States (October 2025) includes Bulgaria from 1 January 2026 and does not include Poland. Whether a file carries PL613 today depends on how the bank’s system populates the attribute, which is worth checking before building the Polish part of the crosswalk.

A property held as collateral sits in the former Sud Sardegna province (ITG2H). Which code applies from January 2027?

It depends on the municipality. ITG2H disappears, seven Sardinian codes from ITG2I to ITG2O replace the four withdrawn ones, and neither the BCL subdomain workbook nor its difference file provides a municipality-level crosswalk. The property’s address or postal code has to drive the new value, and the same applies to DE719 and PL613.

When should LUZZZ be used for a Luxembourg counterparty?

The technical specifications do not say. LUZZZ arrives as an Extra-Regio code matching the ZZZ codes the list already held for 26 other countries, and LU000 remains the only regional NUTS 3 code for Luxembourg, so an ordinary Luxembourg-resident counterparty is unaffected. A case that seems to call for LUZZZ is one to raise with the BCL.

Can the production file for 31 January 2027 be prepared and sent before that date to get ahead of the switch?

The BCL validation rules point the other way. TR0140 treats a preparation date earlier than the reference date as incoherent and rejects the file, and TR0220 rejects a file whose preparation date does not correspond to the real submission date. Early work belongs in local validation against the v1.0.15 XSDs, which needs no submission.

Related Articles

• AnaCredit Reporting in Germany: Bundesbank Credit Data and Deadlines: how German credit institutions report AnaCredit loan-level data to the Bundesbank and when.
• FINREP Reporting Explained: the supervisory financial reporting framework that AnaCredit accounting data is compared against.
• EBA Updates Supervisory Reporting Validation Rules: What XBRL and DPM Reporting Teams Must Check: the June 2026 changes to EBA validation checks for supervisory reporting pipelines.
• ESPREP-RES Reporting in Luxembourg: CSSF Real Estate Lending Data: who files the CSSF residential and commercial real estate lending returns and when they fall due.

Key Takeaways

• Reference date 31 January 2027 is the first on v1.0.15; July to December 2026 stays on v1.0.14 and January to June 2026 on v1.0.13, corrections included.
• Budget the work as a namespace change plus a code-list remap: no cube, attribute or facet moved.
• Use address data for DE719, ITG2D, ITG2E, ITG2F, ITG2H and PL613, the split or redrawn regions the BCL file leaves without a crosswalk. Name matches for the recoded Belgian, Bulgarian and Thuringian regions need a municipality check.
• Keep both NUTS code versions with validity dates in the counterparty master and the collateral data.
• Generate the header from the reference date; the v1.0.15 sample files still declare the v1_0_14 namespace.
• Diff against the v1.0.14 package, since the v1.0.15 redline is marked against an older baseline.
• If feedback files are parsed, BCL_ANCRDT_REF_FDBCK_ACMD_v1_1_0.xsd is now the documented reference.

Sources and References

• Banque centrale du Luxembourg, AnaCredit reporting instructions page (schema versions and mandatory reference dates): BCL AnaCredit instructions
• BCL, Technical specifications AnaCredit, Version 1.0.15 (October 2026): PDF
• BCL, Technical specifications AnaCredit, Version 1.0.15, revision marks: PDF
• BCL, AnaCredit SDMX schemas v1.0.15 (schemas, feedback schemas, difference files, examples): zip
• BCL, AnaCredit SDMX schemas v1.0.14 (including the v1.0.14 technical specifications): zip
• BCL, AnaCredit subdomains v1.0.15: xlsx
• BCL, AnaCredit cube structure v1.0.15: xlsx
• BCL, AnaCredit facets v1.0.15: xlsx
• BCL, List of SDMX schemas by reference date (October 2026): xlsx
• BCL, Report AnaCredit, Reporting instructions, Version 4.6 (October 2025): PDF
• BCL, AnaCredit validation rules (TR0010, TR0130, TR0140, TR0210, TR0220, NA0090): xlsx
• BCL, List of reporting Member States for the AnaCredit report (October 2025): PDF
• Regulation (EU) 2016/867 of the European Central Bank of 18 May 2016 on the collection of granular credit and credit risk data (ECB/2016/13): EUR-Lex
• ECB, AnaCredit Reporting Manual, Part II, Datasets and data attributes (May 2019), sections 2.4, 9.4.7 and 12.4.11: PDF
• Commission Delegated Regulation (EU) 2026/195 amending the annexes to Regulation (EC) No 1059/2003 (NUTS 2027): EUR-Lex
• Commission Delegated Regulation (EU) 2023/674 amending the annexes to Regulation (EC) No 1059/2003 (NUTS 2024): EUR-Lex
• Regulation (EC) No 1059/2003 of the European Parliament and of the Council on the establishment of a common classification of territorial units for statistics (NUTS): EUR-Lex
• Eurostat, NUTS overview (NUTS 2024 and NUTS 2027 region counts and validity dates): Eurostat NUTS
• Eurostat, NUTS history (versions, regulations and transmission periods): Eurostat NUTS history
• Flemish decree of 19 April 2024 on the voluntary merger of the municipalities of Beveren, Kruibeke and Zwijndrecht and the change of the boundary between the provinces of Antwerp and East Flanders (Codex Vlaanderen, consolidated text): Codex Vlaanderen

Before the 31 January 2027 ANTREF file leaves the bank

Every v1.0.15 change lands in the files for one reference date. The 15th working day after 31 January 2027 is the first monthly deadline on which the ANTREF, ANTT1M and ANTT2M files must carry the v1_0_15 namespace, and ANTT2Q files for reference dates from January 2027 onwards follow. Wherever ANTREF or ANTT2M reports a NUTS 3 value, it has to be one of the NUTS 2027 codes in the v1.0.15 enumeration, while a correction to a July to December 2026 period in the same weeks still goes out on v1.0.14, and one to the first half of 2026 on v1.0.13. The artefact to produce before the end of January is a dry-run ANTREF file for 31 January 2027 that validates against the v1.0.15 XSDs with every withdrawn code remapped.

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.