← Luxembourg

Communication of 14 July 2022 on amendments to Annexes 1 and 2 of Circular CSSF 20/747 relating to the accounts register (CRBA)

Published on 14 July 2022 Email this Share this on LinkedIn Share this on Facebook Communiqué Communication of 14 July 2022 on amendments to Annexes 1 and 2 of Circular CSSF 20/747 relating to the accounts register (CRBA) The CSSF hereby notifies the professionals of certain amendments to Annexes 1 and 2 of Circular CSSF 20/747 on the technical arrangements relating to the application of the Law of 25 March 2020 establishing a central electronic data retrieval system related to IBAN accounts and safe-deposit boxes held by credit institutions in Luxembourg (“the Law”). Professionals are reminded that they are obliged to include in their data files, any information allowing the identification of all natural or legal persons who hold or control, within those professionals, payment accounts or bank accounts identified by an IBAN number, within the meaning of Article 2

(15)of Regulation (EU) No 260/2012, or safe-deposit boxes, in accordance with the technical modalities of annex 2 of Circular CSSF 20/747, as long as those are available in their electronic systems feeding the CRBA file, notwithdstanding the generic professional obligation to conserve these data in their books, even though those might not necessarily be available in an electronic form within the professionnals’ dedicated system or application. With regard to Annex 1, professionals are no longer required to transmit a data file on weekends, following the initial instructions in Part 4.1.1, paragraph 1 of the said Annex. Henceforth, professionals must make their data file available in the CRBA on a daily basis from Monday to Friday only, except on the days of Luxembourg public and banking holidays. With regard to Annex 2, the new qualification as “optional” of certain identification data is a technical IT qualification (i.e. the file will in principle be accepted in the CRBA even in the absence of such technically optional data), serving purely technical standards in the CRBA. From a legal perspective, the particular data must be stored in the books of the professionals on the basis of Article 3 of the Law of 12 November 2004 on the fight against money laundering and the financing of terrorism (“AML/CFT Law”) and Article 16 of CSSF Regulation No 12-02 on the fight against money laundering and the financing of terrorism (“CSSF Regulation 12-02”). From a technical point of view, professionals have the possibility to not include the data in question in their respective data files, should the systems at their disposal and through which they make the required information available to the CSSF into the CRBA, not yet allow this reporting. The amendments to Annex 2 specifically refer to the following: 1) The indication of the IBAN number of a payment account or a bank account becomes mandatory. Failing that, the data file will be rejected. Specifically, line 14 of Annex 2 is amended in order to only allow the reporting of the IBAN number of a bank or a payment account. 2) The reporting of the inactive status of certain accounts or safe-deposit boxes within the meaning of the Law of 30 March 2022 on inactive accounts, inactive safe-deposit boxes and unclaimed insurance policies1, is now possible. On this basis, a new optional block has been added in Annex 2, entitled “inactive”, allowing the declaration of a payment account or a bank account identified by an IBAN number or a safe-deposit box, as inactive. More precisely, a new block of lines, from 19 to 22 referring to bank or payment accounts and from 77 to 80 referring to safe-deposit boxes, is added to Annex 2, allowing reporting into the new technically optional fields. The “isInactive” field in line 20 allows declaring an account as inactive. The “isInactive” field in line 78 is used for the declaration of a safe-deposit box as inactive. It should also be noted that it is possible to report the date from which the account or safe-deposit box is to be considered as inactive (“inactivityStartDate” line 21 and line 79 of Annex 2, respectively), as well as to specify the reasons for this inactivity (“comment” line 22 and line 80, respectively, of the said annex). The information in question does not affect the acceptance of the data file. 3) In respect of any natural person linked to a payment account or a bank account identified by an IBAN number and/or a safe-deposit box, the data: ‘city of birth’ (line 32 of Annex 2 and line 90, respectively, as regards safe-deposit boxes), ‘passport number, identity number, driving licence number’, initially designated as mandatory data under the ‘identifiers’ block of Annex 2 (lines 35 to 38 and lines 93 to 96, respectively, with regard to safe-deposit boxes in Annex 2), “address: street, city, postal code”, initially designated as mandatory data, are now to be considered as optional data, from a technical point of view
  1. The changes specifically apply to line 40 “street” and to line 98 as regards safe-deposit boxes, line 41 “city” and line 99 for safe-deposit boxes, as well as to line 44 “postal code” and finally to line 102 for safe-deposit boxes. It is furthermore noted that, if, within Annex 2 and in relation with the data “passport number, identity number, driving licence number”, respectively, professionals specifically choose to report an official national identification number (cf. second indent above: data not mandatory from a technical point of view), they must, in addition to the number, also report the type of the identification document used. Failing that, the data file will not be accepted in the CRBA. Example: With regards to the identification data of natural person A, a professional foreseeing to provide technically optional information on the passport of natural person A, based on the previously obtained copy. On this basis, the type of “identifier” chosen in Annexe 2 will be “passport”, which entails the obligation to additionally report the particular number of the said passport. 4) In respect of any legal person linked to a payment account or bank account identified by an IBAN number and/or a safe-deposit box: The fields “head office address – street, head office address – number, head office address – town, head office address – postal code”, initially designated as mandatory, are now to be considered as optional from a technical point of view. Specifically, the fields in Annex 2 “street”, “town” and “postalCode” referring to the head office (“headquarter” block: lines 59 to 65 for accounts and lines 117 to 123 for safe-deposit-boxes) and the place of business (“placeOfBusiness”: lines 66 to 72 for accounts and lines 124 to 130 for safe-deposit boxes), become technically optional3, as far as their submission in the professionals’ data file is concerned. Professionals are reminded that, despite the optional nature, from a technical point of view, of the above-mentioned data, which may indeed not be included in the professionals’ data files, they are still obliged to include them in their data files made available to the CSSF in accordance with the instructions in Annex 2 of Circular CSSF 20/747 as soon as those are available in their respective systems. It is further noted that the changes described above will be visible in the CRBA test environment from 15.07.
  2. Professionals subject to the Law are required to implement these changes in the CRBA production environment by 15.09.
  3. With reference to the “alternative designations”, on the subject of which the CSSF issued two previous communications, the first dated 29 January 2021 and the second dated 23 November 2021, in order to deal with the exceptional and provisional use of certain technical designations within Annex 2 of Circular CSSF 20/747, so as to avoid that the absence of particular data in the file compromises the successful transmission of the entire data file to the CSSF, their application becomes further restricted following the amendments in Annex
  4. Based on the above, the only alternative designations that shall be accepted from 15.09.2022 and onwards are those corresponding to the two exceptional cases described below, where the information requested is not applicable (“not applicable” into the Annex 2 reporting): the beneficial owner, in the particular case of the client being a company listed on a regulated market that is subject to disclosure requirements consistent with EU law or equivalent international standards that ensure adequate transparency of ownership information; the company or legal entity during the process of incoporation. Professionals are informed that any question relating to this communication may be addressed to the dedicated electronic mailbox of the CSSF: registre.compte@cssf.lu. 1 Article 5 referring to the start of the inactivity of an account. 2 As stated above, they remain, however, mandatory from a legal and regulatory point of view, in accordance with Article 3
(2)a of the AML/CFT Law and Article 16
(1)of RCSSF 12-02. 3 As stated above, they remain, however, mandatory from a legal and regulatory point of view, in accordance with Article 3
(2)second point (b) of the AML/CFT Law and Article 16
(2)of RCSSF 12-
  1. 23 July 2020 - Updated on 23 July 2020 Circular CSSF 20/747 (version of 23.07.2020) Technical arrangements relating to the application of the Law of 25 March 2020 establishing a central electronic data retrieval system related to IBAN accounts and safe-deposit boxes held by credit institutions in Luxembourg (the “Law”) Link to the communiqué of… CSSF circular PDF (107.95Kb) PDF (108.19Kb) 7 September 2020 - Updated on 14 July 2022 Annex 1 to Circular CSSF 20/747 Version of 14.07.2022 Annex to a CSSF circular PDF (374Kb) PDF (347.35Kb) 14 July 2022 Annex 1 to Circular CSSF 20/747 (track changes) Version of 14.07.2022 Annex to a CSSF circular PDF (374.44Kb) PDF (347.75Kb) 24 July 2020 - Updated on 14 July 2022 Annex 2 to Circular CSSF 20/747 Version of 14.07.2022 Annex to a CSSF circular XLSX (19.35Kb) XLSX (18.89Kb) Main topic: Financial crime Relevant for Central Securities Depositories (CSDs) Credit institutions Payment institutions/electronic money institutions/AISPs Circulaire CSSF 20/747 Modalités techniques relatives à l’application de la loi du 25 mars 2020 instituant un système électronique central de recherche de données concernant des comptes de paiement et des comptes bancaires identifiés par un numéro IBAN et des coffres-forts tenus par des établissements de crédit au Luxembourg (la « loi ») CIRCULAIRE CSSF 20/747 1/4 Circulaire CSSF 20/747 Concerne : Modalités techniques relatives à l’application de la loi du 25 mars 2020 instituant un système électronique central de recherche de données concernant des comptes de paiement et des comptes bancaires identifiés par un numéro IBAN et des coffresforts tenus par des établissements de crédit au Luxembourg (la « loi ») Luxembourg, le 23 juillet 2020 Mesdames, Messieurs, À tous les établissements de crédit et prestataires de de paiement au Luxembourg proposant des services La loi du 25 mars 2020 (« la loi ») institue un système électronique central de recherche de données concernant des comptes de paiement et des comptes bancaires identifiés par un numéro IBAN, ainsi que des coffres-forts tenus par des établissements de crédit au Luxembourg. services de tenue de comptes de La présente circulaire vise à apporter aux professionnels tels que définis à paiement l’article 1er point 6 de la loi, les précisions nécessaires en vue de la mise en place ou de comptes par un et l’opération dans leurs systèmes informatiques, de l’infrastructure technique sens du nécessaire afin de permettre le fonctionnement efficace, dans la relation entre règlement (UE) n° 260/2012 du la CSSF et le professionnel, du système électronique central de recherche de Parlement données mis en place et géré par la CSSF
  2. bancaires numéro Conseil identifiés IBAN, au européen du 14 établissant des techniques et pour les et mars 2012 exigences commerciales virements et les euros et prélèvements en modifiant règlement le du (CE) L’objet de la présente circulaire consiste plus précisément à éclairer les professionnels en ce qui concerne les aspects techniques et informatiques du système électronique central de recherche de données afin qu’ils puissent aménager et adapter leurs systèmes en conformité avec les exigences techniques du système tel qu’il est mis en place par la CSSF. n° 924/2009, ainsi que tout Le système est basé sur la création et la mise à disposition pour la CSSF d’un établissement de crédit tenant fichier par chacun des professionnels, en ce qui concerne des comptes de des paiement 2, des comptes bancaires identifiés par un numéro IBAN et des coffres- coffres-forts au forts tenus par des établissements de crédit, excluant ainsi les comptes tenus Luxembourg pour des besoins internes ou techniques. La CSSF, en sa capacité de gestionnaire, accédera aux fichiers respectifs des professionnels par moyen d’une procédure sécurisée afin de pouvoir procéder à des recherches. Les annexes de la circulaire apportent des précisions sur la structure du fichier et le détail des données à y renseigner, la mise en place et la sauvegarde, la confidentialité et la sécurité dudit fichier. Et dont la mise en place est requise pour le 10 septembre 2020 au plus tard selon les exigences de l’article 67
