CSSF eDesk cutover in 2027: prepare the official filing record

By Alexander Akkarie. Content reviewed on 26 October 2026.

The CSSF’s announced 2027 cutover for covered PI, EMI and Article 63 MiCAR CASP prudential returns is driven by submission due date. Tests in January to March are non-official; covered returns due from 1 April use the new route even when their reporting period ends earlier. Prepare a record that joins the approved dataset, the exact submitted version and the official acknowledgement, while keeping rehearsals separate. This News & Analysis note is checked as of 26 October 2026. CSSF transition notice

The migration creates two pieces of work. One is getting the new submission route to work. The other is preserving the meaning of a filing record across the change. A team can complete the first and still lose track of which approved data it sent.

My analysis: the useful unit of preparation is one return with its due date, approved version, submission evidence and correction history. Start there before reporting an overall percentage complete.

Use the due date to select the route

The September notice sets the test window from 1 January to 31 March 2027. Tests are explicitly non-official. Covered returns due through 31 March stay on the current channels. Returns due from 1 April use the new route, regardless of reporting period; the notice expressly includes March monthly and Q1 returns. Submission can use manual eDesk or automated S3 JSON. The optional data-feed API is a separate facility, not the act of submitting the return. CSSF transition notice

That gives a reporting team a practical routing rule, but it does not supply every return’s due date. Put the applicable deadline beside the period in the schedule, then assign the route. A period label such as “March” cannot decide the route by itself.

The scope also matters. The notice concerns the covered prudential returns for payment institutions, electronic money institutions and crypto-asset service providers authorised under Article 63 of MiCAR. It does not move every report that those firms send to the CSSF. CSSF transition notice

At publication preparation on 26 October, the inspected CSSF reporting reference page still lists Circulars 11/511 and 11/522, while the September notice describes the replacement circular as forthcoming. Those observations are a reason to keep final instructions as an explicit dependency. They are not proof that no later document exists elsewhere. Before live use, the reporting owner must confirm the applicable circular, final specifications and submission procedures. CSSF reporting reference page

Keep three filing states separate

Consider a fictional team reviewing three returns on 8 April 2027. All deadlines, IDs and amounts below are invented for the example. They illustrate a record design, not a CSSF filing calendar or acknowledgement specification.

These rows describe three different conditions. R1 has the relevant official evidence, even though its successful test used the future route. R2 has tested the route but has not filed its actual return. R3 has filed, but the evidence does not yet establish that its submitted data agrees with the approved dataset.

The distinction belongs in the record itself. Keep a test reference, an official submission reference and an internal data-check result in separate fields. Record what the acknowledgement actually establishes under the applicable procedure. A timestamped receipt may establish receipt without proving every subsequent validation or substantive data check is complete.

Resolve the approved-versus-sent difference

For R3, assume the team uses a narrowly defined internal control measure: the sum, in euros, of ten source balances included in this reconciliation. The measure is not a CSSF reporting line, a total across unrelated reporting cells or a general rule for reconciling a return.

The retained source comparison explains the difference. Balance B07 increased by EUR 6,000 and B09 by EUR 4,000 following two approved source corrections. The other eight balances are unchanged. Together, the two changes explain the entire EUR 10,000 difference. A mere agreement of totals would not be enough if individual balances offset each other; this example also retains the balance-level comparison.

At 10:00 on 8 April, the reporting lead has the approved V3 extract, the exact V2 payload sent, approval A3, submission reference NEW-03 and comparison REC-03. The record supports a precise decision: the payload sent was V2, and two approved changes are absent from it. It does not support describing NEW-03 as a failed test or inventing a CSSF rejection.

The team therefore preserves V2 as sent. It does not rename V3 “submitted” and attach the older receipt. That shortcut would destroy the useful evidence of what happened and make later investigation harder.

Carry the correction forward

Continue the example to an outcome. Assume the authorised reporting lead confirms that a corrective submission is required and checks the applicable official procedure. This article does not prescribe the portal steps, replacement flags or acknowledgement meanings; those were not established by the September announcement.

The team builds a corrective payload from approved V3, performs the same balance-level comparison and obtains approval COR-A1 on 9 April. It retains the original filing and links the new action to R3 and NEW-03. The approved corrective payload is submitted as correction COR-03 under the assumed procedure.

For this example, the team then obtains official evidence NEW-03-C whose meaning under that procedure confirms the corrective submission has reached the required filing status. It verifies that the received version is the intended corrective payload, with EUR 250,000 across the same ten balances. The two changed balances match V3 and the eight unchanged balances remain unchanged.

R3 can now be recorded as “corrective filing evidenced; internal reconciliation closed”, within the example’s assumptions. The original discrepancy remains visible in its history. If NEW-03-C only showed receipt, or if the team could not identify the received payload, the relevant verification would remain open. The evidence determines the status.

R2 has a separate route to completion. The team chooses 14 April as an internal submission target, checks the real-period V1 payload and obtains its own official evidence. TEST-02 never becomes that evidence. An internal target is useful planning information; it does not alter the assumed 20 April deadline.

Rehearse the handover before January

Preparation should finish with a usable handover, not a successful login. Assign one person to maintain the final-instruction dependency, one to verify access and permissions for the chosen submission route, and one to own the filing record. Those may be existing responsibilities rather than new roles.

Rehearse one return with a deliberate version difference. Ask the operator to identify which dataset was approved, which file was sent, what the receipt means and what remains open. Then have a second colleague reconstruct the same answer using the retained record. If they need the original operator’s memory, the record is not ready for handover.

The accompanying workbook contains the three-return schedule, the R3 difference and its completed correction chain. Its values are static teaching examples. Replace them with verified local facts and review the actual submission guidance before using the design in production. It is not a file generator or an automated compliance check.

The first preparation decision is to identify the covered returns and their real due dates. The next is to prove that one approved dataset can travel through the new route without losing its identity. That evidence gives the reporting lead something useful to sign off before the cutover arrives.

Companion workbook

Use the due date to choose the route and preserve test evidence separately from the official payload and correction chain.

• Download the editable Excel workbook

• Download the PDF