BOP 1.2: Luxembourg external-sector reporting to the BCL

Luxembourg’s balance of payments is built, in large part, out of one monthly file of payment records. BOP 1.2 — «Cross-border payments executed on behalf of resident customers» — is the return through which the Banque centrale du Luxembourg collects, payment by payment, the cross-border flows that resident credit institutions execute for their clients. It is short on schedules and long on codes: a sign convention, a country, a currency, and an identifier that says exactly which kind of resident sat behind the payment. This piece sets out who reports, the ten-working-day deadline, the four breakdowns, the counterpart identifier types with their formats, and why a Luxembourg payment or e-money institution is almost never a BOP 1.2 reporting agent.

1. What BOP 1.2 is

The BCL and STATEC are jointly in charge of establishing the Luxembourg balance of payments, with the BCL responsible for the financial account, Luxembourg’s international investment position and the valuation of investment income. BOP 1.2 feeds that work: the instructions state its purpose as providing the BCL, on behalf of STATEC and the BCL, with the information necessary to establish the Luxembourg balance of payments.

The unit of observation is the payment, not the balance. BOP 1.2 carries all cross-border payments executed on behalf of resident counterparts meeting the definition below. It sits alongside BOP 1.1, «Breakdown of certain elements from the credit institutions profit and loss account», which decomposes P&L items rather than payments, and an annual survey on foreign direct investment.

A definitional document sits underneath the return — «Definitions and concepts for the balance-of-payments reporting of credit institutions and the financial services of Postes et Télécommunications» — and it, not the instruction sheet, is where borderline classification questions are settled.

2. The reporting population is narrow, and deliberately so

BOP 1.2 must be provided by all resident credit institutions regardless of their legal status, together with the financial services of the Entreprise des Postes et Télécommunications. That is the whole population. Legal status is explicitly irrelevant, so a Luxembourg branch of a foreign bank is in scope on the same footing as a locally incorporated one.

What follows is the most commonly missed point in the regime. A Luxembourg payment institution or electronic money institution is not a credit institution and is therefore not a BOP 1.2 reporting agent. Its cross-border payments still reach the statistics, through a different door: the BCL’s collection of data on payment instruments and operations, resting on BCL Regulation 2011/N°9 of 4 July 2011 and running in parallel with the euro-area payments-statistics framework. Two collections, two legal bases, two populations.

There is one further carve-out inside the population. Transmission of cross-border payments made on behalf of resident investment funds and other credit institutions is optional. The instructions spell out what the Luxembourg fund sector means here: undertakings for collective investment (UCI), specialised investment funds (SIF) and investment companies in risk capital (SICAR). A reporting agent servicing those clients has a genuine choice, and it should be made once, documented, and applied consistently rather than left to whichever extract the pipeline happens to run.

3. Frequency, deadline and reference date

BOP 1.2 is monthly, due no later than 10 working days after the end of the reference period. Reporting agents may opt to provide cross-border payments with non-residents on a daily basis instead — a real option, not a theoretical one, and the sensible choice for an institution whose payment volumes make a monthly batch unwieldy.

Ten working days is tighter than it reads. In a month with a mid-month public holiday the calendar date moves, and the BCL resolves this by publishing a calendar of remittance dates for statistical reports on its website. That calendar, not a working-day count in a spreadsheet, is the authority for any given month.

The reference date is the date of the payment. Not the value date, not the accounting date, not the date the instruction was received. That single line decides which month a payment falls into, and a pipeline keyed to booking date will put month-boundary payments in the wrong file.

4. What counts as a cross-border payment

The definition has four limbs, and all four must hold. A cross-border payment means any payment transaction that is processed electronically by a resident credit institution or the financial services of the Entreprise des Postes et Télécommunications, involving a resident payer or beneficiary, where the payment service provider is located in a foreign territory.

Read the third limb carefully. The test is the location of the payment service provider on the other side — not the nationality of the client, not the currency, and not whether the counterparty holds an account in Luxembourg. A payment between two Luxembourg residents routed through a foreign PSP meets the definition; a payment to a non-resident-owned account held at another Luxembourg institution does not.

The reported amount is the actual cross-border payment, reported without decimals, rounded down, with currency conversion taken at the day of the accounting for the transaction. Rounding down rather than to nearest is a small rule with a persistent effect: a pipeline that rounds half-up drifts against the BCL’s expectation on every file, in one direction.

5. The four breakdowns

Every cross-border payment executed for the account of a resident client is reported with four breakdowns: the sign convention, the country of the counterpart, the transaction currency, and the resident counterpart as a type plus an identification number.

