How to issue Luxembourg IBANs

You cannot ask for a Luxembourg bank code until you already hold two other identifiers — and that dependency chain, not the licence, is what usually decides when your first LU IBAN can exist. A Luxembourg IBAN is 20 characters: LU, two check digits, a three-digit bank code and a thirteen-character account identifier. This covers the format, the allocation sequence that actually gates a launch, what SEPA reachability does and does not guarantee you, and the obligations that switch on once accounts go live.

1. The Luxembourg IBAN format

Luxembourg follows the ISO 13616 structure with a fixed length of 20 alphanumeric characters:

• Positions 1–2: the country code LU
• Positions 3–4: two check digits computed under ISO 7064 (mod-97-10)
• Positions 5–7: the three-digit bank code identifying the institution
• Positions 8–20: a thirteen-character account identifier, assigned by the institution

Positions 5 to 20 together are the BBAN. Print form groups the string in blocks of four; electronic form is unbroken and carries no spaces. The constraint worth designing around is the account field: thirteen characters is the whole of your internal numbering space, and it has to absorb not just accounts but whatever structure you encode into them — product lines, entities, client-money sub-ledgers, safeguarding segregation. Firms that encode a scheme into the first characters and then change product taxonomy discover the cost late, because IBANs already issued to customers are not practically re-issuable.

2. The allocation chain — and why it is the real critical path

The three-digit bank code is not self-assigned and not issued by the regulator. Luxembourg’s national IBAN/BIC register is maintained by the country’s banking association in agreement with the Luxembourg supervisory authorities, and a supervised entity applies to that register for its code. The requirement reaches all Luxembourg supervised entities that open accounts and offer payment services — expressly including branches of foreign institutions operating in Luxembourg, which is the point most passporting firms get wrong.

What makes this a sequencing problem is what the application has to contain. The register asks for the identification number assigned by the CSSF, the BIC — issued by the ISO-designated registration authority for BICs, on request of the supervised entity — and the operational date from which the IBAN and BIC codes are to be live. So two identifiers have to exist before the third can be requested, and a date has to be committed before the infrastructure is proven.

Facts: an EMI with CSSF authorisation in sight puts “obtain LU IBAN range” on the technical backlog for the sprint before launch, alongside the payments integration.

What the rule says: the bank-code application requires the CSSF identification number and the BIC already in hand, plus a declared operational date. None of the three is instantaneous, and the first is a by-product of a licensing process the firm does not control.

What the practitioner does: starts the BIC request as soon as the authorisation outcome is reasonably certain, treats the bank-code application as a dependency on both, and picks an operational date with slack — because the date is a commitment made to a register, not a target in a plan.

Outcome: the IBAN chain runs in parallel with licensing rather than after it, and the launch date stops depending on a three-step queue nobody owns.

3. Reachability, and what “no IBAN discrimination” actually promises

The rule usually quoted as IBAN discrimination is Article 9 of Regulation (EU) 260/2012, and it is narrower than its reputation. Article 9(1) provides that a payer making a credit transfer to a payee holding a payment account located in the Union shall not specify the member state in which that account is to be located. Article 9(2) does the same for a payee accepting a credit transfer or collecting by direct debit. Both are conditioned on one thing: provided that the payment account is reachable in accordance with Article 3.

Two consequences follow, and they matter to anyone launching an LU range into a market where customers are used to local IBANs. First, the obligation binds payers and payees — a corporate that refuses to pay salary to an LU IBAN, or a merchant that will not collect from one — not the payment service provider. Second, the protection is conditional on reachability, and Article 3 defines that in scheme terms: a payee’s PSP reachable for a national credit transfer under a payment scheme must be reachable, under the rules of a Union-wide scheme, for credit transfers initiated through a PSP in any member state, with the mirror rule in Article 3(2) for direct debits and a consumer limitation in Article 3(3).

Facts: an issuer launches LU IBANs and its customers report that a large employer in another member state will not register the account for payroll, citing its own bank’s process.

What the rule says: assuming the account is reachable under Article 3, Article 9(1) is directed at exactly that behaviour — the payer may not specify the member state in which the payee’s account is to be located.

What the practitioner does: confirms and documents scheme reachability first, so the Article 3 condition is demonstrably met, then raises the refusal with the competent authority designated under Article 10 rather than treating it as a customer-service issue.

4. What issuing IBANs commits you to

Issuing LU IBANs means operating as a SEPA-reachable payment service provider, with the scheme stack that implies: SEPA Credit Transfer as the baseline euro scheme; SEPA Instant Credit Transfer, whose send and receive obligations and accompanying verification of payee duty are phased in by the Instant Payments Regulation; and SEPA Direct Debit, Core and B2B, where the product collects.

Then the obligations that attach to live accounts rather than to the licence. Ongoing CSSF prudential and statistical returns for the institution; AML transaction monitoring on the accounts, with suspicious-activity reporting to the Cellule de Renseignement Financier through goAML; CESOP cross-border payment reporting once the quarterly per-payee threshold is crossed; and the fraud-reporting and statistical duties that come with instant payments. The pattern worth internalising is that the IBAN is the trigger: several of these obligations are keyed to holding payment accounts for clients, not to the scale of the business.

5. LU IBANs against the other core formats

The comparison matters mainly for two reasons — validation logic and the size of your account field.

If you operate more than one range, the practical trap is validation code written against the longest format and then reused: a 20-character LU IBAN, an 18-character NL one and a 27-character FR one all validate under ISO 7064, but national sub-structures do not generalise, and a parser that assumes a numeric bank code will silently reject valid Dutch accounts.

6. FAQ

7. What to do, today

• Sequence the three identifiers, and start the middle one early. CSSF identification number, then BIC, then bank code. The BIC request is the step you can begin before the register application and the one most often left until it blocks.
• Choose the operational date with slack. It goes into the register application, so it is a commitment rather than an internal target.
• Fix the numbering scheme before the first account exists. Thirteen characters is the entire space, and issued IBANs are not practically re-issuable.
• Evidence reachability in both directions before you rely on payment accessibility. Article 9 is conditioned on Article 3, and the condition is yours to satisfy.
• Map the obligations that trigger on live accounts — CSSF returns, goAML reporting, CESOP once the threshold is crossed, instant-payments fraud data — because they attach to holding client payment accounts, not to scale.

Related: EMI licence in Luxembourg · PI licence in Luxembourg · How to issue German IBANs · Verification of payee under the IPR · CRBA — Luxembourg’s central register of bank accounts