clean - Banque centrale du Luxembourg

Transcription

Règlement de la BCL – Collecte directe des données paiement
Annexe 1 : Note de guidance relative à la transmission des données
paiements (version 4)
Contents
1.
2.
3.
4.
Introduction ..................................................................................................................................... 3
Remarques importantes concernant la transmission des données :................................................. 4
Informations à renseigner pour tous les tableaux............................................................................ 5
Instructions spécifiques aux instruments ........................................................................................ 5
4.1 Les tableaux virements – Principes généraux .......................................................................... 5
4.1.1
Les agents rapporteurs ...................................................................................................... 7
4.1.2
Les sous-tableaux virements ............................................................................................. 7
4.1.3
Les canaux de règlement ................................................................................................... 9
4.2 Les tableaux virement ............................................................................................................ 11
4.2.1
Tableau V 1.1 : Virements de clientèle ........................................................................... 11
4.2.2
Tableau V 1.2 : Virements interbancaires ....................................................................... 24
4.3 Tableau V 1.3 : Domiciliations .............................................................................................. 31
4.3.1
Sous –tableau V 1.3.1 : Domiciliations legacy ............................................................... 32
4.3.2
Sous –tableau V 1.3.2 : Règlement du solde des cartes de paiement ............................. 32
4.3.3
Sous –tableau V 1.3.3 : SEPA Direct Debit transactions (reporting en tant que Banque
du débiteur) ................................................................................................................................... 32
4.3.4
Sous-tableau V 1.3.4 :R-transactions – SEPA Direct Debit (reporting en tant que
Banque du débiteur) ...................................................................................................................... 33
4.3.5
Sous –tableau V 1.3.5: SEPA Direct Debits transactions (reporting en tant que Banque
du créancier) .................................................................................................................................. 33
4.3.6
Sous –tableau V 1.3.6: R-transactions - SEPA Direct Debits (reporting en tant que
Banque du créancier) .................................................................................................................... 33
4.4 Tableau V 1.4 : Inventaire des cartes de paiement & des terminaux acceptant des cartes de
paiement ............................................................................................................................................ 37
4.4.1
Sous-tableau V 1.4.1: Inventaire des cartes de paiement ................................................ 37
4.4.2
Définition des concepts utilisés dans le sous-tableau V1.4.1 ......................................... 38
4.4.3
Sous-tableau V 1.4.2: Opérations de (dé)chargement sur cartes prépayées ................... 40
4.4.4
Sous-tableau V 1.4.3 : Nombre de terminaux acceptant des cartes de paiement ............ 42
4.5 Tableau V 1.5 : Transactions cartes (volet issuing) ............................................................... 43
4.6 Tableau V 1.6 : Transactions cartes (volet acquiring)............................................................ 46
4.7 Tableau V 1.7 : Chèques et mandats de paiement .................................................................. 49
4.7.1
Sous tableau V1.7.1 : Chèques et mandats de paiement émis ........................................ 49
4.7.2
Sous-tableau V1.7.2 : Chèques et mandats de paiement reçus ....................................... 49
4.8 Tableau V 1.8 : Schéma de Monnaie Electronique (SME) sur réseau ................................... 52
4.8.1
Sous-tableau V1.8.1 : Inventaire des schéma de monnaie électronique sur réseau ........ 52
4.8.2
Sous-tableau V1.8.2 : retiré............................................................................................. 52
4.8.3
Sous-tableau V1.8.3 : Opérations de (dé)chargement en monnaie électronique sur
réseau 52
4.8.4
Sous-tableau V1.8.4 : Transferts en monnaie électronique sur réseau ........................... 52
4.8.5
Sous-tableau V1.8.5 : Mode d’initiation des transferts en monnaie électronique sur
réseau 53
Version 4 – Juin 2015
1
4.9 Tableau V 1.9 : Schéma de Monnaie Electronique (SME) sur carte (monnaie électronique
stockée sur la puce de la carte) (NOUVEAU TABLEAU) .............................................................. 57
4.9.1
Sous-tableau V1.9.1 : Inventaire des SME sur carte (monnaie électronique stockée sur
la puce de la carte) ........................................................................................................................ 57
4.9.2
Sous-tableau V1.9.2 : Inventaire des SME sur carte (monnaie électronique stockée sur
la puce de la carte) ........................................................................................................................ 57
4.9.3
Sous-tableau V1.9.3 : Opérations de (dé)chargement en monnaie électronique sur carte
servant de support à la monnaie électronique ............................................................................... 57
4.9.4
Sous-tableau V1.9.4 : Transferts en monnaie électronique depuis une carte servant de
support à la monnaie électronique ................................................................................................ 57
4.10
Tableau V1.10: Nombre de comptes de paiement en monnaie scripturale (NOUVEAU
TABLEAU) ....................................................................................................................................... 60
4.11
Tableau V1.11: Opérations en espèces réalisées au guichet de la banque (OTC cash
transactions) (NOUVEAU TABLEAU) ........................................................................................... 60
4.12
Tableau V1.12: Transactions de paiement réalisées au moyen d’un dispositif de
télécommunication, numérique ou informatique (NOUVEAU TABLEAU) .................................. 61
4.13
Tableau V1.13: Crédits effectués sur les comptes de paiement par le biais d’une simple
écriture comptable (book entry) (NOUVEAU TABLEAU) ............................................................ 63
4.14
Tableau V1.14: Débits effectués depuis les comptes de paiements par le biais d’une
simple écriture comptable (NOUVEAU TABLEAU) ...................................................................... 64
5. Exemples de reporting – Virements .............................................................................................. 67
5.1 Exemple 1: Intermédiation avec règlement du paiement via un ACH: .................................. 69
5.2 Exemple 2: Relation “Nostro/Loro”: ...................................................................................... 70
5.2.1
En cas d’intermédiation: ................................................................................................. 70
5.2.2
En l’absence d’intermédiation: ....................................................................................... 72
5.3 Exemple 3: Cas de règlement dans une devise étrangère ....................................................... 73
5.3.1
Cas n°1: Connecté – règlement du paiement dans un ACH .......................................... 73
5.3.2
Cas n°2: Connecté – règlement via une relation de compte Nostro/Loro ...................... 74
5.3.3
Cas n°3: Non-connecté – règlement du paiement via un PSP ........................................ 75
5.3.4
Cas n°4: Non-connecté – règlement via relation de compte Nostro/Loro ..................... 76
5.4 Exemple 4: Simulation de reporting dans le cas d’une série de paiements divers ................. 77
6. Rubrique « Catégorie client » ....................................................................................................... 80
Definition : IFM et non-IFM ................................................................................................................ 80
Table de conversion entre le reporting CDDP et les definitions de la BCL ......................................... 81
Vue d’ensemble................................................................................................................................. 81
Vue détaillée ..................................................................................................................................... 82
7. R-transactions - Définitions .......................................................................................................... 87
SCT r-transactions: ........................................................................................................................... 87
SDD r-transactions: ........................................................................................................................... 88
8. R- transactions – Champ d’application ......................................................................................... 89
8.1 Principes généraux ................................................................................................................. 89
8.2 Hors champ d’application ...................................................................................................... 89
8.3 Les messages R-Transactions au niveau interbancaire dans le schema SDD ........................ 89
8.4 Les messages R-Transactions au niveau interbancaire dans le schema SCT ......................... 90
9. Transactions SEPA et R-transactions – Description des flux de paiements et des flux des
messages................................................................................................................................................ 90
10.
Liste des modifications apportées dans les différentes versions de ce document ................... 104
2
1.
Introduction
- Les tableaux mesurent la volumétrie (le volume et la valeur des transactions) des transactions de paiement
réalisées à l’aide des différents instruments de paiement à l’exception des tableaux V 1.4, V 1.8.1, et V1.9.1
qui recensent des stocks.
- Etendue de la collecte :
•
La collecte vise :
o
les instruments de paiement couverts par la PSD1
o
les paiements interbancaires2
o
Les chèques et mandats de paiement
o
Les transactions on-us3
o
les book entries4 (à partir de janvier 2017)
o
les opérations en espèces (retraits et dépôts) réalisées au guichet de banque (à partir de janvier
2017)
o
les transactions de paiement réalisées au moyen d’un dispositif de télécommunication,
numérique ou informatique (à partir de janvier 2017)
La collecte vise toutes les transactions réalisées vers / depuis les comptes de paiements ouverts par
l’agent rapporteur pour ses clients. Les paiements relatifs à l’activité titre5 ainsi que les opérations de
prêt à la clientèle6 sont donc couvertes par la collecte (à partir de janvier 2017).
En ce qui concerne les données collectées en 2017, la méthodologie sera disponible à partir du 2ème
semestre 2016.
Une enquête annuelle pourra être effectuée afin d’estimer les paiements non couverts par la collecte mensuelle.
1
C.à.d. les virements, les domiciliations, les cartes de paiement, la monnaie électronique.
Afin d’avoir une collecte homogène, seront considérés les paiements interbancaires (paiements effectifs et non pas les
« notice » ou « Advice ») identifiés par des messages SWIFT MT2xx à l’exclusion des MT202COV.
Les paiements interbancaires (opérations de change, opérations de trésorerie, crédits documentaires ou autre activité de
salle de marché) exécutés via un message SWIFT MT2xx sont ainsi inclus dans la collecte.
N.B. : un message SWIFT MT2xx ne signifie pas de facto que le virement est interbancaire (cf. paragraphe 4.2.2)
3
Une transaction on-us est un paiement pour lequel le donneur d’ordre et le bénéficiaire détiennent un compte auprès de
la même institution financière (aussi appelé « in-house payment »).
2
4
Débits ou crédits effectués par la banque sur les comptes de paiement de ses clients par le biais d’une simple écriture
comptable et résultant d’un contrat.
5
C.à.d. les coupons, les achats et ventes de titres pour clients. Sont également inclues les opérations sur fonds
d’investissement (souscriptions ou rachats). Les paiements relatifs à l’activité titres constituent principalement des book
entries.
6
C.à.d. l’octroi de prêts à des clients et le remboursement de ces prêts par les clients. Les opérations de prêts constituent
principalement des book entries.
3
- Une opération de paiement est définie comme suit : une action initiée par le payeur ou le bénéficiaire,
consistant à verser, transférer ou retirer des fonds, indépendamment de toute obligation sous-jacente entre le
payeur et le bénéficiaire (Source : directive 2007/64/CE du Parlement européen et du Conseil concernant les
services de paiement dans le marché intérieur).
- La valeur des transactions de paiement est à renseigner dans la devise du capital.
- Le principe de la résidence du compte devra être appliqué. Ainsi un compte ouvert dans un établissement
Luxembourgeois sera considéré comme un compte luxembourgeois, quel que soit le pays de résidence du
titulaire du compte.
- Traitement des opérations de netting (exemple : opérations envoyées dans CLS, du règlement d’opérations
bilatérales…) : le flux net (correspondant au paiement effectif) sera indiqué. Le canal de règlement à
renseigner sera celui utilisé pour le règlement de la position nette. Ex : pour un paiement en euros envoyé dans
le système CLS, le canal de règlement pourra être Target2 (cf. paragraphe 4.2.2).
Une enquête annuelle pourra être effectuée afin d’estimer le netting en général et les activités via CLS plus
particulièrement.
- La présente collecte couvre notamment les exigences en matière de statistiques de paiement requises par le
règlement BCE/2013/43. A titre indicatif, celles-ci ont été surlignées en rose dans les tableaux V du présent
document.
Légende applicable au présent document:
Exigences statistiques découlant du règlement BCE 2013/43 du 28/11/2013
[applicables via la circulaire BCL]
Autres exigences statistiques dont celles issues de l’orientation BCE 2014/15 du
04/04/2014 (ECB guideline) [applicables via le règlement BCL 2011/9 modifié]
2.
Remarques importantes concernant la transmission des données :
- Envoi séparé de tableaux: les différents tableaux (les tableaux virements, domiciliations,…) peuvent faire
l’objet d’envois séparés. Les sous-tableaux d’un même tableau doivent cependant parvenir dans un même
envoi (ex : les sous-tableaux virements de clientèle).
- Reporting des combinaisons/lignes du tableau qui correspondent à une activité uniquement:
Pour chaque tableau ou sous-tableau, il s’agira de ne fournir que les lignes pour lesquelles le volume et la
valeur ne sont pas nuls. Il ne faudra donc pas fournir une ligne pour chaque combinaison possible, celles-ci
incluant également des combinaisons pour lesquelles l’activité est nulle.
Exemple: si pour une devise il n’y a pas eu de transactions, il ne s’agira pas d’envoyer une ligne avec pour
indication que le volume et la valeur sont nuls
- Reporting des lignes vides:
Le reporting concerne tous les tableaux ce qui signifie que tous les tableaux doivent être envoyés. Dans le cas
où l’agent rapporteur n’a pas d’activité pour l’un des instruments de paiement soumis à collecte, le tableau
4
dénué de toute donnée devra néanmoins être envoyé à la BCL. Seul le “header” accompagnant le tableau
“vide” devra être complété.
- Envoi de corrections : il est important de noter que lors du renvoi d’un tableau pour une période donnée, le
nouveau tableau généré écrase le précédent. En particulier, si un tableau est composé de plusieurs soustableaux, lors de corrections l’ensemble des sous-tableaux doit être renvoyé. Ceci même si les corrections ne
concernent qu’un seul sous-tableau.
- Tous les chiffres sont à envoyer en valeur absolue, le système n’accepte pas de valeurs négatives.
3.
Informations à renseigner pour tous les tableaux
Il s’agit des informations à renseigner en entête des tableaux.
o
Fréquence
o
Période
o
Catégorie d’institution7
o
Nom de l’institution
o
Numéro signalétique (NOSIG)8
Dans la présente collecte, il est fait référence à la notion de banque. Le terme de « banque » est utilisé ici
dans un sens générique et désigne tout établissement actif dans le domaine des paiements. Le terme
« banque » couvre ainsi non seulement les établissements bancaires mais également les établissements de
paiement, les établissements de monnaie électronique ainsi que l’EPT en tant qu’établissement actif dans
le domaine des paiements.
4.
4.1
Instructions spécifiques aux instruments
Les tableaux virements – Principes généraux
La collecte relative aux virements comprend les paiements de clientèle et les paiements interbancaires dans
deux tableaux distincts.
Chacun de ces deux tableaux comporte trois sous-tableaux, le premier dédié aux virements émis, le deuxième
aux virements reçus et le troisième aux virements intermédiés.
Particularités liées à la collecte des données sur les virements:
- Le traitement des rejets et des retours au niveau des virements:
7
8
Etablissement de crédit, établissement de paiement, EPT, établissement de monnaie électronique.
Numéro attribué par la CSSF
5
En ce qui concerne les virements « legacy », les rejets ne sont pas inclus dans la collecte puisqu’il s’agit de
messages n’ayant pas abouti pour une raison ou une autre. Les retours sont quant à eux inclus dans les chiffres
bruts. Ceci est largement dû au fait qu’ils ne peuvent pas être neutralisés.
En ce qui concerne les virements SEPA (SCT), les R-transactions générés en interbancaire, c.à.d. entre la
« Originator bank » et la « Creditor bank » doivent être rapportés dans les tableaux prévus à cet effet.
- La collecte relative aux virements se réfère à une chaîne de traitement des paiements commerciaux pour les
opérations de clientèle et se base sur les messages swift de type 2xx pour les opérations/instructions
interbancaires.
Chaîne de traitement de type paiement
Volet « Emis »
dans la chaîne de traitement
DNO
BQE
DNO
Volet « Reçu »
dans la chaîne de traitement
ACH
(s)
PSP1
PSP2
BQE
BEN
BEN
Transaction
Reporting
BCL
REPORTING A LA BCL
Sous-tableau
« Virements émis »
Sous-tableau
« Virements intermédiés »
Sous-tableau
« Virements reçus »
(Reporting de la
BQE DNO)
(Reporting des
PSP)
(Reporting de la
BQE BEN)
Légende :
DNO : Donneur d’ordre (particulier, corporate, banque,…)
BQE DNO: Banque du donneur d’ordre
PSP: Payment Service Provider (banque, établissement de paiement)
ACH: Automated Clearing House
BQE BEN: Banque du bénéficiaire
BEN : Bénéficiaire (particulier, corporate, banque…)
6
4.1.1 Les agents rapporteurs
Les agents rapporteurs dans le cadre de la présente collecte sont:
1) la banque du donneur d’ordre (BQE DNO), qui rapportera ses transactions dans le sous-tableau dédié aux
virements émis ;
2) la banque du bénéficiaire (BQE BEN), qui rapportera ses transactions dans le sous-tableau dédié aux
virements reçus ;
3) et en cas d’intermédiation, le (ou les) établissements intermédiaires (PSP), rapportera (rapporteront) ses
(leurs) transactions dans le sous-tableau dédié aux virements intermédiés ;
4.1.2 Les sous-tableaux virements
Les trois sous-tableaux évoqués ci-dessus et qui s’appliquent aux virements de clientèle, respectivement aux
virements interbancaires, permettent de mesurer :
1) Sous-tableau « Virements émis » : sont renseignés ici les virements émis, c.à.d. les virements envoyés par la
banque DNO. Ce sous-tableau permet de mesurer d’une part la volumétrie des virements émis.
Il permet d’autre part de mesurer l’utilisation des canaux de règlement par la banque DNO pour exécuter ces
virements :
En effet, lorsque la BQE DNO règle ses virements directement dans un système, le nom de celui-ci sera
indiqué
Lorsque la BQE DNO passe par un intermédiaire pour l’exécution de ses virements, elle renseignera « PSP
LU » ou « PSP non-LU » comme canal de règlement. L’identification du système utilisé in fine pour dénouer
ces transactions se fera au niveau du tableau des virements intermédiés, à renseigner par l’établissement
intermédiaire ou PSP.
2) Sous-tableau « Virements reçus » : sont renseignés ici les virements reçus, c.à.d reçus par la BQE BEN. Ce
sous-tableau permet de mesurer d’une part la volumétrie des virements reçus.
Il permet d’autre part de mesurer l’utilisation par la BQE BEN des canaux de règlement pour réceptionner ces
virements :
En effet, lorsque la BQE BEN reçoit ses virements directement dans un système, le nom de celui-ci sera
indiqué.
Lorsque la banque BEN passe par un intermédiaire pour la réception de ses virements, elle renseignera « PSP
LU » ou « PSP non-LU » comme canal de règlement. L’identification du système dans lequel le PSP a
préalablement reçu le paiement, se fera au niveau du tableau des virements intermédiés, à renseigner par
l’établissement intermédiaire ou PSP.
7
3) Sous-tableau « Virements intermédiés » : sont renseignés ici les virements intermédiés, c.à.d les virements
réglés par les PSP pour le compte d’autres établissements.
Ce sous-tableau permet d’une part de mesurer l’utilisation des canaux de règlement pour exécuter ces
virements intermédiés et d’autre part de mesurer l’intermédiation financière pour compte d’établissements
luxembourgeois et non-luxembourgeois.
8
4.1.3 Les canaux de règlement
Le « Canal de règlement» renseigne sur le système, respectivement la méthode d’exécution, utilisé pour régler
les virements :
L’indication relative au canal de règlement, en général le nom du système de paiement utilisé pour régler ces
virements, permet de mesurer l’utilisation des différents systèmes ou autres méthodes de règlement des
virements.
L’arbre décisionnel décrit ci-dessous constitue une aide à l’identification du canal de règlement tel que celui-ci
doit être renseigné dans le tableau virement.
Arbre décisionnel
DEVISE ?
Etape n°1
Etape n°2
Etape n°3
Connecté
Nom système
règlement
Relation
Nostro/ Loro
Pas connecté
PSP LU
ou
PSP non- LU
Le processus d’identification se déroule en 3 étapes:
Etape n°1: Identification de la devise de la transaction:
Le raisonnement permettant de déterminer le canal de règlement se base sur la devise du paiement à
exécuter. Il s’agit donc en premier lieu de se placer dans la devise du paiement, c.à.d de répondre à la
question suivante:
“Quelle est la devise de cette transaction?”
9
Etape n°2: Identification de la (non-)connexion à un système de règlement:
Il s’agit, ensuite pour la devise considérée, de raisonner en terme de “connecté” ou ”pas connecté” à un
système de paiement, c.à.d de répondre à la question suivante:
“Pour la devise de ce paiement, mon établissement est-il connecté ou pas à un système de règlement?”.
Etape n°3: Identification du canal de règlement:
1) En cas de connexion par l’agent rapporteur, pour cette devise, à un système de règlement:
N.B: il s’agit d’une connexion “directe”. Un participant indirect dans un système de paiement est considéré
comme passant par un PSP pour cette collecte.
Dans ce cas, le nom du système sera renseigné.
Il peut cependant également opter pour un règlement via une relation de compte nostro/loro. Dans ce cas,
“Relation Nostro/Loro” sera renseigné.
En conclusion, lorsque pour une devise donnée, un établissement est connecté à un système de
règlement, les deux canaux de règlement possibles sont soit le système de règlement (nom du système
utilisé) soit une relation de compte nostro/loro.
2) En cas de non-connexion par l’agent rapporteur, pour cette devise, à un système de règlement:
Le paiement est usuellement réglé via un PSP que l’établissement a choisi pour faire exécuter ses
transactions dans cette devise. Le canal de règlement à renseigner est “PSP LU” ou “PSP non-LU” en
fonction que le PSP usuel pour cette devise est luxembourgeois ou non.
Il est cependant également possible que l’établissement “non-connecté” entretienne une relation de
compte nostro/loro avec la contrepartie et règle le paiement via ce biais. Néanmoins, par convention, ces
transactions seront renseignées comme si elles avaient été réglées par le PSP usuel pour cette devise.
Remarque concernant les paiements de couverture:
Le canal de règlement n’est pas lié au flux du message swift: quand une instruction de paiement est
envoyée à la banque du bénéficiaire, le canal de règlement sera “PSP, ceci même si elle s’accompagne
d’un paiement de couverture (MT202 COV) envoyé au PSP. Le reporting n’est donc pas dépendant du
chemin de paiement choisi (paiement de couverture respectivement paiement en série via le PSP).
10
4.2
Les tableaux virement
4.2.1 Tableau V 1.1 : Virements de clientèle
- Un virement de clientèle est en général un virement dont l’une des contreparties est non-bancaire et qui est
exécuté dans une chaîne de traitement de type paiement. Le Donneur d’ordre respectivement le bénéficiaire
peut être un particulier, un corporate ou une banque.
- Les virements de clientèle comprennent les ordres permanents. Ceux-ci seront considérés comme des
virements dont le format est électronique.
- Seules les transactions réalisées depuis un compte de paiement9 ou reçues sur un compte de paiement et en
utilisant un instrument de paiement (de type virement) sont à rapporter dans la collecte mensuelle.
- Les virements multiples à débit unique ou virements collectifs (ex : paiement de salaires) seront à
renseigner au titre des virements émis, le nombre total de crédits effectués. Tous les virements émis devront
être renseignés, faisant abstraction du débit unique.
Sous –tableau V 1.1.1 : Virements de clientèle émis (paiements envoyés par la banque DNO)
Type
instrument
paiement
Catégorie
client (DNO)
Canal de
règlement
SEPA
capable
Virement
-
TARGET
Oui
Etablissement
Euro1
Non
de crédit
Step1
Mode initiation
Instruction au format
papier
Pays de
destination
de la
banque
bénéficiaire
Code ISO
du pays de
destination
Papier
Volume
Valeur
Devise de
la
transaction
Code ISO
devise
Electronic - File batch
[IFM]
- Fonds
Step2
monétaires
EQUENS
[IFM]
On-us
- Autres
Relation
IFMs [IFM]
N./L.
Single - Online
PSP LU
- Fonds nonmonétaires
( Electronic – Single )
PSP non-
banking e-payments10
Single – Web
banking
Single - Other
LU
[non- IFM]
- Autres non
Autre
IFMs [nonIFM]
(- Inconnu)
9
Définition de compte de paiement : cf. article 4.14 de la directive 2007/64/CE du Parlement européen et du Conseil
concernant les services de paiement dans le marché intérieur.
10
Statistiques requises par l’orientation ECB/2014/15 du 4/04/2014 (ECB guideline).
11
Définition des concepts utilisés dans le sous tableau V1.1.1 Virements de clientèle émis :
Ce sous-tableau est à renseigner par les établissements qui agissent en tant que banque DNO.
- Définition du concept de banque DNO :
De manière générale dans la présente collecte, est considéré comme banque DNO l’établissement qui émet des
instructions de paiements dans un système ou qui, le cas échéant, les transmet à son PSP en vue d’exécuter ces
paiements.
o
La banque DNO agit en général sur instruction de son client, le DNO.
o
Cas des opérations pour compte propre (exemple : le paiement par une banque du salaire de ses employés
ou de factures de ses fournisseurs) :
DNO [=BQE DNO] -> BQE DNO -> PSP1 -> Règlement : ACH, Nostro/Loro -> PSP2 -> BQE BEN -> BEN
Le DNO (le département Ressources humaines ou Comptabilité de la banque) est une banque qui a pour
particularité d’être également la BQE DNO. La banque effectue un reporting dans son rôle de BQE DNO.
o
Cas spécifique de la transmission des instructions de paiement pour compte propre via un canal spécifique
(ex : Multiline).
Dans ce cas, l’établissement qui instruit un autre établissement d’effectuer des paiements pour son propre
compte, tout comme le ferait un client à sa banque, est considéré comme DNO. L’autre établissement a donc le
rôle de BQE DNO.
Exemple : la « banque 1 » transmet des instructions de paiement pour compte propre via Multiline à la
« banque 2 » :
DNO [=banque 1] via Multiline -> BQE DNO [=banque 2] -> Règlement : ACH, Nostro/Loro -> PSP2 -> BQE BEN -> BEN
La banque 1, en tant que DNO, n’effectue pas de reporting à la BCL. La banque 2 effectue un reporting en tant
que BQE DNO à la BCL.
- Type d’instrument de paiement:
Le type d’instrument de paiement à renseigner dans ce sous-tableau est le virement.
La seule valeur possible est donc: Virement.
- Catégorie client (DNO) :
La catégorie client vise à apporter une granularité supplémentaire selon que le client soit une « Institution
Financière Monétaire (IFM) » ou non (« non-Institution Financière Monétaire (non-IFM) »).
12
Les valeurs possibles sont: Etablissement de crédit, Fonds monétaires, Autres IFMs, Fonds non-IFM, Autres
non-IFM, Inconnu.
En ce qui concerne le détail de chacune des catégories, se référer à la liste figurant au point 6 Rubrique
« Catégorie client » à la page 80 du présent document.
Il est à noter que la valeur « inconnu » ne devrait à priori pas être utilisée. En effet, d’une part, chaque
établissement est sensé connaître ses clients et d’autre part, la liste mentionnée ci-dessus est accompagnée
d’une table de conversion qui est sensée couvrir tous les cas possibles. La valeur « inconnu » est ainsi
uniquement permise dans le cas d’une situation non prévue par la table de conversion.
- Mode initiation :
Le mode d’initiation renseigne sur la façon dont les virements ont été initiés par les donneurs d’ordre.
Les valeurs possibles sont: Papier, Electronic - File batch, Electronic – Single, Single - Online banking epayments, Single - Web banking, Single - Other.
Définitions des différents modes d’initiations contenues dans le sous-tableau V1.1.1 :
1.
Virement initié sur support papier (« Papier »). Il requiert, soit un encodage de l’instruction, soit une
reconnaissance optique (OCR)11
2.
Virement initié par voie électronique: tout virement présenté par le payeur sans support papier, c’està-dire par voie électronique. Cela comprend:
→ les présentations par télécopie (fax) ou par d’autres moyens, tels que des services bancaires informatisés
par téléphone, si celles-ci se transforment en paiements électroniques sans intervention manuelle.
→ les ordres permanents présentés initialement sur un support papier mais exécutés ensuite
électroniquement.
→ les virements exécutés par un PSP au titre d’un service financier, si ledit service est initié par voie
électronique, ou si le moyen de soumission dudit service n’est pas connu et que le PSP a exécuté le
virement par voie électronique.
→ les virements initiés à un GAB ayant une fonction de virement.
Parmi les virements initiés par voie électronique, on distingue ceux initiés dans un fichier ou lot
(« Electronic - File batch »), de ceux initiés sur base d’un paiement unique (« Electronic –Single ») [cf.
définitions ci-dessous].
2.1 Virement (électronique) initié dans un fichier/lot (« Electronic - File batch »). Il s’agit d’un virement
initié par voie électronique faisant partie d’un groupe de virements initiés ensemble par le payeur. Chaque
virement compris dans un lot est recensé comme un virement distinct lors de la déclaration du nombre
d’opérations.
11
Cas des transactions scannées dont le traitement n’est pas entièrement automatisé.
13
2.2 Virement (électronique) initié sur la base d’un paiement unique (« Electronic –Single ») : Virement
initié par voie électronique et de façon indépendante, c’est-à-dire qui ne fait pas partie d’un groupe de
virements initiés ensemble.
Dans le reporting CDDP, les virements initiés sur la base d’un paiement unique se subdivisent en 3 souscatégories, respectivement : Single - Online banking e-payments, Single - Web banking , Single –
Other [cf. définitions ci-dessous].
2.2.1 Virement (électronique) initié sur la base d’un paiement unique qualifié de (« Single - Online
banking e-payments ») : il s’agit d’un virement initié à partir de schéma bancaires et de services
d’initiation de paiement simultanément à un achat en ligne. Cette rubrique exclut ainsi les paiements
réalisés par le biais d’un schéma bancaire n’impliquant pas de transaction d’achat en ligne simultanée.
Cette rubrique exclut également les factures présentées en ligne mais n’impliquant pas de transaction
d’achat simultanée. A titre d’exemple, un virement initié depuis les services de paiement « My Bank » ou
« Ideal » est à reporter dans cette rubrique.
2.2.2 Virement (électronique) initié sur la base d’un paiement unique qualifié de (« Single -
Web
banking ») : il s’agit d’un virement initié à partir du service de banque en ligne que l’établissement de
crédit offre à ses clients (web banking, online-banking).
2.2.3 Virement (électronique) initié sur la base d’un paiement unique qualifié de (« Single - Other ») : il
s’agit d’un virement initié sur la base d’un paiement unique autres que « Single_Online banking epayments » et « Single Web banking ».
Le tableau ci-dessous renseigne sur la hierarchie des différents modes d’initiation demandés dans le reporting
CDDP :
Virements initiés sur support papier (« Papier »).
Virements initiés par voie électronique
dont Virements initiés dans un fichier/lot (« Electronic - File batch »)
dont Virements initiés sur la base d’un paiement unique (« Electronic - Single »)
dont (« Single - Online banking e-payments »)
dont (« Single – Web banking »)
dont (« Single - Other »)
Quel reporting transmettre ?
Dans le reporting CDDP, il est demandé de reporter le mode d’initiation selon la granularité suivante :
Papier
Electronic – File batch
(Electronic) Single – Online banking e-payments
(Electronic) Single – Web banking
(Electronic) Single – Other
14
1)
2)
3)
4)
5)
Remarques très importantes:
Les messages envoyés au titre de paiements multiples sont à reporter « Electronic-file batch »
Lorsque l’agent rapporteur, pour un canal de règlement particulier, n’est pas en mesure de réaliser la
distinction entre « Electronic-file batch » et « Electronic-single-others », il lui est accordé la possibilité de
déterminer un mode d’initiation pour ce canal de règlement, en se basant sur les cas les plus fréquemment
rencontrés. Dans le cas de Multiline par exemple, l’agent rapporteur a la possibilité de renseigner tous les
paiements réglés par ce biais en tant qu’ « Electronic file-batch », ce mode d’initiation étant majoritairement
utilisé (ceci, même si le lot ne comporte qu’un seul paiement).
En ce qui concerne les ordres permanents et les paiements Digicash, le mode d’initiation à renseigner est
« Electronic-single-other ». Les ordres permanents initiés par le biais du « webbanking » peuvent être
renseignées « Single-Webbanking » dans le cas où elles ont été identifiées comme telles dans les systèmes
de l’agent rapporteur.
En ce qui concerne les virements, la distinction entre « batch » et « single » est à reprendre au niveau de
l’initiation de l’instruction et non pas au niveau de la comptabilisation des opérations.
Les virements initiés par le biais de tablettes et de « smartphone », ainsi que les virements initiés à un GAB,
seront repris sous « Electronic single – web banking ».
- Canal de règlement :
Le canal de règlement renseigne sur le système ou le mode de règlement utilisé par la BQE DNO pour exécuter
le paiement.
o
En cas de connexion à un système de paiement permettant l’exécution du paiement dans la devise
correspondante:
1) Si la BQE DNO utilise ce système pour exécuter le paiement, le nom de celui-ci sera indiqué. Les
valeurs possibles sont : TARGET, Euro1, Step1, Step2, EQUENS, Autre.
2) Si la BQE DNO, bien que connectée à ce système de règlement, opte plutôt pour l’exécution du
paiement dans ses livres en raison de l’existence d’une relation de compte avec l’établissement
destinataire du paiement, le canal de règlement à renseigner sera Relation Nostro/Loro.
o
En cas de non-connexion à un système de paiement permettant l’exécution du paiement dans cette
devise:
Les valeurs possibles sont donc : PSP LU ou PSP non-LU, en conformité avec la convention
explicitée au paragraphe 4.1.3.
o
Traitement des transactions on-us :
Si les comptes bancaires du donneur d’ordre et du bénéficiaire concernés par le paiement sont
détenus auprès du même établissement (BQE DNO = BQE BEN), le canal de règlement à renseigner
est « on-us ».
La valeur sera alors : on-us.
15
- SEPA capable :
Un paiement SEPA capable est un paiement qui peut être traité selon les normes SEPA. Dans la présente
collecte, est considéré comme SEPA capable tout paiement dans la devise Euro émis dans la zone SEPA12 et
respectant les critères IBAN + SHARE13.
La BQE DNO renseignera qu’un paiement est « SEPA capable » si elle dispose du numéro de compte du BEN
dans la norme IBAN et si les frais sont partagés.
Les opérations « on us » sont à considérer comme SEPA capable si elles sont basées sur ces mêmes critères.
Les valeurs possibles sont: oui, non.
- Pays de destination de la banque bénéficiaire :
Le pays de destination renseigne sur le pays de la banque du bénéficiaire dans le cas d’un virement émis. C’est
le pays de la banque du bénéficaire, qui doit être renseigné et pas le pays de la /des banque(s) intermédiaire(s)
éventuelle(s).
Valeur possible : le pays de destination, identifié par le code ISO correspondant (Code ISO 3166 à deux
lettres).
- Volume :
Le volume est un indicateur quantitatif désignant le nombre de transactions
- Valeur :
La valeur est un indicateur quantitatif désignant la valeur, dans la devise du capital, correspondant au volume
de transactions.
- Devise de la transaction :
La devise de la transaction est renseignée par le code ISO de la devise (Code ISO 4217 à trois lettres) dans
laquelle la transaction a été réglée. Toutes les devises, dans lesquelles des transactions ont été effectuées, sont
à rapporter.
Exemple de reporting concernant une transaction dont la devise de la transaction est USD, la devise du capital
de l’agent rapporteur étant l’Euro : il sera renseigné « USD » dans la colonne « Devise de la transaction ». La
valeur de cette transaction (colonne « Valeur ») sera renseignée en euros.
12
Liste des pays appartenant à la zone SEPA :
http://www.europeanpaymentscouncil.eu/knowledge_bank_detail.cfm?documents_id=328
13
Les paiements initiés selon les critères SEPA mais qui in fine peuvent être réglés dans un système non-SEPA compliant
seront ainsi considérés comme SEPA capable.
16
Sous –tableau V 1.1.2 : Virements de clientèle reçus (paiements reçus par la banque BEN) :
Type
instrument
paiement
Catégorie client (BEN)
Canal de règlement
Virement
- Etablissement de crédit [IFM]
- Fonds monétaires [IFM]
- Autres IFMs [IFM]
TARGET
Euro1
Step1
Step2
EQUENS
On-us
Relation Nostro / Loro
PSP LU
PSP non-LU
Autre
- Fonds non-monétaires [nonIFM]
- Autres non IFMs [non-IFM]
(- Inconnu)
Pays d’émission
de la banque
donneur d’ordre
Volume
Valeur
Code ISO du pays
d’émission
Devise de
la
transaction
Code ISO
devise
Définition des concepts utilisés dans le sous tableau V1.1.2 Virements de clientèle reçus :
Ce sous-tableau est à renseigner par les établissements qui agissent en tant que banque BEN.
- Définition du concept de banque BEN :
De manière générale dans la présente collecte, est considéré comme banque BEN l’établissement qui reçoit un
paiement, soit via un système de paiement dans lequel il est connecté, soit via son PSP.
o
La banque BEN reçoit en général un paiement pour compte de son client, le BEN.
o
Dans le cas des opérations pour compte propre (exemple : la réception du paiement d’un loyer par un tiers
bancaire), la BQE BEN revêt également le rôle de BEN :
DNO-> BQE DNO -> PSP1 -> Règlement : ACH, Nostro/Loro -> PSP2 -> BQE BEN -> [BEN = BQE BEN]
Le BEN (le département Comptabilité de la banque) est une banque qui a pour particularité d’être également la
BQE BEN. Seule la banque dans son rôle de BQE BEN effectue un reporting.
Les valeurs possibles sont donc: virement.
- Catégorie client (BEN):
non-IFM, Inconnu.
17
La BQE BEN renseigne le canal de règlement, c.à.d le système ou le mode utilisé par lequel elle a reçu le
paiement.
o
Dans le cas où la BQE BEN est connectée à un système dans la devise en question :
1. Si ce système de règlement a été utilisé pour exécuter le paiement, le nom de celui-ci sera indiqué.
Les valeurs possibles sont : TARGET, Euro1, Step1, Step214, EQUENS, Autre.
2. Si, bien que la BQE BEN soit connectée à un système de règlement dans la devise considérée,
l’exécution du paiement a été faite via une relation de compte avec l’établissement émetteur du
paiement, le canal de règlement à renseigner sera Relation Nostro/Loro.
o
devise:
Les valeurs possibles sont donc : PSP LU ou PSP non-LU, conformément à la convention explicitée
au paragraphe 4.1.3
o
Traitement des transactions on-us :
Si les comptes bancaires du donneur d’ordre et du bénéficiaire concernés par le paiement sont
détenus auprès du même établissement (BQE DNO = BQE BEN), le canal de règlement à renseigner
est « on-us ».
La valeur sera alors : on-us.
- Le pays d’émission de la banque du donneur d’ordre :
Le pays d’émission renseigne sur le pays de la banque du donneur d’ordre dans le cas d’un virement reçu.
C’est le pays de la banque du donneur d’ordre qui doit être renseigné et non pas le pays de la/des banque(s)
intermédiaire(s) éventuelle(s).
Valeur possible : le pays d’émission, identifié par le code ISO correspondant (Code ISO 3166 à deux lettres)
Pour les versements, le pays d’émission sera «LU»
- Volume :
- Valeur :
14
Etant donné que XCT est voué à disparaître à court terme, pas de distinction SCT et XCT demandée.
18
de transactions.
à rapporter.
Sous –tableau V 1.1.3 : Virements de clientèle intermédiés (paiements envoyés et paiements reçus par les
PSP) :
Type
instrument
paiement
Type
client
Canal de
règlement
Sens de
l’opération
Pays
d’émission
de la
banque
donneur
d’ordre
Pays de
destination
de la
banque
bénéficiaire
Virement
Banque
LU
Banque
non-LU/
TARGET
Euro1
Step1
Step2
EQUENS
Relation Nostro /
Loro
PSP LU
PSP non-LU
Autre
Emis
Reçu
Code ISO
du pays
d’émission
Code ISO du
pays de
destination
Volume
Valeur
Devise de la
transaction
Code ISO
devise
Définition des concepts utilisés dans le sous tableau V1.1.3 Virements de clientèle intermédiés:
Ce sous-tableau est à renseigner par les établissements qui agissent en tant que PSP.
- Définition du concept de PSP:
De manière générale dans la présente collecte, est considéré comme PSP un établissement intermédiaire de la
BQE DNO ou de la BQE BEN, de nature bancaire ou non15 et qui exécute des instructions de paiements dans
un système, ceci pour le compte soit d’une banque DNO dans le cas d’un virement émis soit d’une banque
BEN dans le cas d’un virement reçu.
La seule valeur possible est donc: virement.
15
Exemple : établissement de paiement
19
- Type client :
Le type client permet de mesurer l’intermédiation pour le compte de banques luxembourgeoises de celle pour
le compte de banques non-luxembourgeoises. Le PSP renseignera donc au titre du « Type client » : BQE LU
ou BQE non-LU.
N.B. : en cas de règlement via relation de compte nostro/loro : lorsque le PSP est à la fois du côté émis et du
côté reçu (PSP1 et PSP2), celui-ci renseignera les deux transactions c.à.d. la transaction émise (« transaction
side = émis » et la transaction reçue (« transaction side = reçu ») et il précisera quel est le type client (« BQE
LU » ou « BQE non-LU »).
Cette catégorisation est distincte de la « catégorie client ».
Les valeurs possibles sont: Banque LU ou Banque non-LU.
Le canal de règlement renseigne sur le système ou le mode de règlement du paiement.
o
En cas de connexion par le PSP au système de paiement permettant l’exécution du paiement dans
cette devise:
1) Si ce système de règlement a été utilisé pour exécuter le paiement, le nom de celui-ci sera indiqué.
Les valeurs possibles sont : TARGET, Euro1, Step1, Step216, EQUENS, Autre.
2) Si, bien que le PSP soit connecté à un système de règlement dans la devise considérée, l’exécution
du paiement a été faite via une relation de compte, le canal de règlement à renseigner sera Relation
Nostro/Loro.
o
En cas de non-connexion par le PSP à un système de paiement permettant l’exécution du paiement
dans cette devise:
Les valeurs possibles sont: PSP LU ou PSP non-LU., conformément à la convention explicitée
au
paragraphe 4.1.3.
- Le sens de l’opération concerne uniquement les sous-tableaux dédiés aux virements intermédiés. Il permet
de distinguer les virements émis des virements reçus dans les systèmes et donc de mesurer l’activité des PSP
dans ces systèmes. Les valeurs possibles sont « émis » ou « reçu ».
- Le pays d’émission / de réception renseigne sur le pays de la banque du donneur d’ordre ayant émis une
instruction de paiement dans le cas d’un virement reçu, respectivement sur le pays de la banque du bénéficiaire
dans le cas d’un virement émis. Ce sont les pays de la banque du donneur d’ordre, respectivement de la banque
du bénéficiaire, qui doivent être renseignés et non pas le pays des banques intermédiaires.
Valeur possible : le pays d’émission, respectivement le pays de réception, identifié par le code ISO
correspondant (Code ISO 3166 à deux lettres).
- Volume :
16
Etant donné que XCT est voué à disparaître à court terme, pas de distinction SCT et XCT demandée.
20
- Valeur :
de transactions.
à rapporter.
Sous –tableau V 1.1.4 : R-transactions relatives aux virements SCT émis (reporting en tant que BQE
DNO ou Originator bank) :
Type Rtransaction
Catégorie client
(DNO)
Canal de
règlement
Pays de
destination de
la banque
bénéficiaire (*)
Return
Recall
- Etablissement de
crédit [IFM]
- Fonds monétaires
[IFM]
- Autres IFMs [IFM]
- Fonds nonmonétaires [non- IFM]
- Autres non IFMs
[non-IFM]
- Inconnu
TARGET
Euro1
Step1
Step2
EQUENS
On-us
Relation Nostro
/ Loro
PSP LU
PSP non-LU
Autre
Code ISO du
pays de
destination
Volume
Valeur
Devise de la
transaction
Code ISO devise
(*) du virement SCT d’origine et non de la R-transaction.
Remarque : les R-transactions réglées via le canal de règlement « on-us » sont à renseigner uniquement si
l’agent rapporteur est en mesure de le faire.
Définition des concepts utilisés dans le sous tableau V1.1.4 R-transactions relatives aux virements SCT
émis:
- Type de R-transaction:
Les types de R-transaction à renseigner dans ce sous-tableau sont le Return et le Recall.
Les valeurs possibles sont donc: return ou recall.
Pour plus de détails concernant les r-transactions (définitions, champ d’application, flux des messages), se
reporter aux points suivants du présent document :
21
7
22
R-transactions - Définitions (page 87)
8 R- transactions – Champ d’application (page 89)
9 Transactions SEPA et R-transactions – Description des flux de paiements et des flux des messages (page 90)
- Catégorie client :
non-IFM, Inconnu.
Le canal de règlement renseigne sur le système ou le mode de règlement du virement initial.
- Le pays de destination de la BQE BEN renseigne sur le pays de la banque du bénéficiaire du virement
initial.
Valeur possible : le pays de réception, identifié par le code ISO correspondant (Code ISO 3166 à deux lettres).
- Volume :
- Valeur :
de transactions.
à rapporter.
23
Sous –tableau V 1.1.5 : R-transactions relatives aux virements SCT reçus (reporting en tant que BQE
BEN ou Beneficiary Bank) :
Type Rtransaction
Catégorie client
(BEN)
Canal de
règlement
Pays
d’émission de
la BQE DNO
(*)
Return
Recall
- Etablissement de
crédit [IFM]
- Fonds monétaires
[IFM]
- Autres IFMs [IFM]
- Fonds nonmonétaires [non- IFM]
- Autres non IFMs
[non-IFM]
- Inconnu
TARGET
Euro1
Step1
Step2
EQUENS
On-us
Relation Nostro
/ Loro
PSP LU
PSP non-LU
Autre
Code ISO du
pays d’émission
Volume
Valeur
Devise de la
transaction
Code ISO devise
(*) du virement SCT d’origine et non de la R-transaction.
Remarques :
- Les R-transactions réglées via le canal de règlement « on-us » sont à renseigner uniquement si l’agent
rapporteur est en mesure de le faire.
- Sont à exclure du reporting les messages camt.029 générés lors d’une « negative answer to a recall message »
- Les messages générés par le CSM17 vers la Originator Bank sont également à exclure (exemple messages
pacs.002).
- Pour le volet SCT, il n’y a pas de Reject initié par la Beneficiary Bank vers la Originator Bank .
Définition des concepts utilisés dans le sous tableau V1.1.5 R-transactions relatives aux virements SCT
reçus:
- Type de R-transaction:
Les types de R-transaction à renseigner dans ce sous-tableau sont le Return et le Recall.
Les valeurs possibles sont donc: return ou recall.
7
17
CSM = Clearing and Settlement Mechanism
24
- Catégorie client (BEN) :
non-IFM, Inconnu.
Le canal de règlement renseigne sur le système ou le mode de règlement du virement initial.
- Le pays d’émissionde la BQE DNO renseigne sur le pays de la banque du donneur d’ordre du virement
initial.
Valeur possible : le pays d’émission, identifié par le code ISO correspondant (Code ISO 3166 à deux lettres).
- Volume :
- Valeur :
de transactions.
à rapporter.
4.2.2 Tableau V 1.2 : Virements interbancaires
Un virement interbancaire est un virement dont le donneur d’ordre et le bénéficiaire sont des banques.
25
Afin d’avoir une base de collecte homogène, la collecte des virements interbancaires est effectuée sur base des
messages SWIFT MT2XX18, à l’exclusion des MT202COV.
Les paiements interbancaires (opérations de change, opérations de trésorerie, crédits documentaires ou autre
activité de salle de marché) exécutés via un message SWIFT MT2xx sont ainsi inclus dans la collecte.
Un message SWIFT MT2xx ne signifie cependant pas de facto que le virement est interbancaire. En effet, une
transaction identifiée par un message SWIFT MT2xx mais dont le DNO et/ou le BEN ne sont pas des banques
doit être rapportée au titre des virements de clientèle. Les opérations des fonds d’investissement identifiées par
un message SWIFT MT2xxx sont ainsi à rapporter au titre des virements de clientèle.
Le virement correspondant au netting des opérations réalisées dans CLS est à rapporter au titre des virements
interbancaires.
Les MT204 étant des « Financial Markets Direct Debit Message », ils sont à considérer comme des
domiciliations19. Ceci quelque soit leur nature : opérations de change, opérations de trésorerie, crédits
documentaires, activité de salle de marché….
De même que pour les virements de clientèle, trois perspectives sont considérées, celle de la BQE DNO, de la
BQE BEN et enfin celle du ou des intermédiaires.
Dans la présente collecte, en ce qui concerne les opérations pour compte propre, on considère que
l’établissement concerné remplit le rôle à la fois de DNO et de BQE DNO (volet émis), respectivement de
BEN et de BQE BEN (volet reçu).
Sous –tableau V 1.2.1 : Virements interbancaires émis (paiements envoyés par la banque DNO)
Type
instrument
paiement
Canal de règlement
Pays de destination
de la banque
bénéficiaire
Virement
TARGET
Euro1
Step1
EQUENS
Relation Nostro / Loro
PSP LU
PSP non-LU
Autre
Code ISO du pays de
destination
Volume
Valeur
Devise de la
transaction
Code ISO de la
devise
Définition des concepts utilisés dans le sous tableau V1.2.1 Virements interbancaires émis :
Ce sous-tableau est à renseigner par les établissements qui agissent en tant que banque DNO.
18
19
Les établissements n’utilisant pas la messagerie Swift choisiront, en coordination avec la BCL, un critère équivalent.
Les domiciliations interbancaires sont à rapporter dans le sous-tableau V1.3.1 Domiciliations legacy
26
- Définition du concept de banque DNO :
De manière générale dans la présente collecte, est considéré comme banque DNO l’établissement qui émet des
instructions de paiements dans un système ou qui, le cas échéant, les transmet à son PSP en vue d’exécuter ces
paiements.
Le canal de règlement renseigne sur le système ou le mode utilisé par la BQE DNO pour exécuter le paiement.
o
En cas de connexion à un système de paiement permettant l’exécution du paiement dans cette devise:
1) Si la BQE DNO utilise ce système pour exécuter le paiement, le nom de celui-ci sera indiqué. Les
valeurs possibles sont : TARGET, Euro1, Step1, EQUENS, Autre.
2) Si la BQE DNO, bien que connectée à ce système de règlement, opte plutôt pour l’exécution du
paiement dans ses livres en raison de l’existence d’une relation de compte avec l’établissement
destinataire du paiement, le canal de règlement à renseigner sera Relation Nostro/Loro.
o
devise:
Que la BQE DNO utilise un intermédiaire pour l’exécution du paiement ou que le règlement se
fasse dans ses livres en raison de l’existence d’une relation de compte nostro/loro avec la banque
destinataire, le canal de règlement à renseigner sera toujours « PSP ».
Une distinction est à faire entre les transactions traitées par des correspondants établis au
Luxembourg (PSP LU) et ceux établis à l’étranger (PSP non-LU).
Les valeurs possibles sont donc : PSP LU ou PSP non-LU.
- Pays de destination de la banque bénéficiaire :
Le pays de destination renseigne sur le pays de la banque du bénéficiaire dans le cas d’un virement émis. C’est
le pays de la banque du bénéficiaire, qui doit être renseigné et non pas le pays de la /des banque(s)
intermédiaire(s) éventuelle(s).
Valeur possible : le pays de destination, identifié par le code ISO correspondant (Code ISO 3166 à deux
lettres).
- Volume :
Le volume est un indicateur quantitatif désignant le nombre de transactions.
- Valeur :
27
de transactions.
28
à rapporter.
Sous –tableau V 1.2.2 : Virements interbancaires reçus (paiements reçus par la banque BEN) :
Type instrument
paiement
Canal de
règlement
Pays d’émission de la banque
donneur d’ordre
Virement
TARGET
Euro1
Step1
EQUENS
Relation Nostro /
Loro
PSP LU
PSP non-LU
Autre
Code ISO du pays d’émission
Volume
Valeur
Devise de la
transaction
Code ISO de la
devise
Définition des concepts utilisés dans le sous tableau V1.2.2 Virements interbancaires reçus :
Ce sous-tableau est à renseigner par les établissements qui agissent en tant que banque BEN.
- Définition du concept de banque BEN :
De manière générale dans la présente collecte, est considéré comme banque BEN l’établissement qui reçoit un
paiement, soit directement via un système de paiement dans lequel il est connecté, soit via son PSP.
La BQE BEN renseigne le canal de règlement, c.à.d le système ou le mode utilisé pour exécuter le paiement.
o
En cas de connexion au système de paiement utilisé par la banque émettrice pour exécuter le
paiement ou (dans le nostro/loro) en cas de connexion à un système de règlement permettant
l’exécution du paiement dans cette devise:
29
1) Si ce système de règlement a été utilisé pour exécuter le paiement, le nom de celui-ci sera indiqué.
Les valeurs possibles sont : TARGET, Euro1, Step1, EQUENS, Autre.
2) Si, bien que la BQE BEN soit connectée à un système de règlement dans la devise considérée,
l’exécution du paiement a été faite via une relation de compte avec l’établissement émetteur du
paiement, le canal de règlement à renseigner sera Relation Nostro/Loro.
o
devise:
Que la BQE BEN soit passée par un intermédiaire pour l’exécution du paiement ou qu’elle ait réglé
le paiement via une relation de compte nostro/loro , le canal de règlement à renseigner sera « PSP ».
Une distinction est à faire entre les transactions traitées par des correspondants établis au
Luxembourg (PSP LU) et ceux établis à l’étranger (PSP non-LU).
Les valeurs possibles sont donc : PSP LU ou PSP non-LU.
- Le pays d’émission de la banque du donneur d’ordre :
Le pays d’émission renseigne sur le pays de la banque du donneur d’ordre ayant émis une instruction de
paiement dans le cas d’un virement reçu. C’est le pays de la banque du donneur d’ordre qui doit être renseigné
et non pas le pays de la/des banque(s) intermédiaire(s) éventuelle(s).
Valeur possible : le pays d’émission, identifié par le code ISO correspondant (Code ISO 3166 à deux lettres)
- Volume :
- Valeur :
de transactions.
à rapporter.
30
Sous –tableau V 1.2.3 : Virements interbancaires intermédiés (paiements envoyés et reçus par les PSP) :
Type
instrument
paiement
Type
client
Canal de
règlement
Sens de
l’opération
Pays
d’émission
de la
banque
donneur
d’ordre
Pays de
destination
de la
banque
bénéficiaire
Virement
Banque
LU
Banque
non-LU/
TARGET
Euro1
Step1
EQUENS
Relation Nostro /
Loro
PSP LU
PSP non-LU
Autre
Emis
Reçu
Code ISO
du pays
d’émission
Code ISO du
pays de
destination
Volume
Valeur
Devise de la
transaction
Code ISO
devise
Définition des concepts utilisés dans le sous tableau V1.2.3 Virements interbancaires intermédiés :
Ce sous-tableau est à renseigner par les établissements qui agissent en tant que PSP.
- Définition du concept de PSP:
De manière générale dans la présente collecte, est considéré comme PSP un établissement intermédiaire de la
BQE DNO ou de la BQE BEN, de nature bancaire ou non20 et qui exécute des instructions de paiements dans
un système, ceci pour le compte soit d’une banque DNO dans le cas d’un virement émis soit d’une banque
BEN dans le cas d’un virement reçu.
- Type client :
Le type client permet de mesurer l’intermédiation pour le compte de banques luxembourgeoises de celle pour
le compte de banques non-luxembourgeoises. Le PSP renseignera donc au titre du « Type client » : BQE LU
ou BQE non-LU.
N.B : en cas de règlement via relation de compte nostro/loro : lorsque le PSP est à la fois du côté émis et du
côté reçu (PSP1 et PSP2), celui-ci renseignera les deux transactions, c.à.d la transaction émise (« transaction
side = émis » et la transaction reçue (« transaction side = reçu ») et il précisera quel est le type client (« BQE
LU » ou « BQE non-LU »).
Les valeurs possibles sont : Banque LU ou Banque non-LU.
Le canal de règlement renseigne sur le système ou le mode de règlement du paiement.
20
Exemple : établissement de paiement.
31
o
En cas de connexion par le PSP à un système de paiement permettant l’exécution du paiement dans
cette devise:
1) Si le PSP utilise ce système de règlement pour exécuter le paiement, le nom de celui-ci sera
indiqué. Les valeurs possibles sont : TARGET, Euro1, Step1, EQUENS, Autre.
2) Si, bien que le PSP soit connecté à un système de règlement dans la devise considérée, l’exécution
du paiement a été faite via une relation de compte, le canal de règlement à renseigner sera Relation
Nostro/Loro.
o
En cas de non-connexion par le PSP à un système de paiement permettant l’exécution du paiement
dans cette devise:
Les valeurs possibles sont: PSP LU ou PSP non-LU, conformément à la convention explicitée au
paragraphe 4.1.3.
- Le sens de l’opération concerne uniquement les sous-tableaux dédiés aux virements intermédiés. Il permet
de distinguer les virements émis des virements reçus dans le système et donc de mesurer l’activité des PSP
dans ces systèmes. Les valeurs possibles sont « émis » ou « reçu ».
- Le pays d’émission / de réception renseigne sur le pays de la banque du donneur d’ordre ayant émis une
instruction de paiement dans le cas d’un virement reçu, respectivement sur le pays de la banque du bénéficiaire
dans le cas d’un virement émis. Ce sont les pays de la banque du donneur d’ordre, respectivement de la banque
du bénéficiaire, qui doit être renseigné et non pas le pays des banques intermédiaires.
Valeur possible : le pays d’émission, respectivement le pays de réception, identifié par le code ISO
correspondant (Code ISO 3166 à deux lettres).
- Volume :
- Valeur :
de transactions.
à rapporter.
32
4.3
Tableau V 1.3 : Domiciliations
-
Une domiciliation est un virement initié par le créancier.
-
Deux types de domiciliations existent ; les domiciliations legacy (sous-tableau V1.3.1) et les
domiciliations SEPA (sous-tableaux V1.3.3 et V 1.3.5). Les flux d’informations sont différents dans
ces deux types de domiciliations.
o
Dans les domiciliations de type legacy, la banque du créancier n’est pas impliquée dans le flux
d’informations21, seule la banque du débiteur renseigne les domiciliations (ou demandes
d’encaissements). Le reporting des domiciliations legacy ne couvre pas les « opérations de
type R22 ».
Dans les domiciliations de type legacy, seront renseignées les demandes débit nettes, c.à.d. les
demandes de débit auxquelles la banque du débiteur peut donner suite (collection qui ont pu
être honorées). Les rejets ne sont donc pas inclus.
o
Dans les domiciliations de type SEPA (SDD), le flux d’informations passe par la banque du
créancier. Dans les domiciliations SEPA, les deux banques effectuent un reporting (en tant que
banque du débiteur et en tant que banque du créancier), respectivement dans le sous-tableau
Domiciliations SEPA-Banque du débiteur et dans le sous-tableau Domiciliations SEPABanque du créancier.
Dans les domiciliations de type SEPA, il s’agit de demandes de débit brutes. Le reporting des
domiciliations de type SEPA couvre les « opérations de type R »
-
Les domiciliations interbancaires sont également à renseigner dans le tableau des domiciliations legacy
et sont collectées sur base des messages SWIFT MT 204
-
Le règlement du solde des cartes de paiement : dans le cas où la distinction peut être faite entre une
demande de débit traditionnelle et une opération de règlement du solde de carte bancaire de paiement,
celle-ci est à renseigner séparément dans le sous-tableau V1.3.2 y dédié. Dans le cas où cette
distinction ne peut être faite, le règlement du solde des cartes de paiement est donc inclus dans le soustableau V1.3.1 dédié aux domiciliations legacy ou dans le sous-tableau V1.3.3 dédié aux SDD.
Le règlement de cartes de crédit qui se fait par une demande de débit traditionnelle23 est à renseigner
dans le sous-tableau V1.3.1 ou dans le sous-tableau V1.3.3 dédié aux SDD.
21
Pour la banque du créancier, c’est un paiement entrant, sans pouvoir identifier qu’il s’agit d’une domiciliation.
Opération de type R ou R-transaction = Refund, Reject etc….
Pour les domiciliations legacy, les banques ne gardent pas d’information aisément exploitables dans leurs systèmes
informatiques pour les opérations de type R.
22
23
Exemple : AMEX
33
4.3.1 Sous –tableau V 1.3.1 : Domiciliations legacy
Type instrument
paiement
Canal de transmission
Canal de règlement
Demandes de débit
DOM
TARGET, Euro1, Step1, Step
2, On-us, Relation Nostro/Loro,
PSP LU, PSP non-LU, Autre
Bilatéral
Domiciliations interbancaires
Volume
Valeur
Devise de la
transaction
Code ISO de
la devise
Autre
4.3.2 Sous –tableau V 1.3.2 : Règlement du solde des cartes de paiement
Type instrument
paiement
Canal de règlement
Règlement de solde
carte
N/A
On-us
Autre
Volume
Valeur
Devise de la
transaction
Code ISO de
la devise
4.3.3 Sous –tableau V 1.3.3 : SEPA Direct Debit transactions (reporting en tant que Banque du
débiteur)
Instrument
de
paiement
Catégorie client
Schema
SDD
Canal de
règlement
Demande
de débit
- Etablissement de crédit
[IFM]
- Fonds monétaires
[IFM]
- Autres IFMs [IFM]
Core
B2B
TARGET,
Euro1, STEP1,
STEP2,
EQUENS, onus, NOLO, PSP
LU, PSP NLU,
Autre
- Fonds non-monétaires
[non- IFM]
- Autres non IFMs [nonIFM]
Pays de la
banque du
créancier
Code ISO
du pays
Volume
Valeur
Devise de la
transaction
Code ISO de
la devise
(- Inconnu)
remarque: les demandes de débit concernant le règlement du solde des cartes de crédit pour lesquelles l’agent rapporteur n’est ni
l’émetteur ni le distributeur (ex : AMEX) sont à rapporter dans ce tableau. En effet, l’agent rapporteur n’est pas en mesure de les
identifier comme des règlements de solde de carte de crédit.
34
4.3.4 Sous-tableau V 1.3.4 :R-transactions – SEPA Direct Debit (reporting en tant que Banque
du débiteur)
Type Rtransaction
Catégorie client
Schema
SDD
Canal de
règlement
Reject, Return
Reversal,
Refund
Request for
cancellation,
- Etablissement de
crédit [IFM]
- Fonds monétaires
[IFM]
- Autres IFMs [IFM]
- Fonds nonmonétaires [nonIFM]
- Autres non IFMs
[non-IFM]
- Inconnu
Core
B2B
TARGET,
Euro1,
STEP1,
STEP2,
EQUENS, onus, NOLO,
PSP LU, PSP
NLU, Autre
Volume
Pays de la banque
du créancier
Valeur
Devise de la
transaction
Code ISO de
la devise
4.3.5 Sous –tableau V 1.3.5: SEPA Direct Debits transactions (reporting en tant que Banque du
créancier)
Type
Instrument
de paiement
Catégorie client
Schema
SDD
Demande de
débit
- Etablissement de
crédit [IFM]
- Fonds monétaires
[IFM]
- Autres IFMs [IFM]
- Fonds nonmonétaires [nonIFM]
- Autres non IFMs
[non-IFM]
(- Inconnu)
Core
B2B
Mode
d’initiation
Electronic File batch
Electronic Single
Canal de
règlement
Pays de
la banque
du
débiteur
TARGET,
Euro1,
STEP1,
STEP2,
EQUENS,
on-us,
NOLO, PSP
LU, PSP
NLU, Autre
Code ISO
de la
devise
Volume
Valeur
Devise de la
transaction
Code ISO de
la devise
Les transactions on-us sont à renseigner uniquement dans le cas où l’agent rapporteur est dans la capacité de le faire.
4.3.6 Sous –tableau V 1.3.6: R-transactions - SEPA Direct Debits (reporting en tant que
Banque du créancier)
Type Rtransaction
Catégorie client
Schema
SDD
Canal de
règlement
Reject (*),
Return
Reversal,
Refund
Request for
cancellation
- Etablissement de crédit
[IFM]
- Fonds monétaires
[IFM]
- Autres IFMs [IFM]
- Fonds non-monétaires
[non- IFM]
- Autres non IFMs [nonIFM]
- Inconnu
Core
B2B
TARGET,
Euro1, STEP1,
STEP2,
EQUENS, on-us,
NOLO, PSP LU,
PSP NLU, Autre
Pays de la
banque du
débiteur
Volume
Valeur
Devise de la
transaction
Code ISO de
la devise
(*) Sont à exclure du reporting les messages pacs. 002 générés par le CSM vers la Creditor Bank.
Les transactions on-us sont à renseigner uniquement dans le cas où l’agent rapporteur est dans la capacité de le faire.
35
Définition des concepts utilisés dans les sous-tableaux relatifs aux domiciliations:
Le type d’instrument :
Cette colonne concerne les sous-tableaux V1.3.1, V1.3.2, V1.3.3 et V1.3.5 uniquement.
Les valeurs possibles:
-
Sous-tableau V1.3.1 : Demande de débit (net)
-
Sous-tableau V1.3.2 : Règlement de solde carte
-
Sous-tableau V1.3.3 : Demande de débit
-
Sous-tableau V1.3.5 : Demande de débit
Le type de R-transaction :
Cette colonne concerne les sous-tableaux V1.3.4 et V1.3.6 uniquement.
Les valeurs possibles sont: Reject, Return, Reversal, Refund, Request for cancellation
7
36
- Catégorie client :
La catégorie client vise à apporter une granularité supplémentaire selon que le client soit de type « Institution
Financière Monétaire (IFM) » ou « non-Institution Financière Monétaire (non-IFM) ».
non-IFM, Inconnu.
- Mode initiation :
Le mode d’initiation, qu’il est demandé de reporter dans le sous-tableau V1.3.5, renseigne sur la façon dont les
domiciliations SDD ont été initiées par les créanciers.
Domiciliation/prélèvement automatique initié dans un fichier/lot (« Electronic - File batch ») : il
s’agit d’une domiciliation (prélèvement automatique) initiée par voie électronique et faisant partie
d’un groupe de domiciliations initiées ensemble par le créancier. Chaque domiciliation comprise dans
un lot est recensée comme une domiciliation distincte lors de la déclaration du nombre d’opérations.
« Electronic - Single » : il s’agit d’une domiciliation (prélèvement automatique) initiée par voie
électronique et qui est indépendante d’autres domiciliations, c’est-à-dire qui ne fait pas partie d’un
groupe de domiciliations initiées ensemble.
Les valeurs possibles sont: Electronic - File batch, Electronic - Single
Remarque : Les domiciliations sont majoritairement initiées en lots (file batch). Dans le cas où l’agent
rapporteur n’est pas en mesure de faire la distinction entre une initiation sur la base d’un paiement unique
ou en lot, la possibilité lui est accordée de rapporter toutes les transactions en tant que « Electronic-file
batch ».
- Schema SDD : cette colonne concerne les domiciliations SEPA uniquement (sous-tableaux V1.3.3 à V1.3.6).
Elle renseigne sur le schéma SDD, conformément aux règles de l’EPC.
Les valeurs possibles sont : Core ou Business to Business (B2B).
- Le canal de transmission désigne le canal utilisé pour transmettre les instructions de paiement. Ce n’est pas
un système de règlement.
Cette colonne concerne les sous-tableaux V1.3.1 et V1.3.2.
37
Les valeurs possibles:
-
Sous-tableau V1.3.1 : Domiciliations legacy : les valeurs possibles sont « DOM » (= système de
domiciliation national géré par le CETREL), « Bilatéral » en cas de relation bilatérale entre le
créancier et la banque du débiteur), « Domiciliation interbancaire » (si le virement est un MT204) ou
« Autre » (cas de transactions on-us ou des opérations de compte nostro/loro).
-
Sous-tableau V1.3.2 : Règlement du solde des cartes de paiement : le montant du règlement du solde
carte est fourni par l’opérateur technique à l’agent rapporteur. La valeur à renseigner est : N/A.
- Le canal de règlement est le système par lequel l’établissement effectue son paiement.
o
Si l’établissement injecte le paiement dans un système, le nom de celui-ci sera indiqué (ex: Step2).
o
Si les deux comptes bancaires concernés par le paiement sont détenus auprès du même établissement,
le canal de règlement à renseigner est « on-us ». Seuls les paiements on-us émis sont à renseigner.
Dans le cas où la BQE DNO et la BQE BEN sont distinctes et en l’absence de système de règlement
ou d’ACH, le canal de règlement est Relation nostro/loro.
o
Les banques utilisant une banque intermédiaire indiqueront « PSP ». Une distinction est à faire entre
les transactions traitées par des correspondants établis au Luxembourg (PSP LU) et ceux établis à
l’étranger (PSP non LU).
Les valeurs possibles
-
Sous-tableau V1.3.1 « Domiciliations legacy » : les valeurs possibles sont TARGET, Euro1, Step1,
Step2, on-us, PSP LU, PSP non LU, Autre et Relation Nostro/Loro.
-
Sous-tableau V1.3.2 « Règlement du solde des cartes de paiement » : l’encaissement se fait dans la
majorité des cas en « on-us » sur le compte du détenteur auprès de la banque émettrice de la carte. La
valeur à renseigner est : on-us.
-
Sous-tableau V1.3.3 à V1.3.6 : les valeurs possibles sont TARGET, Euro1, Step1, Step2, EQUENS,
on-us, PSP LU, PSP non LU, Autre et Relation Nostro/Loro.
- Pays de la banque du créancier / Pays de la banque du débiteur : ces colonnes concernent les
domiciliations SEPA uniquement (sous-tableaux V1.3.3 à V1.3.6). Elles renseignent sur le pays de la banque
du créancier ayant émis une instruction de paiement SDD, respectivement sur le pays de la banque du débiteur
ayant reçu une instruction de paiement SDD.
- Volume : indicateur quantitatif désignant le nombre de transactions
- Valeur : indicateur quantitatif désignant la valeur, dans la devise du capital, correspondant au volume de
transactions.
38
laquelle la transaction a été réalisée. Toutes les devises, dans lesquelles des transactions ont été effectuées, sont
à rapporter.
4.4
Tableau V 1.4 : Inventaire des cartes de paiement & des terminaux acceptant
des cartes de paiement
4.4.1 Sous-tableau V 1.4.1: Inventaire des cartes de paiement
Emission de
cartes /
Distribution de
cartes
EMISSION
Type d’instrument de paiement
Schéma
Cartes de débit
Maestro
Vpay
China
UnionPay
Autre
Visa
Mastercard
Diner’s Club
American
Express
JCB 27
China
UnionPay
Autre
Visa
Mastercard
Autre
Cartes de crédit ou ayant une fonction de
débit différé
Cartes mixte (débit et crédit)
Volume
clients24
Volume
parties
tierces 25
Pays 26
Float
N/A
N/A
N/A
24
Activité d’émission de cartes: le volume se réfère au nombre de cartes émises aux clients de l’établissement émetteur de ces cartes..
Activité de distribution de cartes: le volume se réfère au nombre de cartes distribuées aux clients de l’établissement distributeur de ces cartes.
Activité d’émission de cartes: le volume se réfère au nombre de cartes émises à des clients d’entités tierces (i.e.: distributeurs)
Activité de distribution: N/A
26
Activité d’émission de cartes: le pays se réfère au pays du distributeur (entité tierce).
Activité de distribution de cartes : le pays se réfère au pays de l’émetteur.
27
JCB = Japan Credit Bureau
25
39
Cartes prépayées (affiliées à un schéma de
carte)
« One-off cards »
Cartes permettant l’accès à de la monnaie
électronique stockée sur un compte de
monnaie électronique sur réseau
Autres cartes
Cartes de débit
Cartes de crédit ou ayant une fonction de
débit différé
DISTRIBUTION
Cartes mixte (débit et crédit)
Cartes prépayées
(affiliées à un schéma de carte)
« One-off cards »
Cartes permettant l’accès à de la monnaie
électronique stockée sur un compte de
monnaie électronique sur réseau
Autres cartes
Visa
Mastercard
China
UnionPay
Autre
Visa
MasterCard
JCB
Propriétaire
Autre
Visa
MasterCard
JCB
Autre
Visa
MasterCard
JCB
Autre
Maestro
Vpay
China
UnionPay
Autre
Visa
Mastercard
Diner’s Club
American
Express
JCB
China
UnionPay
Autre
Visa
Mastercard
Autre
Visa
Mastercard
China
UnionPay
Autre
Visa
MasterCard
JCB
Propriétaire
Autre
Visa
MasterCard
JCB
Autre
Visa
MasterCard
JCB
Autre
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
4.4.2 Définition des concepts utilisés dans le sous-tableau V1.4.1
- Ce tableau consiste en un inventaire des cartes de paiement actives en circulation suivantes : cartes de débit,
cartes de crédit, cartes mixtes, cartes prépayées. Une distinction est faite entre les cartes émises et les cartes
distribuées.
40
- Une carte active est une carte permettant d’effectuer des transactions de paiement et respectant les critères
suivants : la carte n’est pas expirée, le contrat lié à la carte n’a pas été résilié et la carte n’a pas été bloquée de
manière définitive.
- Emetteur de cartes / activité d’émission de cartes (card issuing bank):
L’émetteur de cartes est l’entité qui émet des cartes de paiement sur base soit de sa propre licence28 ou d’une
licence co-marquée.
L’émetteur fournit des cartes à ses propres clients ou aux clients d’autres banques (cardholder bank) qui soustraitent leur activité d’émission de cartes. La colonne « volume clients » renseigne les cartes émises pour ses
propres clients et la colonne « volume parties tierces » reprend les cartes émises pour les clients d’autres
banques ainsi que le pays de ces banques (colonne « pays »).
L’émetteur est l’entité qui couvre le risque financier des cartes émises
- Distributeur de cartes / activité de distribution de cartes (cardholder bank):
Le distributeur de cartes est l’entité qui fournit des cartes de paiement à ses clients sans en être l’émetteur,
cette activité d’émission étant sous-traitée à un émetteur de cartes. La colonne « volume clients » renseigne les
cartes que l’agent rapporteur met à disposition de ses clients. Il indique dans la colonne « pays » le pays
d’origine de l’émetteur des cartes.
- Le type d’instrument de paiement est : cartes de débit, cartes de crédit ou carte ayant une fonction de débit
différé, cartes mixtes, cartes prépayées (affiliées à un schéma de carte), cartes permettant l’accès à de la
monnaie électronique stockée sur un compte de monnaie électronique.
Définition des différents types de cartes :