The sign convention is stated from the resident client’s perspective. Incoming payments, where funds are credited to a resident client’s account, are reported as Credit (C); outgoing payments, debited to a resident client’s account, as Debit (D). Systems carrying an internal flag from the institution’s own ledger perspective invert this, and the inversion is silent — the file validates, the statistics are wrong.

The country is that of residence of the non-resident counterpart, or failing that of the non-resident payment service provider, given as a two-character ISO 3166 code or a code supplied by the BCL for specific counterparties. The currency is a three-character ISO 4217 code, and amounts may be reported in the institution’s accounting currency, in euro equivalents, or in the original currency of the payment — a choice that, like the fund carve-out, should be made once and held.

6. Counterpart identifier types

The fourth breakdown is where most of the engineering sits. The resident counterpart is identified by an identifier type and a number, each type with its own format rule.

Type 28 carries a checksum worth implementing at source: the first six distinct digits of the 8-digit code, less the last two digits, must be an integer multiple of 89. That runs before submission rather than after rejection, and it catches transposed digits that no amount of eyeballing will.

The residual rule matters for onboarding. Legal persons not listed in article 1 of the rules of 19 December 2002 on the business register, and those without an identification number, must be identified by VAT number; failing that the BCL can assign individual identification numbers. So there is a hierarchy, not a free choice, and asking the BCL for an assigned number is a normal step.

7. Three cases that decide the mapping

The rules above only become concrete when a real payment has to be classified. Three cases cover most of what a reporting team actually argues about.

The e-money institution that built a BOP 1.2 pipeline. A Luxembourg EMI with heavy SEPA volume finds BOP 1.2 and scopes a build. Facts to rule: the population is resident credit institutions plus the financial services of the Entreprise des Postes et Télécommunications, and an EMI is neither. What the reporting owner does: stop the build, and scope instead the BCL collection on payment instruments and operations under Regulation 2011/N°9, whose population does include payment and e-money institutions. Outcome: the right collection, with no wasted mapping.

The client-type field that was never populated. A resident bank maps identifier type 28 for every corporate client and type 25 with generic code 2222 for every individual, with no branch for legal persons still awaiting an 8-digit number. Facts to rule: type 25 carries generic code 3332 for exactly that case, and the type-29 business register number is available for any company. What the analyst does: add the 3332 branch and the type-29 fallback, and make the VAT-modulo-89 check a hard pre-submission gate. Outcome: newly onboarded corporates stop landing in the household bucket.

The month-end payment on the wrong side of the line. A payment is instructed on 31 March, booked on 1 April, and appears in the April file because the extract is keyed to accounting date. Facts to rule: the reference date is the date of the payment. What the team does: rekey the extract to payment date and reconcile both files against the payment-date population. Outcome: the month-on-month series stops showing a spike with no economic content.

8. What BOP 1.2 cannot see

BOP 1.2 is a bank-intermediated collection, and its blind spot is structural rather than accidental. Where a Luxembourg resident settles a cross-border transaction without passing through a resident credit institution — through an account held abroad, or by set-off inside a group — there is no resident reporting agent in the chain and the payment never enters the file. That is the gap direct collection from residents is designed to close, and it is why the annual foreign-direct-investment survey sits alongside the payment-based returns rather than duplicating them.

For a payments firm the consequence is that a clean BOP 1.2 file does not say the group’s external position has been reported. It says the payments a resident credit institution executed for resident clients have been. Anything settled outside that channel belongs to a different collection.

9. What to do, today

• Settle the population question before anything else: if the entity is not a resident credit institution, BOP 1.2 is the wrong return and Regulation 2011/N°9 is probably the right one.
• Key the extract to payment date, and prove it by reconciling two consecutive months against a payment-date population rather than the ledger.
• Implement the VAT modulo-89 check on identifier type 28 as a pre-submission gate.
• Add the type-25 generic 3332 branch and the type-29 business register fallback, so newly incorporated clients are not defaulted into the household code 2222.
• Round amounts down, not to nearest, and strip decimals at source rather than in the file writer.
• Verify the sign convention is taken from the resident client’s perspective — an inverted flag validates cleanly and corrupts the statistics silently.
• Make one recorded decision on the optional fund and interbank population, and one on reporting currency, and hold both across periods.
• Use the BCL’s published remittance calendar as the authority for each month’s date, and read the definitions-and-concepts document before classifying borderline flows.

Related: External-sector reporting compared across the EU · CSSF legal reporting for payment and e-money institutions · The ECB payment statistics regulation · How to issue Luxembourg IBANs