BCL CDDP – V reports Solution

We’ve developed a simple, efficient, and cost-effective tool using Excel.

Key features include:

  • Data mapping
  • XSD check, ensuring technical format compliance
  • Specific file naming convention

The entire process is conducted on your premises: fill in the template, run automatic checks, and generate the XML locally, ready to be sent .

The BCL CDDP reporting requirements are extensive, covering a wide range of payment instruments including credit transfers, direct debits, payment cards, e-money, checks, and money orders. The framework also captures specialized operations such as Over-The-Counter (OTC) cash transactions, interbank payments, on-us transactions, and simple book entries. The collection adheres to the “residence of the account” principle, meaning any payment account held with an institution legally established in Luxembourg is considered a Luxemburgish account, irrespective of the account holder’s country of residence.
The data collection is structured into a series of 14 detailed reporting tables, designated as “V-reports” (V1.1 to V1.14), each targeting a specific payment instrument or activity. These tables demand a high level of granularity, requiring reporting agents to classify transactions by customer category (MFI vs. non-MFI), settlement channel, initiation mode, and various geographical indicators.
A significant focus is placed on differentiating between legacy and SEPA (Single Euro Payments Area) instruments, with specific sub-tables dedicated to SEPA Credit Transfers (SCT) and SEPA Direct Debits (SDD), including detailed reporting for exception handling through “R-transactions” (e.g., Rejects, Returns, Recalls). The legal foundation for this collection incorporates the requirements of regulation ECB/2013/43 on payment statistics, ensuring alignment with broader European standards.

Purpose and Legal Foundation

The core objective of the CDDP reporting is to compile comprehensive statistics on the payment activities of financial actors in Luxembourg. The collected data measures both stocks of payment instruments and accounts, as well as the flows of payment transactions by volume and value.
The legal basis for this reporting is established by:
BCL Regulation 2011/N°9 of 4 July 2011 on the collection of data on payment instruments and operations.
BCL Regulation 2015/N°20 of 24 August 2015, which amends the 2011 regulation.
ECB Regulation ECB/2013/43, which sets European-level requirements for payment statistics and is implemented via BCL circulars and regulations.
A payment transaction is defined as “an act, initiated by the payer or by the payee (beneficiary), of placing, transferring or withdrawing funds, irrespective of any underlying obligations between the payer and the payee,” sourcing from the Payment Services Directive (PSD) 2007/64/EC.

Scope of the Reporting Framework

The CDDP reporting framework is designed to be exhaustive, covering a wide array of payment instruments and transaction types.
Key Areas Covered:
PSD Instruments: Credit transfers, direct debits, card payments, and e-money.
Other Instruments: Checks and money orders.
Transaction Types:
    ◦ Interbank payments.
    ◦ On-us transactions (where the payer and payee use the same financial institution).
    ◦ Over The Counter (OTC) cash deposits and withdrawals.
    ◦ Transactions via telecommunication, digital, or IT devices.
    ◦ Simple book entries (credits and debits initiated by the payment service provider without a specific payment instruction, such as interest payments or fee deductions).
Related Financial Operations: Payments related to securities transactions (e.g., coupons, purchases/sales) and customer lending operations (granting and refunds of loans) are also included, primarily classified as book entries.
Core Principles:
Residence of the Account: The collection applies to all payment accounts opened by a reporting agent legally established in Luxembourg, regardless of the account holder’s country of residence.
Netting Operations: For netted transactions, only the net flow corresponding to the effective payment is reported.
Rejected vs. Returned Transactions: Rejected transactions, which are not processed, are excluded from the collection. Returned transactions for legacy credit transfers are included in gross figures, while SEPA (R-transactions) are reported in dedicated tables.

The V-Report Tables: A Structured Overview