Carte de débit : carte permettant que les achats effectués par son porteur soient directement et
immédiatement portés au débit de son compte.
Une carte ayant une fonction de débit peut être associée à un compte permettant les découverts, à titre
accessoire. Le nombre de cartes ayant une fonction de débit représente le nombre total de cartes en circulation
et non le nombre de comptes auxquels les cartes sont rattachées.

Carte de crédit : carte permettant à son porteur d’effectuer des achats et, dans certains cas, de retirer
des espèces à concurrence d’un plafond fixé d’avance. Le crédit accordé peut être remboursé soit
intégralement à la fin d’une période déterminée, soit en partie, le solde étant considéré comme une prorogation
de crédit, généralement porteur d’intérêts. Une carte de crédit peut se présenter sous la forme traditionnelle
(support plastique) ou sous format papier (carte “virtuelle” permettant notamment de réaliser des transactions
de commerce électronique sur internet).

Carte ayant une fonction de débit différé : Carte permettant que les achats effectués par le porteur
de la carte soient portés au débit d’un compte ouvert auprès de l’émetteur de la carte, à concurrence d’un
28
L’activité relative à toutes les licences d’émission doit être renseignée, y compris celles permettant l’émission de cartes à l’étranger.
41
plafond autorisé. Le solde de ce compte est ensuite réglé en totalité à l’expiration d’une période déterminée à
l’avance. Le porteur de la carte doit généralement payer une cotisation annuelle.La différence entre une carte
ayant une fonction de débit différé et une carte ayant une fonction de crédit ou une fonction de débit réside
dans l’accord contractuel conférant une ligne de crédit assortie d’une obligation de régler la dette contractée à
la fin d’une période prédéfinie.

