Blog

CRS LUXEMBOURG : ECHA – n° 4

Last Updated on July 5, 2025 by Arnaud Collignon

1. ECHA – n° 4

The ECHA – n° 4 serves as a detailed guide for Luxembourgish RFIs on fulfilling their CRS reporting obligations. It covers various aspects of XML file generation, transmission, correction mechanisms, and specific scenarios for declaring financial accounts. The goal is to ensure compliance with administrative cooperation in the tax field, as mandated by EU Directives (DAC and DAC2).

If you are looking for a XML production solution, feel free to contact us: https://fund-xp.lu/contact-us/

2. Technical File Specifications and Structure:

  • File Format and Size: The maximum file size allowed by the ACD is 60 MB. (Section 7.5, page 23; Section 8, page 67)
  • Special Characters: Section 7.4 (page 23) and Table 10 (page 26) detail the allowed characters for identifiers, including uppercase letters (A-Z), numbers (0-9), space, parentheses, hyphen, period, colon, underscore, and slash.
  • XSD Schema: The declaration adheres to specific XML Schema Definition (XSD) structures.
  • Luxembourgish Envelope (<AEOI_LUX>): This is a specific Luxembourgish data structure that “allows the ACD to uniquely identify the message, the filer of the declaration and the Luxembourgish reporting financial institution declared. It ‘envelops’ the official data structure defined by the OECD for international exchanges.” (Section 7.7, page 29). Each new message must use a new, unique <AEOI_RefId>. (Section 7.7.1.1, page 29).
  • Declaration Body (<CRS_OECD>): This is the core of the declaration, containing <MessageSpec> (contextual data) and <CrsBody> (details of records to be transmitted to a Reportable Jurisdiction (JSD)). (Section 7.7.2, page 32).
  • TransmittingCountry and ReceivingCountry: For messages, both elements within <MessageSpec> must always be present and populated with the ISO 3166-alpha 2 country code for Luxembourg (“LU”). Failure to do so will result in the file being rejected. (Section 7.7.2.1, page 34).
  • CrsBody Structure: While the <CrsBody> element is repeatable, the ACD only allows a single occurrence of the <ReportingGroup> element within the same <CrsBody>. Multiple occurrences will lead to a rejection. (Section 7.7.2.2, page 36). Importantly, declarations for multiple JSDs can be made within the same file by having multiple <CrsBody> occurrences. (Section 7.7.2.2, page 36).
CRS Reporting Solution

3. Identifiers and Naming Conventions:

  • Identifiant Technique Luxembourgeois (Luxembourgish Technical Identifier): This identifier is composed of the NIF (Taxpayer Identification Number) + 9 characters. (Page 13). For a reporting financial institution, it’s 20 alphanumeric characters. (Page 22).
  • File Naming Convention: The file name for data messages follows a strict format including: <SEP> (underscore), DateHeure (YYYYMMDDhhmmss), MessageTypeIndic, AnnéeFiscale (YYYY >= 2016), Canal (B for Bourse/FUNDSQUARE-e-File, C for Cetrel/SIX Payment Services-SOFiE), MatriculeDuDéposant (depositor’s Luxembourgish NIF), MatriculeDuRFI (RFI’s Luxembourgish Technical Identifier), Environnement (P for Production, T for Pre-validation/Test). (Section 7.2.2, page 22-23). An incorrect environment value will lead to rejection (error code “98901”).
  • Structure of Identifiers within the Message (Section 7.6, page 25):First Block: Country code (e.g., LU) + Fiscal Year (e.g., 2016) + JSD country code.
  • Second Block: Block type (HL for <AEOI_RefId>, HC for <MessageRefId>, RF for <ReportingFI>, AR for <AccountReport>) + underscore + 20-character Luxembourgish technical identifier.
  • Third Block: Unique identifier (up to 67 alphanumeric characters) determined by the RFI.