(1)de la Directive (UE) 2015/849 telle que modifiée par la Directive (UE) 2018/
  1. 1 2 Voir également les Q&A de la CSSF du 3 juin 2020 portant sur la définition de comptes de paiement, sous le lien suivant : https://www.cssf.lu/wp-content/uploads/QA_payment_account_definition.pdf CIRCULAIRE CSSF 20/747 2/4 L’annexe 1 décrit les modalités techniques que les professionnels sont appelés à suivre strictement. L’annexe 2 décrit la structure du fichier de données attendu par la CSSF. La CSSF rappelle que les professionnels sont responsables de l’exactitude et du caractère complet des données qu’ils ont l’obligation de renseigner dans leurs fichiers auxquels la CSSF accède dans le cadre du système électronique central de recherche de données. Concernant les données que l’annexe 2 présente comme étant à inclure à titre « optionnel » dans le fichier mis à disposition de la CSSF, il est précisé qu’à partir du moment où les professionnels disposent de ces données dans leur système, ils ont l’obligation de les faire figurer dans les fichiers auxquels la CSSF accédera. Il convient de noter que l’obligation de mise en place du fichier de données concerne les comptes de paiement et les comptes bancaires identifiés par un numéro IBAN, au sens du règlement (UE) n° 260/2012, existants à la date d’entrée en vigueur de la loi du 25 mars 2020 et donc le 26 mars 2020, ou clôturés depuis cette date, ainsi que les comptes ouverts après cette date. Il est également à noter que ladite obligation concerne les coffres-forts en location en date du 26 mars 2020, ou clôturés depuis cette date, ainsi que les coffres-forts mis en location après cette date. Pour tout compte de paiement et compte bancaire identifié par un numéro IBAN, ainsi que tout coffre-fort clôturé après le 26 mars 2020, les durées de conservation de l’article 3, paragraphe 6, de la loi modifiée du 12 novembre 2004 relative à la lutte contre le blanchiment et contre le financement du terrorisme s’appliquent. Claude WAMPACH Directeur Marco ZWICK Directeur Françoise KAUTHEN Claude MARX Directeur Directeur général CIRCULAIRE CSSF 20/747 Jean-Pierre FABER Directeur 3/4 Commission de Surveillance du Secteur Financier 283, route d’Arlon L-2991 Luxembourg (+352) 26 25 1-1 direction@cssf.lu www.cssf.lu CIRCULAIRE CSSF 20/747 4/4 Circular CSSF 20/747 Technical modalities relating to the application of the Law of 25 March 2020 establishing a central electronic data retrieval system related to payment account and bank accounts identified by IBAN and safe-deposit boxes held by credit institutions in Luxembourg (the “Law”) CIRCULAR CSSF 20/747 1/4 In case of discrepancies between the French and the English text, the French text shall prevail. Circular CSSF 20/747 Re: Technical modalities relating to the application of the Law of 25 March 2020 establishing a central electronic data retrieval system related to payment account and bank accounts identified by IBAN and safe-deposit boxes held by credit institutions in Luxembourg (the “Law”) Ladies and Gentlemen, Luxembourg, 23 July 2020 The Law of 25 March 2020 (“the Law”) establishes a central electronic data To all credit institutions and retrieval system related to payment accounts and bank accounts identified by payment service providers in IBAN and safe-deposit boxes held by credit institutions in Luxembourg. Luxembourg offering payment account services or bank account services for accounts identified by IBAN, within the meaning of Regulation (EU) No 260/2012 of the European This circular aims at providing the professionals, as defined in point 6 of Article 1 of the Law, with the necessary details in view of setting up and implementing in their IT systems, the technical infrastructure required to allow the central electronic data retrieval system established and managed by the CSSF to operate efficiently between the CSSF and professionals
  2. Parliament and of the Council of The purpose of this circular is more precisely to provide the professionals with 14 March 2012 establishing an insight into the technical and IT related aspects of the central electronic data and business retrieval system in order to allow them to adapt their systems accordingly and credit assure conformity with the particular technical requirements of the system as technical requirements for transfers and direct debits in euro and amending Regulation (EC) No 924/2009, as well as to any credit institution holding safe-deposit boxes in Luxembourg established by the CSSF. The system is based on creating and making a file available to the CSSF by each of the professionals with regard to payment accounts 2, bank accounts identified by IBAN and safe-deposit boxes held by credit institutions, excluding thus accounts held for internal or technical purposes. The CSSF, in its capacity as manager of the central electronic data retrieval system, will access the respective files submitted by the professionals, by means of a secure procedure in order to be able to conduct researches. The circular’s annexes break down the structure of the file and data to be entered, and provide details on the creation, backup, confidentiality and security of said file. Annex 1 describes the technical modalities the professionals are required to strictly follow. The setup of such a system is required by 10 September 2020 at the latest in accordance with the requirements of Article 67