The BCL CDDP reporting is organized into 14 primary tables, many of which contain multiple sub-tables to capture specific data facets.
Code Description
V01100 Payment services provided by e-money institutions and payment institutions without the provision of payment accounts
V01110 Payment initiation services (payments)
V0120 Customer credit transfers sent (payments)
V01200 Stock of issued payment cards
V01201 Stock of distributed payment cards
V0121 Customer credit transfers received
V01210 Customer credit transfers received
V01220 Stock of accounts (except e-money accounts)
V01221 Stock of e-money accounts
V01222 Stock of accessed accounts – account information services (AIS)
V01230 Number of customers
V0130 Direct debits – reporting as creditor’s PSP (payments)
V0131 Direct debits – reporting as debtor’s PSP
V0140 SEPA R-transactions
V0141 Interbank payment transactions
V0142 Intermediated payment transactions
V0150 Card transactions with cards issued by resident PSPs (payments)
V0151 Electronic card transactions with cards issued by resident PSPs, split by Merchant Category Codes (MCC)
V0152 Card transactions acquired by resident PSPs (payments)
V0153 Fundings and withdrawals related to prepaid cards
V0160 Cheques and money remittances (payments)
V0170 Over-the-counter (OTC) cash transactions
V0180 Book entries
V0190 Fundings and withdrawals in e-money (except prepaid cards)
V0191 E-money transfers (payments)

Key Reporting Concepts and Definitions

The accuracy of the reported data relies on a precise understanding of several key concepts that provide the necessary granularity.
Credit Transfer Reporting
Credit transfers are analyzed from three distinct perspectives within the payment processing chain (Ordering Party → Bank OP → Intermediary PSP → Bank BEN → Beneficiary):
Transfers Sent (V1.1.1, V1.2.1): Reported by the Bank of the Ordering Party (Bank OP).
Transfers Received (V1.1.2, V1.2.2): Reported by the Beneficiary Bank (Bank BEN).
Intermediated Transfers (V1.1.3, V1.2.3): Reported by any Payment Service Provider (PSP) acting as an intermediary.
A critical data point is the Settlement Channel, which identifies the system or method used to settle the payment. A decision tree helps reporting agents determine the correct channel based on the transaction currency and whether the agent has a direct connection to a payment system. Key channels include:
Payment Systems: TARGET, EURO1, STEP1, STEP2, EQUENS.
In-house: ON-US (for transactions where Bank OP and Bank BEN are the same).
Bilateral: RELATION NOSTRO-LORO (settlement via correspondent accounts).
Intermediated: PSP LU or PSP NON-LU (when an intermediary is used).
Customer Categorization
Transactions must be categorized based on the customer type, distinguishing between Monetary Financial Institutions (MFI) and non-Monetary Financial Institutions (non-MFI). The framework provides a detailed matching table to ensure consistent classification, breaking down categories further:
MFI: Credit Institutions, Money Market Funds, Other MFIs.
Non-MFI: Non-MFI Funds, Other non-MFIs (which includes government, other financial intermediaries, insurance corporations, non-financial corporations, and households).
Payment Card Activities
The reporting for payment cards makes a fundamental distinction between two primary activities:
Issuing Activity: Reflects transactions made with cards physically issued by the reporting institution. This is further divided into cards issued for the institution’s own customers and those issued for customers of third-party distributors.
Acquiring Activity: Reflects transactions processed by the reporting institution on behalf of merchants.
Distribution Activity: A sub-category where an institution provides cards to its customers but is not the issuer (i.e., the activity is outsourced). This is reported separately in the stock-taking table (V1.4.1).

SEPA R-Transactions

The framework includes comprehensive reporting for exception handling in SEPA schemes, known as R-transactions. The reporting is based on specific interbank XML messages and covers different scenarios for SCT and SDD.
SCT R-Transactions (V1.1.4, V1.1.5):
    ◦ Return: Occurs after settlement when a beneficiary bank cannot execute a transfer for a valid reason (e.g., wrong account number).
    ◦ Recall: A request by the originator bank to cancel a transfer, which can be for reasons like duplicate sending, technical problems, or fraud.
SDD R-Transactions (V1.3.4, V1.3.6):
    ◦ Reject: A collection diverted before settlement due to technical reasons or a debtor’s refusal.
    ◦ Return: A collection diverted after settlement, initiated by the Debtor Bank.
    ◦ Reversal: A reimbursement initiated by the Creditor after settlement for an erroneous collection.
    ◦ Refund: A claim by the Debtor for reimbursement after settlement.
    ◦ Request for Cancellation: A request by the Creditor Bank to recall a collection before settlement.