The MFSA closes the DORA register window on 21 March, and only a submission that reaches Accepted counts

The Malta Financial Services Authority sets the Register of Information reporting period at 1 January to 21 March of every reporting year, with 31 December of the preceding calendar year as the reference date. Two of its circulars tie the obligation to a submission that has reached the status Accepted on the LH Portal, and a third records that the European Supervisory Authorities planned further data quality checks for April, after the window had closed. So the calendar date that matters sits earlier than 21 March, and the work deciding what goes into the file happens in December.

Last verified: 2026-09-05.

What the MFSA circulars say

The standing document is the MFSA circular of 3 November 2025, Register of Information Reporting Timelines for the Year 2026 and Onwards. It scopes itself to "Financial Entities that fall within the scope of the DORA Regulation", then gives the schedule: "Submit the RoI within the Reporting Period, which is between 01 January, or the next working day, and 21 March, or the next working day (both days included) of every Reporting Year", and "Use the date of 31 December of the calendar year preceding the Reporting Period as the Reference Date (e.g., 31 December 2025 for Reporting Year 2026)."

The duty behind it is Article 28(3) of Regulation (EU) 2022/2554, whose first subparagraph reads: "As part of their ICT risk management framework, financial entities shall maintain and update at entity level, and at sub-consolidated and consolidated levels, a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers."

The same circular narrows what counts as done: "A RoI submission is only considered DORA compliant once it attains the status of 'Accepted' on the LH Portal." The consequence sentence repeats that condition rather than softening it: "Failure to submit a fully validated and DORA compliant RoI with final acceptance confirmed on the LH Portal within the above-mentioned annual Reporting Period may result in regulatory action by the Authority by virtue of the L.N. 166 of 2024 and the MFSA Act." The reminder circular of 28 January 2026 uses a shorter form of the same test, "an Accepted and DORA compliant RoI".

Two MFSA circulars, two readings of the same end date

The November circular qualifies both ends of the window with "or the next working day", and the RoI section of the MFSA Supervisory ICT Risk and Cybersecurity page repeats it: the portal "ends March 21, or next working day". The January 2026 reminder drops the qualifier and states the period as "between 01 January 2026 and 21 March 2026". That mattered in the cycle just closed, because 21 March 2026 fell on a Saturday, and it matters again next time: 21 March 2027 falls on a Sunday. The MFSA defines working day nowhere in these documents and publishes no resulting date, so the only end date every source supports is 21 March itself. Plan against that one and confirm any extension with the Authority.

flowchart TD
  accTitle: The DORA register cycle from reference date to the April checks
  accDescr: Arrangements are frozen at 31 December, the register is submitted through the LH Portal between 1 January and 21 March, a rejected file is corrected inside that window, and a file that reached Accepted can still return in the April ESA checks.
  A[31 Dec reference date] -->|window opens 1 Jan| B[Submit on LH Portal]
  B -->|Rejected| C[Fix inside window]
  C --> B
  B -->|Accepted| D[Window shuts 21 Mar]
  D -->|ESA checks, April| E[Resubmission possible]

Why Accepted reads as finished

Read alone, "only considered DORA compliant once it attains the status of 'Accepted'" states a condition that has to be met and reads as one that settles the matter. The MFSA circular of 5 March 2026, Register of Information Additional Data Quality Checks, says otherwise for the cycle it covers. The additional checks on the 2026 submissions "are planned to be carried out during April 2026", and a submission can fail them "even though an ''Accepted'' Status is attained on the LH Portal upon submission". Where that happens, the Authority "will reach out the respective Financial Entities with an expectation for resubmission, without undue delay, by 30 April 2026".

The cost lands twice. Inside the window, the MFSA FAQ sets the correction deadline at the same closing date as the submission deadline: "a re-submission will be required to be done by the end of the annual reporting period (March 21)", so a file uploaded on the closing day and rejected has a correction budget of zero. After the window, a team that stood the work down in late March is the team that has to reassemble it inside April, on an authority timetable.

What the reference date does, and what does not check it

The reference date is the day the register describes, and it travels with the file: the MFSA naming convention encodes it as YYYY-12-31, with 2025-12-31 as the example for reporting in 2026. The instruction is unambiguous. The validation behind it is not.

The ESAs reporting FAQ, still at version 28 March 2025 and still the only reporting FAQ linked from the EBA preparations page when both were read on 5 September 2026, sets the same reference date from 2026 onwards and then adds, reproduced as published, that "considering the specificity of the registers of information focusing from the reporting perspective on valid or in-force contracts at the time of the reporting this reference date is not strongly enforced in practices. Therefore, there is no specific validation rules applied on a reference data apart from the date format."