(1)of Directive (EU) 2015/849, as amended by Directive (EU) 2018/843. 1 2 Cf. also the CSSF Q&A of 3 June 2020 on payment account definition, under the following link: https://www.cssf.lu/wp-content/uploads/QA_payment_account_definition.pdf CIRCULAR CSSF 20/747 2/4 Annex 2 describes the structure of the data file to be submitted by the professionals to the CSSF. The CSSF reminds that professionals are responsible for the accuracy and completeness of the data they are required to enter in their files, which the CSSF accesses within the framework of the central electronic data retrieval system. As regards the data which, according to Annex 2, can be optionally registered within the file made available to the CSSF, it is noted that if professionals have these data in their system, they are required to reflect them in the files which the CSSF will access. It should be pointed out that the obligation to create a data file applies to payment accounts and bank accounts identified by IBAN, within the meaning of Regulation (EU) No 260/2012, which exist at the date of entry into force of the Law of 25 March 2020, i.e. on 26 March 2020, or which are closed since that date, as well as the accounts that were opened after that date. It should also be noted that this obligation concerns safe-deposit boxes leased on 26 March 2020, or closed since that date, as well as safe-deposit boxes leased out after that date. For all payment accounts and bank accounts identified by IBAN as well as all safe-deposit box closed after 26 March 2020, the retention periods laid down in Article 3
(6)of the Law of 12 November 2004 on the fight against money laundering and terrorist financing, as amended, shall apply. Claude WAMPACH Director Marco ZWICK Director Françoise KAUTHEN Claude MARX Director Director General CIRCULAR CSSF 20/747 Jean-Pierre FABER Director 3/4 Commission de Surveillance du Secteur Financier 283, route d’Arlon L-2991 Luxembourg (+352) 26 25 1-1 direction@cssf.lu www.cssf.lu CIRCULAR CSSF 20/747 4/4 Annexe 1 Suivi des versions Version Date Commentaires 0.1 16/06/2020 Draft 1.0 21/07/2020 Version 1 – publication officielle 2.0 04/09/2020 Version 2 – publication officielle - Modifications concernant la procédure d’enrôlement - Modifications concerannt l’authentification de la CSSF auprès du professionnel - Ajout des spécifications concernant le stockage des fichiers / clarification sur la fréquence d’envoi - Ajout d’informations concernant les environnements mis à disposition par la CSSF - Informations supplémentaires à fournir pour la demande de création de compte MFT 2.1 22/06/2022 Version 2.1 – publication officielle Modification concernant la fréquence d’envoi des fichiers Table des matières 1. Architecture générale ............................................................................. 4 2. Enrôlement ........................................................................................... 6 2.1. Principe .......................................................................................... 6 2.2. Protection du canal sécurisé .............................................................. 6 3. Interfaces d’échanges ............................................................................ 7 3.1. Authentification des APIs................................................................... 7 3.2. API fournie par les professionnels ....................................................... 7 3.3. API fournie par la CSSF ..................................................................... 8 3.3.1. API d’authentification HTTP .......................................................... 8 3.3.2. API d’enrôlement ........................................................................ 8 3.3.3. API de réinitialisation .................................................................. 9 3.3.4. API de notification ...................................................................... 9 3.3.5. API de récupération des clés PGP publiques ................................. 10 4. Echange de fichiers .............................................................................. 10 4.1. Le fichier mis en place par le professionnel ........................................ 10 4.1.1. Fréquence d’envoi .................................................................... 10 4.1.2. Unicité du téléchargement ......................................................... 10 4.1.3. Sécurité des fichiers .................................................................. 11 4.1.4. Structure du fichier ................................................................... 11 4.1.5. Reprise des données ................................................................. 11 4.2. Le fichier de retour/réponse de la CSSF ............................................ 12 4.2.1. Structure du retour ................................................................... 12 4.2.2. Exemples de retours ................................................................. 13 4.2.3. Modalités en cas de rejet ........................................................... 14 5. Stockage des fichiers ........................................................................... 15 6. Informations diverses ........................................................................... 15 6.1. Environnements ............................................................................. 15 6.2. Disponibilité du fichier de données ................................................... 15 6.3. Demande d’accès par MFT ............................................................... 16 6.4. Informations de contact auprès de la CSSF........................................ 16 1. Architecture générale Afin de mettre en place le système électronique central de recherche des données tel que défini dans la présente circulaire, le professionnel doit mettre à disposition dans son système informatique, un fichier de données auquel la CSSF accédera. L’approche générale : 1. Sur base journalière, le professionnel doit constituer dans son système informatique les fichiers de données concernant toute information relative aux comptes de paiements, aux comptes bancaires et/ou aux coffres-forts », selon le format défini dans l’annexe 2 (cf. §4.1.4 « Structure du fichier ») 2. Le professionnel met à disposition le fichier et prévient la CSSF de sa disponibilité [Etape 1 : « Registry ready » du schéma d’architecture] ; 3. La CSSF se connecte et télécharge le fichier [Etape 2 : « download registry » du schéma d’architecture] ; 4. La CSSF envoie aux professionnels un fichier de retour (feedback) incluant le statut du fichier téléchargé : accepté ou rejeté incluant les erreurs rencontrées. En cas de rejet, un fichier corrigé doit être mis à disposition de la CSSF. (cf. §4.2 « Retour/Réponse CSSF »). 5. Le professionnel est responsable de la sécurisation du fichier mis à disposition. Il pourra par exemple le supprimer une fois le fichier téléchargé par la CSSF. Afin de s’identifier auprès de la CSSF et de mettre à disposition son fichier le professionnel doit implémenter une interface de communication spécifique, dite « Application Programming Interface », (« API »). 2. Enrôlement 2.1. Principe Pour garantir le bon fonctionnement du nouveau canal de sécurité entre le professionnel et la CSSF, il est nécessaire de procéder à une phase d’initialisation, permettant d’échanger différents types d’informations de sécurité. La procédure d’enrôlement, l’API détaillée et les détails d’implémentation technique seront fournis aux professionnels moyennant une demande spécifique qui devra parvenir à la CSSF une fois la présente circulaire publiée (cf. 5.3 Demande d’accès par MFT). Veuillez trouver ci-dessous les grandes étapes de la phase d’enrôlement : 1. Initialisation : La CSSF fournit les clés RSA privées et publiques du professionnel qui seront utilisées pour l'initialisation de la connexion sécurisée entre le professionnel et la CSSF. La clé privée envoyée est protégée par un mot de passe (passphrase) qui sera envoyé par la CSSF au professionnel via un autre canal sécurisé. Le professionnel récupère la clé publique RSA de la CSSF correspondant à son certificat client TLS ainsi que les clés publiques PGP nécessaires au chiffrement des fichiers ; 2. Toute communication entre la CSSF et le professionnel utilise au minimum une authentification « Mutual TLS » ; 3. Le professionnel fournit une API permettant à la CSSF d’envoyer les identifiants « HTTP » du professionnel utilisés pour s’authentifier auprès de la CSSF ; 4. Les clés publiques PGP des professionnels, utilisées pour signer les fichiers envoyés et déchiffrer les fichiers reçus, sont publiées par chaque professionnel dans l’API d’enrôlement de la CSSF. 2.2. Protection du canal sécurisé L’échange des fichiers et l’accès à l’API se font par le biais d’une connexion Internet chiffrée en HTTPS et authentifiée à l’aide de certificats TLS mutuels. La présence d’une API du côté de la CSSF et d’une API coté professionnel implique l’utilisation de deux canaux HTTPS différents (l’un du professionnel vers la CSSF et l’autre de la CSSF vers le professionnel). Chacun de ces deux canaux est pourvu d’une authentification par certificat client (TLS mutuel). La CSSF met en œuvre une liste blanche des adresses IP pouvant accéder à ses API. Une liste blanche doit également être maintenue par le professionnel concernant les accès réalisés par la CSSF. Les certificats utilisés pour l’authentification mutuelle sont signés par l’autorité de certification de la CSSF et sont fournis aux professionnels. Les spécifications techniques concernant cette authentification TLS sont les suivantes : - - La CSSF doit fournir la clé publique de son certificat client et la chaine de confiance complète (« Chain file ») au professionnel ; Les deux connexions HTTPS (du professionnel vers la CSSF, et vice versa) doivent utiliser des protocoles de chiffrements robustes et dépourvus de failles connues, tant pour le chiffrement de la connexion, l’échange de clé et le mécanisme de hachage ; Le protocole TLSv1.2 minimum doit être mis en œuvre. Certaines des API exposées par la CSSF seront également authentifiées au niveau HTTP (à l’aide d’un identifiant et d’un mot de passe, générant un token JWT). 3. Interfaces d’échanges 3.1. Authentification des APIs Le professionnel doit s’authentifier en HTTP lors de certains appels API vers la CSSF. Le but de cette authentification est de limiter les appels à l’API en plus de la partie certificat client HTTPS. Le professionnel utilise alors un compte de service fourni par la CSSF. Le cycle de vie des mots de passe est géré par la CSSF. 3.2. API fournie par les professionnels Chaque professionnel doit mettre à disposition une API liée à la récupération du fichier pour la construction du registre central de recherche. Le professionnel peut obtenir les détails techniques de cette API par l’intermédiaire du point de contact défini par la CSSF (registre.compte@cssf.lu). Ces détails techniques sont fournis au format OpenAPI v3.0 (OpenAPI). L’API à fournir par le professionnel propose, de manière sécurisée, les services suivants : - Mise à disposition d’un fichier contenant l’ensemble des informations attendues par la CSSF (cf. Notification) Réception du feedback CSSF informant les professionnels sur le statut du fichier (cf. Retour de la CSSF) Réception des identifiants utilisés par le professionnel pour se connecter auprès de la CSSF. 3.3. API fournie par la CSSF La CSSF expose plusieurs API : - L’API d’authentification http ; L’API enrôlement ; L’API de réinitialisation ; L’API de notification ; L’API de récupération des clés PGP publiques. 3.3.1. API d’authentification HTTP Cette API permet au professionnel d’obtenir un token JWT utilisable sur le reste des API. Pour ce faire, le professionnel doit fournir les identifiants HTTP préalablement fournis par la CSSF. Cette API n’est disponible que sur présentation d’un certificat client TLS valide. 3.3.2. API d’enrôlement L’API d’enrôlement permet l’enregistrement des professionnels dans le système. Elle permet au professionnel de transmettre les informations suivantes : - Adresse web de l’API du professionnel, où les fichiers vont être récupérés Adresses IP utilisées par le professionnel pour appeler les API de la CSSF Clé PGP publique pour la signature des fichiers envoyés à la CSSF Clé PGP publique pour le déchiffrement des fichiers reçus par le professionnel Les clés PGP seront fournies au format ASCII Armor. 3.3.3. API de réinitialisation Suite à un enrôlement réussi, le professionnel reçoit en confirmation un code de sécurité (reset token) qui lui servira à initier une nouvelle phase d’enrôlement dans un des cas suivants : - Changement d’une ou plusieurs clés PGP du professionnel ; Changement de l’adresse web de l’API du professionnel ; Changement d’adresses IP utilisées par le professionnel pour appeler les API de la CSSF ; Révocation du certificat client HTTPS du professionnel ; Changement de mot de passe du professionnel. 3.3.4. API de notification L’API de notification instruit la CSSF de la présence d’un fichier à télécharger. 3.3.5. API de récupération des clés PGP publiques Cette API est publiée par la CSSF. Elle permet au professionnel de récupérer 2 clés PGP : - la clé PGP publique permettant de vérifier la signature de la CSSF la clé PGP publique permettant de chiffrer les fichiers à envoyer à la CSSF. 4. Echange de fichiers 4.1. Le fichier mis en place par le professionnel 4.1.1. Fréquence d’envoi Le professionnel doit fournir à la CSSF un nouveau fichier complet (« FULL ») et valide, contenant toutes les données visées à l’annexe 2 de la présente circulaire, relatives aux comptes de paiements, aux comptes bancaires et/ou aux coffres-forts, reflétant l’état des informations des professionnels au jour J. Le professionnel doit mettre à disposition ce registre tous les jours du lundi au vendredi uniquement, hormis les jours fériés publics et bancaires à Luxembourg. Sauf situation exceptionnelle qui devra, dans la mesure du possible, être communiquée à la CSSF à l’avance, la notification à la CSSF de la mise à disposition du fichier du jour J par le professionnel est attendue entre le jour J à 18h et le jour J+1 à 6h (heures de Luxembourg). Dans le cas où aucune modification ou ajout n’ont eu lieu, la CSSF s’attend à recevoir les mêmes données que la veille. Chaque ajout ou modification des informations que la CSSF s’attend à recevoir doit être mis à disposition dans les 24h au plus tard. 4.1.2. Unicité du téléchargement Le fichier mis à disposition à la CSSF par le professionnel ne sera téléchargé que via une URL à usage unique. Cette URL comporte un « token » unique transmis lorsque le professionnel prévient la CSSF de la disponibilité du fichier pour téléchargement. De multiples appels sur une URL unique devraient générer une alerte dans le système d’information du professionnel. Dans le cas d’un échec de téléchargement (par exemple, si une erreur survient durant le téléchargement du fichier par la CSSF), le professionnel devra renotifier le CSSF avec un nouveau token et invalider l’ancien. 4.1.3. Sécurité des fichiers Le fichier envoyé par le professionnel doit être chiffré et compressé en PGP avec une clé publique fournie par la CSSF et signée avec une clé privée PGP du professionnel. Le fichier envoyé par la CSSF au professionnel lui notifiant le statut de l’envoi doit être chiffré et compressé en PGP avec une clé publique PGP fournie par le professionnel et signée avec une clé privée PGP de la CSSF. Les spécifications techniques concernant le chiffrement PGP des fichiers sont les suivantes : - - - Les clés publiques PGP sont conservées par la CSSF pendant 20 ans, même après un renouvellement de clé afin de garantir la non répudiation ; Les clés privées PGP doivent avoir au minimum 4096 bits (RSA) ou 256 bits en courbes elliptiques ; Les clés PGP du professionnel doivent avoir une durée de validité d’au moins 2 ans. A l’issue de ces deux années, la CSSF se réserve le droit de demander un renouvellement des clés ; Les fichiers envoyés doivent être au format PGP binaire ; les clés PGP sont elles au format ASCII Armor. 4.1.4. Structure du fichier L’annexe 2 présente la structure du fichier au format JSON attendu, les informations obligatoires ou optionnelles, ainsi que leur format, et un fichier exemple de valeurs possibles. Les informations doivent être encodées au format UTF8. Note : La CSSF conseille aux professionnels d’utiliser le validateur JSON qui sera mis à leur disposition ou d’implémenter leur propre validateur. Celui-ci doit permettre de vérifier la validité de leur fichier de données, de relever et de notifier les éventuelles erreurs d’encodage avant l’échange. Le validateur JSON mis à disposition du professionnel sera identique à celui utilisé par la CSSF pour valider les fichiers reçus quotidiennement. 4.1.5. Reprise des données Dans le cas où le professionnel souhaite corriger ou mettre à jour des informations dans le fichier du jour, il garde la possibilité de fournir à la CSSF un nouveau fichier de données comportant les nouvelles informations. De même, si le professionnel reçoit un fichier de retour de la CSSF comportant des erreurs (voir §4.2), il doit corriger les erreurs associées et envoyer un nouveau fichier valide en respectant les délais prévus par la loi. 4.2. Le fichier de retour/réponse de la CSSF 4.2.1. Structure du retour La CSSF envoie à la fin du traitement de chaque fichier de données des professionnels, un fichier de retour (« feedback ») concernant le traitement du fichier. Cet appel est initié par la CSSF et utilise l’API fournie par les professionnels (cf. §1.1). Ce fichier de retour est structuré en JSON comme décrit par le schéma OpenAPI v3.0 (OpenAPI) suivant : openapi: 3.0.0 info: version: 1.0.0 initial_file_key: emprunte du fichier initial de type SHA-512 components: feedback: title: Statut de traitement du fichier type: object properties: status: type: string enum: [ACPT, RJCT] description: Statut du fichier reçu par la CSSF. Si le fichier est au statut RJCT, l'entité doit corriger le fichier et notifier à nouveau la CSSF de sa disponibilité. fileid: type: string pattern: '^[A-Z]\d{8}-\d+$' description: Identifiant unique du fichier téléchargé. ID qui doit provenir d'une notification envoyée à la CSSF. Il doit commencer par l'identificateur d'entités «-» valeur de séquence du fichier. errors: type: array items: type: object properties: id: type: string pattern: '^CSSF-\d{3}$' description: Code d'identification de l'erreur message: type: string description: Details du message d'erreur required: - status - fileid 4.2.2. Exemples de retours Le JSON suivant est un exemple de retour en cas d’acceptation par la CSSF : { "status":"ACPT" "initial_file_key":"c672b8d1ef56ed28ab87c3622c5114069bdd3ad7b8f9737498d0c 01ecef0967a" } Le JSON suivant est un exemple de refus par la CSSF : { "status": "RJCT" "initial_file_key":"c672b8d1ef56ed28ab87c3622c5114069bdd3ad7b8f9737498d0c01e cef0967a" "errors": [ { "uuid": "QQOIUZHGF3GH45IK" "id": "CSSF-999" "message": "Wrong IBAN format" } ] } 4.2.3. Modalités en cas de rejet Si le retour de la CSSF contient un statut rejeté « RJCT », le professionnel doit fournir à la CSSF un nouveau fichier de données jusqu’à ce qu’il obtient un statut accepté « ACPT ». 5. Stockage des fichiers Le professionnel a pour obligation de stocker quotidiennement le dernier fichier accepté par la CSSF pour le jour courant ainsi que la preuve d’acceptation (fichier de retour fourni par la CSSF). La CSSF gardera également une copie du fichier de retour ; afin de vérifier l’intégrité de ces fichiers, elle générera et stockera plusieurs empreintes de type Hash pour chacun des fichiers stockés. Le délai de conservation obligatoire est de 5 ans conformément aux dispositions prévues par l’article 3, paragraphe 6, de la loi modifiée du 12 novembre 2004 relative à la lutte contre le blanchiment et contre le financement du terrorisme. 6. Informations diverses 6.1. Environnements En plus de l’environnement de production, la CSSF mettra à disposition un environnement de test. Il est demandé au professionnel d’effectuer des tests de mise à disposition du fichier de données sur cet environnement avant passage à l’environnement de production. Les fichiers mis à disposition par le professionnel dans l’environnement de test devront contenir des données anonymisées. 6.2. Disponibilité du fichier de données Le professionnel s’engage à garantir un niveau de disponibilité de service suffisant pour transmettre les informations contenues au sein de leur fichier, au moins une fois toutes les 24h à la CSSF. Le fichier doit être disponible au téléchargement une fois la notification envoyée à la CSSF et jusqu’à la fin du téléchargement du fichier. La plateforme du professionnel peut être indisponible le reste du temps. En cas de non réponse de la CSSF, le professionnel continuera à notifier la CSSF toutes les 10 minutes tant que le fichier n’a pas été récupéré par celle-ci. 6.3. Demande d’accès par MFT Les documents relatifs aux détails techniques sont transmis de manière sécurisée au professionnel par la CSSF au moyen de son système dit Managed File Transfer (« MFT »). Afin d’obtenir un identifiant permettant la connexion au système en ligne, le professionnel renseignera à la CSSF par envoi à l’adresse de courriel électronique registre.compte@cssf.lu les informations suivantes : - Numéro signalétique attribué par la CSSF (de type « Bxxx ») - Nom de l’organisation - Nom et prénom de la personne responsable en matière d’envoi - Adresse de courriel principale de contact 1 - Seconde adresse de courriel de contact à laquelle une partie des informations d’identification sera envoyée1 - Téléphone de contact - Si le professionnel délègue une ou plusieurs des obligations prévues par la loi du 25 mars 2020, préciser quel(
  1. s)sera (respectivement seront) le(
  2. s)prestataire(
  3. s)choisi pour remplir chacune d’elles. 6.4. Informations de contact auprès de la CSSF Toute question technique registre.compte@cssf.lu est à adresser à l’adresse électronique Il est requis que les adresses de contacts principale et secondaire fournies soient différentes et génériques, c’est-à-dire qu’elles ne soient pas nominativement attribuées à une personne physique. Il est requis que ces adresses ne soient pas accessibles par les mêmes personnes. 1 Annex 1 Version tracking Version Date Comments 1.0 21/07/2020 Version 1 – Official publication 2.0 04/09/2020 Version 2 – Official publication - 2.1 24/06/2022 Modification of the enrolment procedure Modification of CSSF’s authentication to the professional interface Additional information of file storage/clarification on the frequency of file sending Additional information on the environment made available by the CSSF Additional information to be provided for the MFT account creation request Version 2 – Official publication Update on file exchange frequency CONTENTS 1. 2. 3. 4. 5. 6. General architecture Enrolment 2.1 Principle 2.2 Secure channel protection Exchange interfaces 3.1 API authentication 3.2 API provided by professionals 3.3 API provided by the CSSF Exchange of files 4.1 File established by professionals 4.2 CSSF Feedback/Answer File storage Various information 6.1 Environments 6.2 Data file availability 6.3 Access request via MFT 6.4 Contact information at the CSSF CIRCULAR CSSF 20/747 2 3 3 4 4 4 5 5 7 7 8 10 11 11 11 11 12 1/12 1. General architecture For the purposes of setting up a central electronic data retrieval system, as defined in this circular, professionals shall make a data file available, in their IT system, which the CSSF will have access to. General approach: 1. Professionals shall prepare on day to day basis, in their IT system, data files related to information on payment accounts, bank accounts identified by IBAN (hereinafter “bank accounts”) and/or safe-deposit boxes. The files shall comply with the format defined in annex 2 (cf. §4.1.4 “Structure of the file”); 2. Professionals shall make the file available and notify the CSSF of its availability [Step 1: “Registry ready” of the architectural pattern]; CIRCULAR CSSF 20/747 2/12 3. The CSSF connects to the professional interface and downloads the file 4. The CSSF notifies the professionals with a feedback containing the status [Step 2: “Download registry” of the architectural pattern]; of the file processing: accepted or rejected and the list of errors encountered when relevant. In case of failure, , a corrected file shall be made available to the CSSF (cf. §4.2 CSSF Feedback/Answer”); 5. Professionals are in charge of securing this file provided. Professionals should foresee, for example, to delete it once the file has been downloaded by the CSSF. To identify themselves with the CSSF and to make their file available, professionals shall implement a specific communication interface, the socalled “Application Programming Interface”, (“API”). 2. Enrolment 2.1 Principle In order to set up a secure channel between the CSSF and the professional, an initialisation phase called enrolment must be conducted. During this phase, the CSSF and the professional will exchange through a secure way, security and identification information. All the necessary information (the enrolment procedure, the detailed API and the technical implementation details) will be provided to professionals. The professional shall address a specific request to the CSSF once the circular has been published (cf. §5.3 “Access request via MFT”). Please find below the major steps of the enrolment phase: 1. Initialisation The CSSF provides the professionals’ private and public RSA keys which will be used for the initialisation of the secure connection between professionals and the CSSF. This private key is protected by a password (passphrase) which will be sent by the CSSF to professionals via another secure channel. Professionals receive via an API the CSSF’s RSA public key corresponding to their TLS client certificate as well as the PGP public keys used for the file encryption; 2. Any communication between the CSSF and the professional uses at least “Mutual TLS” authentication. 3. The professional exposes an API to the CSSF to send the professional “HTTP” identifiers used to identify itself to the CSSF. CIRCULAR CSSF 20/747 3/12 4. Professionals’ PGP public keys, which are used to sign the files sent and to decrypt files received, are made available by each professional through the CSSF’s enrolment API. 2.2 Secure channel protection The exchange of files and the access to the API are performed through HTTPSencrypted Internet connections. The connection is authenticated via a mutual TLS certificate. Two APIs (one from CSSF’s side and one from professionals’ side) are made available. This requires to use two different HTTPS channels: one, from professionals to the CSSF, and the other, from the CSSF to professionals. Both channels include a customer certificate authentication (mutual TLS). The CSSF maintains a white list of IP addresses that are authorised to access its APIs. A white list shall also be maintained by professionals with respect to the access achieved by the CSSF. The certificates used for the mutual authentication are signed by the CSSF’s certification authority and will be provided to professionals. The technical specifications regarding this TLS authentication are as follows: - The CSSF shall provide a public key of its client certificate and a complete trust chain file to the professional; - Both HTTPS connections (from the professional to the CSSF, and viceversa) shall include strong encryption protocols without known issue for the connection encryption, key exchange and hashing mechanism; - The minimum TLSv1.2 protocol shall be implemented. Some APIs used by the CSSF will also be authenticated at HTTP level (using a username and a password, that will generate a JWT token). 3. Exchange interfaces 3.1 API authentication When calling the professional’s API, the CSSF shall authenticate using HTTP. The aim of this authentication is to limit calls to the API in addition to the HTTPS client certificate. The professional then uses credentials provided by the CSSF The life cycle of passwords is managed by the CSSF CIRCULAR CSSF 20/747 4/12 3.2 API provided by professionals Each professional shall make available an API to enable the file retrieval. Professionals may request to get more technical details on this API through the contact point defined by the CSSF (registre.compte@cssf.lu). These technical details will be provided in OpenAPI v3.0 (OpenAPI). The API provided by the professional allows in a secure way, to exchange the following information: - the daily file including all the information expected by the CSSF (cf. “Notification”); - the feedback provided by the CSSF that informs professionals of the file’s - identifiers used by the professional to connect to the CSSF interface. status (cf. “CSSF feedback”). 3.3 API provided by the CSSF The CSSF provides several APIs: - HTTP authentication API; - Enrolment API; - Reset API; - Notification API; - The Public PGP Keys Recovery API. 3.3.1 HTTP authentication API This API allows the professional to retrieve a JWT token which will be used on the other the APIs. To do so, the professional must provide HTTP user identifications previously provided by the CSSF. This API is only available on presentation of a valid TLS client certificate. 3.3.2 Enrolment API Enrolment 1. Call to the enrolment API 2. CSSF feedback on several channels Entity CIRCULAR CSSF 20/747 CSSF 5/12 The enrolment API allows professionals registration into the system. It allows professionals to share the following information: - Web address of the professional’s API where the files will be retrieved; - IP addresses used by the professional to call the CSSF’s APIs; - Public PGP key for the files signature sent to the CSSF - Public PGP key for files decryption received by the professional. PGP keys will be provided into the Armor ASCII format. 3.3.3 Reset API Professionals receive a confirmation security code (reset token) that will be used in case of a new enrolment phase. The new enrolment shall occur in the following cases: - Change of one or several professional’s PGP keys; - Change of the professional’s API website; - Change of IP contact addresses used by the professional for calling the CSSF’s APIs. - Revocation of the professional's HTTPS client certificate - Change of the professional’s password. 3.3.4 Notification API Notification API informs the CSSF about a file to download. 3.3.5 Public PGP key retrieval API This API is published by the CSSF. It allows the professional to receive two PGP keys: - The public PGP key allowing to verify the CSSF’s signature - The public PGP key allowing to encrypt files to send to the CSSF. CIRCULAR CSSF 20/747 6/12 4. Exchange of files 4.1 File established by professionals 4.1.1 Frequency of transmission Professionals shall provide the CSSF with a new valid and full file (“FULL”), that contains all the data referred to in annex 2 of this circular, relating to payment accounts, bank accounts and/or safe-deposit boxes. The professionals must provide with the most recent information available on D - day. A file shall be made available to the CSSF from Monday to Friday, at least once a day (excluding weekends and Luxembourg public and bank holidays). Unless there is a special situation that, where possible, will have to be communicated to the CSSF in advance, the notification to the CSSF of the file availability on the day D by the professional is expected between the day D 6 p.m. and the day D+1 6 a.m (Luxembourg time). If there is no change or modification in the information to be provided, the CSSF expects to receive the same data as the previous day. Each new entry or modification of the information previously reported shall be made available within no more than 24 hours later. 4.1.2 Single download The file made available to the CSSF by professionals will be downloaded via a single-use URL. This URL includes a single token transmitted when the professional notifies the CSSF that the file is available for download. Several calls that URL should generate an alert in the professionals’ IT system. In the case of a download failure (for example, if an error occurs while downloading the file by the CSSF), the professional will have to notify again the CSSF with a new token and to invalidate the older one. 4.1.3 File Security The file sent by the professional must be encrypted and compressed using PGP with a public key provided by the CSSF and signed with a private PGP key of the professional. The file sent by the CSSF to the professional notifying the daily file processing status, must be encrypted and compressed in PGP with a PGP key provided by the professional and signed with a CSSF’s PGP private key. The technical specifications regarding the PGP encryption of the files are as follows: CIRCULAR CSSF 20/747 7/12 - PGP public keys are kept by the CSSF during 20 years even after a key - The PGP private keys shall support at least 4096 bits (RSA) or 256 in renewal in order to guarantee non-repudiation; elliptical curves; - The PGP keys of the professional shall have a validity of at least 2 years. After these two years, the CSSF may request renewal of the keys. - Files sent shall be in PGP binary format; PGP keys are in the ASCII Armor format. 4.1.4 File structure The Annexe 2 presents the description of the data expected and outlines the structure of the file in the expected JSON format, the optional or mandatory information, as well as their format, and an example file of possible values. The information shall be encrypted in UTF8 format. Note: The CSSF recommends professionals to check the validity of their data file either against the JSON validator that will be made available to them or against their own validator. This should allow to identify and notify possible encoding errors prior to the exchange. The JSON validator made available to the professional will be the same as the one used by the CSSF to validate files received daily. 4.1.5 Data recovery In the case the professionals would like to correct or update information already provided into the file of the day, they shall provide a new data file including new information. When the professional receives a feedback file from the CSSF including errors (See §4.2), he has to correct them, and send a new valid file respecting the legal deadlines. 4.2 CSSF Feedback/Answer 4.2.1 Feedback structure At the end of the processing of the professional’ data file, the CSSF sends a feedback about the file processing. This call shall be initiated by the CSSF using the API provided by professionals (cf. §3.2). This feedback file is JSON-structured as described in the following OpenAPI v3.0 schema (OpenAPI): CIRCULAR CSSF 20/747 8/12 openapi: 3.0.0 info: version: 1.0.0 initial file key: borrow from the initial file SHA-512 type components: feedback: title: File processing status type: object properties: status: type: string enum: [ACPT, RJCT] description: Status of the file received by the CSSF. If the file status is RJCT, the entity must correct the file and re-notify the CSSF of its availability. fileid: type: string pattern: '^[A-Z]\d{8}-\d+$' description: Unique identifier of the downloaded file. ID which shall be included in a notification sent to the CSSF. It shall start with the entities identifier «-» value sequence of the file. errors: type: array items: type: object properties: id: type: string pattern: '^CSSF-\d{3}$' description: Identification code of the error message: type: string description: Details on the error message required: - status - fileid 4.2.2 Feedback examples The following JSON is an example of an accepted feedback: CIRCULAR CSSF 20/747 9/12 { "status": "ACPT" "initial_file_key": "B99999999-1" } The following JSON is an example of rejected feedback { "status": "RJCT" "initial_file_key":c672b8d1ef56ed28ab87c3622c5114069bdd3ad7b8f9737498d0c01ece f0967a" "errors": [ { "uuid": "QQOIUZHGF3GH45IK" "id": "CSSF-999" "message": "Wrong IBAN format" } ] } 4.2.3 Procedure in case of rejection If the CSSF feedback contains an “RJCT” rejected status, professionals shall provide the CSSF with a new data file until the file is accepted (the feedback status is accepted “ACPT”). 5. File storage The professional has to store on daily basis the last file accepted by the CSSF for the current day as well as the acceptance proof (feedback provided by the CSSF) The CSSF will keep and store the feedback sent to the professional. In order to check the daily file integrity, the CSSF will generate and store several Hash for each of the stored files. CIRCULAR CSSF 20/747 10/12 The mandatory retention period is 5 years according with the provisions of the Article 3 § 6 of the Law of the 12 November 2004 (coordinated version as of March 25, 2020) on the fight against money laundering and terrorism financing. 6. Various information 6.1 Environments In addition to the production environment, the CSSF will set up a test environment. The CSSF requests to the professionals to perform tests during which they make the data file available on this environment, prior to before any transition to the production environment. The files made available by the professional in the test environment must contain anonymized data. 6.2 Data file availability Professionals shall ensure a sufficient level of availability in order to make available, to the CSSF, the file through its interface, at least once every 24 hours. The file shall be available for download once the notification has been sent to the CSSF and until the end of the file download. The professional's platform can be unavailable the remaining time. In the absence of a response by the CSSF, professionals must continue to notify the CSSF every 10 minutes as long as the file has not been downloaded by the CSSF. 6.3 Access request via MFT The documents relating to technical details are transmitted to the professional by the CSSF in a secure way through its online Managed File Transfer (“MFT”) system. In order to obtain an identifier for connection to the online system, professionals shall send an email to the CSSF at registre.compte@cssf.lu with the following information: - The identification number allocated by the CSSF (“Bxxx”); - Name of the entity; - Surname and first name of the person responsible for email sending; CIRCULAR CSSF 20/747 11/12 - Main contact email address 1; - Secondary contact email address to which part of the identification information will be sent. 2 - Contact phone number. - If the professional delegates one or several obligations laid down in the Law of 25 March 2020, the name(
  4. s)of the provider(
  5. s)chosen to fulfil each obligation 6.4 Contact information at the CSSF Any technical question should be submitted to: registre.compte@cssf.lu. 1 It is recommended to use a generic and lasting email address instead of the name address of an employee who might perform other duties over time, or even to leave the firm 2 It is recommended to use a generic and lasting email address instead of the name address of an employee who might perform other duties over time, or even to leave the firm CIRCULAR CSSF 20/747 12/12 Annexe 1 Suivi des versions Version Date Commentaires 0.1 16/06/2020 Draft 1.0 21/07/2020 Version 1 – publication officielle 2.0 04/09/2020 Version 2 – publication officielle - Modifications concernant la procédure d’enrôlement - Modifications concerannt l’authentification de la CSSF auprès du professionnel - Ajout des spécifications concernant le stockage des fichiers / clarification sur la fréquence d’envoi - Ajout d’informations concernant les environnements mis à disposition par la CSSF - Informations supplémentaires à fournir pour la demande de création de compte MFT 2.1 22/06/2022 Version 2.1 – publication officielle Modification concernant la fréquence d’envoi des fichiers Table des matières 1. Architecture générale ............................................................................. 4 2. Enrôlement ........................................................................................... 6 2.1. Principe .......................................................................................... 6 2.2. Protection du canal sécurisé .............................................................. 6 3. Interfaces d’échanges ............................................................................ 7 3.1. Authentification des APIs................................................................... 7 3.2. API fournie par les professionnels ....................................................... 7 3.3. API fournie par la CSSF ..................................................................... 8 3.3.1. API d’authentification HTTP .......................................................... 8 3.3.2. API d’enrôlement ........................................................................ 8 3.3.3. API de réinitialisation .................................................................. 9 3.3.4. API de notification ...................................................................... 9 3.3.5. API de récupération des clés PGP publiques ................................. 10 4. Echange de fichiers .............................................................................. 10 4.1. Le fichier mis en place par le professionnel ........................................ 10 4.1.1. Fréquence d’envoi .................................................................... 10 4.1.2. Unicité du téléchargement ......................................................... 10 4.1.3. Sécurité des fichiers .................................................................. 11 4.1.4. Structure du fichier ................................................................... 11 4.1.5. Reprise des données ................................................................. 11 4.2. Le fichier de retour/réponse de la CSSF ............................................ 12 4.2.1. Structure du retour ................................................................... 12 4.2.2. Exemples de retours ................................................................. 13 4.2.3. Modalités en cas de rejet ........................................................... 14 5. Stockage des fichiers ........................................................................... 15 6. Informations diverses ........................................................................... 15 6.1. Environnements ............................................................................. 15 6.2. Disponibilité du fichier de données ................................................... 15 6.3. Demande d’accès par MFT ............................................................... 16 6.4. Informations de contact auprès de la CSSF........................................ 16 1. Architecture générale Afin de mettre en place le système électronique central de recherche des données tel que défini dans la présente circulaire, le professionnel doit mettre à disposition dans son système informatique, un fichier de données auquel la CSSF accédera. L’approche générale : 1. Sur base journalière, le professionnel doit constituer dans son système informatique les fichiers de données concernant toute information relative aux comptes de paiements, aux comptes bancaires et/ou aux coffres-forts », selon le format défini dans l’annexe 2 (cf. §4.1.4 « Structure du fichier ») 2. Le professionnel met à disposition le fichier et prévient la CSSF de sa disponibilité [Etape 1 : « Registry ready » du schéma d’architecture] ; 3. La CSSF se connecte et télécharge le fichier [Etape 2 : « download registry » du schéma d’architecture] ; 4. La CSSF envoie aux professionnels un fichier de retour (feedback) incluant le statut du fichier téléchargé : accepté ou rejeté incluant les erreurs rencontrées. En cas de rejet, un fichier corrigé doit être mis à disposition de la CSSF. (cf. §4.2 « Retour/Réponse CSSF »). 5. Le professionnel est responsable de la sécurisation du fichier mis à disposition. Il pourra par exemple le supprimer une fois le fichier téléchargé par la CSSF. Afin de s’identifier auprès de la CSSF et de mettre à disposition son fichier le professionnel doit implémenter une interface de communication spécifique, dite « Application Programming Interface », (« API »). 2. Enrôlement 2.1. Principe Pour garantir le bon fonctionnement du nouveau canal de sécurité entre le professionnel et la CSSF, il est nécessaire de procéder à une phase d’initialisation, permettant d’échanger différents types d’informations de sécurité. La procédure d’enrôlement, l’API détaillée et les détails d’implémentation technique seront fournis aux professionnels moyennant une demande spécifique qui devra parvenir à la CSSF une fois la présente circulaire publiée (cf. 5.3 Demande d’accès par MFT). Veuillez trouver ci-dessous les grandes étapes de la phase d’enrôlement : 1. Initialisation : La CSSF fournit les clés RSA privées et publiques du professionnel qui seront utilisées pour l'initialisation de la connexion sécurisée entre le professionnel et la CSSF. La clé privée envoyée est protégée par un mot de passe (passphrase) qui sera envoyé par la CSSF au professionnel via un autre canal sécurisé. Le professionnel récupère la clé publique RSA de la CSSF correspondant à son certificat client TLS ainsi que les clés publiques PGP nécessaires au chiffrement des fichiers ; 2. Toute communication entre la CSSF et le professionnel utilise au minimum une authentification « Mutual TLS » ; 3. Le professionnel fournit une API permettant à la CSSF d’envoyer les identifiants « HTTP » du professionnel utilisés pour s’authentifier auprès de la CSSF ; 4. Les clés publiques PGP des professionnels, utilisées pour signer les fichiers envoyés et déchiffrer les fichiers reçus, sont publiées par chaque professionnel dans l’API d’enrôlement de la CSSF. 2.2. Protection du canal sécurisé L’échange des fichiers et l’accès à l’API se font par le biais d’une connexion Internet chiffrée en HTTPS et authentifiée à l’aide de certificats TLS mutuels. La présence d’une API du côté de la CSSF et d’une API coté professionnel implique l’utilisation de deux canaux HTTPS différents (l’un du professionnel vers la CSSF et l’autre de la CSSF vers le professionnel). Chacun de ces deux canaux est pourvu d’une authentification par certificat client (TLS mutuel). La CSSF met en œuvre une liste blanche des adresses IP pouvant accéder à ses API. Une liste blanche doit également être maintenue par le professionnel concernant les accès réalisés par la CSSF. Les certificats utilisés pour l’authentification mutuelle sont signés par l’autorité de certification de la CSSF et sont fournis aux professionnels. Les spécifications techniques concernant cette authentification TLS sont les suivantes : - - La CSSF doit fournir la clé publique de son certificat client et la chaine de confiance complète (« Chain file ») au professionnel ; Les deux connexions HTTPS (du professionnel vers la CSSF, et vice versa) doivent utiliser des protocoles de chiffrements robustes et dépourvus de failles connues, tant pour le chiffrement de la connexion, l’échange de clé et le mécanisme de hachage ; Le protocole TLSv1.2 minimum doit être mis en œuvre. Certaines des API exposées par la CSSF seront également authentifiées au niveau HTTP (à l’aide d’un identifiant et d’un mot de passe, générant un token JWT). 3. Interfaces d’échanges 3.1. Authentification des APIs Le professionnel doit s’authentifier en HTTP lors de certains appels API vers la CSSF. Le but de cette authentification est de limiter les appels à l’API en plus de la partie certificat client HTTPS. Le professionnel utilise alors un compte de service fourni par la CSSF. Le cycle de vie des mots de passe est géré par la CSSF. 3.2. API fournie par les professionnels Chaque professionnel doit mettre à disposition une API liée à la récupération du fichier pour la construction du registre central de recherche. Le professionnel peut obtenir les détails techniques de cette API par l’intermédiaire du point de contact défini par la CSSF (registre.compte@cssf.lu). Ces détails techniques sont fournis au format OpenAPI v3.0 (OpenAPI). L’API à fournir par le professionnel propose, de manière sécurisée, les services suivants : - Mise à disposition d’un fichier contenant l’ensemble des informations attendues par la CSSF (cf. Notification) Réception du feedback CSSF informant les professionnels sur le statut du fichier (cf. Retour de la CSSF) Réception des identifiants utilisés par le professionnel pour se connecter auprès de la CSSF. 3.3. API fournie par la CSSF La CSSF expose plusieurs API : - L’API d’authentification http ; L’API enrôlement ; L’API de réinitialisation ; L’API de notification ; L’API de récupération des clés PGP publiques. 3.3.1. API d’authentification HTTP Cette API permet au professionnel d’obtenir un token JWT utilisable sur le reste des API. Pour ce faire, le professionnel doit fournir les identifiants HTTP préalablement fournis par la CSSF. Cette API n’est disponible que sur présentation d’un certificat client TLS valide. 3.3.2. API d’enrôlement L’API d’enrôlement permet l’enregistrement des professionnels dans le système. Elle permet au professionnel de transmettre les informations suivantes : - Adresse web de l’API du professionnel, où les fichiers vont être récupérés Adresses IP utilisées par le professionnel pour appeler les API de la CSSF Clé PGP publique pour la signature des fichiers envoyés à la CSSF Clé PGP publique pour le déchiffrement des fichiers reçus par le professionnel Les clés PGP seront fournies au format ASCII Armor. 3.3.3. API de réinitialisation Suite à un enrôlement réussi, le professionnel reçoit en confirmation un code de sécurité (reset token) qui lui servira à initier une nouvelle phase d’enrôlement dans un des cas suivants : - Changement d’une ou plusieurs clés PGP du professionnel ; Changement de l’adresse web de l’API du professionnel ; Changement d’adresses IP utilisées par le professionnel pour appeler les API de la CSSF ; Révocation du certificat client HTTPS du professionnel ; Changement de mot de passe du professionnel. 3.3.4. API de notification L’API de notification instruit la CSSF de la présence d’un fichier à télécharger. 3.3.5. API de récupération des clés PGP publiques Cette API est publiée par la CSSF. Elle permet au professionnel de récupérer 2 clés PGP : - la clé PGP publique permettant de vérifier la signature de la CSSF la clé PGP publique permettant de chiffrer les fichiers à envoyer à la CSSF. 4. Echange de fichiers 4.1. Le fichier mis en place par le professionnel 4.1.1. Fréquence d’envoi Le professionnel doit fournir à la CSSF un nouveau fichier complet (« FULL ») et valide, contenant toutes les données visées à l’annexe 2 de la présente circulaire, relatives aux comptes de paiements, aux comptes bancaires et/ou aux coffres-forts, reflétant l’état des informations des professionnels au jour J. Le professionnel doit mettre à disposition ce registre tous les jours du lundi au vendredi uniquement, hormis les jours fériés publics et bancaires à Luxembourg.Un fichier doit être disponible pour la CSSF au moins une fois par jour, tous les jours (weekend et jours fériés compris). Sauf situation exceptionnelle qui devra, dans la mesure du possible, être communiquée à la CSSF à l’avance, la notification à la CSSF de la mise à disposition du fichier du jour J par le professionnel est attendue entre le jour J à 18h et le jour J+1 à 6h (heures de Luxembourg). Dans le cas où aucune modification ou ajout n’ont eu lieu, la CSSF s’attend à recevoir les mêmes données que la veille. Chaque ajout ou modification des informations que la CSSF s’attend à recevoir doit être mis à disposition dans les 24h au plus tard. 4.1.2. Unicité du téléchargement Le fichier mis à disposition à la CSSF par le professionnel ne sera téléchargé que via une URL à usage unique. Cette URL comporte un « token » unique transmis lorsque le professionnel prévient la CSSF de la disponibilité du fichier pour téléchargement. De multiples appels sur une URL unique devraient générer une alerte dans le système d’information du professionnel. Dans le cas d’un échec de téléchargement (par exemple, si une erreur survient durant le téléchargement du fichier par la CSSF), le professionnel devra renotifier le CSSF avec un nouveau token et invalider l’ancien. 4.1.3. Sécurité des fichiers Le fichier envoyé par le professionnel doit être chiffré et compressé en PGP avec une clé publique fournie par la CSSF et signée avec une clé privée PGP du professionnel. Le fichier envoyé par la CSSF au professionnel lui notifiant le statut de l’envoi doit être chiffré et compressé en PGP avec une clé publique PGP fournie par le professionnel et signée avec une clé privée PGP de la CSSF. Les spécifications techniques concernant le chiffrement PGP des fichiers sont les suivantes : - - - Les clés publiques PGP sont conservées par la CSSF pendant 20 ans, même après un renouvellement de clé afin de garantir la non répudiation ; Les clés privées PGP doivent avoir au minimum 4096 bits (RSA) ou 256 bits en courbes elliptiques ; Les clés PGP du professionnel doivent avoir une durée de validité d’au moins 2 ans. A l’issue de ces deux années, la CSSF se réserve le droit de demander un renouvellement des clés ; Les fichiers envoyés doivent être au format PGP binaire ; les clés PGP sont elles au format ASCII Armor. 4.1.4. Structure du fichier L’annexe 2 présente la structure du fichier au format JSON attendu, les informations obligatoires ou optionnelles, ainsi que leur format, et un fichier exemple de valeurs possibles. Les informations doivent être encodées au format UTF8. Note : La CSSF conseille aux professionnels d’utiliser le validateur JSON qui sera mis à leur disposition ou d’implémenter leur propre validateur. Celui-ci doit permettre de vérifier la validité de leur fichier de données, de relever et de notifier les éventuelles erreurs d’encodage avant l’échange. Le validateur JSON mis à disposition du professionnel sera identique à celui utilisé par la CSSF pour valider les fichiers reçus quotidiennement. 4.1.5. Reprise des données Dans le cas où le professionnel souhaite corriger ou mettre à jour des informations dans le fichier du jour, il garde la possibilité de fournir à la CSSF un nouveau fichier de données comportant les nouvelles informations. De même, si le professionnel reçoit un fichier de retour de la CSSF comportant des erreurs (voir §4.2), il doit corriger les erreurs associées et envoyer un nouveau fichier valide en respectant les délais prévus par la loi. 4.2. Le fichier de retour/réponse de la CSSF 4.2.1. Structure du retour La CSSF envoie à la fin du traitement de chaque fichier de données des professionnels, un fichier de retour (« feedback ») concernant le traitement du fichier. Cet appel est initié par la CSSF et utilise l’API fournie par les professionnels (cf. §1.1). Ce fichier de retour est structuré en JSON comme décrit par le schéma OpenAPI v3.0 (OpenAPI) suivant : openapi: 3.0.0 info: version: 1.0.0 initial_file_key: emprunte du fichier initial de type SHA-512 components: feedback: title: Statut de traitement du fichier type: object properties: status: type: string enum: [ACPT, RJCT] description: Statut du fichier reçu par la CSSF. Si le fichier est au statut RJCT, l'entité doit corriger le fichier et notifier à nouveau la CSSF de sa disponibilité. fileid: type: string pattern: '^[A-Z]\d{8}-\d+$' description: Identifiant unique du fichier téléchargé. ID qui doit provenir d'une notification envoyée à la CSSF. Il doit commencer par l'identificateur d'entités «-» valeur de séquence du fichier. errors: type: array items: type: object properties: id: type: string pattern: '^CSSF-\d{3}$' description: Code d'identification de l'erreur message: type: string description: Details du message d'erreur required: - status - fileid 4.2.2. Exemples de retours Le JSON suivant est un exemple de retour en cas d’acceptation par la CSSF : { "status":"ACPT" "initial_file_key":"c672b8d1ef56ed28ab87c3622c5114069bdd3ad7b8f9737498d0c 01ecef0967a" } Le JSON suivant est un exemple de refus par la CSSF : { "status": "RJCT" "initial_file_key":"c672b8d1ef56ed28ab87c3622c5114069bdd3ad7b8f9737498d0c01e cef0967a" "errors": [ { "uuid": "QQOIUZHGF3GH45IK" "id": "CSSF-999" "message": "Wrong IBAN format" } ] } 4.2.3. Modalités en cas de rejet Si le retour de la CSSF contient un statut rejeté « RJCT », le professionnel doit fournir à la CSSF un nouveau fichier de données jusqu’à ce qu’il obtient un statut accepté « ACPT ». 5. Stockage des fichiers Le professionnel a pour obligation de stocker quotidiennement le dernier fichier accepté par la CSSF pour le jour courant ainsi que la preuve d’acceptation (fichier de retour fourni par la CSSF). La CSSF gardera également une copie du fichier de retour ; afin de vérifier l’intégrité de ces fichiers, elle générera et stockera plusieurs empreintes de type Hash pour chacun des fichiers stockés. Le délai de conservation obligatoire est de 5 ans conformément aux dispositions prévues par l’article 3, paragraphe 6, de la loi modifiée du 12 novembre 2004 relative à la lutte contre le blanchiment et contre le financement du terrorisme. 6. Informations diverses 6.1. Environnements En plus de l’environnement de production, la CSSF mettra à disposition un environnement de test. Il est demandé au professionnel d’effectuer des tests de mise à disposition du fichier de données sur cet environnement avant passage à l’environnement de production. Les fichiers mis à disposition par le professionnel dans l’environnement de test devront contenir des données anonymisées. 6.2. Disponibilité du fichier de données Le professionnel s’engage à garantir un niveau de disponibilité de service suffisant pour transmettre les informations contenues au sein de leur fichier, au moins une fois toutes les 24h à la CSSF. Le fichier doit être disponible au téléchargement une fois la notification envoyée à la CSSF et jusqu’à la fin du téléchargement du fichier. La plateforme du professionnel peut être indisponible le reste du temps. En cas de non réponse de la CSSF, le professionnel continuera à notifier la CSSF toutes les 10 minutes tant que le fichier n’a pas été récupéré par celle-ci. 6.3. Demande d’accès par MFT Les documents relatifs aux détails techniques sont transmis de manière sécurisée au professionnel par la CSSF au moyen de son système dit Managed File Transfer (« MFT »). Afin d’obtenir un identifiant permettant la connexion au système en ligne, le professionnel renseignera à la CSSF par envoi à l’adresse de courriel électronique registre.compte@cssf.lu les informations suivantes : - Numéro signalétique attribué par la CSSF (de type « Bxxx ») - Nom de l’organisation - Nom et prénom de la personne responsable en matière d’envoi - Adresse de courriel principale de contact 1 - Seconde adresse de courriel de contact à laquelle une partie des informations d’identification sera envoyée1 - Téléphone de contact - Si le professionnel délègue une ou plusieurs des obligations prévues par la loi du 25 mars 2020, préciser quel(
  6. s)sera (respectivement seront) le(
  7. s)prestataire(
  8. s)choisi pour remplir chacune d’elles. 6.4. Informations de contact auprès de la CSSF Toute question technique registre.compte@cssf.lu est à adresser à l’adresse électronique Il est requis que les adresses de contacts principale et secondaire fournies soient différentes et génériques, c’est-à-dire qu’elles ne soient pas nominativement attribuées à une personne physique. Il est requis que ces adresses ne soient pas accessibles par les mêmes personnes. 1 Annex 1 Version tracking Version Date Comments 1.0 21/07/2020 Version 1 – Official publication 2.0 04/09/2020 Version 2 – Official publication - 2.1 24/06/2022 Modification of the enrolment procedure Modification of CSSF’s authentication to the professional interface Additional information of file storage/clarification on the frequency of file sending Additional information on the environment made available by the CSSF Additional information to be provided for the MFT account creation request Version 2 – Official publication Update on file exchange frequency CONTENTS 1. 2. 3. 4. 5. 6. General architecture Enrolment 2.1 Principle 2.2 Secure channel protection Exchange interfaces 3.1 API authentication 3.2 API provided by professionals 3.3 API provided by the CSSF Exchange of files 4.1 File established by professionals 4.2 CSSF Feedback/Answer File storage Various information 6.1 Environments 6.2 Data file availability 6.3 Access request via MFT 6.4 Contact information at the CSSF CIRCULAR CSSF 20/747 2 3 3 4 4 4 5 5 7 7 8 10 11 11 11 11 12 1/12 1. General architecture For the purposes of setting up a central electronic data retrieval system, as defined in this circular, professionals shall make a data file available, in their IT system, which the CSSF will have access to. General approach: 1. Professionals shall prepare on day to day basis, in their IT system, data files related to information on payment accounts, bank accounts identified by IBAN (hereinafter “bank accounts”) and/or safe-deposit boxes. The files shall comply with the format defined in annex 2 (cf. §4.1.4 “Structure of the file”); 2. Professionals shall make the file available and notify the CSSF of its availability [Step 1: “Registry ready” of the architectural pattern]; CIRCULAR CSSF 20/747 2/12 3. The CSSF connects to the professional interface and downloads the file 4. The CSSF notifies the professionals with a feedback containing the status [Step 2: “Download registry” of the architectural pattern]; of the file processing: accepted or rejected and the list of errors encountered when relevant. In case of failure, , a corrected file shall be made available to the CSSF (cf. §4.2 CSSF Feedback/Answer”); 5. Professionals are in charge of securing this file provided. Professionals should foresee, for example, to delete it once the file has been downloaded by the CSSF. To identify themselves with the CSSF and to make their file available, professionals shall implement a specific communication interface, the socalled “Application Programming Interface”, (“API”). 2. Enrolment 2.1 Principle In order to set up a secure channel between the CSSF and the professional, an initialisation phase called enrolment must be conducted. During this phase, the CSSF and the professional will exchange through a secure way, security and identification information. All the necessary information (the enrolment procedure, the detailed API and the technical implementation details) will be provided to professionals. The professional shall address a specific request to the CSSF once the circular has been published (cf. §5.3 “Access request via MFT”). Please find below the major steps of the enrolment phase: 1. Initialisation The CSSF provides the professionals’ private and public RSA keys which will be used for the initialisation of the secure connection between professionals and the CSSF. This private key is protected by a password (passphrase) which will be sent by the CSSF to professionals via another secure channel. Professionals receive via an API the CSSF’s RSA public key corresponding to their TLS client certificate as well as the PGP public keys used for the file encryption; 2. Any communication between the CSSF and the professional uses at least “Mutual TLS” authentication. 3. The professional exposes an API to the CSSF to send the professional “HTTP” identifiers used to identify itself to the CSSF. CIRCULAR CSSF 20/747 3/12 4. Professionals’ PGP public keys, which are used to sign the files sent and to decrypt files received, are made available by each professional through the CSSF’s enrolment API. 2.2 Secure channel protection The exchange of files and the access to the API are performed through HTTPSencrypted Internet connections. The connection is authenticated via a mutual TLS certificate. Two APIs (one from CSSF’s side and one from professionals’ side) are made available. This requires to use two different HTTPS channels: one, from professionals to the CSSF, and the other, from the CSSF to professionals. Both channels include a customer certificate authentication (mutual TLS). The CSSF maintains a white list of IP addresses that are authorised to access its APIs. A white list shall also be maintained by professionals with respect to the access achieved by the CSSF. The certificates used for the mutual authentication are signed by the CSSF’s certification authority and will be provided to professionals. The technical specifications regarding this TLS authentication are as follows: - The CSSF shall provide a public key of its client certificate and a complete trust chain file to the professional; - Both HTTPS connections (from the professional to the CSSF, and viceversa) shall include strong encryption protocols without known issue for the connection encryption, key exchange and hashing mechanism; - The minimum TLSv1.2 protocol shall be implemented. Some APIs used by the CSSF will also be authenticated at HTTP level (using a username and a password, that will generate a JWT token). 3. Exchange interfaces 3.1 API authentication When calling the professional’s API, the CSSF shall authenticate using HTTP. The aim of this authentication is to limit calls to the API in addition to the HTTPS client certificate. The professional then uses credentials provided by the CSSF The life cycle of passwords is managed by the CSSF CIRCULAR CSSF 20/747 4/12 3.2 API provided by professionals Each professional shall make available an API to enable the file retrieval. Professionals may request to get more technical details on this API through the contact point defined by the CSSF (registre.compte@cssf.lu). These technical details will be provided in OpenAPI v3.0 (OpenAPI). The API provided by the professional allows in a secure way, to exchange the following information: - the daily file including all the information expected by the CSSF (cf. “Notification”); - the feedback provided by the CSSF that informs professionals of the file’s - identifiers used by the professional to connect to the CSSF interface. status (cf. “CSSF feedback”). 3.3 API provided by the CSSF The CSSF provides several APIs: - HTTP authentication API; - Enrolment API; - Reset API; - Notification API; - The Public PGP Keys Recovery API. 3.3.1 HTTP authentication API This API allows the professional to retrieve a JWT token which will be used on the other the APIs. To do so, the professional must provide HTTP user identifications previously provided by the CSSF. This API is only available on presentation of a valid TLS client certificate. 3.3.2 Enrolment API Enrolment 1. Call to the enrolment API 2. CSSF feedback on several channels Entity CIRCULAR CSSF 20/747 CSSF 5/12 The enrolment API allows professionals registration into the system. It allows professionals to share the following information: - Web address of the professional’s API where the files will be retrieved; - IP addresses used by the professional to call the CSSF’s APIs; - Public PGP key for the files signature sent to the CSSF - Public PGP key for files decryption received by the professional. PGP keys will be provided into the Armor ASCII format. 3.3.3 Reset API Professionals receive a confirmation security code (reset token) that will be used in case of a new enrolment phase. The new enrolment shall occur in the following cases: - Change of one or several professional’s PGP keys; - Change of the professional’s API website; - Change of IP contact addresses used by the professional for calling the CSSF’s APIs. - Revocation of the professional's HTTPS client certificate - Change of the professional’s password. 3.3.4 Notification API Notification API informs the CSSF about a file to download. 3.3.5 Public PGP key retrieval API This API is published by the CSSF. It allows the professional to receive two PGP keys: - The public PGP key allowing to verify the CSSF’s signature - The public PGP key allowing to encrypt files to send to the CSSF. CIRCULAR CSSF 20/747 6/12 4. Exchange of files 4.1 File established by professionals 4.1.1 Frequency of transmission Professionals shall provide the CSSF with a new valid and full file (“FULL”), that contains all the data referred to in annex 2 of this circular, relating to payment accounts, bank accounts and/or safe-deposit boxes. The professionals must provide with the most recent information available on D - day. A file shall be made available to the CSSF from Monday to Friday, at least once a day (excluding weekends and Luxembourg public and bank holidays). A file shall be available to the CSSF at least once a day, on all business days (including weekends and public holidays). Unless there is a special situation that, where possible, will have to be communicated to the CSSF in advance, the notification to the CSSF of the file availability on the day D by the professional is expected between the day D 6 p.m. and the day D+1 6 a.m (Luxembourg time). If there is no change or modification in the information to be provided, the CSSF expects to receive the same data as the previous day. Each new entry or modification of the information previously reported shall be made available within no more than 24 hours later. 4.1.2 Single download The file made available to the CSSF by professionals will be downloaded via a single-use URL. This URL includes a single token transmitted when the professional notifies the CSSF that the file is available for download. Several calls that URL should generate an alert in the professionals’ IT system. In the case of a download failure (for example, if an error occurs while downloading the file by the CSSF), the professional will have to notify again the CSSF with a new token and to invalidate the older one. 4.1.3 File Security The file sent by the professional must be encrypted and compressed using PGP with a public key provided by the CSSF and signed with a private PGP key of the professional. The file sent by the CSSF to the professional notifying the daily file processing status, must be encrypted and compressed in PGP with a PGP key provided by the professional and signed with a CSSF’s PGP private key. CIRCULAR CSSF 20/747 7/12 The technical specifications regarding the PGP encryption of the files are as follows: - PGP public keys are kept by the CSSF during 20 years even after a key renewal in order to guarantee non-repudiation; - The PGP private keys shall support at least 4096 bits (RSA) or 256 in elliptical curves; - The PGP keys of the professional shall have a validity of at least 2 years. - Files sent shall be in PGP binary format; PGP keys are in the ASCII Armor After these two years, the CSSF may request renewal of the keys. format. 4.1.4 File structure The Annexe 2 presents the description of the data expected and outlines the structure of the file in the expected JSON format, the optional or mandatory information, as well as their format, and an example file of possible values. The information shall be encrypted in UTF8 format. Note: The CSSF recommends professionals to check the validity of their data file either against the JSON validator that will be made available to them or against their own validator. This should allow to identify and notify possible encoding errors prior to the exchange. The JSON validator made available to the professional will be the same as the one used by the CSSF to validate files received daily. 4.1.5 Data recovery In the case the professionals would like to correct or update information already provided into the file of the day, they shall provide a new data file including new information. When the professional receives a feedback file from the CSSF including errors (See §4.2), he has to correct them, and send a new valid file respecting the legal deadlines. 4.2 CSSF Feedback/Answer 4.2.1 Feedback structure At the end of the processing of the professional’ data file, the CSSF sends a feedback about the file processing. This call shall be initiated by the CSSF using the API provided by professionals (cf. §3.2). This feedback file is JSON-structured as described in the following OpenAPI v3.0 schema (OpenAPI): CIRCULAR CSSF 20/747 8/12 openapi: 3.0.0 info: version: 1.0.0 initial file key: borrow from the initial file SHA-512 type components: feedback: title: File processing status type: object properties: status: type: string enum: [ACPT, RJCT] description: Status of the file received by the CSSF. If the file status is RJCT, the entity must correct the file and re-notify the CSSF of its availability. fileid: type: string pattern: '^[A-Z]\d{8}-\d+$' description: Unique identifier of the downloaded file. ID which shall be included in a notification sent to the CSSF. It shall start with the entities identifier «-» value sequence of the file. errors: type: array items: type: object properties: id: type: string pattern: '^CSSF-\d{3}$' description: Identification code of the error message: type: string description: Details on the error message required: - status - fileid 4.2.2 Feedback examples The following JSON is an example of an accepted feedback: CIRCULAR CSSF 20/747 9/12 { "status": "ACPT" "initial_file_key": "B99999999-1" } The following JSON is an example of rejected feedback { "status": "RJCT" "initial_file_key":c672b8d1ef56ed28ab87c3622c5114069bdd3ad7b8f9737498d0c01ece f0967a" "errors": [ { "uuid": "QQOIUZHGF3GH45IK" "id": "CSSF-999" "message": "Wrong IBAN format" } ] } 4.2.3 Procedure in case of rejection If the CSSF feedback contains an “RJCT” rejected status, professionals shall provide the CSSF with a new data file until the file is accepted (the feedback status is accepted “ACPT”). 5. File storage The professional has to store on daily basis the last file accepted by the CSSF for the current day as well as the acceptance proof (feedback provided by the CSSF) The CSSF will keep and store the feedback sent to the professional. In order to check the daily file integrity, the CSSF will generate and store several Hash for each of the stored files. CIRCULAR CSSF 20/747 10/12 The mandatory retention period is 5 years according with the provisions of the Article 3 § 6 of the Law of the 12 November 2004 (coordinated version as of March 25, 2020) on the fight against money laundering and terrorism financing. 6. Various information 6.1 Environments In addition to the production environment, the CSSF will set up a test environment. The CSSF requests to the professionals to perform tests during which they make the data file available on this environment, prior to before any transition to the production environment. The files made available by the professional in the test environment must contain anonymized data. 6.2 Data file availability Professionals shall ensure a sufficient level of availability in order to make available, to the CSSF, the file through its interface, at least once every 24 hours. The file shall be available for download once the notification has been sent to the CSSF and until the end of the file download. The professional's platform can be unavailable the remaining time. In the absence of a response by the CSSF, professionals must continue to notify the CSSF every 10 minutes as long as the file has not been downloaded by the CSSF. 6.3 Access request via MFT The documents relating to technical details are transmitted to the professional by the CSSF in a secure way through its online Managed File Transfer (“MFT”) system. In order to obtain an identifier for connection to the online system, professionals shall send an email to the CSSF at registre.compte@cssf.lu with the following information: - The identification number allocated by the CSSF (“Bxxx”); - Name of the entity; - Surname and first name of the person responsible for email sending; CIRCULAR CSSF 20/747 11/12 - Main contact email address 1; - Secondary contact email address to which part of the identification information will be sent. 2 - Contact phone number. - If the professional delegates one or several obligations laid down in the Law of 25 March 2020, the name(
  9. s)of the provider(
  10. s)chosen to fulfil each obligation 6.4 Contact information at the CSSF Any technical question should be submitted to: registre.compte@cssf.lu. 1 It is recommended to use a generic and lasting email address instead of the name address of an employee who might perform other duties over time, or even to leave the firm 2 It is recommended to use a generic and lasting email address instead of the name address of an employee who might perform other duties over time, or even to leave the firm CIRCULAR CSSF 20/747 12/12

🔗 Vers la source officielle

AI explanation based on the official legal text. Indicative, not a substitute for legal advice.