4. Message Types and Document Types (DocTypeIndic):

  • New Data Message (CRS701): Declares data not yet known by the ACD. MessageTypeIndic is “CRS701”, and DocTypeIndic for “record” type data is “OECD1” (except for <ReportingFI> which can be “OECD0” under certain conditions). (Section 7.1, page 18).
  • Correction Message (CRS702): Used to correct or cancel previously validated data. (Section 9, page 70).
  • Zero Reporting Message (CRS703): Indicates no data to declare for a given fiscal year. (Section 7.7.2.1, page 35).
  • DocTypeIndic Values:OECD0: Data return (re-sending data, e.g., in split files for a previously declared RFI).
  • OECD1: New data.
  • OECD2: Corrected data.
  • OECD3: Data deletion.
  • Test data values (OECD10-OECD13) are explicitly not allowed and will result in rejection (error code “98030”). (Section 7.7.2.2.1.1, page 42; Section 7.7.2.2.2.3.1, page 48).

5. Reporting Financial Institution (RFI) Details (<ReportingFI>):

  • Required Elements: <DocSpec>, <ResCountryCode>, <IN> (NIF), and <Name>. (Section 7.7.2.2.1, page 38).
  • Residency and NIF: The ResCountryCode of the RFI must be “LU” (equal to the TransmittingCountry). (Section 7.7.2.2.1.2, page 43). The RFI’s Luxembourgish NIF (<IN>) must be present, non-null, and match the IdentificationNumber in the Luxembourgish envelope (<AEOI_LUX>). (Section 7.7.2.2.1.3, page 43). The RFI’s name (<Name>) must match the NameReportingFI in the Luxembourgish envelope. (Section 7.7.2.2.1.4, page 44).

6. Account Reporting Details (<AccountReport>):

  • Account Number (<AccountNumber>): If no account number exists, the value should be “NANUM”. Specific validations apply for IBAN (OECD601) and ISIN (OECD603) formats. (Section 7.7.2.2.2.3.2, page 50).
  • Account Holder (<AccountHolder>): Can be an <Individual> or an <Organisation>.
  • Individual Account Holder: Requires ResCountryCode, TIN (NIF), Name, Address, Nationality, and BirthInfo. (Section 7.7.2.2.2.3.3.1, page 54). At least one TIN per declared ResCountryCode must be provided. (Section 7.7.2.2.2.3.3.1.2, page 55).
  • Organisation Account Holder: Requires ResCountryCode, IN (NIF), Name, and Address. (Section 7.7.2.2.2.3.3.2, page 60).
  • Passive Non-Financial Entities (ENF passives): When the account holder is a passive NFE, specific rules apply for declaring controlling persons. (Section 10.1, page 85; Section 7.7.2.2.2.3.3, page 53, CRS101).
  • Joint Accounts: Reported by multiple <AccountReport> elements, one per co-titular, each declaring a different <AccountHolder>. (Section 10.2, page 87).
  • Multiple Tax Jurisdictions: For accounts held or controlled by a person residing in multiple JSDs, all tax residency countries must always be declared in the <ResCountryCode> field of the Account Holder or Controlling Person. (Section 10.3, page 89-90).
  • Account Balance (<AccountBalance>): Must be a numeric value with two decimals, greater than or equal to zero. If the account is closed, the balance must be strictly zero. (Section 7.7.2.2.2.3.5, page 65).
  • Payments (<Payment>): Accounts can have zero, one, or multiple income types (Dividends, Interest, Gross Proceeds/Redemptions, Other – CRS). (Section 7.7.2.2.2.3.6, page 66).
  • PoolReport: This element must not be declared, and its presence will lead to file rejection. (Section 7.7.2.2.2.4, page 66).

7. Tax Identification Number (NIF / TIN) Specifics:

  • Missing TIN: If an RFI cannot obtain a TIN, they can use the code “#NTA001#”, where “NTA” stands for “No TIN Available” and “001” indicates the reason (“No TIN has been obtained despite reasonable efforts engaged by the RFI”). The @issuedBy attribute must still specify the country for which the TIN is unavailable. (Section 11, page 94).
  • Transmission to JSDs: The ACD replaces this special code with a default TIN for each JSD during export. It’s crucial to respect the “#” format, otherwise, the code might be transmitted as is, leading to clarifications from JSDs. (Section 11, page 94).

8. File Splitting (“Splitting” de fichiers):

  • Purpose: RFIs must split files that exceed the 60 MB maximum size. (Section 8, page 67).
  • Splitting Points: Splitting can only occur between <AccountReport> or <CrsBody> elements. (Section 8, page 67).
  • DocTypeIndic for Split Files:If splitting between <AccountReport> elements within a new data message: The DocTypeIndic of the ReportingFI in the second file (and subsequent files) should be “OECD0” if the RFI was already declared, or “OECD1” if the split occurs between two <CrsBody> and the RFI was not previously declared in that context.
  • For correction messages, DocTypeIndic for subsequent files after the first split file should be “OECD0”. (Section 8, page 67).
  • Recommendation: For a large number of AccountReport entries (+20,000) for a single JSD, the ACD recommends creating separate messages for that JSD to avoid rejection of correctly reported data for other JSDs if an error occurs. (Section 8, page 69).

