CRBA — Luxembourg’s central register of bank accounts
Almost every account register in the EU works by submission: the firm builds a file and sends it somewhere. Luxembourg’s does not. Under the Law of 25 March 2020, the professional keeps the file on its own infrastructure, tells the CSSF it is ready, and the CSSF comes and takes it — once, through a single-use link, every working day. That inversion changes what has to be engineered: not a reporting pipeline but an authenticated service the supervisor calls. This piece sets out who is caught, the daily rhythm, the data model traps in Annex 2 of Circular CSSF 20/747, and what changes when BARIS arrives.
1. What the CRBA is, and who has to feed it
The Law of 25 March 2020 established a central electronic data retrieval system covering payment accounts and bank accounts identified by an IBAN, and safe-deposit boxes held in Luxembourg. It was published in Mémorial A n° 193 of 26 March 2020 and entered into force the same day; CSSF Circular 20/742 announced it alongside the parallel law of the same date that amended the amended Law of 12 November 2004. The register is generally referred to as the CRBA.
The obligation is not, in the first instance, a submission obligation. Each professional in scope must put in place a data file allowing identification of any natural or legal person holding or controlling, within that professional, a payment account, an IBAN-identified bank account or a safe-deposit box. The CSSF’s December 2023 reminder of professional obligations identifies the population as credit institutions, payment institutions, electronic money institutions and specialised PFS, and states that the financial intelligence unit and national authorities have direct, immediate and unfiltered access to the data.
For a payments firm the scoping question is the one that catches people out in France and Spain too: the trigger is the account, not the customer. An IBAN-identified payment account kept in Luxembourg is in the file whether its holder is Luxembourgish or not.
2. The architecture: you host, the CSSF pulls
Annex 1 to Circular CSSF 20/747 sets out the exchange. The professional builds, in its own systems, a complete data file in the structure defined by Annex 2. It then notifies the CSSF that the file is available; the CSSF connects and downloads it; the CSSF returns a feedback file stating whether the file was accepted or rejected, with the errors where it was rejected. The professional is responsible for securing the file, and may delete it once collected.
Making that work means standing up an interface, not a batch job. Both directions run over HTTPS with mutual TLS — 1.2 as a minimum — on certificates signed by the CSSF’s certification authority, with an IP allow-list maintained on each side. Files are compressed and encrypted with PGP: the professional encrypts to a CSSF public key and signs with its own private key, and the CSSF does the reverse on the feedback. Private keys must be at least 4096-bit RSA or 256-bit elliptic curve, the professional’s keys valid for at least two years, files travelling as binary PGP and keys as ASCII armor. The CSSF keeps public keys for twenty years so signatures stay verifiable after renewal.
3. The daily rhythm, and the window
The file is a full snapshot, not a delta. Each working day the professional must make available a complete, valid file reflecting the state of its data as at that day.
| Rule | What Annex 1 requires |
|---|---|
| Days | Monday to Friday only, excluding Luxembourg public and bank holidays |
| Notification window | Between 18:00 on day J and 06:00 on day J+1, Luxembourg time |
| Nothing changed that day | The CSSF still expects a file — carrying the same data as the previous day |
| A change or addition occurs | Must be made available within 24 hours at the latest |
| Availability | Service must be sufficient to transmit at least once every 24 hours; the platform may be down outside the collection window |
| CSSF does not collect | Re-notify every 10 minutes until the file has been retrieved |
The retry rule is the one to design for: a silent CSSF is not an exception to escalate the next morning, it is a loop the sending service must run. And the “same data as yesterday” expectation means there is no nil file here — a professional with no movements sends a full file that happens to be identical, and one that sends nothing has missed a day.
4. The data model, and where it bites
Annex 2 defines a JSON structure — schema version 1.0.0, described with OpenAPI 3.0.0, encoded UTF-8. The CSSF makes available the same validator it uses on receipt, and recommends running it before exchange rather than finding encoding errors through rejection. The parts that generate real work:
| Element | Rule | Why it catches people |
|---|---|---|
iban / accountNumber | At least one must be present; historical values are kept in oldIbans and oldAccountNumbers | Identifier history is declarable, so a renumbering exercise is a register event |
uuid | RFC 4122 version 4, unique within the file; it need not be stable from one file to the next | It is the only handle returned on error — IBANs and account numbers are not echoed back |
endDate | Mandatory; where the account is not closed, the value 01-01-2500 is used | A null or omitted date fails validation; the sentinel is prescribed, not invented |
roles | Values holder, proxy, ubo; at least one holder and at least one beneficial owner are mandatory | A file with a holder and no beneficial owner is structurally incomplete, whatever the product |
naturalPerson / legalPerson | Exactly one of the two per party block — never both | Sole traders and similar hybrids have to be resolved to one branch before mapping |
| Names | Multiple surnames or forenames are separated by commas within the single field | Systems that concatenate with spaces produce a valid file with wrong data |
| Countries and nationality | ISO 3166-1 alpha-3; XXA for stateless persons | Most internal models store alpha-2, so a mapping table is required |
identifiers | Passport, ID, driving licence, national identification number, tax identification number, other — comment mandatory for “nin” and “other” | The NIN follows Article 16.1 of CSSF Regulation 12-02, not an internal definition |
inactive | Optional flag, start date and comment, per the Law of 30 March 2022 | Dormancy is a separate regime most account models do not carry as a field |
Where the holder is a legal person the block widens: legal name, legal form, creation date, identifiers, headquarters and places of business, that legal person’s beneficial owner with role ubo, and at least one of an authorised representative — whose role must be proxy — or a director. Safe-deposit boxes mirror the account structure with their own number, history and party list.
Worked example. An e-money institution onboards a Luxembourg holding company. Facts to rule: the party is a legalPerson, so legalName, legalForm and creationdate are mandatory; at least one beneficial owner must be carried; and at least one authorised representative or director must be present. What the analyst does: confirm the beneficial owner determined for customer due diligence has a date of birth, country of birth and nationality recorded to the register’s standard — a senior-managing-official determination under the 2004 Law still has to resolve to a named natural person here. Outcome: the block validates. The failure mode is a beneficial owner captured as a free-text onboarding note, which cannot be serialised at all.
5. Acceptance, rejection, and what a rejection obliges
The CSSF’s feedback is itself JSON, described by an OpenAPI 3.0.0 schema. It carries a status of ACPT or RJCT, a file identifier and, on rejection, an array of errors each with an identifier of the form CSSF-nnn and a message — the published example being a malformed IBAN. Where the status is RJCT, the professional must supply a new file, and keep doing so until it obtains ACPT, correcting the errors while respecting the deadlines set by the Law.
Worked example. A file is rejected overnight with three errors, each naming a different UUID. Facts to rule: the feedback carries no IBANs, so the UUIDs are the only route back to the affected records — and Annex 2 does not require them to be stable between files. What the engineer does: persist the file-to-UUID mapping for at least the correction cycle, resolve the three accounts, correct them at source rather than in the output, and re-notify. Outcome: ACPT in the same window. The failure mode is generating UUIDs at serialisation time and discarding them, which makes a rejection uninvestigable.
A rejection is not a deferral. The duty is to have the data available; a file under correction does not stop the clock, which is why the 24-hour change rule and the correction loop need one operational owner.
6. Storage, proof and the five-year rule
The professional must store, each day, the last file accepted by the CSSF for that day and the acceptance feedback that proves it. The CSSF keeps its own copy of the feedback and generates hashes of the stored files to verify integrity. The mandatory retention period is five years, following Article 3, paragraph 6 of the amended Law of 12 November 2004.
Two points follow. The proof of acceptance is part of the record, not a transient log line — an archive holding files without their feedback does not evidence compliance. And the CSSF provides a test environment, to be used with anonymised data before go-live; the technical documentation and enrolment details are delivered through the CSSF’s managed file transfer system on request.
7. What BARIS changes
Article 16 of Directive (EU) 2024/1640 re-states the requirement for centralised automated mechanisms and extends the perimeter. In addition to payment accounts, IBAN-identified bank accounts and safe-deposit boxes, Member States must cover virtual IBANs, securities accounts and crypto-asset accounts. For a virtual IBAN, Article 16(3)(d) requires the identifier itself together with the unique identifier of the account to which payments addressed to it are automatically redirected, and treats the holder of that underlying account as the customer account holder.
Article 16(6) requires the national mechanisms to be interconnected through the bank account registers interconnection system, BARIS, which the Commission is to develop, operate and deliver with Member States by 10 July 2029; transposition generally falls due on 10 July 2027. Article 16(8) requires holder information to remain available nationally and through BARIS for five years after closure, with an optional further five where a Member State establishes necessity.
For a Luxembourg professional the read is straightforward: the CRBA’s daily-file mechanics are not in question, its perimeter is. Firms holding crypto-asset accounts or issuing virtual IBANs should assume those objects enter the file, and stop treating them as outside the identity model that already feeds it.
8. Questions that come up
Do we send a file on a day with no account activity?
Yes. Annex 1 is explicit that where nothing has changed the CSSF expects to receive the same data as the previous day. The file is a full daily snapshot, so an unchanged book still produces one.
What goes in endDate for an open account?
01-01-2500. The field is mandatory and the sentinel value is prescribed by Annex 2; leaving it empty is a validation failure.
Must the account UUID stay the same between files?
No — Annex 2 says it need not. But because the feedback file identifies errors only by UUID, the mapping must be retained long enough to investigate a rejection.
Who can query the register?
The CSSF operates the system, and the CSSF’s 2023 reminder states that the financial intelligence unit and national authorities have direct, immediate and unfiltered access. From the professional’s side the visible interface is the daily collection, not the queries.
Is this the same thing as the beneficial ownership register?
No. The RBE created by the Law of 13 January 2019 records beneficial owners of registered entities. The CRBA records who holds or controls accounts and safe-deposit boxes. Different laws, different populations, different filing mechanics.
9. What to do, today
- Confirm the scope line: every IBAN-identified payment account kept in Luxembourg belongs in the file, regardless of customer residence.
- Run the CSSF validator in your own pipeline before notification, so rejections are the exception rather than the feedback loop.
- Persist the UUID-to-account mapping per file. It is the only key the feedback gives you.
- Implement the 10-minute re-notification loop and the single-use token invalidation as code, not as a runbook step.
- Archive the accepted file and its acceptance feedback together for five years, per Article 3(6) of the amended Law of 12 November 2004.
- Map alpha-2 country codes to ISO 3166-1 alpha-3 once, centrally, including XXA for stateless persons.
- Add virtual IBANs and any crypto-asset accounts to the register data model now, ahead of the 10 July 2027 transposition of Directive (EU) 2024/1640.
Related: Account registers compared across the EU · How to issue Luxembourg IBANs · CSSF Regulation 12-02 · Filing an STR with the CRF in goAML