Carte mixte : carte ayant à la fois une fonction de carte de débit et de carte de crédit.

Carte prépayée : carte prépayable et rechargeable conférant à son titulaire la possibilité de retirer
des billets de banque aux GAB ainsi que de payer des biens et des services offerts auprès des commerçants
affiliés au réseau du schéma de carte concerné. Sont uniquement considérés ici les cartes prépayées affiliées à
un schéma de carte. L’activité relative aux cartes prépayées de type cartes cadeaux et utilisables auprès de la
société émettrice uniquement, est exclue de la collecte.
Carte permettant l’accès à de la monnaie électronique sur réseau: carte donnant accès à la

monnaie électronique stockée sur des comptes de monnaie électronique.
Un compte de monnaie électronique est un compte sur lequel est stockée de la monnaie électronique. Le solde
du compte peut être utilisé par le titulaire du compte pour effectuer des paiements et transférer des fonds entre
des comptes. Les cartes permettant le stockage de monnaie électronique sur la puce de la carte sont exclues.
« One-off card » contrairement aux cartes de paiement traditionnelles, qui peuvent être utilisées

jusqu’à une date de fin de validité, les « one-off cards » sont destinées à un usage unique : une « one-off card »
est donc émise pour la réalisation d’une seule transaction et, inversement, pour chaque transaction à réaliser,
une nouvelle « one-off card » est émise. Contrairement à une carte prépayée, une « one-off card » ne peut être
rechargée.
« Autres cartes » : cet intitulé désigne tout autre type de carte que celles énumérées ci-dessus.
- Le schéma désigne le schéma de paiement : Maestro, Vpay, Visa, Mastercard, Diners’Club, American
Express, JCB, China UnionPay, Propriétaire, Autre.
Un schéma peut être qualifié de « propriétaire » lorsque que celui-ci a été conçu pour une utilisation en réseau
fermé, c.à.d sur les appareils et terminaux de l’agent rapporteur uniquement.
- Le volume est un indicateur quantitatif désignant le nombre de cartes en circulation :
o
Le volume clients désigne le nombre de cartes actives émises ou distribuées pour le compte de clients
de l’agent rapporteur.
o
Le volume parties tierces désigne le nombre de cartes actives émises pour le compte de clients non pas
de l’agent rapporteur mais d’une entité tierce.
- Le pays désigne :
-
pour l’activité émission (haut du tableau) le pays de l’entité tierce ou du distributeur.
-
pour l’activité distribution (bas du tableau) le pays de l’émetteur des cartes.
Le pays sera indiqué sous forme de code ISO 3166 à deux lettres.
42
- Le float, qui s’applique aux cartes prépayées uniquement, indique la valeur en circulation, dans la devise du
capital, sur les instruments de paiements concernés à la fin de la période du reporting.
4.4.3 Sous-tableau V 1.4.2: Opérations de (dé)chargement sur cartes prépayées
Type d’instrument
de paiement
Schéma ou
support
Type
d’opération
Cartes prépayées
(affiliées à un
schéma de carte)
Visa / Mastercard /
China UnionPay /
Autre
Chargement
Déchargement
Instrument sous-jacent à
l’origine du chargement /
Destination du
déchargement
Cash
SCT
SDD
Carte de paiement
Autre
Volume
Valeur
Devise de
la
transaction
- Ce tableau recense les opérations de chargement et de déchargement sur cartes prépayées affiliées à un
schéma de carte.
- Le type d’instrument est : Cartes prépayées (affiliées à un schéma de carte)
- Le schéma désigne le schéma de paiement : Visa, Mastercard, China UnionPay, Autre.
- Le type d’opération (cartes prépayées) est chargement ou déchargement
- Opération de chargement/déchargement sur une carte prépayée: transfert de valeur monétaire qui aboutit à
un dépôt, respectivement à un retrait sur la carte prépayée.
- L’origine du chargement et la destination du déchargement permettent d’identifier
→ si l’opération de chargement, a été effectuée par :
en échange d’espèces (Cash)
l’exécution d’un virement ou d’une domiciliation depuis un compte bancaire (SCT ou SDD), que
l’initiation du transfert ait été effectuée à partir d’un service de banque en ligne ou non.
l’intermédiaire d’une carte de paiement (Carte de paiement)
un transfert au moyen d’un autre canal (Autre)
→ si l’opération de déchargement, a été effectuée par :
un retrait en espèces (Cash)
un remboursement sur un compte bancaire (SCT)
un crédit sur une carte de paiement (Carte de paiement)
un transfert au moyen d’un autre canal (Autre)
43
- Le volume est un indicateur quantitatif désignant le nombre d’opérations de chargements et de
déchargements sur les cartes prépayées.
- La valeur : indicateur quantitatif indiquant la valeur, dans la devise du capital, correspondant au volume des
chargements et des déchargements
à rapporter.
4.4.4 Sous-tableau V 1.4.3 : Nombre de terminaux acceptant des cartes de paiement
Type de terminal
Terminal de paiement (POS)
Volume
29
Terminal de retrait (ATM/GAB 30)
Code pays (ISO)
Code ISO du pays du
commerçant
Code ISO du pays d’installation
Dont terminaux de retrait (ATM/GAB) ayant
une fonction de virement
Dont terminaux de retrait (ATM/GAB) ayant
une fonction de chargement/déchargement
Terminal de chargement
Terminal de paiement « e-money»
Définition des concepts utilisés dans le sous-tableau V1.4.3:
Ce tableau reflète le stock relatif aux terminaux (POS, ATM, terminaux de chargement) dont l’agent
rapporteur est propriétaire.
−
Le type de terminal :
Terminal de paiement (POS) : terminal de point de vente (TPV), c.à.d. dispositif d’un point de vente
permettant l’utilisation de cartes de paiement à un point de vente physique (non virtuel). Les informations
relatives au paiement sont enregistrées soit manuellement sur des bons papiers, soit par des moyens
électroniques, c.à.d. sur un terminal de transfert électronique de fonds (TTEF) situé à un point de vente.
Le TPV est conçu pour permettre la transmission d’informations en ligne, avec une demande d’autorisation en
temps réel, et/ou hors ligne.
29
30
POS = Point of Sale
GAB : Guichet Automatique de Banque ; ATM : Automated Teller Machine
44
Terminaux de retraits (ATM/GAB) : Dispositif électromécanique permettant aux utilisateurs autorisés,
généralement en utilisant des cartes physiques lisibles par machine, de retirer des espèces de leur compte et/ou
d’accéder à d’autres services leur permettant, par exemple, de consulter leur solde, de transférer des fonds ou
de déposer de l’argent.
Un dispositif permettant uniquement la consultation de solde ne constitue pas un GAB.
Le GAB peut être utilisé en ligne, au moyen d’une demande d’autorisation en temps réel, ou hors ligne.
Terminaux de retrait (ATM/GAB) ayant une fonction de virements : terminaux de retrait permettant, aux
utilisateurs autorisés, d’effectuer des virements à l’aide d’une carte ayant une fonction espèces.
Terminaux de retrait (ATM/GAB) ayant une fonction de chargement / déchargement : terminaux de retrait
permettant, aux utilisateurs autorisés, de charger ou de décharger une carte prépayée ou une carte servant de
support à de la monnaie électronique.
Remarque concernant le reporting des données relatives aux terminaux de retrait : les rubriques « dont
terminaux de retrait (ATM/GAB) ayant une fonction de virement » et « dont terminaux de retrait (ATM/GAB)
ayant une fonction de chargement/déchargement », ne sont pas des rubriques exclusives, c.à.d. que leur
somme ne correspond pas forcément au nombre total de terminaux de retraits, renseignés sous « Terminal de
retrait (ATM/GAB).
Terminaux de chargement: terminaux dédiés au chargement et au déchargement de cartes prépayées ou de
cartes servant de support à de la monnaie électronique. Ces terminaux sont distincts des terminaux de retrait
(ATM/GAB), sur lesquels des opérations de chargements de cartes prépayées peuvent avoir lieu.
Terminaux de paiement « e-money » : terminaux acceptant des Schéma de Monnaie Electronique (SME) sur
carte, c.à.d. ceux dont la monnaie électronique est stockée sur la puce de la carte (ex : l’ancien SME
« MiniCash »).
- Le volume concerne le nombre de terminaux (POS, ATM, terminaux de chargement).
- L’indication du code pays par le code ISO (Code ISO 3166 à deux lettres) permet de localiser l’emplacement
des différents terminaux.
4.5
Tableau V 1.5 : Transactions cartes (volet issuing)
Type
instrument
paiement
Cartes de débit
Cartes de crédit
ou ayant une
fonction de
Schéma
Type
d’opération
Type de
terminal
Mode
d’acceptation
Pays de
transaction 31
Maestro
ATM
ATM
Chip online
Vpay
Sales
ECO
Chip offline
Manuel Offline
Code ISO du
pays du
commerçant
où a lieu la
transaction
Volume
Valeur
Devise de
la
transaction
Code ISO
de la devise
ATM cash
31
Il s’agit du pays du commerçant et non le pays de l’acquirer
45
débit différé
Visa
deposit
Imprinter
Online
POS
Stronger
customer
authentication 32
Cartes mixtes
Mastercard
Cartes
prépayées
Diners’
Club
Credit
American
Express
Cash advances
at POS
terminalsAutre
Autre
Autre
« One-off
cards »
Cartes
permettant
l’accès à de la
monnaie
électronique
stockée sur un
compte de
monnaie
électronique
sur réseau
Non-connu
JCB
China
UnionPay
Propriétaire
Autre
Autres cartes
Définition des concepts utilisés dans le sous-tableau Tableau V 1.5 : Cartes (volet issuing):
- Ce tableau reflète l’activité réalisée à l’aide de cartes de paiement émises par l’établissement, c.à.d. l’activité
« issuing ».
- Le type d’instrument :
Les valeurs possibles sont : cartes de débit, cartes de crédit ou ayant une fonction de débit différé, cartes
mixtes, cartes prépayées, one-off cards ou cartes permettant l’accès à de la monnaie électronique stockée sur
un compte de monnaie électronique sur réseau.
Pour les définitions, se référer à : Définition des concepts utilisés dans le sous-tableau V1.4.1 page 38
- Le schéma désigne le schéma de paiement : Maestro, Vpay, Visa, Mastercard, Diners’ Club, American
La rubrique Autre comprend tous les autres schémas. Pas de distinction des différents schémas inclus dans
cette rubrique « Autre ».
- Le type d’opération peut être :
32
o
ATM : retrait d’espèces auprès d’un Guichet Automatique de Banque (GAB)
o
33
Sales : opération d’achat payée à l’aide d’une carte de débit/crédit/mixte/prépayée.
Exemple : 3DSecure.
33
La collecte de ces données est transférée au tableau V1.11.
46
o
Credit : opération de remboursement effectuée par le commerçant
o
Cash advances at POS terminals: une avance d’espèce à un terminal de point de vente (TPV) est une
operation lors de laquelle le porteur de la carte obtient des espèces au TPV, cette obtention allant de
pair avec une operation de paiement de biens ou de services. S’il n’est pas possible de distinguer les
données relatives aux advances d’espèces aux TPV, celles-ci sont alors declarées comme des
“operations à un point de vente” (c.à.d “type d’opération = sales” + “type de terminal = POS”)
o
ATM cash deposit: dépôt d’espèces effectué à un GAB à l’aide d’une carte ayant une fonction espèces.
Inclut toutes les opérations pour lesquelles des espèces sont déposées à un terminal, sans intervention
manuelle, et pour lesquelles le payeur est identifié au moyen d’une carte de paiement.
o
Autre
N.B. : Les opérations non-monétaires réalisées à l’aide d’une carte de paiement, comme les demandes de
documents (ex : chèques, virement) ne sont pas inclus dans la présente collecte, celle-ci se limitant aux
opérations de paiement réalisées à l’aide des instruments de paiement.
- Le type de terminal pour effectuer la transaction peut être :
o
ATM : Guichet Automatique de Banque (GAB)
o
ECO : se réfère à des opérations de commerce électronique effectuées à l’aide d’une carte de
débit/crédit/mixte/prépayée.
o
Imprinter : terminal de paiement de type « sabot » ou « ritch ratch ».
o
POS : terminal de paiement électronique
o
Autre : dans cette rubrique sont inclus tous les autres moyens pouvant être utilisés pour effectuer une
transaction. Exemple : téléphone, mail. Le mode d’acceptation sera dans ce cas : manuel.
- Le mode d’acceptation concerne le processus d’acceptation de la transaction. Les différentes valeurs
possibles sont :
o
Offline / Chip offline : L’autorisation du paiement n’est pas basée sur la demande à un centre
d’autorisation. Dans le cas de « Chip offline », la transaction est basée sur la lecture d’une puce.
o
Online / Chip online : L’autorisation de la transaction est basée sur une demande en direct à un centre
d’autorisation. Dans le cas de « Chip online », l’autorisation est basée sur la lecture d’une puce.
o
Manuel : une empreinte de la carte de crédit est prise par un terminal de type « sabot » ou « ritch
ratch ».
o
Stronger customer authentication : l'Authentification forte du client est une procédure basée sur
l'utilisation de deux ou plusieurs des éléments suivants, catégorisés en tant que connaissance,
possession et inhérence:
i) quelque chose que l'utilisateur sait, comme par exemple un mot de passe, un code, un numéro
d'identification personnel statique;
47
ii) quelque chose que l'utilisateur possède, comme par exemple un token, une smart card, un téléphone
mobile;
iii) quelque chose que l'utilisateur est, comme par exemple une caractéristique biométrique ou une
empreinte digitale.
En outre, les éléments sélectionnés doivent être mutuellement indépendants, à savoir la violation de
l'un ne compromet pas l'autre/les autres. Au moins un des éléments doit être non réutilisable et nonreproductible (sauf pour l'inhérence), et non susceptible d'être subrepticement volés via internet. La
procédure d'authentification forte est conçue de façon à préserver la confidentialité des données
d'authentification.
Le mode d’acceptation « Stronger customer authentication » est à renseigner si l’agent rapporteur
dispose de cette information.
o
Autre : tout autre mode d’acceptation.
o
Non-connu : Lorsque l’agent rapporteur n’est pas en mesure de préciser le mode d’acceptation qui
s’est appliqué à la transaction, il pourra renseigner « non-connu » comme mode d’acceptation.
48
- Le pays de transaction, identifié avec le code ISO du pays concerne le pays où la transaction a lieu (Code
ISO 3166 à deux lettres)
- Volume : indicateur quantitatif désignant le nombre de transactions autorisées
- Valeur : indicateur quantitatif désignant la valeur dans la devise du capital correspondant au volume de
transactions.
à rapporter.
4.6
Tableau V 1.6 : Transactions cartes (volet acquiring)
Type
instrument
paiement
Cartes de
débit
Cartes de
crédit ou
ayant une
fonction de
débit
différé
Cartes
mixtes
Cartes
prépayées
Schéma
Type
d’opération
Type de
terminal
Mode
d’acceptation
Pays
d’origine
de carte 34
Pays de la
transaction 35
Maestro
ATM
ATM
Chip online
Vpay
Sales
Visa
ATM cash
deposit
Code ISO
du pays
d’émission
de la carte
ou XX
Code ISO du
pays où a
lieu la
transaction
ou XX
Mastercard
Diners’
Club
American
Express
JCB
China
UnionPay
ECO
Imprinter
POS
Credit
Cash
advances at
POS
terminals
Autre
Chip offline
Manuel
Offline
Volume
Valeur
Devise de
la
transaction
Code ISO
de la devise
Online
Stronger
customer
authentication 36
Autre
Non-connu
Autre
Autre
« One-off
cards »
Cartes
permettant
l’accès à de
la monnaie
électronique
stockée sur
un compte
de monnaie
électronique
sur réseau
34
35
36
Pays de la banque ayant émis la carte de paiement (identifié par le code BIN de la carte).
L’acquisition se faisant depuis un POS, l’information concernant les pays de la transaction permet d’identifier l’activité acquiring luxembourgeoise de l’activité acquiring étrangère.
Exemple : 3DSecure
49
Autres
cartes
Définition des concepts utilisés dans le sous-tableau Cartes (volet acquiring):
- Ce tableau reflète l’activité d’acquisition de cartes de paiement, c.à.d. l’activité « acquiring ».
- Le type d’instrument :
Les valeurs possibles sont : cartes de débit, cartes de crédit ou ayant une fonction de débit différé, cartes
prépayées, cartes mixtes, one-off cards, cartes permettant l’accès à de la monnaie électronique stockée sur un
compte de monnaie électronique sur réseau, autres cartes.
Pour les définitions, se référer à : Définition des concepts utilisés dans le sous-tableau V1.4.1 page 38
- Le schéma désigne le schéma de paiement : Maestro, Vpay, Visa, Mastercard, Diners’ Club, American
- Le type d’opération peut être :
o
ATM : retrait d’espèces auprès d’un Guichet Automatique de Banque (GAB)
o
Sales : opération d’achat payée à l’aide d’une carte de débit/crédit/mixte.
o
Credit : opération de remboursement effectuée par le commerçant
o
Cash advances at POS terminals: une avance d’espèce à un terminal de point de vente (TPV) est une
operation lors de laquelle le porteur de la carte obtient des espèces à TPV cette obtention allant de pair
avec une operation de paiement de biens ou de services. S’il n’est pas possible de distinguer les
données relatives aux advances d’espèces aux TPV, celles-ci sont alors declarées comme des
“operations à un point de vente” (c.à.d “type d’opération = sales” + “type de terminal = POS”).
o
ATM cash deposit: dépôt d’espèces effectué à un GAB à l’aide d’une carte ayant une fonction
espèces. Inclut toutes les opérations pour lesquelles des espèces sont déposées à un terminal, sans
intervention manuelle, et pour lesquelles le payeur est identifié au moyen d’une carte de paiement.
o
Autre
50
- Le type de terminal pour effectuer la transaction peut être :
o
ATM : Guichet Automatique de Banque (GAB)
o
ECO : se réfère à des opérations de commerce électronique effectuées à l’aide d’une carte de
débit/crédit/mixte/prépayée.
o
Imprinter : terminal de paiement de type « sabot » ou « ritch ratch ».
o
POS : terminal de paiement électronique.
o
Autre : dans cette rubrique sont inclus tous les autres moyens pouvant être utilisés pour effectuer une
transaction. Exemple : téléphone, mail. Le mode d’acceptation sera dans ce cas : manuel.
- Le mode d’acceptation concerne le processus d’acceptation de la transaction. Les différentes valeurs
possibles sont :
o
Offline / Chip offline : L’autorisation du paiement n’est pas basée sur la demande à un centre
d’autorisation. Dans le cas de « Chip offline », la transaction est basée sur la lecture d’une puce.
o
Online / Chip online : L’autorisation de la transaction est basée sur une demande en direct à un centre
d’autorisation. Dans le cas de « Chip online », l’autorisation est basée sur la lecture d’une puce.
o
Manuel : une empreinte de la carte de crédit est prise par un terminal de type « sabot » ou « ritch
ratch ».
o
Stronger customer authentication : l'Authentification forte du client est une procédure basée sur
l'utilisation de deux ou plusieurs des éléments suivants, catégorisés en tant que connaissance,
possession et inhérence:
i) quelque chose que l'utilisateur sait, comme par exemple un mot de passe, un code, un numéro
d'identification personnel statique;
ii) quelque chose que l'utilisateur possède, comme par exemple un token, une smart card, un téléphone
mobile;
iii) quelque chose que l'utilisateur est, comme par exemple une caractéristique biométrique ou une
empreinte digitale.
En outre, les éléments sélectionnés doivent être mutuellement indépendants, à savoir la violation de
l'un ne compromet pas l'autre/les autres. Au moins un des éléments doit être non réutilisable et nonreproductible (sauf pour l'inhérence), et non susceptible d'être subrepticement volés via internet. La
procédure d'authentification forte est conçue de façon à préserver la confidentialité des données
d'authentification.
Le mode d’acceptation « Stronger customer authentication » est à renseigner si l’agent rapporteur
dispose de cette information..
o
Autre : tout autre mode d’acceptation.
o
Non-connu : Lorsque l’agent rapporteur n’est pas en mesure de préciser le mode d’acceptation qui
s’est appliqué à la transaction, il pourra renseigner « non-connu » comme mode d’acceptation.
51
-
Le pays d’origine de la carte, identifié par un code ISO (Code ISO 3166 à deux lettres), concerne le pays
d’émission de la carte de débit/crédit.
-
Le pays de la transaction est identifié par un code ISO (Code ISO 3166 à deux lettres). Il concerne le
pays dans lequel la transaction carte a été réalisée.
La mention XX est à utiliser strictement dans le cas où le pays d’origine de la carte et/ou le pays de la
transaction ne peut être renseigné par la banque, cette information n’étant pas disponible.
- Volume : indicateur quantitatif désignant le nombre de transactions autorisées.
transactions.
à rapporter.
4.7
Tableau V 1.7 : Chèques et mandats de paiement
4.7.1 Sous tableau V1.7.1 : Chèques et mandats de paiement émis
Type
instrument
paiement
Pays de réception
Chèque
d’assignation
Chèque (autre)
Mandat de
paiement
Echange bilatéral
On-us
Western Union, Moneygram
Autre
Code ISO du pays de
réception ou XX
Volume
Valeur
Devise de la
transaction
Code ISO de la
devise
4.7.2 Sous-tableau V1.7.2 : Chèques et mandats de paiement reçus
Type
instrument
paiement
Pays d’émission
Chèque
Mandat de
paiement
Echange bilateral, On-us,
Western Union, Moneygram
Autre
Code ISO du pays
d’émission ou XX
Volume
Valeur
Devise de la
transaction
Code ISO de la
devise
52
Définition des concepts utilisés dans le sous-tableau Chèques et mandats de paiement:
- Ce tableau reflète l’activité réalisée à l’aide de chèques et de mandats de paiement.
- Le type d’instrument de paiement est :
o
Sous-tableau V1.7.1 : Chèque d’assignation, chèque (autre), mandat de paiement
o
Sous-tableau V1.7.2 : Chèque ou mandat de paiement
- Mandat de paiement : titre par lequel une personne donne ordre de payer à un tiers une certaine somme en
liquide
- Chèque : moyen de paiement scriptural normalisé avec lequel le titulaire d'un compte donne l'ordre à son
banquier de payer au bénéficiaire du chèque la somme inscrite sur celui-ci.
o
Chèques d’assignation : chèques garantis en utilisation auprès de l’EPT.
o
Chèques (autres) : tous les chèques autres que les chèques d’assignation
Sont exclus de la collecte du volet des chèques : les chèques repas ainsi que les MT103 portant la mention
CHQB, qui étant des virements de clientèle, sont comptabilisés dans les tableaux y dédiés.
- Le canal de transmission est le système par lequel l’établissement effectue son paiement. En ce qui
concerne les chèques, le canal de transmission peut être « échange bilatéral » ou - pour les chèques émis
uniquement - « Transactions on-us ». En ce qui concerne les mandats de paiement, le canal de transmission est
« Western Union », « moneygram » or « autre » (pour les autres schémas).
- Le pays d’émission / de réception renseigne sur le pays de l’établissement ayant émis une instruction de
paiement dans le cas d’une instruction de paiement reçue, respectivement sur le pays de l’établissement ayant
reçu une instruction de paiement dans le cas d’une instruction de paiement envoyée.
Le pays d’émission, respectivement de réception doit être identifié par le code ISO correspondant (Code ISO
3166-1 à deux lettres).
La mention XX est à utiliser strictement dans le cas où le pays d’émission ou de réception ne peuvent être
renseignés par la banque, cette information n’étant pas disponible.
- Volume : indicateur quantitatif désignant le nombre de transactions
transactions.
à rapporter.
53
54
4.8
Tableau V 1.8 : Schéma de Monnaie Electronique (SME) sur réseau
ME = Monnaie électronique
SME : Schéma de Monnaie électronique
4.8.1 Sous-tableau V1.8.1 : Inventaire des schéma de monnaie électronique sur réseau
Type d’inst.paiemt
Schéma de monnaie
électronique (SME)
Type de
support
Niveau
d’activité
Type de compte
/ carte
Volume
Pays de
résidence du
détenteur du
compte
Float
Réseau
Actif
Inactif
Professionnel
Privé
Nombre de
comptes en
ME
Code ISO du
pays du détenteur
du compte en ME
Devise
float
4.8.2 Sous-tableau V1.8.2 : retiré
(LES RUBRIQUES DE CE TABLEAU ONT ÉTÉ TRANSFEREES DANS LE V1.4.3)
4.8.3 Sous-tableau V1.8.3 : Opérations de (dé)chargement en monnaie électronique sur réseau
Type
d’instrument
de paiement
Type de
support
Type
d’opération
Instrument de
paiement sousjacent à
l’origine du
chargement /
Destination du
déchargement
Pays
d’interaction
Pays de
résidence du
détenteur du
compte
Schéma de
monnaie
électronique
(SME)
Réseau
Chargement
Déchargement
Chargement
marchand
Déchargement
marchand
- SCT
- SDD
- Carte de
paiement
Code ISO du
pays
d’émission
ou de
réception
Code ISO du
pays de
résidence du
détenteur du
compte
Volume
Valeur
Devise de
la
transaction
Code ISO
de la devise
Autre
4.8.4 Sous-tableau V1.8.4 : Transferts en monnaie électronique sur réseau
Type
d’instrument
de paiement
Type
de
support
Type de
transfert
Pays du
SME du
débiteur
Pays du
SME du
créancier
Pays de
résidence
du
débiteur
Pays de
résidence
du
créancier
Schéma de
monnaie
électronique
(SME)
Réseau
Purchase
Code ISO du
pays de
Code ISO
du pays
Code ISO
du pays
Code ISO
du pays
Volume
Valeur
Devise de
la
transaction
Code ISO
de la devise
P2P
Inconnu
55
4.8.5 Sous-tableau V1.8.5 : Mode d’initiation des transferts en monnaie électronique sur réseau
Type instrument paiement
Mode d’initiation
Schéma de monnaie
électronique (SME)
Demande de débit en ME initiée par le créancier sur le
compte de ME du débiteur
Volume
Valeur
Devise de la
transaction
Code ISO de
la devise
Cartes permettant d’accéder à de la monnaie
électronique stockée sur un compte de monnaie
électronique
Demande de transfert en ME initiée par le débiteur
depuis son compte de ME
Autre
Définition des concepts utilisés dans le sous-tableau V1.8 relatif aux schéma de monnaie
électronique sur réseau:
- Ce tableau reflète l’activité réalisée en monnaie électronique (ME):
o
Le sous-tableau V1.8.1 est un inventaire des schéma de monnaie électronique (SME) sur support
réseau (« software based »).
o
Le sous-tableau V1.8.2 : l’inventaire des terminaux acceptant des SME a été transféré dans le soustableau V1.4.3.
o
Le sous-tableau V1.8.3 recense les opérations de chargement et de déchargement sur les SME sur
support réseau
o
Le sous-tableau V1.8.4 recense les transferts en ME réalisés sur les SME sur support réseau
(transactions d’achat et opérations P2P37)
o
Le sous-tableau V1.8.5 renseigne sur le mode d’initiation des transferts en ME réalisée sur les SME
sur support réseau.
- Monnaie électronique (ME): valeur monétaire de nature électronique et stockée sur un support, par exemple
de type carte de paiement ou réseau (serveur distant) (voir aussi définition de la Directive 2009/110/CE).
- Schéma de monnaie électronique (SME):
Ensemble de concepts techniques, règles, protocoles, algorithmes, fonctions, accords légaux/contractuels,
accords commerciaux et procédures administratives qui forment la base pour la fourniture d’un
produit/dispositif spécifique en monnaie électronique sur lequel peut être stocké de la monnaie électronique et
avec lequel des paiements peuvent être réglés sans passer par un compte bancaire. Le chargement du
compte/carte en monnaie électronique peut néanmoins être réalisé à partir d’un compte bancaire.
- Le type d’instrument de paiement est : schéma de monnaie électronique (SME).
- Le type de support est réseau («software based»)
37
P2P = Person to Person. Transaction entre deux personnes, en opposition à une transaction commerciale entre un
acheteur et un commerçant.
56
- Le niveau d’activité permet de distinguer les comptes actifs de ceux qui sont inactifs. Un compte en ME est
qualifié d’actif s’ils n’est pas bloqué et si des mouvements ont eu lieu durant les douze mois précédents.
- Le type de compte : indique si le compte est de type professionnel ou non. Les comptes sont dit
professionnels s’ils sont au nom d’un marchand et de type privé pour les autres comptes.
- Le type d’opération :
o
Dans le tableau V1.8.3, le type d’opération permet de distinguer les opérations de chargement des
opérations de déchargement.
De manière générale, il conviendra d’utiliser les rubriques « chargement » et « déchargement » pour
reporter les transactions de chargement, respectivement de déchargement. Lorsque seul le marchand
peut disposer d’un compte de monnaie électronique, et uniquement dans ce cas, il s’agira de reporter
les transactions relatives aux chargements par « chargements marchands » et les transactions relatives
aux déchargements par « déchargements marchands ».
- L’instrument sous-jacent à l’origine du chargement ou destination du déchargement permet d’identifier
si l’opération de chargement ou de déchargement a été effectuée par le biais d’un virement (SCT), d’une
domiciliation (SDD), d’une Carte de paiement ou Autre.
Un compte de monnaie électronique est un compte sur lequel est stockée de la monnaie électronique. Le
solde du compte peut être utilisé par le titulaire du compte pour effectuer des paiements et transférer des fonds
entre des comptes ou être déchargé. Les cartes permettant le stockage direct de monnaie électronique sur la
puce de la carte sont exclues.
-
Le type de transfert indique si la transaction est de type purchase ou P2P.
Pour une transaction dont au moins une des parties est un commerçant professionnel, la valeur est
« Purchase ».
Pour une transaction entre deux particuliers la valeur est « P2P ».
Les agents rapporteurs étant dans l’incapacité de renseigner cette distinction renseigneront la valeur
« Inconnu »
- Le mode d’initiation. Les valeurs possibles sont : Demande de débit en ME initiée par le créancier sur le
compte de ME du débiteur, Cartes permettant d’accéder à de la monnaie électronique stockée sur un compte de
monnaie électronique, Demande de transfert en ME initiée par le débiteur depuis son compte de ME, Autre.
- Le float concerne la valeur (dans la devise du capital) de monnaie électronique disponible sur le SME à la fin
de la période de reporting. Il renseigne plus précisément sur la valeur de monnaie électronique en circulation
dans le circuit économique:
o
Le float de monnaie électronique sur réseau désigne le montant prépayé sur le compte actif de ME.
- La devise du float renseigne la devise du compte sur lequel le float est stocké. La devise du float est
renseigné par le code ISO 4217 à trois lettres.
57
- Le pays de résidence du détenteur du compte: Code ISO du pays de résidence du détenteur du compte de
monnaie électronique.
- Le pays d’interaction :
o
Dans le cas d’une opération de chargement, le pays d’interaction renseigne sur le pays d’où provient
l’argent (Code ISO 3166 à deux lettres).
i. Une opération de chargement réalisée à l’aide d’une carte de paiement peut être identifiée
par le code BIN de la carte.
ii. Une opération de chargement réalisée à l’aide d’un virement ou d’une domiciliation Sepa
peut être identifiée par l’IBAN.
o
Dans le cas d’un déchargement, le pays d’interaction renseigne sur le pays où va l’argent (Code ISO
3166 à deux lettres).
o
- Le pays du SME du débiteur, dans le sous-tableau V1.8.4: code ISO 3166 à deux lettres du pays du
SME du débiteur.
o
- Le pays du SME du créancier, dans le sous-tableau V1.8.4: code ISO 3166 à deux lettres du pays
du SME du créancier.
o
- Le pays de résidence du débiteur, dans le sous-tableau V1.8.4: code ISO 3166 à deux lettres du
pays de résidence du débiteur.
o
- Le pays de résidence du créancier, dans le sous-tableau V1.8.4: code ISO 3166 à deux lettres du
pays de résidence du créancier.
- Volume : indicateur quantitatif
o
Sous-tableau V1.8.1 : le volume désigne le nombre de comptes en monnaie électronique. Ce tableau
recense d’une part le volume de comptes émis pour compte de clients de l’agent rapporteur et d’autre
part le volume émis pour le compte de clients non pas de l’agent rapporteur mais d’une entité tierce.
o
Sous-tableau V1.8.3 à V1.8.5 : le volume désigne le nombre d’opérations respectivement le nombre de
chargements/déchargements, le nombre de transferts en ME et le nombre de domiciliations en ME.
transactions.
à rapporter.
58
- Le type de transfert indique si la transaction est de type purchase ou P2P. Pour une transaction dont au
moins une des parties est un commerçant professionnel, la valeur est « Purchase ». Pour une transaction entre
deux particuliers la valeur est « P2P ». Les agents rapporteurs étant dans l’incapacité de renseigner cette
distinction renseigneront la valeur « Inconnu »
59
4.9
Tableau V 1.9 : Schéma de Monnaie Electronique (SME) sur carte (monnaie
électronique stockée sur la puce de la carte) (NOUVEAU TABLEAU)
4.9.1 Sous-tableau V1.9.1 : Inventaire des SME sur carte (monnaie électronique stockée sur la
puce de la carte)
Type d’inst.paiemt
Type de support
Volume
Float
Schéma de monnaie électronique (SME)
Carte
Nombre de cartes
4.9.2 Sous-tableau V1.9.2 : Inventaire des SME sur carte (monnaie électronique stockée sur la
puce de la carte)
LES RUBRIQUES DE CE TABLEAU SONT COLLECTEES DANS LE SOUS-TABLEAU V1.4.3.
4.9.3 Sous-tableau V1.9.3 : Opérations de (dé)chargement en monnaie électronique sur carte
servant de support à la monnaie électronique
Type d’instrument de
paiement
Type de
support
Type d’opération
Pays d’émission
de la carte
Pays de la
transaction de
(dé)chargement
Schéma de monnaie
électronique (SME)
Carte
Chargement
Déchargement
Code ISO du pays
Code ISO du
pays
Volume
Valeur
4.9.4 Sous-tableau V1.9.4 : Transferts en monnaie électronique depuis une carte servant de
support à la monnaie électronique
Type
d’instrument de
paiement
Type de
support
Type de
transfert
Pays du SME du
débiteur
Pays du SME du
créancier
Schéma de
monnaie
électronique
(SME)
Carte
Purchase
Code ISO du pays
Code ISO du pays
Volume
Valeur
P2P
Inconnu
Définition des concepts utilisés dans le tableau V1.9 relatif aux schéma de monnaie électronique sur
carte:
- Ce tableau reflète l’activité réalisée en monnaie électronique (ME) et dont le support est la puce d’une carte:
o
Le sous-tableau V1.9.1 est un inventaire des schéma de monnaie électronique (SME) dont le support
est la puce de la carte pour lesquels la fonctionalité est activée..
60
o
Le sous-tableau V1.9.2 : l’inventaire des terminaux acceptant des SME, dont le support est la puce
d’une carte, est collecté dans le sous-tableau V1.4.3.
o
Le sous-tableau V1.9.3 recense les opérations de chargement et de déchargement sur des SME dont le
support est la puce d’une carte
o
Le sous-tableau V1.9.4 recense les transferts en ME réalisés sur les SME dont le support est la puce
d’une carte (transactions d’achat et opérations P2P38)
- Monnaie électronique (ME): valeur monétaire de nature électronique et stockée sur un support, par exemple
la puce d’une carte de paiement ou un réseau (serveur distant) (voir aussi définition de la Directive
2009/110/CE).
- Schéma de monnaie électronique (SME):
Ensemble de concepts techniques, règles, protocoles, algorithmes, fonctions, accords légaux/contractuels,
accords commerciaux et procédures administratives qui forment la base pour la fourniture d’un
produit/dispositif spécifique en monnaie électronique sur lequel peut être stocké de la monnaie électronique et
avec lequel des paiements peuvent être réglés sans passer par un compte bancaire. Le chargement du
compte/carte en monnaie électronique peut néanmoins être réalisé à partir d’un compte bancaire.
- Le type d’instrument de paiement est : schéma de monnaie électronique (SME).
- Le type de support indique le type de support sur lequel la monnaie électronique est stockée. Pour le tableau
V1.9, le type de support est « carte ».
N.B. : sont recensées uniquement les cartes sur lesquelles la monnaie électronique est stockée sur la puce
même de la carte. Sont exclues les cartes permettant d’initier une transaction en monnaire électronique dont la
monnaie électronique est stockée ailleurs que sur cette carte. Exemple : stockage sur un compte de monnaie
électronique, sur réseau.
- L’origine du chargement ou destination du déchargement permet d’identifier si l’opération de chargement
ou de déchargement a été effectuée depuis ou vers un Compte bancaire (virement ou domiciliation), via une
Carte de paiement ou d’une Autre façon.
- Le type de transfert indique dans le sous-tableau V1.9.4, si la transaction est de type purchase ou P2P. Pour
une transaction dont au moins une des parties est un commerçant professionnel, la valeur est « Purchase ».
Pour une transaction entre deux particuliers la valeur est « P2P ». Les agents rapporteurs étant dans
l’incapacité de renseigner cette distinction renseigneront la valeur « Inconnu »
- Le float concerne la valeur (dans la devise du capital) de monnaie électronique disponible sur le SME à la fin
de la période de reporting. Il renseigne plus précisément sur la valeur de monnaie électronique en circulation
dans le circuit économique:
38
P2P = Person to Person. Transaction entre deux personnes, en opposition à une transaction commerciale entre un
acheteur et un commerçant.
61
o
Le float de monnaie électronique sur la puce de la carte désigne le montant prépayé sur la puce de la
carte active.
- Le code pays (code ISO 3166 à deux lettres), renseigne sur le pays du commerçant en ce qui concerne les
terminaux de paiement et sur le pays d’installation en ce qui concerne les terminaux de chargement.
- Le pays d’émission de la carte (code ISO 3166 à deux lettres), dans le sous-tableau V1.9.3, renseigne sur le
pays dans lequel la carte servant de support à la monnaie électronique a été émise.
- Le pays de la transaction de (dé)chargement (code ISO 3166 à deux lettres), dans le sous-tableau V1.9.3,
renseigne sur le pays où le chargement, respectivement le déchargement, a été réalisé.
- Le pays du SME du débiteur (code ISO 3166 à deux lettres), dans le sous-tableau V1.9.4, renseigne, dans le
cas d’un transfert reçu, sur le pays du SME du débiteur, c.à.d. sur le pays du SME du donneur d’ordre du
transfert et dont la carte est débitée.
- Le pays du SME du créancier (code ISO 3166 à deux lettres), dans le sous-tableau V1.9.4, renseigne, dans
le cas d’un transfert émis, sur le pays du SME du créancier, c.à.d. sur le pays du SME du bénéficiaire du
transfert et dont la carte est débitée.
- Volume : indicateur quantitatif
o
Sous-tableau V1.9.1 : le volume désigne le nombre de cartes servant de support à de la ME.
o
Sous-tableau V1.9.3: le volume désigne le nombre d’opérations de chargements et de déchargements
en ME sur des cartes servant de support à de la ME.
o
Sous-tableau V1.9.4 : le volume désigne le nombre de transferts réalisés entre deux cartes servant de
support à de la ME.
transactions.
à rapporter.
62
4.10
Tableau V1.10: Nombre de comptes de paiement en monnaie scripturale
(NOUVEAU TABLEAU)
Type de compte
Volume
Compte de paiement
Définition des concepts utilisés dans le sous-tableaux V1.10 Nombre de comptes de paiement en monnaie
scripturale:
-
Type d’établissement:
Il s’agit de l’établissement auprès duquel ont été ouverts les comptes de paiements.
-
Volume:
Le volume est un indicateur quantitatif. Il désigne ici le nombre de comptes de paiement ouverts par l’agent
rapporteur pour ses clients.
Le terme “Compte de paiement” a la même signification que celui défini à l’article 4 de la directive
2007/64/CE.
Dans le sous-tableau V1.10 relatif à la collecte du nombre de comptes de paiements est cependant exclu le
nombre de comptes de monnaie électronique. Le nombre de comptes de monnaie électronique est en effet
collecté séparément dans le sous-tableau V1.8.1.
Pour les établissements de crédit, le nombre de comptes de paiement correspond au nombre de comptes de
depôt à vue transférables. En ce qui concerne la definition de “comptes de dépots à vue transferable”, les
agents rapporteurs se réfèreront à la définition fournie dans les instructions du rapport S3.2 intitulées “Rapport
S3.2 - Informations non-bilantaires” et disponibles sur le site internet de la BCL.
4.11
Tableau V1.11: Opérations en espèces réalisées au guichet de la banque (OTC
cash transactions) (NOUVEAU TABLEAU)
[N.B.: TABLEAU FIGURANT A TITRE INDICATIF. IL SERA FINALISE AVEC LES
AGENTS RAPPORTEURS POUR LA MI-2016]
Type d’opération
Volume
Valeur
Devise de la
transaction
Retraits en espèces (OTC cash withdrawals)
Dépôts en espèces (OTC cash deposits)
Définition des concepts utilisés dans le tableau V1.11 :
-
Type d’opération:
63
Dans ce tableau sont recensées les transactions en espèces réalisées aux guichets des agences de l’agent
rapporteur, c.à.d. les retraits en espèces (OTC cash withdrawals) et les dépôts en espèces (OTC cash deposits).
Remarque: les dépôts en espèces comprennent les versements sur compte propre ainsi que ceux realisés sur les
comptes de tiers.
Les valeurs possible sont: OTC cash withdrawals, OTC cash deposits
-
Volume:
Le volume est un indicateur quantitatif. Il désigne le nombre de nombre de transactions.
-
Valeur:
La valeur est un indicateur quantitative. Il désigne le montant, dans la devise du capital, correspondant au
volume de transactions.
-
Devise de la transaction:
à rapporter.
4.12
Tableau V1.12: Transactions de paiement réalisées au moyen d’un dispositif de
télécommunication, numérique ou informatique (NOUVEAU TABLEAU)
Type d’opération
Transactions de paiement réalisées
au moyen d’un dispositif de
télécommunication, numérique ou
informatique
Sens de
l’opération
Émis
Reçus
Pays
d’émission/
réception
Code iso
Volume
Valeur
Devise de
la
transaction
-
La seule valeur possible est: Transactions de paiement réalisées au moyen d’un dispositif de
télécommunication, numérique ou informatique
64
Cela concerne toutes les opérations de paiement pour lesquelles le consentement du payeur a été donné au
moyen d’un dispositif de télécommunication, numérique ou informatique et pour lesquelles le paiement a été
adressé à l’opérateur du système ou du réseau de télécommunication ou informatique, agissant uniquement en
qualité d’intermédiaire entre l’utilisateur de services de paiement et le fournisseur de biens ou services (PSD,
annexe “services de paiement”, point 7)
-
Sens de l’opération:
Le sens de l’opération permet de distinguer les transactions émises des transactions recues.
Les valeurs possible sont: émis, reçu.
-
Pays d’émission / de réception:
Le pays d’émission renseigne sur le pays de la banque du donneur d’ordre.
Le pays de reception renseigne sur le pays de la banque du bénéficiaire.
Valeurs possibles: le pays d’émission, respectivement de réception, identifié par le code ISO correspondant
(code ISO 3166 à deux lettres).
- Volume:
Le volume est un indicateur quantitatif. Il désigne le nombre de transactions.
-
Valeur:
-
à rapporter.
65
4.13
Tableau V1.13: Crédits effectués sur les comptes de paiement par le biais d’une
simple écriture comptable (book entry) (NOUVEAU TABLEAU)
Catégorie clients
Type d’opération
Volume
Intérêts payés par la banque
Montant des prêts mis à
disposition par la banque à ses
clients en créditant leur
compte courant
Coupons & dividendes payés
par la banque
- Fonds non-monétaires [non-
Vente de titres et rachat de
parts de fonds d’investissement
Autres
- Inconnu
Valeur
Devise de
la
transaction
- Autres IFMs [IFM]
IFM]
-
Le type d’opération:
Les «crédits effectués sur les comptes de paiement par le biais d’une simple écriture comptable (credits to
the accounts by simple book entry) » sont des opérations de crédit, effectuées par la banque (le déclarant)
sur le compte bancaire de ses clients, ceci par le biais d’une écriture comptable et résultant d’un contrat.
Pour l’initiation et l’exécution de ces transactions, aucun instrument de paiement n’est donc utilisé.
Seules les écritures comptables créditrices suivantes sont à reporter :
1. Les intérêts payés par la banque
2. Le montant des prêts mis à disposition par la banque à ses clients en créditant leur compte courant
3. Les coupons & dividendes payés par la banque
4. La vente de titres et le rachat de parts de fonds d’investissement
5. Autres
non-IFM, Inconnu.
66
- Volume:
- Valeur:
-
Devise de la transaction :
à rapporter.
4.14
Tableau V1.14: Débits effectués depuis les comptes de paiements par le biais
d’une simple écriture comptable (NOUVEAU TABLEAU)
Catégorie clients
Type d’opération
Volume
Value
Devise de
la
transaction
Intérêts prélevés par la banque
Frais bancaires prélevés par la
banque
Impôts et taxes relatifs à des actifs
financiers prélevés par la banque
- Autres IFMs [IFM]
- Fonds non-monétaires [non- IFM]
Remboursements par les clients du
montant de prêts
Achat de titres / souscriptions à des
parts de fonds d’investissement
Autres
- Inconnu
67
-
Les « débits effectués depuis les comptes de paiement par le biais d’une simple écriture comptable (debits
from the accounts by simple book entry) » sont des opérations de débit, effectuées par la banque (le
déclarant) sur le compte bancaire de ses clients, ceci par le biais d’une écriture comptable et résultant d’un
contrat. Pour l’initiation et l’exécution de ces transactions, aucun instrument de paiement n’est donc
utilisé.
Seules les écritures comptables débitrices suivantes sont à reporter :
1. Les intérêts prélevés par la banque
2. Les frais bancaires prélévés par la banque
3. Les impôts et taxes relatifs à des actifs financiers prélevés par la banque
4. Les remboursements par les clients du montant de prêts
Remarque : si le remboursement du principal et le paiement des intérêts bancaires sont réalisés de
manière distincte, alors il conviendra de reporter les deux montants dans les rubriques adéquates, c.à.d.
d’une part « remboursement par les clients du montant de prêts » et d’autre part « intérêts prélevés par
la banque ». Dans le cas contraire, le montant global, combinant le remboursement du principal et le
paiement des intérêts, est à reporter sous « remboursement par les clients du montant de prêts »
5. L’achat de titres et de souscriptions à des parts de fonds d’investissement
6. Autres
non-IFM, Inconnu.
68
-
Volume:
-
Valeur:
-
à rapporter.
69
5.
Exemples de reporting – Virements
o
Les exemples de reporting se focalisent sur le reporting des virements de clientèle en raison des
spécificités du reporting relatif à cet instrument de paiement. Le reporting des virements
interbancaires suit une logique identique.
o
Dans les exemples, les tableaux ne sont pas présentés dans leur entièreté. Les champs de
reporting représentés sont les suivants:
1. le type client
2. le canal de règlement
3. le sens de l’opération,
4. le pays d’émission
5. le pays de destination
o Résumé des cas génériques traités dans les exemples:
1. En l’absence d’intermédiation :
DNO -> BQE DNO ->
Règlement :
ACH,
Nostro/Loro
On-us
-> BQE BEN -> BEN
2. En cas d’intermédiation :
DNO -> BQE DNO -> PSP1 ->
Règlement :
ACH,
Nostro/Loro
On-us
-> PSP2 -> BQE BEN -> BEN
70
3. Cas spécifique des opérations pour compte propre :
Exemple
1 : Paiement par une banque du salaire de ses employés ou de factures de ses
fournisseurs
[DNO = BQE DNO] -> BQE DNO -> PSP1->
Règlement :
ACH,
Nostro/Loro
Le DNO (le département Ressources Humaines ou comptabilité de la banque) est une banque qui a
pour particularité d’être également la BQE DNO. La banque effectue un reporting dans son rôle de
BQE DNO.
o
Exemple 2 : Réception du
DNO -> BQE DNO -> PSP1 ->
paiement d’un loyer par un tiers bancaire BEN.
Règlement :
ACH,
Nostro/Loro
-> PSP2 -> BQE BEN -> [BEN = BQE BEN]
On se trouve donc dans le cas où le BEN est une banque qui a pour particularité d’être également la
BQE BEN. La banque effectue un reporting dans son rôle de BQE BEN.
o
Exemple 3: Transmission des instructions de paiement pour compte propre via un canal
spécifique Ex : Multiline
[DNO = BQE] via Multiline
-> BQE DNO ->
Règlement :
ACH,
Nostro/Loro
La banque, qui envoie ses instructions via Multiline, a le rôle de DNO. Elle n’effectue pas de reporting.
71
5.1
Exemple 1: Intermédiation avec règlement du paiement via un ACH:
Hypothèse:
Exécution d’un paiement en Euros
BQE DNO = participant indirect dans STEP2 (donc non-connectée directement à un ACH en euros)
BQE BEN = participant indirect dans STEP2 (donc non-connectée directement à un ACH en euros)
PSP1 = pour la devise Euro, le PSP1 est connecté au système de paiement (ACH) Step2 (participant direct)
PSP2 = pour la devise Euro, le PSP2 est connecté au système de paiement (ACH) Step2 (participant direct)
Toutes les entités sont luxembourgeoises
Reporting à effectuer?
DNO
BQE DNO
PSP1
PSP2
BQE BEN
BEN
ACH
(Step2)
Agent
rapporteur
Virement émis /
reçu / intermédié
Tableau
Type client
Canal
règlement
BQE DNO
Virement émis
V1.1.1
PSP1
Virement intermédié
PSP2
BQE BEN
Sens de
l’opération
Pays
d’émission
de la BQE
DNO
V1.1.3
Banque-LU
STEP2
Emis
LU
V1.1.3
Banque-LU
LU
STEP2
Reçu
LU
LU
Virement reçu
V1.1.2
PSP LU
Pays de
destination
de la BQE
BEN
LU
PSP LU
LU
Remarque concernant le sens de l’opération pour les virements intermédiés:
Il s’agit de raisonner par rapport à l’ACH, respectivement par rapport à l’endroit où le règlement a lieu dans la
chaîne de paiements. Dans l’exemple considéré, il s’agit d’un ACH, Step2:
1) le PSP1 émet un paiement dans Step2, le sens de l’opération est donc “émis”
2) le PSP2 reçoit un paiement dans Step2, le sens de l’opération est donc “reçu”
72
5.2
Exemple 2: Relation “Nostro/Loro”:
5.2.1 En cas d’intermédiation:
Hypothèse:
BQE DNO = non-connectée directement à un ACH en euros
BQE BEN = non-connectée directement à un ACH en euros
PSP1 = connecté à un ACH pour la devise Euro mais le PSP1 règle le paiement via relation Nostro/Loro
PSP2 = connecté à un ACH pour la devise Euro mais règlement du paiement via relation Nostro/Loro
Cas n°1: Règlement entre deux PSP différents
ACH
DNO
BQE DNO
PSP1
PSP2
BQE BEN
BEN
Relation
Nostro/Loro
Le concept de Relation Nostro/Loro dans la
collecte s’applique uniquement à cet endroit de la
chaîne, quand les contreparties optent de ne pas
faire passer une transaction par un ACH.
Agent
rapporteur
Virement émis /
Tableau
Type client
Canal
règlement
Sens de
l’opération
Pays
d’émission
de la BQE
DNO
Pays de
destination
de la BQE
BEN
BQE DNO
Virement émis
V1.1.1
PSP1
PSP LU
-
-
LU
V1.1.3
Banque LU
R.Nostro/Loro
émis
LU
PSP2
LU
V1.1.3
Banque-LU
R.Nostro/Loro
reçu
LU
LU
BQE BEN
Virement reçu
V1.1.2
PSP LU
-
LU
-
73
Remarque concernant le canal de règlement pour les virements intermédiés:
Dans le cas où l’hypothèse de départ pour le PSP1 et le PSP2 avait été:
PSP1 = non-connecté à un ACH pour la devise Euro. Pour régler ce virement, le PSP1 choisit de ne pas passer
par son PSP habituel qu’il a pour cette devise mais plutôt de le régler via la relation de compte Nostro/Loro qu’il
entretient avec le PSP2 (cas exceptionnel).
et
PSP2 = connecté à un ACH pour la devise Euro mais le règlement du paiement via relation Nostro/Loro (ici
l’hypothèse est identique au scenario de depart)
Alors le canal de règlement à renseigner serait:
1) PSP1, canal de règlement = “PSP LU” (et non pas “R. Nostro/Loro”)
2) PSP2, canal de règlement = “R. Nostro/Loro”
Cas n°2: Cas où le PSP de la BQE DNO et de la BQE BEN est le même
Hypothèse (rappel):
BQE DNO = non-connectée directement à un ACH en euros
BQE BEN = non-connectée directement à un ACH en euros
PSP1 = PSP2 ( = PSP dans l’exemple ci-dessous) connecté à un ACH pour la devise Euro mais le PSP règle le
paiement via relation Nostro/Loro
DNO
BQE DNO
PSP
BQE BEN
BEN
Relation
Nostro/Loro
Agent
rapporteur
Virement émis /
Tableau
Type client
Canal
règlement
Sens de
l’opération
Pays
d’émission de
la BQE DNO
BQE DNO
Virement émis
V1.1.1
PSP
PSP
BQE BEN
PSP LU
-
-
LU
V1.1.3
Banque LU
R.Nostro/Loro
émis
LU
LU
V1.1.3
Banque LU
R.Nostro/Loro
reçu
LU
LU
Virement reçu
V1.1.2
PSP LU
-
LU
-
Pays de
destination
de la BQE
BEN
74
5.2.2 En l’absence d’intermédiation:
(
le principe est le même)
Cas n°1: Règlement entre deux banques différentes
Hypothèse:
BQE DNO = connectée directement à un ACH en euros mais règlement via R.Nostro/Loro
BQE BEN = connectée directement à un ACH en euros; règlement via R.Nostro/Loro
ACH
DNO
BQE DNO
BQE BEN
BEN
Relation
Nostro/Loro
Agent
rapporteur
Virement émis /
Tableau
BQE DNO
Virement émis
BQE BEN
Virement reçu
Type client
Canal
règlement
Sens de
l’opération
Pays
d’émission de
la BQE DNO
Pays de
destination de
la BQE BEN
V1.1.1
R. Nostro/Loro
-
-
LU
V1.1.2
R. Nostro/Loro
-
LU
-
75
Cas n°2: Cas où BQE DNO = BQE BEN
DNO
BQE
BEN
On-us
Agent
rapporteur
Virement émis /
Tableau
BQE DNO
Virement émis
BQE BEN
Virement reçu
Type client
Canal
règlement
Sens de
l’opération
Pays
d’émission de
la BQE DNO
Pays de
destination de
la BQE BEN
V1.1.1
On-us
-
-
LU
V1.1.2
On-us
-
LU
-
Virements réglés via le canal de règlement on-us :
la transaction émise et la transactions reçue sont à rapporter
5.3
Exemple 3: Cas de règlement dans une devise étrangère
Exemple de règlement d’un paiement en CHF
Nous référant à l’arbre décisionnel, 4 cas de figure sont possibles.
5.3.1
Cas n°1: Connecté – règlement du paiement dans un ACH
(cas rare: connecté à un système en devise étangère)
Hypothèse:
BQE DNO = BQE LU connectée à un ACH en devise CHF
BQE BEN = BQE non-LU connectée à cet ACH en devise CHF
Règlement du paiement: le paiement est réglé dans ce système de paiement en devise CHF dans lequel BQE
DNO et BQE BEN sont participants directs.
DNO
BQE DNO
BQE BEN
BEN
ACH
Agent
rapporteur
Virement émis / reçu /
intermédié
Tableau
BQE DNO
Virement émis
V1.1.1
BQE BEN
39
Type client
Canal
règlement
Sens de
l’opération
Pays
d’émission
de la BQE
DNO
Pays de
destination de
la BQE BEN
Autre39
-
-
Code ISO du
pays (non-Lu)
PAS DE REPORTING
Le nom de l’ACH en CHF utilisé ne figure pas dans la liste des canaux de règlement proposés dans le présent reporting.
76
*Dans l’hypothèse où la BQE BEN aurait été luxembourgeoise, le reporting aurait été:
5.3.2
Agent
rapporteur
Virement émis / reçu
/ intermédié
Tableau
BQE DNO
Virement émis
BQE BEN
Virement reçu
Type client
Canal
règlement
Sens de
l’opération
Pays
d’émission
de la BQE
DNO
Pays de
destination de
la BQE BEN
V1.1.1
Autre40
-
-
LU
V1.1.2
Autre41
-
LU
-
Cas n°2: Connecté – règlement via une relation de compte Nostro/Loro
Mêmes hypothèses que dans le cas n°1 à la différence que le règlement se fait via relation Nostro/Loro.
DNO
BQE DNO
BQE BEN
BEN
Relation
Nostro / Loro
Agent
rapporteur
intermédié
Tableau
BQE DNO
Virement émis
V1.1.1
BQE BEN
Type client
Canal
règlement
Sens de
l’opération
Pays
d’émission
de la BQE
DNO
Pays de
destination
de la BQE
BEN
R.Nostro/Loro
-
-
Code ISO du
pays (nonLu)
PAS DE REPORTING
* Dans l’hypothèse où la BQE BEN aurait été luxembourgeoise, le reporting aurait été:
Agent
rapporteur
intermédié
Tableau
BQE DNO
Virement émis
BQE BEN
Virement reçu
Type client
Canal
règlement
Sens de
l’opération
Pays
d’émission
de la BQE
DNO
Pays de
destination
de la BQE
BEN
V1.1.1
R.Nostro/Loro
-
-
LU
V1.1.2
R.Nostro/Loro
-
LU
-
** Dans l’hypothèse où la BQE BEN aurait été luxembourgeoise et non-connectée, le reporting aurait été:
Agent
rapporteur
intermédié
Tableau
BQE DNO
Virement émis
BQE BEN
Virement reçu
Type client
Canal
règlement
Sens de
l’opération
Pays
d’émission
de la BQE
DNO
Pays de
destination
de la BQE
BEN
V1.1.1
R.Nostro/Loro
-
-
LU
V1.1.2
PSP LU ou
PSPnon-LU42
-
LU
-
40
42
La réponse est PSP LU ou PSP non-LU en fonction que le PSP usuel de la BQE BEN pour la devise CHF est LU ou
non-LU.
41
77
5.3.3
Cas n°3: Non-connecté – règlement du paiement via un PSP
(Cas plus fréquent pour le règlement en devise: non-connecté)
Hypothèse:
BQE DNO = BQE LU non-connectée à un ACH en devise CHF; passe par un PSP
BQE BEN = BQE non-LU (donc pas de reporting à la BCL) non-connectée à un ACH en devise CHF; passe par
un PSP
PSP1, PSP2 = PSP LU non-connectés à un système de paiement de la devise du paiement; ils passent donc par
leur PSP pour les règlements dans cette devise.
PSP3 & PSP4 = PSP non-LU (donc pas de reporting à la BCL)
DNO
BQE DNO
PSP1
PSP2
PSP3
Agent
rapporteur
intermédié
Tableau
BQE DNO
Virement émis
V1.1.1
PSP1
V1.1.3
PSP2
V1.1.3
Règlement
(1)
Type client
BQE BEN
BEN
PSP4
Canal
règlement
Sens de
l’opération
Pays
d’émission
de la BQE
DNO
Pays de
destination de
la BQE BEN
PSP LU
-
-
Code ISO du
pays (non-Lu)
BQE LU
PSP non-LU
émis
LU
Code ISO du
pays (non-Lu)
BQE nonLU
PSP non-LU
reçu
LU
Code ISO du
pays (non-Lu)
PSP3
PAS DE REPORTING
PSP4
PAS DE REPORTING
BQE BEN
PAS DE REPORTING
(1) Dans cet exemple, la façon dont se fait le règlement entre le PSP3 et le PSP4 est insignifiante (ACH, relation
Nostro/Loro)
Agent
rapporteur
intermédié
Tableau
BQE DNO
Virement émis
V1.1.1
PSP1
V1.1.3
PSP2
V1.1.3
PSP3
Canal
règlement
Sens de
l’opération
Pays
d’émission
de la BQE
DNO
Pays de
destination de
la BQE BEN
PSP LU
-
-
Code ISO du
pays (Lu)
BQE LU
PSP non-LU
émis
LU
Code ISO du
pays (non-Lu)
BQE nonLU
PSP non-LU
reçu
LU
Code ISO du
pays (non-Lu)
-
LU
-
PAS DE REPORTING
PSP4
BQE BEN
Type client
PAS DE REPORTING
Virement reçu
V1.1.2
PSP LU
78
5.3.4
Cas n°4: Non-connecté – règlement via relation de compte Nostro/Loro
Hypothèse:
BQE DNO = BQE LU non-connectée à un ACH en devise CHF; passe par son PSP pour le règlement
d’operations dans cette devise
BQE BEN = BQE non-LU (donc pas de reporting à la BCL) non-connectée à un ACH en devise CHF; passe par
son PSP pour le règlement d’operations dans cette devise
PSP1 = PSP LU
PSP2 = PSP non-LU (donc pas de reporting à la BCL)
PSP1 et PSP2 non-connectés à un système de paiement de la devise du paiement; étant donné qu’ils entretiennent
une relation de compte nostro/loro, ils règlent le paiement via ce biais.
DNO
BQE DNO
PSP1
PSP2
BQE BEN
BEN
Relation
Nostro / Loro
Ce cas étant dans la pratique exceptionnel, il a été convenu de le traiter de façon similaire au cas n°3, c.à.d. que
le canal de règlement à renseigner est “PSP” et non pas “R. Nostro/Loro”
Agent
rapporteur
intermédié
Tableau
BQE DNO
Virement émis
V1.1.1
PSP1
V1.1.3
Type
client
BQE LU
Canal
règlement
Sens de
l’opération
Pays
d’émission
de la BQE
DNO
Pays de
destination de
la BQE BEN
PSP LU
-
-
Code ISO du
pays (non-Lu)
PSP LU ou
PSP nonLU43
émis
LU
Code ISO du
pays (non-Lu)
PSP2
PAS DE REPORTING
BQE BEN
PAS DE REPORTING
Agent
rapporteur
intermédié
Tableau
BQE DNO
Virement émis
V1.1.1
PSP1
V1.1.3
Virement reçu
V1.1.2
PSP2
BQE BEN
43
44
Type
client
BQE LU
Canal
règlement
Sens de
l’opération
Pays
d’émission
de la BQE
DNO
Pays de
destination de
la BQE BEN
PSP LU
-
-
Code ISO du
pays (non-Lu)
PSP LU
ou PSP nonLU44
émis
LU
Code ISO du
pays (non-Lu)
LU
-
PAS DE REPORTING
PSP non-LU
-
La réponse est PSP LU ou PSP non-LU en fonction que le PSP usuel de la BQE DNO pour la devise CHF est LU ou non-LU.
La réponse est PSP LU ou PSP non-LU en fonction que le PSP usuel de la BQE DNO pour la devise CHF est LU ou non-LU.
79
5.4
Exemple 4: Simulation de reporting dans le cas d’une série de paiements divers
Cet exemple couvre divers scenario de paiements dans le but de simuler le reporting des différents agents rapporteurs
concernés.
L’objectif étant ici d’être le plus concret possible, des noms réels de banques ont été utilisés.
Il est à mentionner à cet égard que les différents scenarios de transactions élaborés sont fictifs, et ceci tout
particulièrement en ce qui concerne les relations d’intermédiation liant les différents acteurs.
* Liste de paiements réalisés:
1) DNO -> Fortuna -> Dexia -> Step2 -> BCEE -> BEN (EUR 25’000)
2) Fortuna (= DNO) via Multiline -> Dexia -> Step2 -> BCEE -> Bqe Forêt noire (DE) -> BEN (EUR 18’500)
(Pas de reporting: Bqe Forêt noire)
3) DNO -> Fortuna -> Dexia -> Target -> BGL -> SEB -> BEN (EUR 72’000)
4) DNO -> Fortuna -> Dexia -> City NY ($) -> Nostro/Loro -> Chase NY -> BGL -> SEB -> BEN (Paiement en
USD pour une valeur de EUR 15’000; Dexia et BIL non connectés à un système de paiement)
(Pas de reporting: City NY, Chase NY)
5) DNO -> Dexia -> Target -> ING -> BEN (EUR 125’000)
6) Dexia (=DNO) -> Dexia -> Target -> BGL -> BEN (EUR 375’000)
(hypothèse: le départment Ressources Humaines de Dexia (=DNO) paie des salaires de ses employés pour un
montant EUR375’000))
7) DNO -> ING (on-us) -> BEN (EUR 83)
8) BGL (=DNO) -> BGL -> Step2 -> BCEE -> BEN (EUR 1’500)
(hypothèse: le department Comptabilité de BGL (= DNO) paie une facture d’un fournisseur d’un montant de EUR
1’500)
9) DNO -> EPT -> BCEE -> Step2 -> Deutsche Bank (DE) -> BEN (EUR 3’000)
(Pas de reporting: Deutsche Bank (DE))
10) DNO -> BCEE -> Nostro/loro -> BGL -> BEN (EUR 900)
(hypothèse: BCEE et BGL ont une connexion à un système de paiement en EUR mais choisissent de régler ce
paiement via relation Nostro/Loro)
11) DNO -> PayPal -> ING -> Nostro/loro -> C.Agricole (FR) -> BEN (EUR 1’200)
(hypothèse: ING est connectée à un système de paiement / ACH en EUR mais préfère régler via nostro/loro)
(pas de reporting: C.Agricole (FR))
12) DNO -> BGL -> Nostro/loro -> Dexia -> BEN (EUR 480)
(hypothèse: BGL et Dexia ont une connexion à un système de paiement en EUR mais choisissent de régler ce
paiement via relation Nostro/Loro)
13) DNO -> C.Agricole (FR) -> Nostro/Loro -> ING -> PayPal -> BEN (EUR 1000)
80
(pas de reporting: C.Agricole (FR))
14) DNO -> BDL -> CIAL (FR) -> Step2 -> ING -> PayPal -> BEN (EUR 1500)
(pas de reporting: CIAL (FR))
15) DNO -> Fortuna -> Dexia -> Nostro/Loro -> Dexia -> C. Agricole (FR) -> BEN (EUR 250)
Ou encore : DNO -> Fortuna -> Dexia -> C. Agricole (FR) -> BEN (EUR 250) [Dexia = PSP de Fortuna et de C.
Agricole]
* Reporting des banques concernant ces 15 opérations:
Fortuna
opération
Virement émis /
Tableau
Type
client
Canal
règlement
Sens de
l’opération
Pays
d’émission de
la BQE DNO
1
Virement émis
V1.1.1
2
PAS DE REPORTING (paiement realisé via Multiline)
3
Virement émis
V1.1.1
PSP LU
LU
72’000
4
Virement émis
V1.1.1
PSP LU
LU
15’000
15
Virement émis
V1.1.1
PSP LU
LU
250
opération
Virement émis /
Tableau
Type
client
Canal
règlement
Sens de
l’opération
Pays
d’émission de
la BQE DNO
Pays de
destination de la
BQE BEN
Valeur
(EUR)
1
Virement
V1.1.3
BQE
LU
Step2
Emis
LU
LU
25’000
PSP LU
Pays de
destination de la
BQE BEN
Valeur
(EUR)
LU
25’000
Dexia
intermédié
2
Virement émis
V1.1.1
DE
18’500
3
Virement
V1.1.3
BQE
LU
Target
Emis
LU
LU
72’000
V1.1.3
BQE
LU
PSP non-LU
Emis
LU
LU
15’000
intermédié
4
Virement
intermédié
Step2
5
Virement émis
V1.1.1
Target
LU
125’000
6
Virement émis
V1.1.1
Target
LU
375’000
12
Virement reçu
V1.1.2
R.Nostro/loro
15
Virement
V1.1.3
BQE
LU
R.Nostro/loro
Emis
LU
FR
250
V1.1.3
BQE
nonLU
R.Nostro/loro
Reçu
LU
FR
250
Type
client
Canal
règlement
Sens de
l’opération
Pays
d’émission de
la BQE DNO
Pays de
destination de la
BQE BEN
intermédié
15
Virement
intermédié
LU
480
BCEE
Opération
Virement émis /
Tableau
1
Virement reçu
V1.1.2
2
Virement
V1.1.3
intermédié
8
Virement reçu
V1.1.2
9
Virement
V1.1.3
intermédié
10
Virement émis
V1.1.1
Step2
BQE
nonLU
Step2
LU
Reçu
Step2
BQE
LU
Step2
R.
Nostro/loro
LU
25’000
DE
LU
Emis
LU
Valeur
(EUR)
18’500
1’500
DE
3’000
LU
900
BGL
81
Opération
Virement émis /
Tableau
Type
client
Canal
règlement
Sens de
l’opération
Pays
d’émission de
la BQE DNO
Pays de
destination de la
BQE BEN
Valeur
(EUR)
3
Virement
V1.1.3
BQE
LU
Target
Reçu
LU
LU
72’000
V1.1.3
BQE
LU
PSP non-LU
Reçu
LU
LU
15’000
intermédié
4
Virement
intermédié
6
Virement reçu
V1.1.2
Target
8
Virement émis
V1.1.1
Step2
LU
375’000
10
Virement reçu
V1.1.2
R.
Nostro/loro
12
Virement émis
V1.1.1
R.
Nostro/loro
Opération
Virement émis /
Tableau
3
Virement reçu
V1.1.2
PSP LU
LU
72’000
4
Virement reçu
V1.1.2
PSP LU
LU
15’000
Opération
Virement émis /
Tableau
5
Virement reçu
V1.1.2
Target
7
Virement émis
V1.1.1
On-us
LU
83
7
Virement reçu
V1.1.2
On-us
LU
83
11
Virement
V1.1.3
BQE
LU
R.
Nostro/loro
Emis
LU
FR
1’200
V1.1.3
BQE
LU
R.
Nostro/loro
Reçu
FR
LU
1’000
V1.1.3
BQE
LU
Step2
Reçu
LU
LU
1’500
Type
client
Canal
règlement
Sens de
l’opération
Pays
d’émission de
la BQE DNO
Pays de
destination de la
BQE BEN
Valeur
(EUR)
DE
3’000
Pays de
destination de la
BQE BEN
Valeur
(EUR)
LU
1’500
Pays de
destination de la
BQE BEN
Valeur
(EUR)
LU
LU
1’500
900
LU
480
Pays de
destination de la
BQE BEN
Valeur
(EUR)
SEB
Type
client
Canal
règlement
Sens de
l’opération
Pays
d’émission de
la BQE DNO
ING
intermédié
13
Virement
14
Virement
intermédié
intermédié
Type
client
Canal
règlement
Sens de
l’opération
Pays
d’émission de
la BQE DNO
Pays de
destination de la
BQE BEN
LU
Valeur
(EUR)
125’000
EPT
Opération
Virement émis /
Tableau
9
Virement émis
V1.1.1
Opération
Virement émis /
Tableau
14
Virement émis
V1.1.1
Opération
Virement émis /
Tableau
11
Virement émis
V1.1.1
PSP LU
13
Virement reçu
V1.1.2
PSP LU
FR
1’000
14
Virement reçu
V1.1.2
PSP LU
LU
1’500
PSP LU
BDL
Type
client
Canal
règlement
Sens de
l’opération
Pays
d’émission de
la BQE DNO
PSP non-LU
PayPal
Type
client
Canal
règlement
Sens de
l’opération
Pays
d’émission de
la BQE DNO
FR
1’200
82
6.
Rubrique « Catégorie client »
Definition : IFM et non-IFM
Institutions financières monétaires (IFM) (code: 10000)
[extrait “Définitions et concepts pour le reporting statistique des établissements de credit, BCL”45)
“Le secteur des institutions financières monétaires comprend toutes les sociétés et quasi-sociétés46 financières
exerçant, à titre principal, des activités d’intermédiation financière47 consistant à recevoir des dépôts et/ou de
proches substituts de dépôts de la part d’entités autres que des institutions financières monétaires, ainsi qu’à
octroyer des crédits et/ou à effectuer des placements mobiliers pour leur compte propre.
La Banque centrale européenne met à la disposition des établissements déclarants une liste de toutes les
institutions financières monétaires de l’Union européenne sur son site Internet (http://www.ecb.int ou
http://www.ecb.europa.eu) de façon à leur faciliter la tâche d’identifier correctement leurs contreparties. Cette
liste commune est régulièrement mise à jour par les soins des banques centrales nationales.”
Non – IFM (code: 20000)
Les institutions ne faisant pas partie du secteur des IFM se répartissent en deux groupes, à savoir:
- les administrations publiques (code: 30000)
- les autres secteurs (code: 40000)
45
http://www.bcl.lu/fr/reporting/Etablissements_de_credit/Definitions_Concepts_EDC_2010_FR.pdf
Par quasi-société il faut entendre toute entité économique ayant une comptabilité propre mais étant dépourvue d’une personnalité juridique distincte.
Selon le système européen des comptes nationaux SEC95, l’intermédiation financière est l’activité par laquelle une unité institutionnelle acquiert des actifs financiers et, simultanément, contracte des
engagements pour son propre compte par le biais d’opérations financières sur le marché. Les actifs et passifs des intermédiaires financiers présentent des caractéristiques différentes, ce qui suppose que
dans le cadre du processus d’intermédiation financière, les fonds collectés soient transformés ou regroupés sur la base de critères tels que l’échéance, le volume, le degré de risque, etc. (...) L’activité
d’intermédiation financière consiste à mettre en présence une unité institutionnelle disposant de moyens excédentaires et une autre à la recherche de fonds. L’intermédiaire financier n’est pas simplement
un agent agissant pour le compte de ces unités; il supporte lui-même un risque en acquérant des actifs financiers et en contractant des engagements pour son propre compte (SEC95, §2.32 -33 EUROSTAT
juin 1996).
46
47
83
Table de conversion entre le reporting CDDP et les definitions de la BCL48
Vue d’ensemble
REPORTING CDDP « CATÉGORIE CLIENT »
DÉFINITIONS ET CONCEPTS DE LA BCL (VALABLE POUR D’AUTRES
REPORTINGS DE LA BCL)
⇒ IFM [MFI]
⇒ IFM [MFI]
I. Etablissements de crédit [Credit institutions]
(code: 10000)
I. Etablissements de crédit [Credit institutions] : (code: 11000)
-
Opérations pour compte propre [own account operations]
-
Banques centrales [central banks] (code: 11100)
-
Banques centrales [central banks]
-
Autres établissements de crédit [other credit institutions] (code: 11200)
-
Autres établissements de crédit [other credits institutions] ;
-
OPC monétaires [Money Market Funds (MMFs)] (code: 12100)
-
Autres IFM hors OPC monétaires [other MFIs other than MMFs] (ELMI included) (code: 12200)
II. Fonds monétaires [Money Market Funds]
-
OPC monétaires [Money Market Funds]
II. Autres IFMs : (code: 12000)
III. Other MFIs (ELMI included)
⇒ NON IFM [NON-MFI]
⇒ NON IFM [NON-MFI] (code: 20000)
III. Administrations publiques [General government ] : (code: 30000)
IV. Fonds non-monétaires [Non MFI funds]
Fonds non-monétaires [Funds other than MMFs]
- Administrations publiques centrales [central government] (code: 31000)
- Autres administrations publiques [other general government] : (code: 32000)
● administrations d’Etats fédérés [state government] (code: 32100)
● administrations publiques locales [local government.] (code: 32200)
● administrations de la sécurité sociale [social security funds] (code: 32300)
- Institutions supranationales hors BCE [supranational institutions except ECB] (code: 39000)
IV. Autres secteurs [other sectors] : (code: 40000)
- Secteur financier [financial sector] : (code: 41000)
● les autres intermédiaires financiers et les auxiliaires de l'intermédiation financière et de l'assurance
[other financial intermediaries & financial & insurance auxiliaries] (code: 41100)
+
les autres intermédiaires financiers [other financial intermediaries] (code: 41110)
×
les holdings / Sociétés de participations financières (code: 41111)
[holdings / Soparfis]
+
×
les OPC non monétaires [investment funds] (code: 41112)
×
les véhicules de titrisation [securitsation vehicles] (code: 41113)
×
les contreparties centrales [central counterparties] (code: 41114)
×
les autres intermédiaires [other financial intermediairies] (code: 41119)
les auxiliaires de l'intermédiation financière et les auxiliaires de l'assurance (code: 41120)
[financial and insurance auxiliaries]
V. Autres non IFM
[other non-MFIs] (PI included)
− les sociétés d'assurance et les fonds de pension [Insurance corporations & pension funds] (code: 41200)
+
les sociétés d'assurance [insurance Cies] (code: 41210)
+
les fonds de pension [pension funds] (code: 41220)
N.B : EPT and PI included in other financial intermediairies
- Non financial sector [non financial sector] : (code: 42000)
● les sociétés non financières [non financial corporations] (code: 42100)
● les ménages et institutions sans but lucratif au service des ménages (code: 42200)
[Households & non-profit institutions serving households]
+
les ménages [households] (code 42210)
×
les ménages – entreprises individuelles49(code 42211)
[households - Sole proprietors]
×
les ménages – personnes physiques [households –physical persons]
(code 42212)
+
les institutions sans but lucratif au service des ménages (code: 42220)
[Non-profit institutions serving households]
VI. Unknown
48
Cette table est fournie à titre indicatif. La liste exhaustive de référence demeure le document BCL « Définitions et concepts pour le reporting
statistique des établissements de crédit » régulièrement mis à jour : http://www.bcl.lu/fr/reporting/Etablissements_de_credit/Definitions_Concepts_EDC_2010_FR.pdf
49
Conformément au règlement BCE/2008/32, les entreprises individuelles comprennent également les sociétés de personnes sans personnalité juridique
84
Vue détaillée
[IFM/MFI] Etablissement de crédit [Credit institutions]
[“Définitions et concepts pour le reporting statistique des établissements de credit, BCL”, pages 44-55]
Etablissements de crédit (code: 11000)
Le secteur des établissements de crédit se répartit en deux sous secteurs.
1.
Banques centrales (code: 11100)
Il s'agit notamment de:
•
la Banque centrale européenne (BCE)
•
les banques centrales nationales (BCN)
2.
Autres établissements de crédit (code: 11200)
Il s'agit notamment:
•
des banques commerciales, les banques universelles et les banques à vocation polyvalente
•
des caisses d’épargne
•
des banques et caisses de crédit municipal, rural ou agricole
•
des coopératives de banque, les caisses de crédit mutuel
•
des banques spécialisées telles que les banques d’affaires, des banques qui émettent des lettres de gage, des banques privées
[IFM/MFI] Fonds monétaires [Money Market Funds]
[“Définitions et concepts pour le reporting statistique des établissements de credit, BCL”, page 45]
OPC monétaires (code: 12100)
Il s’agit des organismes de placement collectif tels que les fonds communs de placement monétaires ou des sociétés d’investissement monétaires.
Pour ce qui est des pays membres de l'Union monétaire, il y a lieu de reprendre dans cette catégorie uniquement les fonds d’investissement
monétaires qui figurent sur la liste officielle des institutions financières monétaires que la Banque centrale européenne met à la disposition des
établissements déclarants.
[IFM/MFI] Autres IFM [Other MFIs]
85
[“Définitions et concepts pour le reporting statistique des établissements de credit, BCL”, page 45]
Autres institutions financières monétaires hors OPC monétaires (code: 12200)
Il s’agit des autres institutions financières monétaires qui ne figurent pas sur la liste officielle des organismes de placement collectif monétaires
mais qui sont considérées comme étant des autres institutions financières monétaires.
Pour ce qui est des pays membres de l'Union monétaire, il y a lieu de reprendre dans cette catégorie uniquement les sociétés qui figurent sur la liste
officielle des institutions financières monétaires que la Banque centrale européenne met à la disposition des établissements déclarants.
Etablissements de monnaie électronique inclus
[non-IFM/non-MFI] Fonds non-monétaires [Non-monetary Funds]
OPC non monétaires (code: 41112)
Ce secteur comprend tous les organismes de placement collectif (OPC) tels que les fonds commun de placement (FCP), les sociétés
d'investissement à capital variable et/ou à capital fixe (SICAV et/ou SICAF), les fonds d’investissement spécialisés (FIS) qui peuvent être organisés
sous forme de FCP, SICAV, ou SICAF, etc., qui ne relèvent pas du secteur 12100 «OPC monétaires».
[non-IFM/non-MFI] Autres non-IFM [Other non- MFIs]
1. Les administrations publiques (code: 30000)
1.1 Administration publique centrale (code: 31000)
Le secteur de l’administration publique centrale comprend tous les organismes centraux dont la compétence s’étend normalement sur la
totalité du territoire économique, à l’exception des administrations de sécurité sociale de l’administration centrale.
1.2 Autres administrations publiques (code: 32000)
Il y a lieu de regrouper ici l’ensemble des administrations publiques à l’exception de l’administration publique centrale.
Administrations d’Etats fédérés (code: 32100)
Le secteur des administrations d’Etats fédérés réunit les administrations qui, en qualité d’unités institutionnelles distinctes,
exercent certaines fonctions d’administration à un niveau inférieur à celui de l’administration centrale et supérieur à celui des
unités publiques locales50, à l’exception des administrations de sécurité sociale des administrations d’Etats fédérés.
Administrations locales (code: 32200)
Le secteur des administrations locales rassemble toutes les administrations publiques dont la compétence s’étend seulement sur
une subdivision locale du territoire économique, à l’exception des administrations de sécurité sociale des administrations locales.
Administrations de sécurité sociale (code: 32300)
Le secteur des administrations de sécurité sociale réunit toutes les unités institutionnelles centrales, fédérées et locales dont
l’activité principale consiste à fournir des prestations sociales.
50
De telles administrations sont par exemple les administrations des «Länder» allemands.
86
1.3 Institutions supranationales hors BCE (code: 39000)
Le secteur des institutions supranationales comprend les institutions supranationales telles que les institutions européennes par exemple à
l'exception toutefois de la Banque centrale européenne (BCE).
2. Autres secteurs (code: 40000)
Le secteur des autres intermédiaires financiers ainsi que des auxiliaires de l'intermédiation financière et des auxiliaires de l'assurance regroupe les
secteurs suivants.
2.1 Le secteur financier (code: 41000)
2.1.1
Les autres intermédiaires financiers et les auxiliaires de l'intermédiation financière et auxiliaires de l'assurance (code: 41100)
2.1.1.1 Autres intermédiaires financiers (code: 41110)
Le secteur des autres intermédiaires financiers regroupe toutes les sociétés et quasi-sociétés financières dont la fonction principale consiste à fournir
des services d’intermédiation financière en souscrivant des engagements sous des formes autres que du numéraire, des provisions techniques
d’assurance ou des dépôts et/ou des proches substituts de dépôts provenant d’unités institutionnelles autres que des institutions financières
monétaires.
Holdings / Sociétés de participations financières (code: 41111)
Ce secteur regroupe les sociétés ayant pour objet unique de contrôler et de diriger un groupe de filiales dont l’activité
principale consiste à fournir des services d’intermédiation financière et/ou à exercer des activités financières
auxiliaires.
OPC non monétaires (code: 41112)
Ce secteur comprend tous les organismes de placement collectif (OPC) tels que les fonds commun de placement
(FCP), les sociétés d'investissement à capital variable et/ou à capital fixe (SICAV et/ou SICAF), les fonds
d’investissement spécialisés (FIS) qui peuvent être organisés sous forme de FCP, SICAV, ou SICAF, etc., qui ne
relèvent pas du secteur 12100 «OPC monétaires».
Véhicules de titrisation (code: 41113)
Ce secteur comprend tous les véhicules qui sont constitués pour effectuer des opérations de titrisation.
Une opération de titrisation consiste à transférer des actifs et/ou des risques liés à des actifs à un organisme de
titrisation créé pour émettre des titres adossés à ces actifs.
Contreparties centrales (code: 41114)
Ce secteur comprend tous les organismes centraux de compensation et de règlement qui figurent sur la liste publiée
par le Comité Européen des Superviseurs et Régulateurs (http://mifiddatabase.cesr.eu/).
Autres intermédiaires financiers (code: 41119)
Le secteur des autres intermédiaires financiers regroupe l'ensemble des intermédiaires financiers qui ne sont pas
repris dans les catégories holdings, sociétés de participations financières, OPC non monétaires, véhicules de
titrisation et contreparties centrales.
Pour autant qu’elles ne soient pas des institutions financières monétaires le secteur sous rubrique regroupe
notamment les sociétés et quasi-sociétés financières suivantes:
•
les sociétés de crédit-bail
•
les sociétés exerçant des activités de location-vente, offrant des prêts personnels ou proposant des
•
les sociétés d’affacturage
•
les courtiers en valeurs mobilières et produits financiers dérivés (travaillant pour leur compte propre)
financements commerciaux
•
les sociétés financières spécialisées comme, par exemple, celles proposant du capital-risque, des capitaux
d’amorçage ou des financements des exportations/importations
•
les intermédiaires financiers qui reçoivent des dépôts et/ou des proches substituts des dépôts uniquement de
la part d’institutions financières monétaires
•
les sociétés d'investissement en capital à risque (SICAR)
Au Luxembourg, le service financier de l'Entreprise des Poste et Télécommunications (CCPL) est à inclure dans
cette catégorie.
Etablissements de paiement inclus
87
2.1.1.2 Auxiliaires de l'intermédiation financière et auxiliaires de l'assurance (code: 41120)
Le secteur des auxiliaires financiers comprend toutes les sociétés et quasi-sociétés financières dont la fonction principale consiste à exercer
des activités financières auxiliaires, c’est-à-dire des activités étroitement liées à l’intermédiation financière ou à l’assurance mais n’en faisant
pas partie.
Ce secteur comprend notamment:
•
les courtiers d’assurance, les organismes de sauvetage et d’avarie, les conseillers en assurances et en pension, etc.
•
les courtiers de crédit, les courtiers en valeurs mobilières, les conseillers en placement, etc.
•
les sociétés d’émission de titres
•
les sociétés dont la fonction principale consiste à avaliser des effets et instruments analogues
•
les sociétés qui préparent (sans les émettre) des produits financiers dérivés et des instruments de couverture tels que des
swaps, des options et des contrats à terme
•
les sociétés qui fournissent les infrastructures nécessaires au fonctionnement des marchés financiers
•
les autorités centrales de contrôle des intermédiaires financiers et des marchés financiers lorsqu’elles constituent des
unités institutionnelles distinctes
•
les gestionnaires de fonds de pension, d’organismes de placement collectif, etc.
•
les bourses de valeurs mobilières
•
les institutions sans but lucratif dotées de la personnalité juridique qui servent de sociétés financières, mais qui n’exercent
aucune activité d’intermédiation financière ni aucune activité financière auxiliaire
2.1.2 Sociétés d’assurances et fonds de pension (code: 41200)
Il s’agit de toutes les sociétés et quasi-sociétés financières dont la fonction principale consiste à fournir des services d’intermédiation
financière résultant de la mutualisation des risques.
Sont à inclure également les sociétés d’assurances «captives» et de réassurances.
Les sociétés d'assurances et fonds de pension sont à subdiviser en deux catégories:
Sociétés d’assurances (code: 41210)
Il s’agit de toutes les sociétés et quasi-sociétés financières dont la fonction principale consiste à fournir des services
d’intermédiation financière résultant de la mutualisation des risques.
Sont à inclure également les sociétés d’assurances «captives» et de réassurances.
Fonds de pension (code: 41220)
Cette catégorie inclut tous les fonds de pension autonomes qui sont dotés de l'autonomie de décision et disposent d'une
comptabilité complète.
Au Luxembourg, il s'agit notamment des fonds de pension sous forme de société d’épargne-pension à capital variable (sepcav) et
d’association d’épargne-pension (assep) tels que définis par la loi du 8 juin 1999.
Ne sont pas à inclure les fonds de pension non autonomes.
2.2 Le secteur non financier (code: 42000):
2.2.1
Sociétés non financières (code: 42100)
Le secteur des sociétés (et quasi-sociétés) non financières regroupe les unités institutionnelles dont les opérations de répartition et les
opérations financières sont distinctes de celles de leurs propriétaires et qui sont des producteurs marchands51 dont la fonction principale
consiste à produire des biens et des services non financiers.
Sont concernées les unités institutionnelles suivantes:
•
les sociétés de capital privées et publiques qui sont des producteurs marchands dont la fonction principale consiste à produire des
biens et des services non financiers
•
les sociétés coopératives et les sociétés de personnes dotées de la personnalité juridique qui sont des producteurs marchands dont
la fonction principale consiste à produire des biens et des services non financiers
•
les producteurs publics dotés d’un statut qui leur confère la personnalité juridique qui sont des producteurs marchands dont la
51
Dans la terminologie du SEC95, on entend par production marchande la production écoulée ou destinée à être écoulée
sur le marché.
88
fonction principale consiste à produire des biens et des services non financiers
•
les institutions et associations sans but lucratif au service des sociétés non financières dotées de la personnalité juridique qui sont
des producteurs marchands dont la fonction principale consiste à produire des biens et des services non financiers
•
les quasi-sociétés privées et publiques qui sont des producteurs marchands dont la fonction principale consiste à produire des
biens et des services non financiers
2.2.2
Ménages et institutions sans but lucratif au service des ménages (code: 42200)
Le secteur des ménages et des institutions sans but lucratif au service des ménages regroupe deux secteurs.
Ménages (code: 42210)
Le secteur des ménages comprend les individus ou groupes d’individus tant dans leur fonction de consommateurs que dans celle,
éventuelle, d’entrepreneurs produisant des biens marchands ou des services financiers et non financiers marchands, pour autant
que, dans ce dernier cas, les activités correspondantes ne soient pas le fait d’unités distinctes traitées comme des quasi-sociétés.
Ce secteur inclut également les individus ou groupes d’individus qui produisent des biens et des services non financiers
exclusivement pour un usage final propre.
Le secteur des ménages se subdivise en deux sous-secteurs.
Ménages – Entreprises individuelles (code: 42211)
Le secteur des entreprises individuelles comprend les entreprises individuelles et les sociétés de personnes sans
personnalité juridique (autres que des quasi-sociétés) qui sont des producteurs marchands.
Ménages - Personnes physiques (code: 42212)
Le secteur des personnes physiques comprend:
•
les individus ou groupes d’individus dont la fonction principale consiste à consommer
•
les individus ou groupes d’individus dont la fonction principale consiste à consommer et qui produisent des
biens et des services non financiers exclusivement à un usage final propre
•
les institutions sans but lucratif au service des ménages qui ne sont pas dotées de la personnalité juridique
Le secteur des personnes physiques comprend notamment:
•
les salariés
•
les bénéficiaires de revenus de la propriété
•
les bénéficiaires d’autres revenus et de pensions
Institutions sans but lucratif au service des ménages (code: 42220)
Le secteur des institutions sans but lucratif au service des ménages regroupe les unités dotées de la personnalité juridique qui
servent les ménages et qui sont des autres producteurs non marchands privés. Leurs ressources principales, autres que celles
résultant des ventes occasionnelles, proviennent de contributions volontaires en espèces ou en nature effectuées par les ménages
en leur qualité de consommateurs, de versements provenant des administrations publiques, ainsi que de revenus de la propriété.
89
7.
R-transactions - Définitions
SCT r-transactions:
[extract SCT rulebook]
4.4 Exception Processing Flow
Credit transfer transactions are handled according to the time frame described in section 4.3.1. If, for whatever reason, any party
cannot handle the transaction in the normal way, the process of exception handling starts. The different messages resulting from
these situations are all handled in a standardised way, at process level as well as at dataset level.
A ‘Reject’ occurs when a credit transfer is not accepted for normal execution before interbank Settlement. If the rejection is at the
point at which the Originator instructs the Originator Bank, for the purposes of the Scheme, the Originator Bank need only inform
the Originator of the reason.
If it occurs in the interbank space the Reject must be sent as specified in DS-03 below.
The main characteristics of a reject (DS-03) are:
• the transferred amount will be the Original Amount of the Credit Transfer Instruction
the 'Reject' message is routed through the same path taken by the original credit transfer with no alteration of the data contained in the original
credit transfer
• a record of the relevant data relating to the initial credit transfer, sufficient to provide an audit trail, is included
• the initial credit transfer is identified by the original reference of the Originator Bank
• 'Reject' messages contain a reason code (attribute AT-R3, see below)
'Reject' messages should be transmitted on a same day basis and must at the latest be transmitted on the next Banking Business Day.
A 'Return' occurs when a credit transfer is diverted from normal execution after interbank Settlement, and is sent by the Beneficiary Bank to
the Originator Bank for a credit transfer that cannot be executed for valid reasons such as wrong account number or account closed with the
consequence that the Beneficiary account cannot be credited on the basis of the information contained in the original credit transfer message. The
Return procedure must not be used in cases where the Beneficiary’s account has already been credited and the Beneficiary wishes to return the
funds. Instead, the procedure of initiating a new Credit Transfer applies.
The main characteristics of a Return (DS-03) are:
• the transferred amount will be the Original Amount of the Credit Transfer Instruction
• the Return message is routed through the same path taken by the original credit transfer (unless otherwise agreed between the Beneficiary
Bank and the Originator Bank), with no alteration of the data contained in the original credit transfer. In the case of a 'Return' message to
be sent to the Originator by the Originator Bank, the parties may agree a specific mechanism which may differ from the original path
• the initial credit transfer is identified by the original reference of the Originator Bank
• 'Return' messages contain a reason code (attribute AT-R3, see below)
'Return' messages initiated by the Beneficiary Bank must be transmitted to the Originator Bank within three Banking Business Days
after Settlement Date.
A Recall occurs when the Originator Bank requests to cancel a SEPA Credit Transfer. The Recall procedure must be initiated by
the Originator Bank within 10 Banking Business Days after execution date of the SCT subject to the Recall. The Recall procedure
can be initiated only by the Originator Bank, which may do it on behalf of its customer. Before initiating the Recall procedure, the
Originator Bank has to check if the SCT(s) are subject to one of the reasons listed below
A bank may initiate a Recall procedure for following reasons only:
• Duplicate sending
• Technical problems resulting in erroneous SCT(s)
• Fraudulent originated Credit Transfer
The main characteristics of a Recall (DS-05&DS-06) are:
• the returned amount can differ from the Original Amount of the Credit Transfer Instruction. The Beneficiary Bank may decide to
charge a fee to the Originator Bank.
90
• the Recall message is routed through the same path taken by the original credit transfer, with no alteration of the data contained in
the original credit transfer.
• Recall messages contain a reason code (attribute AT-48, see below)
If initiated before settlement, the recall will lead to a cancellation, according to the CSM’s own procedures agreed with its
participants. If initiated after settlement, the recall will be forwarded by the CSM.
The step by step process flow for a Recall (PR02) is given in a foregoing Section 4.3.2
It is the decision of the Beneficiary Bank if it wants to charge a return fee to the Originator Bank. . For this purpose, a field is dedicated in the return
message. This practice is limited to the recall procedure only and has under no circumstances effect on the normal return as defined in the SCT
rulebook.
It is purely limited and restricted for recalls only.
SDD r-transactions:
[extract SDD rulebook]
Rejects are Collections that are diverted from normal execution, prior to inter-bank Settlement, for the following reasons:
• Technical reasons detected by the Creditor Bank, the CSM, or the Debtor Bank, such as invalid format, wrong IBAN check digit
• The Debtor Bank is unable to process the Collection for such reasons as are set out in Article 78 of the Payment Services Directive.
• The Debtor Bank is unable to process the Collection for such reasons as are set out in section 4.2 of the Rulebook (e.g. account closed, Customer
deceased, account does not accept direct debits).
• The Debtor made a Refusal request to the Debtor Bank. The Debtor Bank will generate a Reject of the Collection being refused.
Refusals are claims initiated by the Debtor before Settlement, for any reason, requesting the Debtor Bank not to pay a Collection. This Refusal must be
ndled by the Debtor Bank in accordance with the conditions agreed with the Debtor. If the Debtor Bank agrees to handle the claim prior to inter-bank
settlement, the Refusal results in the Debtor Bank rejecting the associated Collection. (Note: In addition to this ability to refuse individual transactions,
the Debtor has the right to instruct the Debtor Bank to prohibit any direct debits from his bank account). When handled after Settlement, this Refusal is
referred to as a Refund claim. (See description underneath in the Refund section).
Returns are Collections that are diverted from normal execution after inter-bank Settlement and are initiated by the Debtor Bank.
Reversals: When the Creditor concludes that a Collection should not have been processed a Reversal may be used after the Clearing and Settlement by
the Creditor to reimburse the Debtor with the full amount of the erroneous Collection. The Rulebook does not oblige Creditor Banks to offer the
Reversal facility to the Creditors. For Debtor Banks, it is mandatory to handle Reversals initiated by Creditors or Creditor Banks. Creditors are not
obliged to use the Reversal facility but if they do so, a Reversal initiated by the Creditor must be handled by the Creditor Bank and the Debtor Bank.
Reversals may also be initiated by the Creditor Bank for the same reasons. Debtor Banks do not have to carry out any checks on Reversals received.
Revocations are requests by the Creditor to recall the instruction for a Collection until a date agreed with the Creditor Bank. This forms part of the
bilateral agreement between Creditor and Creditor Bank and is not covered by the Scheme.
Requests for cancellation are requests by the Creditor Bank to recall the instruction for a Collection prior to Settlement. This forms part of the bilateral
agreement between Creditor Bank and CSM and is not covered by the Scheme.
Refunds are claims by the Debtor for reimbursement of a direct debit. A Refund is available for authorised as well as for unauthorised direct debit
payments in accordance with the rules and procedures set out in the Rulebook. A request for a Refund must be sent to the Debtor Bank after Settlement
and within the period specified in section 4.3.
91
8.
8.1
R- transactions – Champ d’application
Principes généraux
Le reporting se rapporte aux R-transactions initiées et reçues au niveau interbancaire sur base des
messages XML détaillés ci-dessous.
8.2
Hors champ d’application
Ne sont pas concernées les R-transactions échangées (par message de type ISO 20022 XML ou par d'autres
moyens) dans l'espace Client - Banque (C2B) respectivement Banque - Client (B2C), à savoir :
o
la Revocation (pré-settlement / initié par le Creditor / basé sur un "agreement" avec la Creditor
Bank)
o
le Refusal (pré-settlement / initié par le Debtor)
o
le Refund (post-settlement / initié par le Debtor)
o
le Reversal (pain. 007 / post-settlement / initié par le Creditor)
Le "Customer Payment Status Report" au créancier est également exclus, même dans les cas où ce message
(pain. 002) mentionne uniquement le "negative status" (transactions non-exécutées/rejetées).
Les messages générés par les CSM vers les banques DNO / Originator bank sont à exclure.
8.3
Les messages R-Transactions au niveau interbancaire dans le schema SDD
Les banques renseignent les opérations de type R suivantes :
o
le Request for cancellation (camt. 056 / pré-settlement / Creditor Bank vers Debtor Bank /
non-spécifié dans les IGs de l'EPC)
o
le Reject (pacs. 002 / pré-settlement / Debtor Bank vers Creditor Bank) (*)
o
le Refund (pacs. 004 / post-settlement / Debtor Bank vers Creditor Bank)
o
le Return (pacs. 004 / post-settlement / Debtor Bank vers Creditor Bank)
o
le Reversal (pacs. 007 / post-settlement / Creditor Bank vers Debtor Bank)
(*) Sont à exclure du reporting les messages pacs. 002 générés par le CSM vers la Creditor Bank.
Le Refusal du Débiteur est traité au niveau interbancaire soit comme Reject (si avant settlement), soit comme
Refund (si après settlement).
Le pacs. 004 Refund (1) se distingue du pacs. 004 Return (2) sur base du "Return Originator" (si "Nom" : (1),
si "BIC" : (2))
92
8.4
Les messages R-Transactions au niveau interbancaire dans le schema SCT
En ce qui concerne les R-transactions SCT, les principes généraux décrits ci-avant restent d'application. Le
scope du reporting est donc limité à l'espace interbancaire et inclut :
le Return (pacs. 004 / post-settlement / Beneficiary Bank vers Originator Bank)
le Recall (camt. 056 / pré- ou post-settlement / Originator Bank vers CSM respectivement Beneficiary
Bank) (**)
(**) Sont à exclure du reporting les messages camt. 029 générés lors d'une "negative answer to a recall
message".
Les messages pacs. 002 générés par le CSM vers la Originator Bank sont également à exclure.
N.B. Pour le volet SCT, il n'y a pas de Reject initié par la Beneficiary Bank vers la Originator Bank.
9.
Transactions SEPA et R-transactions – Description des flux de paiements et
des flux des messages
93
SDD transaction flows
Creditor
Debtor
Out of reporting scope
In the reporting scope
Creditor
bank
Debtor
bank
CSM
Message flow
Payment flow
94
R-transaction message flow (SDD)
Reject from the debtor bank
Creditor
Debtor
Creditor
bank
Debtor
bank
Reject
Pacs. 002
CSM
Reject
Pacs. 002
CDDP reporting:
Creditor bank reports having received a reject (pacs. 002)
Debtor bank reports having sent a reject (pacs.002)
95
Refund from the debtor
Creditor
Debtor
Refund
Creditor
bank
Debtor
bank
Refund
Refund
Pacs. 004
Pacs. 004
CSM
CDDP reporting:
Creditor bank reports that it has received a refund (pcas. 004)
Debtor bank reports that it has sent a refund (pacs. 004)
96
Refusal from the debtor (reject / refund)
Debtor
Creditor
Refusal
Creditor
bank
Reject
Reject
Debtor
bank
Pacs. 002
Pacs. 002
Refund
CSM
Refund
Pacs. 004
Pacs. 004
CDDP reporting:
[Pré-settlement - reject] Creditor bank reports that it has received a reject (pacs. 002) and debtor bank reports that it has sent a reject (pacs.002)
[Post-settlement – refusal] Creditor bank reports that it has received a refund (pacs.004) and debtor bank reports that sent a refund (pacs. 004)
97
Return from the debtor bank
Creditor
Debtor
Creditor
bank
Debtor
bank
Return
Return
Pacs. 004
Pacs. 004
CSM
CDDP reporting:
Creditor bank reports that it has received a return (pacs. 004)
Debtor bank reports that it has sent a return (pacs. 004)
98
Reversal from the creditor bank
Creditor
Debtor
Creditor
bank
Debtor
bank
Reversal
Reversal
Pacs. 007
Pacs. 007
CSM
CDDP reporting:
Creditor bank reports sending a reversal (pacs. 007)
Debtor bank reports receiving a reversal (pacs. 007)
99
Revocation from the creditor
Creditor
Debtor
Revocation
Creditor
bank
Request for
cancellation
Request for
cancellation
Camt. 056
Camt. 056
Debtor
bank
CSM
CDDP reporting:
Creditor bank reports that it has sent a request for cancellation (Camt. 056)
Debtor bank reports that it has received a request for cancellation (Camt. 056)
100
Pacs.002 messages generated by the CSM
Creditor
Debtor
! Out of reporting scope !
Creditor
bank
Debtor
bank
Reject
Pacs. 002 generated
by the CSM are
out of scope
CSM
101
SCT transaction flows
Beneficiary
(payee)
Sender
(payer)
Beneficiary
bank
Originator
bank
CSM
Message flow
Payment flow
102
R-transaction message flow (SCT)
Return from the beneficiary bank
Beneficiary
(payee)
Sender
(payer)
Beneficiary
bank
Originator
bank
Return
Return
Pacs. 004
Pacs. 004
CSM
CDDP reporting:
The beneficiary bank reports that it has sent a return (pacs. 004)
The originator bank reports that it has received a return (pacs. 004)
103
Recall from the Originator bank
Case 1 : post-settlement
Beneficiary
(payee)
Sender
(payer)
Beneficiary
bank
Originator
bank
Recall
Recall
Camt.056
Camt.056
CSM
CDDP reporting:
The beneficiary bank reports that it has received a recall (Camt.056)
The originator bank reports that it has sent a recall (Camt.056)
104
Case 2 : pré-settlement
Beneficiary
(payee)
Sender
(payer)
Beneficiary
bank
Originator
bank
Recall
Camt.056
CSM
CDDP reporting:
The originator bank reports that it has sent a recall (Camt.056)
105
Beneficiary
(payee)
Pacs.002 messages generated by
the CSM
Sender
(payer)
Out of the reporting scope
! Out of the reporting scope !
Beneficiary
bank
Originator
bank
Recall
CSM
Pacs. 002 generated
by the CSM are
out of scope
CDDP reporting:
No reporting
106
10. Liste des modifications apportées dans les différentes versions de ce document
N° version
Date version
Description des modifications apportées dans les différentes version de ce document
Version 1
Juillet 2011
Document original annexé au règlement 2011/9 du 4/07/2011 relatif à la collecte des
données sur les instruments et les opérations de paiement
Version 2
Octobre 2011
Modifications conceptuelles introduites dans la version 2:
Néant
Liste de toutes les modifications apportées (par page) :
Page 2 :
Suppression de la note de bas de page n°1 relative au terme “volumétrie”: 1
C.à.d. le volume et la valeur des transactions.
À la 1 ère ligne, ajout à la suite du terme « volumétrie » de la mention
suivante : (le volume et la valeur des transactions)
Page 5 :
Dans le schéma « Chaîne de traitement de type paiement », le pluriel du terme
« ACH » est ajouté, soit « ACH(s) »
Page 13:
Dans le 2 ème paragraphe relatif au canal de règlement, précision que le canal
de règlement à renseigner pour les versements est « cash » :
“o Pour les versements : Cash”
Dans le 2 ème paragraphe relatif au pays d’émission de la banque du donneur
d’ordre, precision que pour les versements le pays d’émission est LU: “Pour
les versements, le pays d’émission sera «LU»”
Page 25 :
Dans le paragraphe, la phrase suivante :
“- Sous-tableau V1.3.2 « Règlement du solde des cartes de paiement » :
l’encaissement se fait dans la majorité des cas en « on-us » sur le compte de la
banque émettrice de la carte. La valeur à renseigner est : on-us.”
est remplacée par :
«- Sous-tableau V1.3.2 « Règlement du solde des cartes de paiement » :
l’encaissement se fait dans la majorité des cas en « on-us » sur le compte du
107
détenteur auprès de la banque émettrice de la carte. La valeur à renseigner est:
on-us.
Page 29:
Le titre suivant:
“Définition des concepts utilisés dans le sous-tableau Cartes (volet issuing):”
est remplacée par :
“Définition des concepts utilisés dans le sous-tableau Tableau V 1.5 : Cartes
(volet issuing):”
Page 32:
Dans les sous-tableaux V1.7.1 et V1.7.2, ajout des 2 canaux de règlement
suivants: “Moneygram” et “Autre”.
Page 33:
La phrase suivante:” - Mandat de paiement : titre par lequel une personne
donne ordre de payer à un tiers une certaine somme” est remplacée par : “Mandat de paiement : titre par lequel une personne donne ordre de payer à un
tiers une certaine somme en liquide”
En ce qui concerne le paragraphe relatif aux chèques, la phrase suivante:”La
provision doit être disponible lors de l'émission du chèque et maintenue
jusqu'à sa présentation. Il est généralement utilisé pour faire transiter de la
monnaie d'un compte bancaire à un autre.” est remplacée par : “Lorsque la
même entité émet et reçoit un chèque (transaction on-us), seul le volet émis
est à reporter (Sous tableau V1.7.1 : Chèques et mandats de paiement émis).”
Dans le paragraphe relatif au canal de transmission, la phrase suivante “En ce
qui concerne les mandats de paiement, le canal de transmission est « Western
Union ».” est remplacée par “En ce qui concerne les mandats de paiement, le
canal de transmission est « Western Union », « moneygram » or « autre »
(pour les autres schémas).”
Page 34:
Dans le sous-tableau V1.8.1, le titre “Pays de résidence du détenteur du SME”
est remplacé par “Pays de résidence du détenteur du compte”
Dans le sous-tableau V1.8.2, le titre “Terminal de paiement” est remplacé par
“Terminal de paiement (POS)”
Dans les sous-tableaux V1.8.3 et V1.8.4, le titre “Pays de résidence du
détenteur du SME” est remplacé par “Pays de résidence du détenteur du
compte.
Dans les sous-tableau V1.8.3 et V1.8.4, dans la colonne relative au pays de
residence du détenteur de compte, la mention “[= Code ISO du pays de
résidence du détenteur de SME] est remplacée par “Code ISO du pays de
résidence du détenteur du compte”.
Page 35:
Dans le paragraphe relatif au sous-tableau V1.8.2, la phrase suivante est
supprimée: “Le type de support « autre » vise à recenser le nombre de terminaux
108
pouvant accepter d’autres types de supports que les cartes.
Dans le paragraphe relative au sous-tableau V1.8.3, le terme “PME” est
remplacé par “SME”.
Page 36:
La phrase suivante “- Le pays de résidence du détenteur du PME: Code ISO
du pays de résidence du détenteur du SME.” Est remplacée par “- Le pays de
résidence du détenteur du compte: Code ISO du pays de résidence du
détenteur du compte de monnaie électronique. Ce champ s’applique
uniquement aux schémas de monnaie électronique sur réseau.”
Page 48: correction d’une faute typographique.
L’intitulé “6) Dexia (=DNO) -> Dexia -> Target -> BGL -> BGL (=BEN)
(EUR 375’000)” est remplacé par “6) Dexia (=DNO) -> Dexia -> Target ->
BGL -> BEN (EUR 375’000)”
Version 3
Juin 2013
Modifications conceptuelles introduites dans la version 2:
Introduction de la « Catégorie client » (concerne les tableaux relatifs aux
virements et aux domiciliations)
Une granularité supplémentaire est nécessaire concernant les virements de clientèle et
les domiciliations. Il s’agit de la distinction entre les transactions dont le client est une
Institution Financière et Monétaire [IFM] ou non-IFM.
Les différentes catégories client sont les suivantes :
Etablissement de crédit [IFM]
Fonds monétaires [IFM]
Fonds non-monétaires [non-IFM]
Autres non-IFMs [non-IFM]
Inconnu
Les sous-tableaux impactés sont les suivants : V1.1.1, V1.1.2, V1.1.4, V1.1.5, V1.3.3,
V1.3.4, V1.3.5 et V1.3.6.
Notion de compte de paiement (concerne les tableaux relatifs aux virements de
clientèle)
En ce qui concerne le reporting des virements de clientèle, la notion de compte de
paiement est ajoutée.
Effectivement, seules les transactions réalisées depuis un compte de paiement ou reçues
sur un compte de paiement et en utilisant un instrument de paiement (de type virement)
sont à rapporter dans la collecte mensuelle CDDP.
En ce qui concerne la définition de compte de paiement, se référer à l’article 4.14 de la
directive 2007/64/CE du Parlement europmen et du Conseil concernant les services de
paiement dans le marché intérieur.
109
Cette règle impacte les sous-tableaux V1.1.1 et V1.1.2.
Modification des critères SEPA capable (concerne les virements de clientèle émis) :
Dans la version initiale de la CDDP, est considéré comme SEPA capable tout paiement
dans la devise Euro émis dans la zone SEPA 52 et respectant les critères IBAN + SHARE
et non plus IBAN + SHARE + BIC.
Avec le règlement CE 260/2012, le BIC n’est plus obligatoire.
Les critères SEPA capable sont désormais : IBAN + SHARE.
Seul le sous-tableau V1.1.1 est impacté.
Collecte des transactions SEPA et r-transactions (nouveaux sous-tableaux) :
La version initiale de la CDDP ne couvrait pas le reporting des transactions SEPA et
des r-transactions et prévoyait de l’ajouter ultérieurement.
Ce nouveau reporting, qui impacte les virements et les domiciliations est ajouté dans la
version 3 de la note de guidance.
Il a pour effet la création des nouveaux sous-tableaux suivants : V1.1.4, V1.1.5, V1.3.3,
V1.3.4, V1.3.5 et V1.3.6.
Versements : les transactions relatives à cet instrument ne sont plus collectées
Les versements n’étant pas significatifs, il a été décidé de ne plus collecter ces
transactions.
Dans le sous-tableau V1.1.2, dans lequel les versements étaient collectés, le type
d’instrument « versement » et le canal de règlement « cash » ont par conséquent été
retirés.
Collecte des virements de clientèle on-us reçus
Le volet reçu des virements « on-us » n’était initialement pas à rapporter car il peut
théoriquement être déduit du volet émis (on-us émis = on-us reçus). En pratique, les
extractions s’avèrent difficiles à réaliser notamment parce que les colonnes des soustableaux V1.1.1 et V1.1.2 ne sont pas strictement identiques : dans le sous-tableau
V1.1.1, le pays à renseigner est le « pays de destination » alors que dans le sous-tableau
V1.1.2, le pays à renseigner est le « pays d’émission ».
Cette nouvelle règle impacte uniquement le sous-tableau V1.1.2, dans lequel le canal de
règlement « on-us » a été ajouté.
Inventaire cartes : distinction entre l’activité d’émission et l’activité de
distribution de cartes
L’inventaire des cartes de paiement concerne l’activité d’émission et l’activité de
52
Liste des pays appartenant à la zone SEPA : http://www.europeanpaymentscouncil.eu/knowledge_bank_detail.cfm?documents_id=328
110
distribution de cartes. La version initiale prévoit que ces deux activités soient collectées
indistinctement dans le sous-tableau V1.4.1, ce qui ne permet pas à la BCL d’effectuer
de contrôles de cohérence.
Dans la version 3, une distinction entre l’activité d’émission et l’activité de distribution
de cartes est prévue dans le sous-tableau V1.4.1.
Cartes de paiement : ajout de 4 schéma et de 2 modes d’acceptation :
Mises à jour pour refléter la réalité du marché :
Les 4 schéma de cartes suivants sont ajoutés : China UnionPay, Diner’s Club, American
Express et JCB.
Les 2 modes d’acceptation suivants sont ajoutés : Stronger Customer Authentication,
Autre.
Intermédiation + règlement via une Relation Nostro/Loro (tableaux virements):
Dans l’intermédiation et dans le cas où la transaction est réglée via une relation
nostro/loro, le PSP ne sait pas s’il est du côté émis ou reçu (PSP1 ou PSP2).
Il était initialement demandé de renseigner une seule transaction avec « sens de
l’opération = N/A » et « type client = N/A ».
Dans la version 3 de la note de guidance il est demandé de renseigner les deux
transactions, c.à.d celle émise et celle reçue. Le sens de l’opération et le type client
peuvent ainsi être renseignés par leur vraie valeur et non plus par « N/A ».
Seuls les sous-tableaux V1.1.3 et V1.2.3 sont impactés.
Monnaie électronique : informations supplémentaires à renseigner
Sous-tableau V1.8.1 :
- une colonne supplémentaire « type de compte/carte » est ajoutée. Il s’agit du « type de
compte/carte » selon qu’il soit détenu par un professionnel ou par une personne privée.
- une colonne supplémentaire « devise float » est ajoutée. Il s’agit de la devise du
compte sur lequel est stocké le float.
- La colonne « Origine du chargement » est renommée : « Origine du chargement /
Destination du déchargement ». Ainsi il devra également être précisé en ce qui concerne
les déchargements, si ceux-ci sont sont réalisés sur des comptes bancaires, sur des
cartes depaiement ou sur un autre support.
- une colonne supplémentaire « Purchase / P2P » est ajoutée. Il s’agit de préciser si la
transaction réalisée est un achat ou un transfert privé entre 2 personnes. Dans le cas où
cette information n’est pas connu, il est renseigné « inconnu ».
111
Liste de toutes les modifications apportées (par page) :
Page 3 :
La phrase suivante « - Les tableaux mesurent la volumétrie (le volume et la
valeur des transactions) des transactions de paiement
réalisées à l’aide des différents instruments de paiement à l’exception du
tableau V 1.4, qui recense des stocks.” Est remplacée par “- Les tableaux
mesurent la volumétrie (le volume et la valeur des transactions) des
transactions de paiement réalisées à l’aide des différents instruments de
paiement à l’exception des tableaux V 1.4, V 1.8.1 et V 1.8.2 qui recensent
des stocks. »
Le 3 ème paragraphe « Etendue de la collecte » est déplacé et devient le 2 ème
paragraphe.
Page 4 :
Dans le paragraphe 2 « Remarques importantes concernant la transmisison des
données », ajout d’une remarque concernant l’envoi de corrections et d’une
remarque concernant lecaractère absolu des chiffres à envoyer :
« - Envoi de corrections : il est important de noter que lors du renvoi d’un
tableau pour une période donnée, le nouveau tableau généré écrase le précédent.
En particulier, si un tableau est composé de plusieurs sous-tableaux, lors de
corrections l’ensemble des sous-tableaux doit être renvoyé. Ceci même si les
corrections ne concernent qu’un seul sous-tableau.
- Tous les chiffres sont à envoyer en valeur absolue, le système n’accepte pas
de valeurs négatives. »
Page 5 :
Paragraphe 4.1 : ajout d’une mention quant aux virements SEPA :
« - Le traitement des rejets et des retours au niveau des virements: Les rejets –
à l’exception des rejets de virements SEPA (SCT) pour lesquels des tableaux
spécifiques sont prévus - ne sont pas inclus dans la collecte puisqu’il s’agit de
messages n’ayant pas abouti pour une raison ou une autre. »
Page 10 :
En haut de page, la remarque suivante est ajoutée : « - Seules les transactions
réalisées depuis un compte de paiement53 ou reçues sur un compte de paiement
et en utilisant un instrument de paiement (de type virement) sont à rapporter
dans la collecte mensuelle.
Tableau V1.1.1 : ajout d’une colonne intitulée « Catégorie client »
Page 11 :
Dans le paragraphe relatif à la définition des concepts utilisés dans le sous-
53
Définition de compte de paiement : cf. article 4.14 de la directive 2007/64/CE du Parlement européen et du Conseil concernant les services de paiement dans le marché
intérieur.
112
tableau V1.1.1, ajout de la définition de « Catégorie client (DNO) ».
Page 12 :
SEPA capable : la phrase suivante « La BQE DNO renseignera qu’un
paiement est « SEPA capable » si elle dispose du numéro de compte du BEN
dans la norme IBAN, du code BIC de la BQE BEN et les frais sont partagés.”
est remplacée par « La BQE DNO renseignera qu’un paiement est « SEPA
capable » si elle dispose du numéro de compte du BEN dans la norme IBAN et
si les frais sont partagés. »
Page 13 :
Devise de la transaction : le verbe « réalisée » est remplacé par « réglée » :
« La devise de la transaction est renseignée par le code ISO de la devise (Code
ISO 4217 à trois lettres) dans laquelle la transaction a été réglée. »
Tableau V1.1.2 : ajout d’une colonne intitulée « Catégorie client »
Tableau V1.1.2 : Suppression du type d’instrument « versement » et du canal
de règlement « cash » y relatif.
Tableau V1.1.2 : ajout du canal de règlement « on-us ».
Page 14 :
Suite à la suppresion du type d’instrument « versement », en ce qui concerne la
valeur à renseigner, le nouveau texte est : « la seule valeur possible est donc:
Virement. »
Dans le paragraphe relatif à la définition des concepts utilisés dans le soustableau V1.1.2, ajout de la définition de « Catégorie client (DNO) »
Page 15 :
Dans le paragraphe relatif à la définition des concepts utilisés dans le soustableau V1.1.2, ajout de la définition de « « traitement des transactions onus »
Page 16 :
Sous-tableau V1.1.3 : suppression de la valeur « N/A » dans les colonnes
relatives au « Type client » et au « Sens de l’opération ».
Type client : modification conceptuelle concernant les transactions réglées
en nostro/loro.
Le texte suivant « En cas de règlement via relation de compte nostro/loro : le
PSP ne sait pas s’il est du côté émis ou du côté reçu (PSP1 ou PSP2). Il peut
donc s’avérer difficile de renseigner si le type client est BQE LU ou BQE nonLU. En conclusion, lorsque des virements intermédiés sont réglés via relation de
compte nostro/loro, par convention il sera renseigné « N/A » au titre du « Type
client ». Les valeurs possibles sont: Banque LU, Banque non-LU ou N/A.”
113
est remplacé par
“N.B. : en cas de règlement via relation de compte nostro/loro : lorsque le PSP
est à la fois du côté émis et du côté reçu (PSP1 et PSP2), celui-ci renseignera les
deux transactions c.à.d. la transaction émise (« transaction side = émis » et la
transaction reçue (« transaction side = reçu ») et il précisera quel est le type
client (« BQE LU » ou « BQE non-LU »). Cette catégorisation est distincte de
la « catégorie client ». Les valeurs possibles sont: Banque LU ou Banque nonLU. »
Dans les versions précédentes, dans le cas indiqué ci-dessus, une seule
transaction était renseignée au titre de la transaction émise ET de la transaction
reçue. Le type client et le sens de l’opération étaient donc renseignés par
« N/A ». Ces précisions étant nécessaires à la BCL, il est désormais demandé de
renseigner les 2 transactions, celle émise et celle reçue et de spécifier le type
client (BQE LU ou BQE non-LU) ainsi que le sens de l’opération « émis ou
reçu).
Page 17 :
Sens de l’opération : suppression de la valeur « N/A » ainsi que du texte
suivant : « Les sens émis et reçus sont à préciser uniquement lors d’un
règlement dans un système. En cas de règlement de l’opération via relation de
compte Nostro/Loro, le sens de l’opération ne pouvant pas être déterminée
aisément par le PSP, la valeur à renseigner sera N/A. »
Pages 18-21 :
Transactions SEPA et r-transactions : de nouveaux tableaux de reporting
sont ajoutés pour collecter des informations sur ces transactions.
Page 21 :
Ajout de la note de bas de page suivante : « Les domiciliations interbancaires
sont à rapporter dans le sous-tableau V1.3.1 Domiciliations legacy ».
Page 23 :
Page 25 :
Sous-tableau V1.2.3 : suppression de la valeur « N/A » dans les colonnes
relatives au « Type client » et au « Sens de l’opération ».
114
Page 26 :
Le texte suivant « En cas de règlement via relation de compte nostro/loro : le PSP
ne sait pas s’il est du côté émis ou du côté reçu (PSP1 ou PSP2). Il peut donc
s’avérer difficile de renseigner si le type client est BQE LU ou BQE non-LU. En
conclusion, lorsque des virements intermédiés sont réglés via relation de compte
nostro/loro, par convention il sera renseigné « N/A » au titre du « Type client ».
Les valeurs possibles sont: Banque LU, Banque non-LU ou N/A.”
est remplacé par
“N.B. : en cas de règlement via relation de compte nostro/loro : lorsque le PSP
est à la fois du côté émis et du côté reçu (PSP1 et PSP2), celui-ci renseignera les
deux transactions c.à.d. la transaction émise (« transaction side = émis » et la
transaction reçue (« transaction side = reçu ») et il précisera quel est le type
client (« BQE LU » ou « BQE non-LU »). Cette catégorisation est distincte de
la « catégorie client ». Les valeurs possibles sont: Banque LU ou Banque nonLU. »
Dans les versions précédentes, dans le cas indiqué ci-dessus, une seule
transaction était renseignée au titre de la transaction émise ET de la transaction
reçue. Le type client et le sens de l’opération étaient donc renseignés par
« N/A ». Ces précisions étant nécessaires à la BCL, il est désormais demandé de
renseigner les 2 transactions, celle émise et celle reçue et de spécifier le type
client (BQE LU ou BQE non-LU) ainsi que le sens de l’opération « émis ou
reçu).
Sens de l’opération : suppression de la valeur « N/A » ainsi que du texte
suivant : « Les sens émis et reçus sont à préciser uniquement lors d’un
règlement dans un système. En cas de règlement de l’opération via relation de
compte Nostro/Loro, le sens de l’opération ne pouvant pas être déterminée
aisément par le PSP, la valeur à renseigner sera N/A. »
Page 28 : le reporting des domiciliations SEPA étant ajouté dans la version 3, des
mentions relatives aux domiciliations SEPA ont été ajoutées lorsque c’était nécessaire :
2ème Paragraphe :
Deux types de domiciliations existent ; les domiciliations legacy (sous-tableau
V1.3.1) et les domiciliations SEPA (sous-tableaux V1.3.3 et V 1.3.5).
[…] Dans les domiciliations de type legacy, la banque du créancier n’est pas
impliquée dans le flux d’informations54, seule la banque du débiteur renseigne les
domiciliations (ou demandes d’encaissements). Le reporting des domiciliations
legacy ne couvre pas les « opérations de type R55 ».
54
55
Pour la banque du créancier, c’est un paiement entrant, sans pouvoir identifier qu’il s’agit d’une domiciliation.
Opération de type R ou R-transaction = Refund, Reject etc….
115
3 ème Paragraphe :
[…] le règlement du solde des cartes de paiement est donc inclus dans le sous-tableau
V1.3.1 dédié aux domiciliations legacy ou dans le sous-tableau V1.3.3 dédié aux
SDD.
Le règlement de cartes de crédit qui se fait par une demande de débit traditionnelle56
est à renseigner dans le sous-tableau V1.3.1 ou dans le sous-tableau V1.3.3 dédié
aux SDD.
Page 29 :
Sous-tableauV1.3.1 : ajout des canaux de transmision « bilatéral » et « Autre »
Page 29 à 32 :
Ajout de nouveaux tableaux de reporting relatifs aux domiciliations SEPA et
r-transactions.
Page 34-35 :
V1.4.1 : modification conceptuelle relative à l’inventaire des cartes de
paiement. Mise à jour du tableau et des définitions et concepts.
Page 35 :
Ajout de la définition de « pays » relative au sous-tableau V1.4.1.
Sous-tableau V1.4.2 : ajout du schéma China UnionPay.
Pages 38 -39 et 41-42 :
Tableaux V1.5 et V1.6: ajout des schéma « Diners’ Club », « American
Express », « JCB » et « China UnionPay » et des Modes d’acceptation
« Stronger customer authentication » et « Autre ». Les définitions et concepts
sont également mis à jour notamment avec l’ajout de la définition de
« Stronger customer authentication »..
Page 40 :
Page 43 :
Page 44 :
Retrait de la phrase suivante : « Lorsque la même entité émet et reçoit un
chèque (transaction on-us), seul le volet émis est à reporter »
Page 45 :
Pour les domiciliations legacy, les banques ne gardent pas d’information aisément exploitables dans leurs systèmes informatiques pour les opérations de type R.
56
Exemple : AMEX
116
Sous-tableau V1.8.1 : ajout d’une colonne « Type de compte/cartes » ainsi que
des réponses à renseigner : « Professionnel », « Privé ».
Sous-tableau V1.8.1 : ajout d’une colonne « Devise du float »
Sous-tableau V1.8.3 : la colonne « origine du chargement » est renommée :
« origine du chargement/destination du déchargement ».
Page 46 :
Sous-tableau V1.8.4 : ajout d’une colonne « Purchase/P2P » ainsi que des
réponses possibles « Purchase », « P2P », « Inconnu ».
Page 47 :
Type de support : ajout du paragraphe suivant : « N.B. : En ce qui concerne le type
de support « carte », sont recensées uniquement les cartes de type portemonnaie
électronique sur lesquelles la monnaie électronique est stockée directement. Sont
exclues les cartes permettant d’initier une transaction en monnaire électronique
dont la monnaie électronique est stockée ailleurs que sur cette carte. Exemple :
stockage sur un compte de monnaie électronique, sur réseau.
Ajout de la définition de « Type de compte /carte ».
Type d’opération – sous paragraphe relatif au tableau V1.8.5 : ajout de la phrase
suivante « Sont renseignés dans ce tableau les demandes de débit, les transferts
effectifs exécutés suite aux demandes de débits sont à renseigner dans le tableau
V1.8.3.
La colonne « origine du chargement » ayant été renommée : « origine du
chargement/destination du déchargement », la définition y relative a été mise
à jour.
Page 48 :
Ajout de la définition de «devise du float ».
Page 49 :
Ajout de la définition de «Purchase / P2P ».
Page 53 :
Cas n°1 : correction effectuée au niveau du reporting du PSP1 et du PSP2. Le
sens de l’opération n’est pas « N/A » mais « émis », respectivement « reçu ».
La phrase suivante figurant en fin de page est également retirée : « Remarque
concernant le sens de l’opération pour les virements intermédiés:
Les PSP ne peuvent pas identifier avec certitude le sens de l’opération dans le
Nostro/Loro car le lieu de règlement n’est pas défini clairement comme dans le
règlement via un ACH.. Le sens de l’opération à renseigner par les PSP1 et PSP2
est donc: “N/A”.
Page 54 :
Cas n°2 : les phrase suivantes « PSP1 = connecté à un ACH pour la devise Euro
mais le PSP1 règle le paiement via relation Nostro/Loro
PSP2 = connecté à un ACH pour la devise Euro mais règlement du paiement via
117
relation Nostro/Loro »
Sont remplacées par :
«PSP1 = PSP2 ( = PSP dans l’exemple ci-dessous) connecté à un ACH pour la devise
Euro mais le PSP règle le paiement via relation Nostro/Loro »
Page 56 :
Cas n°2 : correction : les virements on-us doivent être rapportés. L’exemple est
mis à jour et précise comment doit être renseigné le virement on-us reçu.
Page 57 :
Dans les 3 tableaux comportant l’indication « Code ISO (Lu)» dans la colonne
« Pays de destination de la BQE BEN », cette mention est remplacée par
« LU ».
Dans le 4ème tableau, le canal de règlement « PSP LU » renseigné au titre de
la BQE BEN est remplacé par « PSP LU ou PSP non-LU ».
La précision suivante (note de bas de page) est également ajoutée : « La réponse
est PSP LU ou PSP non-LU en fonction que le PSP usuel de la BQE BEN pour
la devise CHF est LU ou non-LU. »
Page 58 :
2 ème tableau : correction effectuée au niveau du reporting du PSP1 et du PSP2.
Le sens de l’opération n’est pas « N/A » mais « émis », respectivement
« reçu ».
Page 59 :
1 er et 2 ème tableaux : Correction effectuée au niveau du canal de règlement à
rapporter par le PSP1. La réponse « PSP non-LU » est remplacée par « PSP
LU ou PSP non-LU ». La précision suivante (note de bas de page est
également ajoutée : « La réponse est PSP LU ou PSP non-LU en fonction que le PSP
usuel de la BQE DNO pour la devise CHF est LU ou non-LU . »
1 er et 2 ème tableaux : correction effectuée au niveau du reporting du PSP1. Le
sens de l’opération n’est pas « N/A » mais « émis ».
Page 61 et 62:
Exemple 4 – liste des paiements réalisés : un 15 ème exemple est ajouté.
Reporting des banques concernant ces 15 opérations :
Opération 1 : il est précisé que Fortuna, qui utilise Multiline, ne rapporte pas
cette opération.
Reporting ING – opération 7 : le reporting du virement on-us reçu est ajouté
Reporting ING – opération 11 : le sens de l’opération « N/A » est corrigé et
remplacé par « émis »
Reporting ING – opération 13 : le sens de l’oération « N/A » est corrigé et
remplacém par « reçu »..
Page 63 à 69:
Rubrique « Catégorie clients » : ajout de la table de conversion entre le
118
reporting CDDP et les définitions de la BCL (vue d’ensemble et vue
détaillée).
Pages 70-71:
Ajout d’un paragraphe relatif aux définitions des r-transactions.
Pages 72-73:
Ajout d’un paragraphe relatif au champ d’application des r-transactions.
Pages 73 à 86:
Ajout d’un paragraphe comportant une description des flux de paiement et des
flux de messages.
Version 3
Juin 2013
Non traité dans la version 3 : les book entries, les prêts et les titres
Version 4
Juin 2015
Modifications conceptuelles introduites dans la version 4 :
Introduction du « Mode d’initiation » (concerne les tableaux relatifs aux virements
et aux domiciliations)
La granularité « instruction au format papier » est remplacée par le « mode
d’initiation ».
Les sous-tableaux impactés sont les suivants : V1.1.1 et V1.3.5.
Suppression de la collecte des versements en espèces dans le sous-tableau V1.1.2
La collecte des dépôts et des retraits en espèces au guichet d’une banque seront
collectées dans le futur tableau V1.11 y dédié (à partir de 2017)
Tableau impacté : V1.1.2.
En ce qui concerne les cartes de paiement, mises à jour des rubriques relatives au
« type d’instrument de paiement» :
Les cartes suivantes ont notamment été ajoutées :
o One-off cards
o Cartes permettant l’accès à de l a monnaie électronique stockée sur un compte
de monnaie électronique sur réseau
Les (sous-)tableaux impactés sont les suivants : V1.4.1, V1.5 et V1.6.
Introduction d’une granularité supplémentaire dans le sous-tableau V1.4.2 relatif
aux opérations de (dé)chargement sur cartes prépayées :
La colonne « instrument sous-jacent à l’origine du chargement/destination du
déchargement » a été ajoutée.
Tableau impacté : V1.4.2.
119
Actualisation des rubriques relatives au « type de terminal »:
La colonne « Type de terminal» a été mise à jour avec l’ajout de nouveaux types de
terminaux.
L’inventaire des terminaux relatifs à la monnaie électronique, jusqu’à présent renseigné
dans le tableau V1.8, est transféré dans le sous-tableau V1.4.3.
Tableaux impactés : V1.4.3 et V1.8.2.
Actualisation des rubriques relatives au « type d’opération » (transactions cartes):
La colonne « Type d’opération» a été mise à jour avec l’ajout des nouvelles rubriques
« ATM cash deposit » et « Cash advances at POS terminals ».
Tableaux impactés: V1.5 et V1.6.
Actualisation des rubriques relatives au « type de schéma » (transactions cartes):
La colonne « Type de schéma» a été mise à jour avec l’ajout d’une nouvelle rubrique
« Propriétaire».
Actualisation de la collecte relative aux SME:
En raison de la complexité croissante de la collecte des données des SME sur réseau, il
a été décidé de scinder la collecte des données relatives aux SME sur réseau et celle
des SME sur cartes dans deux tableaux distincts : le tableau V1.8 et le tableau V1.9.
Le tableau V1.8 sera ainsi dédié aux SME sur réseau et le nouveau tableau V1.9 ne
concernera que les SME sur cartes.
Le tableau V1.8 a également fait l’objet de certaines mises à jour.
Nouveau tableau « opération en espèces réalisées au guichet de la banque »
Ce tableau est placé à titre indicatif. Il sera applicable en janvier 2017, après
finalisation, en accord avec les agents rapporteurs (échéance : mi-2016).
Tableau impacté: V1.11.
Nouveau tableau « Transactions de paiement réalisées au moyen d’un dispositif de
télécommunication numérique ou informatique »
120
Nouveau tableau « Crédits effectués sur les comptes de paiement par le biais d’une
simple écriture comptable »
Nouveau tableau « Débits effectués depuis les comptes de paiement par le biais
d’une simple écriture comptable »
121

clean - Banque centrale du Luxembourg

Transcription

Documents pareils

Appareil à Gummy

Republika Hrvatska (hr)

Arnaque aux faux virements bancaires

Play Gear Pocket Logitech

Télécharger la fiche produit

Signification du blason/logo de l`Académie des Dalons à La

PROGRAMME PAINT SHOP PRO 1- Paramètres - ciel

SHR84 code NCAGE Termes et Conditions Prix

Version pdf - GTA sur psp

139 000 € - Sun Immobilier