9. Correction Mechanism:

  • When to Use: The correction mechanism (using MessageTypeIndic = “CRS702”, DocTypeIndic = “OECD2” for correction, or OECD3 for deletion) must be used to modify or cancel data that has been successfully integrated into the ACD’s database (i.e., acknowledged with a “VAL” or “WAR” status message). (Section 9.1, page 70).
  • When NOT to Use: It should not be used for files that were technically rejected (“NAK” or “ERR” (first case) status messages) as the data was not integrated. In such cases, a new message of the same type as the rejected one should be sent. (Section 9.1, page 70).
  • Consequences of Incorrect Correction: Incorrect use (e.g., cancelling and re-declaring valid records) can lead to JSD investigations and RFI/client questioning. The ACD will monitor and audit RFIs that do not use the standard correction mechanism. (Page 82).

10. Status Messages (Flux and Types):

The ACD returns various status messages to the depositor following file submission. (Section 12.1, page 95).

  • Technical Status Messages:NAK (Negative Acknowledgement): Issued immediately upon reception. Indicates technical errors (e.g., naming convention, file size, encoding, wrong environment) that make the file unusable by the ACD. The file is considered unexploitable. The depositor must correct the message and resubmit it. A new AEOI_RefId is required, but MessageRefId and DocRefId can remain the same. (Section 12.1.1, page 96).
  • ACK (Acknowledgement): Issued immediately upon reception. Indicates good technical reception, and the file is “exploitable.” The ACD then proceeds with semantic and syntactic validation. The depositor should expect a second status message (VAL, WAR, or ERR). (Section 12.1.2, page 97).
  • Validation Status Messages (after technical validation):VAL (Validated): All controls (OECD and Luxembourg-specific) passed. Data is integrated and transmitted to JSDs. Subsequent corrections must use the correction mechanism. (Section 12.1.3, page 98).
  • WAR (Warning): File is accepted globally, even with “warning” level errors. The ACD integrates the data and does not require correction, but RFIs should consider these warnings for future reports. (Section 12.1.4, page 99).
  • ERR (Error): File is rejected globally due to at least one “error” level control failure. The depositor must correct the data and resubmit a valid declaration. (Section 12.1.5, page 100). This can occur from the ACD’s internal validation or after a JSD returns errors to the ACD, which then forwards them to the depositor. (Section 12.1, page 95).
  • Status Message Naming Convention: Follows a specific structure including CRS_DateHeure_MessageTypeIndic_AnnéeFiscale_Canal_MatriculeDuDéposant_MatriculeDuRFI_Environnement_IdTransmission_STATUS_JSD_StatutValidation.xml. (Section 12.2.2, page 103).
  • ForeignSenderCountry in Status Messages: Indicates the country that reported the error. It’s “LU” for technical (ACK/NAK) and initial validation (VAL/WAR) messages. For “ERR” messages, it can be “LU” (ACD detected the error) or the JSD’s country code (JSD detected the error after transmission from ACD). (Section 12.3.1.1.3, page 105).

11. Test Platform:

The ACD provides a TEST (pre-validation) platform for XML files throughout the year. (Section 13, page 114).

12. Key Concepts and Acronyms:

  • ACD: Administration des contributions directes (Luxembourg Tax Authorities).
  • CRS: Common Reporting Standard.
  • DAC/DAC2: EU Directives on administrative cooperation in the field of taxation.
  • JSD: Juridiction soumise à déclaration (Reportable Jurisdiction).
  • NIF / TIN: Numéro d’identification fiscale / Taxpayer Identification Number.
  • ENF Passive: Passive Non-Financial Entity.
  • RFI: Reporting Financial Institution.
  • XSD: XML Schema Definition (defines the structure of the XML files).

This briefing provides a comprehensive overview of the technical and procedural requirements for CRS reporting in Luxembourg, emphasizing file structure, validation rules, and the crucial distinction between types of status messages and correction mechanisms.