The same FAQ says what the validation layer is for, answering a different question: "Having no findings does not mean that the data is accepted, since the validation layer does not examine all the information within the file and does not compare the data across files." A clean result is therefore a statement about the file rather than about the estate the file describes, and the reference date is one of the things it does not test. The instruction still comes from the authority receiving the file, which is the party that names L.N. 166 of 2024 as the consequence. Plan against the MFSA wording, and treat an Accepted status as evidence about format rather than about the reference date.

What the register asks for about each provider

Template B_05.01 of Commission Implementing Regulation (EU) 2024/2956 lists every direct provider, every intra-group provider, every subcontractor named in the supply chain template, and the ultimate parent undertaking of each. The fields below are the ones whose answers sit outside the ticket queue.

Three of those five are facts held by the supplier, not by the estate, which makes them December work.

One more version trap sits in the same standard. A corrigendum published on 19 September 2025, 291 days after the Official Journal text of 2 December 2024, rewrote the code type list in B_05.01.0020, corrected B_05.01.0090 to read "Currency of the amount reported in B_05.01.0100" where the printed text said B_05.01.0070, and shifted six column codes in template B_06.01 down by one, so the code printed as B_06.01.0110 reads as B_06.01.0100. A generator built from the December 2024 text and never revisited carries those six labels one place out. Read the consolidated text and align the file to the ESAs technical package.

How to check one supplier before the reference date

The identifier is the field most likely to stall, because it belongs to the supplier. The Global Legal Entity Identifier Foundation publishes the register behind it and answers unauthenticated read-only queries, so an inventory can be checked before anyone opens a vendor ticket. This is a GET request and changes nothing. The -g flag is not optional: curl reads a square bracket as a range and rejects the address without it.

curl -s -g -H "Accept: application/vnd.api+json" \
  "https://api.gleif.org/api/v1/lei-records?filter[entity.legalName]=Microsoft%20Ireland%20Operations%20Limited"

Run against that one name on 5 September 2026, the call returned a single record: LEI 549300WCLFVEBTBNRF76, legal name MICROSOFT IRELAND OPERATIONS LIMITED, headquarters country IE, entity status ACTIVE, registration status ISSUED, next renewal 2026-11-23. Those map onto B_05.01.0010, B_05.01.0050 and B_05.01.0080 directly. A name that returns no record, or several, is a question for the supplier, better asked in December than in January.

The MFSA lists the matching rule among the common data quality errors it saw in the 2025 submissions: VR_71, where the "LEI code mention has to be valid according to GLEIF", and which the same list records as one that "does not lead to rejection". An identifier that fails it is reported rather than fatal, and it is still a finding somebody has to answer.

Recommendation

For an entity already inside this reporting cycle, three dates are worth writing down now. Collect the provider level identifiers in December, before the reference date passes, so the register describes 31 December rather than whatever the inventory said in February. Set an internal submission date weeks ahead of 21 March, because the MFSA's correction deadline is the same closing date as the submission deadline. Leave capacity in April, because the additional checks published for the 2026 cycle were scheduled after the window closed.

Trade-offs

Collecting identifiers in December means chasing suppliers across their own year end, and any arrangement signed in the following weeks is handled separately. Doing it in January puts the same chase inside the window that also has to absorb a rejection. Submitting early buys correction time and costs a second look if the register moves before 21 March; the MFSA documents resubmission for a rejected file, and the ESAs FAQ defines a resubmission mechanically, as a later file from the same competent authority for the same report subject and the same reference date, without stating whether an accepted file may be replaced by choice.

Where it does not apply

This note does not determine who is in scope, and nothing above should be read as doing so. Scope is set by Article 2 of the Regulation, and the MFSA publishes its own guidance on the question along with an address for it. Credit institutions classified as significant under Article 6(4) of Regulation (EU) No 1024/2013 and directly supervised by the European Central Bank are, in the MFSA's words, "to be guided by the ECB regarding the submission of the RoI". An entity reporting at consolidated level to another national competent authority follows a separate notification path the MFSA sets out on its own page.

Limitations

The examples of the additional checks are published as Annex I of the 5 March 2026 circular, an image rather than text, which did not extract during this session, so no example is reproduced here.

The GLEIF lookup confirms that a public record exists and reports its registration status. It does not confirm which code a validation rule will accept. The MFSA names one rule that reads GLEIF, VR_71, and records that it does not lead to rejection; no page read here states what a lapsed identifier produces beyond that. The validation rules and the reporting technical package are published by the EBA and were not exercised. No submission was made, no LH Portal account was used, and the FAQ read here carries the version date 28 March 2025.

The weekday arithmetic can be redone: 21 March 2026 was a Saturday and 21 March 2027 is a Sunday. The resulting end date in each case is not published by the MFSA, which is why this note plans against 21 March itself.

A reporting date that moves nothing technical leaves no trace in any system an operator monitors, which is why it belongs in a written register rather than in a memory. Other dated changes with a primary source attached are collected in the Ops Log.