← Luxembourg

Transmission instructions for reportings under Article 37 of the Money Market Funds Regulation

Published on 22 July 2020 Email this Share this on LinkedIn Share this on Facebook Communiqué Transmission instructions for reportings under Article 37 of the Money Market Funds Regulation Following from the press releases dated April 2, 2020 and June 16, 2020, the CSSF informs that as of July 22, 2020 it accepts the submission of reportings under Article 37 of the Money Market Funds Regulation according to the amended XML schema (version 1.1) published by ESMA on June 4, 2020 in the test environment. Submission of the reporting is exclusively authorised through the transmission channels currently accepted by the CSSF, namely the communication platform e-file (https://www.fundsquare.net/regulatory-services) or the communication platform SOFiE (http://www.cetrel-securities.lu/wp_static/what-do-weoffer/secured-reporting-channel-sofie-sort/). The national specifications to be respected by the entities under the supervision of the CSSF in order to submit the reporting of money market funds are published on its website: https://www.cssf.lu/wp-content/uploads/MMFR_Handbook.pdf https://www.cssf.lu/en/document/xml-lu-specifications-for-mmf-reporting/ https://www.cssf.lu/en/document/example-file-for-mmf-reporting/ The CSSF would like to remind that the reference period for the first reporting remains Q1 2020 but the submission to National Competent Authorities of the quarterly reportings for Q1 and Q2 2020 has been postponed to September

  1. In this context, as of September 1, 2020, the CSSF will accept submission of quarterly reporting for Q1 and Q2 2020 and the following quarters in the production environment. Submission of the reportings in the test environment before the September deadline is encouraged. If you have any questions regarding the reporting instructions please send an email to opc@cssf.lu. Relevant for Investment fund managers Other specific authorisations, registrations and information Specialised investment funds (SIFs) Undertakings for collective investment in transferable securities (UCITS) Undertakings for collective investment subject to Part II of the Law of 17 December 2010 (Part II UCIs) MMFR User Handbook MMFR User Handbook MMFR Public 2/21 TABLE OF CONTENTS
  2. Introduction ............................................................................................................... 4 1.1 Objectives of this document ...................................................................................... 4 1.2 Useful/reference documents ...................................................................................... 4 1.3 Document versions .................................................................................................. 4
  3. MMFR reporting principles ............................................................................................ 5 2.1 Reporting obligations................................................................................................ 5 2.2 Information to be reported ........................................................................................ 5 2.3 Overall reporting process .......................................................................................... 6 2.4 Reporting period ...................................................................................................... 7
  4. CSSF processing principles........................................................................................... 7 3.1 The transmission of the MMF reporting files to the CSSF ............................................... 7 3.1.1 3.1.1.1 Application Programming Interface (API) ......................................................... 7 3.1.1.2 EDesk ......................................................................................................... 7 3.1.2 3.2 Transmission channels pursuant to Circular CSSF 23/833 ........................................ 7 Deactivation of old transmission method (external channels) ................................... 7 MMFREP file structure ............................................................................................... 8 3.2.1 Business Application Header ................................................................................ 8 3.2.2 Business File Header ......................................................................................... 10 3.2.3 MMFREP message definition ............................................................................... 10 3.2.4 MMFREP naming convention .............................................................................. 10 3.3 Validation of the MMFREP file................................................................................... 12 3.3.1 Validation of the MMFREP file ............................................................................. 12 3.3.2 File validation [CSSF feedback] .......................................................................... 12 3.3.3 Content validation [ESMA feedback] ................................................................... 13 3.4 Re-submission and cancellation of reports ................................................................. 18 3.4.1 Re-submission of report after correction or rejection ............................................. 18 3.4.2 Cancellation of report........................................................................................ 18 3.5 Feedback files ....................................................................................................... 19 3.5.1 Naming convention ........................................................................................... 19 3.5.2 Explicit processing statuses ............................................................................... 19
  5. Reporting entities obligations ..................................................................................... 20 4.1 Provide high-quality data ........................................................................................ 20 4.1.1 Sequence number ............................................................................................ 20 4.1.2 Data quality ..................................................................................................... 21 4.2
  6. Review feedbacks and correct rejected reports .......................................................... 21 Miscellanous information ........................................................................................... 21 5.1 Contact information ............................................................................................... 21 5.2 Swift MyStandard .................................................................................................. 21 MMFR Public 3/21
  7. Introduction 1.1Objectives of this document This document describes the reporting principles to be used by the MMF Managers in order to report activity to the CSSF as the National Competent Authority (NCA) for Luxembourg. The information detailed herein relates to: • • • • Reporting obligations including the description of the details to report Technical overview of the reporting system Data and file format of the reports Exchange and encryption protocols Any instruction given by the CSSF in this note is based on the aforementioned legal framework and the technical reporting instructions published by ESMA. 1.2Useful/reference documents Date 2020/06/04 Reference Document ESMA reporting instructions for MMF reporting ESMA webpage 2020/01/28 2017/06/30 2018/05/15 CSSF Circular 20/734 Regulation (EU) 2017/1131 Regulation (EU) 2018/708 Auteur ESMA ESMA CSSF EUR-Lex EUR-Lex 1.3Document versions MMFR Public 4/21 Date Version 2020/06/16 1.0 2020/07/15 1.1 2021/01/28 1.2 2025/07/01 1.3 Status Initial version New layout/encrypt information/add of the chapter 1.3/feedback format information New dashboard for reporting status Deactivation of old transmission method (external channels) from 2025/09/01 New channels available for transmitting reporting from 2025/09/01: eDesk and Application Programming Interface (API)
  8. MMFR reporting principles 2.1Reporting obligations According to Article 37 of the Regulation (EU) 2017/1131 of the European Parliament and of the Council of 14 June 2017 on money market funds (“MMF Regulation”), for each MMF that it manages, the manager of the MMF shall report information to the competent authority of the MMF on at least a quarterly basis (for a MMF whose assets under management in total do not exceed EUR 100 000 000, the manager of the MMF shall report to the competent authority of the MMF on at least a yearly basis). 2.2Information to be reported The Regulation (EU) 2017/1131 of the European Parliament and of the Council of 14 June 2017 on money market funds (“MMF Regulation”) requires among others periodical information from the managers of the money market fund to competent authorities within a frequency depending on their assets under management. The reporting obligations are set out in article 37 of the MMF Regulation. On 17 April 2018 the European Commission adopted Regulation (EU) 2018/708 (“the Regulation”) laying down implementing technical standards with regard to the template to be used by managers of MMFs when reporting to competent authorities under Article 37 of the MMF Regulation. The appendix of the Regulation contains the reporting template that managers of MMFs have to use to comply with their reporting obligations. The European Securities and Markets Authority (ESMA) published the “Guidelines on the reporting obligations to competent authorities under Article 37 of the MMF Regulation” (ref. ESMA34-49-168, “the ESMA MMF reporting guidelines”). Further details and technical supporting material (technical reporting instructions, detailed validation rules and the reporting XSD schema) were also published by ESMA (ref. ESMA65-8-6480). MMFR Public 5/21 CSSF published as well circular 20/734 to clarify technical details that managers of MMFs need in order to fulfil their reporting obligations. 2.3Overall reporting process The CSSF’s information system collects all the reports (MMFREP) submitted by the MMF managers. It is up to the submitter to monitor transmission correctness. Feedback files are systematically generated and sent by the CSSF in response to each MMFREP received. *Pay attention to the sequence number: one report may be validated but it will not be sent to ESMA if a superior sequence number has already been sent to ESMA for the same period (see section 4.1.1 below) Within the CSSF, the files are processed as follows:
  14. File collection via eDesk or Application Programming Interface (API) Validation rules control (technical and functional validation) Generation and sending of the CSSF feedback file to the concerned entities, gathering results from validation [MMFFDB – xml format] Transfer of the last validated version to ESMA following ESMA’s rules Reception of the ESMA’s feedback Transfer of the ESMA’s feedback to the concerned entities [MMFFBH – zip format] The CSSF’s information system collects and routs data using XML/ZIP files (the xml file will be compressed and sent as a .zip. Each .zip file will only contain one xml file). MMFR Public 6/21 2.4Reporting period A report cannot be submitted for a quarter before the end of the quarter or the case may be, before its liquidation/merger date or the date of withdrawal of its authorisation. The CSSF requires that the reporting files are submitted electronically using exclusively one of the channels accepted by the CSSF until 25 days after the end of the corresponding quarter/year-end.
  15. CSSF processing principles 3.1The transmission of the MMF reporting files to the CSSF 3.1.1 Transmission channels pursuant to Circular CSSF 23/833 The channels to be used are those operating in accordance with the provisions of Circular CSSF 23/
  16. Two channels are available for this reporting: - Application Programming Interface (API) - EDesk These channels are available from 2025/09/
  17. 3.1.1.1 Application Programming Interface (API) Method of transmitting reports via Application Programming Interface can be found on our website following the link https://www.cssf.lu/en/Document/methods-of-transmitting-reports-via-s3application-programming-interface-technical-guidance/ On the edesk IT management console, the “IT Expert” of the sender must create a bucket “MMF Reporting”. 3.1.1.2 EDesk Method of transmitting reports via eDesk is available following the link https://edesk.apps.cssf.lu/mmf/edesk-mmf/home EDesk allows the submission of reports and the consultation of feedback via a dashboard. 3.1.2 Deactivation of old transmission method (external channels) The old transmission channels are the following: MMFR Public 7/21 - E-file: exchange platform proposed by Fundsquare SOFiE SORT - ATLAS: exchange platform proposed by Cetrel Securities S.A. These channels are deactivated from 2025/09/
  18. CSSF and ESMA feedback for all reports submitted to the CSSF before 01/09/2025 via these old transmission channels will be sent back via this same channels. 3.2MMFREP file structure 3.2.1 Business Application Header The Business Application Header (BAH) is a header that has been defined by the ISO 20022 community that can form part of an ISO 20022 business message. Specifically, the BAH is an ISO20022 message definition (head.001.001.01) which can be combined with any other ISO20022 message definition to form a business message. The purpose of the BAH is to provide a consistent and predictable way for this data to be conveyed with the message, regardless of implementation factors such as the choice of network. The use of the BAH in MMFREP is mandatory. The below table presents the list of mandatory elements of the BAH that should be included in the message and the specific Business Message Identifier. MMFR Public 8/21 Element From Description Usage in Reporting Message Usage in feedback The sender of <Fr>.<OrgId>.<Id><.<Or <Fr>.<OrgId>.<Id><.<OrgId>.< the message gId>.<Othr>.<ID> Othr>.<ID> Expected value : EU Expected value : LU To The recipient of <To>.<OrgId>.<Id><.<Or <To>.<OrgId>.<Id><.<OrgId>. the message gId>.<Othr>.<ID> <Othr>.<ID> Expected value : LU Expected value : EU Business Unique Message identification of Identifier the message <BizMsgIdr> <BizMsgIdr> OXXXXXXXX-CCCCCCCC- Same as Reporting Message YYYY-QX/YX-0000 where OXXXXXXXX is the funds CCCCCCCC is the sub-funds QX/YX is the ending quarter of the reporting period Ex: Q1, Q2, Q3 or Q4 for quarterly reporting. Y1 for yearly reporting 0000 is the sequence values used in the file name Message Identification of Definition the type of the < MsgDefIdr> < MsgDefIdr> Identifier message 20022 message The identifier of relevant The identifier) ISO 20022 message using 20022 message using base name base e.g. only, MMF status advice message. (ISO name only, auth.093.001.01 for identifier e.g. of relevant auth.031.001.01 ISO for record data message Creation Date and time Date when < CreDt> this Date and time in ISO 8601 format. Business Message was created Related Specifies the Unused In the case of status advice Business message, the copy of the BAH of Application the Header of the allows to link the status advice and Business the data message). Message which referred data message (it to this Business Message relates. MMFR Public 9/21 3.2.2 Business File Header ISO 20022 business message shall be sent together with the Business Application Header (BAH) message. These are separate messages and should be packaged within an additional structure, referred to as “envelope”, in order to constitute a single XML file. The Business File Header is a simple XML file that encapsulates the BAH and the Reporting message or the feedback message. 3.2.3 MMFREP message definition A specific version of the auth.093.001.001 ISO20022 message definition will be used by the MMFR: SPECIFIC XSD In that specific version, the CSSF adds the following restrictions to the ESMA version: - - only one report (update or cancellation) concerning a MMF for a specific period in each file the subfund identification (tag FndNttyId/Id) must comply with the format OMMMMMMMM_CCCCCCCC (with MMMMMMMM the fund identification number and CCCCCCCC the subfund identification number) the fund manager identification (tag FndAuthrtyRegnNb/Id) must comply with the format SXXXXXXXX (for a C15 or C16 management company) or AXXXXXXXX (for an AIFM) the depositary identification (tag DpstryId/Id) must comply with the format BXXXXXXXX (for a credit institution) or PXXXXXXXX (for a Professional depositary of assets other than financial instruments) 3.2.4 MMFREP naming convention The reporting XML file must be compressed into a ZIP file before being sent to the CSSF. As soon as a MMFREP is received by the CSSF system, the CSSF system will check that the zip file transmitted by the submitting entity can be extracted and that the enclosed xml file complies with the defined naming convention. All files must be submitted to the CSSF as per the following naming convention: TYPDIR-EIIIIIIII-EMMMMMMMM-CCCCCCCC-YYYY-QX/YX- Seq.ext MMFR Public 10/21 Code Meaning TYP Structure Reporting type Char

(3)Authorized values ‘MMF’ for “Money Market Fund” reporting DIR Direction Char
(3)‘REP’ for Report file sent to the CSSF - Separator Char
(1)Constant ‘-’ E Entity type of the MMF Char
(1)Usual entity types, e.g. “B” for Bank, manager or the “P” technical agent IIIIIIII Identification number for PSF, “S” for management company, “A” for AIFM Number
(8)00000001…99999999 of the sender - Separator Char
(1)Constant ‘-’ F Entity type Char
(1)Constant - the identification given by the CSSF for the entity has to be used. Usual entity type is “O” for OPC MMMMMMMM Entity identification Number
(8)00000001…99999999 number - Separator Char
(1)Constant ‘-’ CCCCCCCC Sub-fund Number
(8)00000001…99999999 identification number - Separator Char
(1)Constant ‘-’ YYYY Year of the reporting Number
(4)Year of the reporting - Separator Char
(1)Constant ‘-’ Q or Q for “quarter” Char
(1)Constant ‘Q’ or ‘Y’ Number
(1)Identification number of the reporting Y for yearly reporting X the Or Y for “year” Identification number of the reporting quarter (1,2,3 or 4) or quarter Value “1” for the yearly reporting - Separator Char
(1)Constant ‘-’ Seq Sequence number Number
(4)Number with leading zero. Used for determination of the order of processing and guarantees uniqueness .ext Extension Char
(5)‘.zip’ for the REP file containing a single ‘.xml’ file MMFR Public 11/21 Examples: 1) Quarterly reporting file for Q1 of year 2020 sent by technical agent P00000789 for the MMF O00000654-00000123: MMFREP-P00000789-O00000654-00000123-2020-Q1-0001.xml 2) Yearly reporting file for the year 2020 sent by technical agent P00000789 for the MMF O00000654-00000123: MMFREP-P00000789-O00000654-00000123-2020-Y1-0001.xml 3.3Validation of the MMFREP file 3.3.1 Validation of the MMFREP file The MMFREP file goes through a set of mandatory and harmonised validation rules. MMF managers will receive two feedback files: • the first one [CSSF feedback] concerns the integration of the report in the CSSF system after technical and some business controls • the second one [ESMA feedback] concerns the integrations of the report in the ESMA’s system. This feedback will also be sent by the CSSF (see schema) Any report that does not comply with the validation rules is automatically rejected by the CSSF. The respective rejection codes and reasons are indicated in the dedicated feedback file. A report can be rejected for two main purposes: • • File validation o Transmission error: The file cannot be decompressed for example [CSSF feedback] o Format error: The file structure does not correspond to the XML schema [CSSF feedback] Content validation: related to business rules [ESMA feedback] MMF managers must ensure that all feedback files are properly analysed and that any rejected reports are corrected and resubmitted to the CSSF. 3.3.2 File validation [CSSF feedback] The MMFREP is first subject to a file validation to verify its compliance with the XML schemes. In case of file error, the entire MMFREP is rejected by the CSSF. The feedback file indicates the respective rejection codes and reasons for every rejected record included in the MMFREP file. The entire MMFREP must be corrected by the reporting entity and resubmitted to the CSSF. Please find hereafter a list of potential error messages and their appropriate corrective action: MMFR Public 12/21 Validation rules File error Control Error message code This error is returned when the sender FIL-001 defined in the archive nomenclature is Bucket participant does not match filename participant different from the bucket sender This error is returned when the size of the FIL-002 transmitted archive is greater than 20Mb All files on MMFR are compressed in zip The archive size cannot exceed 20 MB FIL-101 The archive is corrupted FIL-102 The file contains no or more than 1 format. When treating a file, the first step is the decompression of the zip file. This error is returned by the system if the file cannot be decompressed or corrupted. This error is returned by the system when no XML or more than one file is found. This error is returned by the system when XML file. FIL-103 The name of the XML file <XML any of the aforementioned fields is not file> is not consistent with the identical in the ZIP and XML filenames. name of its container ZIP file. Validate that the ISO 20022 Message FIL-104 The ISO 20022 Message Identifier Identifier (MsgDefIdr) in the BAH refers to (MsgDefIdr) in the BAH must refer the namespace of the XSD schema for the to the namespace of the XSD MMF Authorisation reports. schema for the MMF Authorisation reports. Validate that the file sent fits to the FIL-105 corresponding XML schema. The file structure does not correspond to the XML schema: [result of XML validation] Validate that the filename complies with the filenaming convention. FIL-113 The file name does not comply with the file naming convention. Note: • • Regarding error code FIL-001, it is only applicable for submission via API; Regarding error code FIL-105, it has to be noted that this error type includes a wide range of errors related to a single report. The result of the XML validation is a list of errors per report generated by the XML parser. Due to the xml structure of the feedback file it is not possible to include all of them (the field “Desc” is limited to 350 Characters). 3.3.3 Content validation [ESMA feedback] CSSF does a light content validation. Business rules are validated by ESMA’s MMFR system. Please refer to the ESMA’s: https://www.esma.europa.eu/document/money-market-fund-reporting- technical-reporting-instructions MMFR Public 13/21 Validation rules File error Error or code Warning Filename data (fund code, sub- CSSF- E fund code, reporting year and 001 Control Error message Data in report file are not consistent with data coming from ending quarter of the reporting filename. period) must be consistent with data included in the XML file. Data in Business Message CSSF- Identifier (tag <BizMsgIdr>) in 002 E Data from Business Message Identifier are not valid. file header must be consistent with filename data. Message (tag CSSF- <MsgDefIdr>) must be equal to Identifier 003 E Data from Message Identifier must be auth.093.001.
  1. “auth.093.001.01”. In the file header, sender of the CSSF- message 004 (tag <Id> under E Data concerning the sender and the recipient of the file are not <From> organization) must be correct in the header. The sender set to ‘LU’ and recipient of the must be set to LU and the recipient message (tag <Id> under <To> must be set to EU. organization) must be set to ‘EU’. File is incorrect and was rejected CSSF- by the system 005 Reporting year must be equal or CME-004 E File is incorrect. E The after 2020 in MMF record (update Reporting year <reporting year> is not equal or after
  2. type). Reporting year must be equal or after 2020 in MMF CME-009 E record The Reporting year <reporting year> is not equal or after
  3. (cancellation type). When sending a cancellation CME-006 E A Cancellation record is received, report to CSSF, at least one MMF and no valid MMF Reporting record record with the same Supervising which has the same Supervising CA NCA country code of the MMF, country code, National code and NCA national code of the MMF, Reporting reporting Year period from/to quarter exists in the period, must and reporting have been Year and Reporting database. previously sent to CSSF. The country code of the CME-007 E The Country code of the supervising CA of the MMF (tag authorising CA of the MMF is not an Issr) must be an ISO 3166 2- ISO character country code of an EU code of an EU country. 3166 2-character Country country in MMF record (update type). MMFR Public 14/21 Validation rules Control The country code of the File error Error or code Warning CME-021 E Error message The Country code of the supervising CA of the MMF (tag authorising CA of the MMF is not an Issr) must be an ISO 3166 2- ISO character country code of an EU code of an EU country. country in MMF 3166 2-character Country record (cancellation type). Validate whether a reporting CME-019 E entity is authorised to send MMFR Your firm is not authorised to send this type of reporting. reporting to the CSSF. The country code of the CME-008 E The Country code of the supervising CA of the MMF (tag Supervising CA of the MMF is not Issr) the same as the From organization must be equal to the supervising CA country included <Id> in the header of the file. in the file header (tag <Id> under <From> organization). This control is relevant for an “update” MMF record. The country code of the CME-022 E The Country code of the supervising CA of the MMF (tag Supervising CA of the MMF is not Issr) the same as the From organization must be equal to the supervising CA country included <Id> in the header of the file. in the file header (tag <Id> under <From> organization). This control is relevant for a “cancellation” MMF record. When available, the LEI of the CME-015 E MMF (tag LEI) must be valid on The LEI of the MMF <LEI> is not a valid and existing LEI. reporting end date, according to the GLEIF database. Moreover, this LEI must have a status different from “DUPLICATE” OR “ANNULLED” in GLEIF database on reporting end date. The LEI of the MMF (tag LEI) is mandatory when quantitative data is reported (tag DataSetActn CME-016 E The LEI of the MMF is not reported whereas quantitative information is reported. is not reported). MMFR Public 15/21 Validation rules Control A warning is raised when the LEI File error Error or code Warning CME-017 W Error message The LEI of the MMF is not reported of the MMF (tag LEI) is not whereas quantitative information is reported and no quantitative data not reported. is reported (tag DataSetActn is reported). A warning is raised when the LEI CME-018 W of the MMF (tag LEI) has a status equal to “RETIRED” The LEI of the MMF <LEI> has status “RETIRED” or “MERGED”. OR “MERGED” in GLEIF database on reporting end date. The domicile country code of the CME-024 E The domicile country code of the MMF (tag Ctry) must be an ISO MMF <country of domicile> is not 3166 2-character country code. an ISO 3166 -character country code. When available, the LEI of the CME-025 E The LEI of the manager of the MMF manager of the MMF (tag LEI) <LEI> is not a valid and existing must be valid on reporting end LEI. date, according to the GLEIF database. Moreover, this LEI must have a status different from “DUPLICATE” OR “ANNULLED” in GLEIF database on reporting end date. The LEI of the manager of the CME-026 E MMF (tag LEI) is mandatory when The LEI of the manager of the MMF is not provided. quantitative data is reported (tag DataSetActn is not reported). A warning is raised when the LEI CME-027 W The LEI of the manager of the MMF of the manager of the MMF (tag <LEI> has status “RETIRED” or LEI) “MERGED”. has a “RETIRED” status OR equal to “MERGED” in GLEIF database on reporting end date. The national code of the manager CME-028 E The national code of the manager of the MMF (NCA country code + of the MMF <national code> is not NCA authorised under Article 4 for that national code) must be authorised under Article 4 by the MMF national code and country. CSSF for that MMF national code and country. MMFR Public 16/21 Validation rules Control The country code of the File error Error or code Warning CME-030 E Error message The country code of the authorising supervising CA of the manager of CA of the manager of the MMF the MMF (tag Issr) must be an param is not an ISO 3166 2- ISO 3166 2-character country character country code of an EU code of an EU country. country. If the manager of the MMFR reports several national registration numbers, all related country codes must be an ISO 3166 2-character country code of an EU country. Several national numbers may registration be CME-031 E Several NCA countries <list of NCA reported countries> are reported whereas tags the domicile of the MMF <domicile (several FndMgmtCpnyAuthrtyRegnNb) country> is an EU Member State. only when the domicile of the MMF (tag Ctry) is not an EU Member State. When several registration national numbers CME-032 E are The same NCA country <NCA country> is reported twice. reported, several countries (tag Id) are then reported. In this case, the same country can’t be reported twice (or more). The base currency of the MMF CME-036 E The currency code of the MMF (tag BaseCcy) must be an ISO <currency> is not an ISO 4217 3- 4217 3-character currency code. character currency code. A warning is raised when the ISIN CME-047 W The ISIN of the share class under of the MMF (tag ISIN) is not field 47 should be populated when populated and the share class the share class indicator indicates indicator that there are no several share (tag ShrClssInd) is populated with “false”. classes. The check sum digits of the ISIN CME-048 E The check sum digits of the ISIN of of the MMF (tag ISIN) must be the asset <ISIN> under field 47 valid. are not valid. A warning is raised when at least CME-051 W The ISIN of the MMF under one of the ISINs of the MMF share field 49 should be populated classes when the share class indicator (tag ISIN) is not populated and the share class indicates indicator several share classes. (tag ShrClssInd) is that there are populated with “true”. MMFR Public 17/21 Validation rules Control The check sum digits of the ISINs File error Error or code Warning CME-052 E Error message The check sum digits of the ISIN of of the MMF share classes (tag the asset <ISIN> under field 49 ISIN) must be valid. are not valid. When available, the inception date of the MMF (first CME-060 E NAV The inception date of the MMF <inception date> is not valid. calculation date – tag IncptnDt) must be before the reporting period end date (tag ToDate). Moreover, must be the inception populated date when quantitative data is reported (tag DataSetActn is not reported). When available, the merger date CME-061 E The merger date <merger date> is (tag MrgrDt) must be equal to the not equal to the reporting end date reporting end date (tag ToDate). <date>. When available, the liquidation date (tag LqdtnDt) must CME-062 be within the reporting period. E The Liquidation Date <date> is not within the Reporting period from <starting quarter> to quarter <ending quarter>. 3.4Re-submission and cancellation of reports 3.4.1 Re-submission of report after correction or rejection When a MMF manager needs to correct erroneous data, it can resubmit the MMFREP report. The information about the update of the report is integrated into the header: the XML should include the value “Upd” (update). Same value to be used for a new report. The sequence number must be increased for each resubmission. 3.4.2 Cancellation of report The cancellation records are mainly used when an incorrect National code was reported for an MMF. When other types of corrections have to be submitted, a new version of the MMF Reporting record must be reported in order to correct the existing one. MMFR Public 18/21 A cancellation record will invalidate the existing valid MMF Reporting record. The FndRpt xml tag should be set to “Cxl” (cancel). 3.5Feedback files 3.5.1 Naming convention A feedback file (MMFFDB) in xml format is sent by the CSSF after technical validation for each MMFREP reporting file received. ESMA’s feedback (MMFFBH) in zip format is recovered by the CSSF and then sent to the reporting entities. ESMA applies data content validation controls. They are detailed on ESMA’s website: https://www.esma.europa.eu/document/money-market-fund-reporting-technicalreporting-instructions Below are the structure and details of the feedback message. ESMA’s and CSSF’s feedback messages have the same structure. All files transmitted by the CSSF as per the following naming convention: Example: MMFFDB-B0000001-O00000001-CCCCCCCC-2020-Q1-0001.xml for the CSSF feedback MMFFBH-B0000001-O00000001-CCCCCCCC-2020-Q1-0001.zip for the ESMA’s feedback The feedback file is encrypted using the sending entity certificate. 3.5.2 Explicit processing statuses The CSSF reports an explicit status for each submitted report. The feedback file may report one of the following three statuses: • - MMFR Public Rejected (RJCT): the MMF report is flagged as rejected when: zip file does not contain one single XML file the contained xml file does not have the same filename as the container zip file (except timestamp and extension) the report does not use the same XML Schema as the one used by the system the report uses exactly the same filename previously used the report cannot be validated against the XML Schema the content of the report violates any of the Data Content Validation rules, in which case Record Status elements will be included in the feedback file, detailing the exact records violating Data Content validation rules, all having the status “RJCT” 19/21 • • Accepted (ACPT): the MMF report is flagged as accepted when it passes successfully all validation checks Warning (WARN): This status is used in case the MMF records has been accepted with one or multiple warnings. Error codes indicating warning validation rules that failed should be provided in the RcrdSts complex element A feedback report contains two distinct components: the message status and the record status, each one containing a unique identifier of the message and of the record and a description of the error if any.e. Feedback)
  4. Reporting entities obligations MMF managers are required to respect the following: 4.1Provide high-quality data 4.1.1 Sequence number Multiple files can be submitted on the same day, but the sequence numbers must be consistent with the chronological order of the reports created and the statuses of the reports (please refer to the naming convention chapter) The MMF managers are required to use an incremental numbering in order for the CSSF to correctly process the received reports. The sequencing is incremental (starting at 0001). No year-end change applies to the sequence numbering. Examples: 1) Quarterly reporting file for Q1 of year 2020 sent by technical agent P00000789 for the MMF O00000654_00000123: MMFREP-P00000789-O00000654-00000123-2020-Q1-0001.xml 2) Correction of the Q1 report of year 2020 sent by technical agent P00000789 for the MMF O00000654_00000123: MMFREP-P00000789-O00000654-00000123-2020-Q1-0002.xml 3) Quarterly reporting file for Q2 of year 2020 sent by new technical agent P00000790 for the MMF O00000654_00000123: MMFREP-P00000790-O00000654-00000123-2020-Q2-0003.xml 4) Cancellation of the Q2 report of year 2020 sent by technical agent P0000790 for the MMF O00000654_00000123: MMFREP-P00000789-O00000654-00000123-2020-Q2-0004.xml The sequence is related to the sub-fund. MMFR Public 20/21 4.1.2 Data quality Submitting entities are strongly advised to use the XML schemes to generate and validate their files before submitting them to the CSSF. Files must be validated against the XML schema provided by in this document. 4.2Review feedbacks and correct rejected reports MMF managers must ensure that all feedback files are properly analysed and that any rejected reports is corrected and resubmitted to the CSSF. Feedback process is an automatic exchange between systems using official transmission channels. MMF managers must resend their corrected files using the same automatic process. The CSSF will regularly publish a reporting status for each MMF manager in the “MMF reporting dashboard” application available under the eDesk portal. This dashboard will consolidate the CSSF and ESMA statuses of all the expected reports. The application is accessible to all the MMF manager’s users with the specific role “MMF reporting dashboard” (please refer to the eDesk Authentication user guide to have all the necessary information about that role).
  5. Miscellanous information 5.1Contact information In case of questions, MMF managers should contact CSSF team which can be reached at the following e-mail address: opc@cssf.lu 5.2Swift MyStandard The MyStandardsReadinesPortal is available to CAs and sending entities to support the testing of ISO 20022 XML messages. This tool enables the users to submit XML messages and check whether they are correctly formatted (i.e. compliant with the XML schema) and in compliance with the data quality rules. https://www2.swift.com/mystandards/#/ MMFR Public 21/21

🔗 Vers la source officielle

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