CSSF eDesk and the S3 API — filing in Luxembourg

In Luxembourg the hardest part of a return is often not the return. It is that nobody in the firm holds the role that lets the file leave the building. eDesk is the CSSF’s own portal, and behind it sits an S3 file-exchange interface carrying a growing share of Luxembourg reporting. Both run on a role matrix the firm administers itself, authenticated by a certificate the firm has to procure — and neither can be arranged on the afternoon a deadline falls. This piece sets out what eDesk is, how the roles fit together, how the S3 channel is configured, how to tell an upload from an acceptance, and what a payment or e-money institution needs in place before its first period closes.

1. What eDesk is, and what it is not

eDesk is the Commission de Surveillance du Secteur Financier’s digital portal for supervised entities, at edesk.apps.cssf.lu. It is two things bolted together: online procedures — forms a named person completes and submits — and an enrolment layer issuing the credentials for machine-to-machine filing.

eDesk is not itself an obligation, and being enrolled says nothing about what a firm owes. The obligations live in the circulars and in the legal reporting framework for each entity type; eDesk is the counter several of them are delivered over. The distinction matters when a plan says “eDesk is done”: what is done is access, not the return.

Three live procedures show the range. Major ICT-related incident notification arrived as an eDesk procedure under Circular CSSF 24/847, mandatory from 1 April 2024 for one set of entity categories and 1 June 2024 for the rest, displacing the older arrangements under Circular CSSF 11/504. The DORA Register of Information has its own procedure, whose window for the 31 December 2025 reference date ran from 11 February to 31 March 2026. And ICT incident and cyber-threat reporting under DORA is now framed by Circular CSSF 25/893 — which repealed Circular CSSF 21/787 on the EBA guidelines for major incident reporting under PSD2, and was itself amended by Circular CSSF 26/915. Payment institutions, e-money institutions and account information service providers appear in that circular’s scope list.

2. Authentication: the certificate is the gate

Access to eDesk requires a LuxTrust means of authentication. The CSSF puts it without qualification: only users authenticated through a LuxTrust token can reach eDesk, and therefore only they can obtain the keys that configure machine filing. There is no password-only route and no delegating the step to a system account.

Two consequences follow, both discovered late by firms whose reporting function sits outside Luxembourg. First, lead time: the authentication means must be ordered, identity-checked and activated before anyone can see the portal, which puts it on an authorisation project’s critical path rather than on a reporting to-do list. Second, identity in eDesk is personal — continuity across leave and turnover comes from enrolling a second individual, not from circulating credentials. The portal publishes an eDesk Authentication User Guide under “Getting started”; the support address is edesk@cssf.lu.

3. The role matrix the firm administers itself

eDesk devolves user administration to the supervised entity. That is efficient, and it is also where most access failures start, because the entity — not the CSSF — has to notice a gap.

The keystone is the Advanced User. An entity with none creates one through eDesk by submitting a “New advanced user request”; the CSSF endorses the appointment on receipt of identification documents and a signed mandate. The Advanced User then accepts or rejects the attachment of other eDesk users to the entity and grants rights and specific roles within it — but is an administrator, not a filer. Holding the role does not by itself permit a submission. Specific roles sit on top:

Read that as a dependency chain rather than a menu. Every specific role depends on an Advanced User existing first, and the Advanced User depends on a CSSF endorsement that involves paper. A firm that discovers on deadline day that it has none has a problem measured in days, not minutes.

4. The S3 channel: buckets, keys and two folders

For structured reporting the CSSF exposes an S3 interface — the object-storage protocol, reached over a web service. The CSSF is explicit that here S3 means only the protocol and does not rely on any commercial cloud service.

The model is small enough to hold in one’s head. Data is stored as objects — a file plus its metadata — inside buckets, and an entity is linked to a bucket divided into two folders: submission for files going out, feedback for what comes back. Each report type has its own bucket, so a mid-sized filer holds several.

Enrolment runs through the roles above. Once the Advanced User has designated an IT Expert, that person signs in to the eDesk IT management console at edesk.apps.cssf.lu/edesk-itmgt, uses “Create access”, selects the relevant service — the scope — then opens the entry to collect three values: bucket, access key and secret key. One warning on that screen deserves reading before the click rather than after: the secret key displays only once, and losing it means resetting the credentials. Access is revoked from the same screen.

Client configuration is deliberately unexotic: any S3-compatible transfer client for manual work, any S3-compatible SDK for automation, pointed at protocol S3, host s3.apps.cssf.lu, port 443. Some clients need their URL style switched to Path. Two smaller behaviours cause most first-day confusion — for each report type the IT Expert may have to create “submission” manually before the first upload, while “feedback” appears by itself; and files in both folders are cleaned 20 days after creation, making the bucket transport, never an archive.

On security the CSSF is direct: the IT Expert monitors every credential created, and sharing credentials or uploading through a third party remains the sole responsibility of the entity. Outsourcing the mechanics does not move the accountability.

5. Feedback is the acceptance — the upload is not

The published process has three steps: the file is collected through the S3 system, it undergoes a formal verification, and a feedback is sent — positive or negative. Nothing there treats a successful upload as the end of the story, and the CSSF states the receiving-side duty plainly: entities must ensure all feedback files are properly analysed and any rejected data corrected and resubmitted.

Two design decisions follow. Monitoring belongs on the feedback folder, not on the transfer client’s exit — a job reporting success because the upload returned cleanly will show green on a rejected return. And since the folders empty after 20 days, each feedback file must be pulled into the firm’s evidence store on receipt; what the CSSF said about a period cannot be reconstructed from the bucket months later.

Before going live there are two ways to test: a dedicated testing environment, and an Echo service that runs in production for connectivity checks. The IT Expert creates an access on the Echo bucket, a dummy file goes into submission, and a dummy feedback returns in feedback — one immediate feedback per file submitted. The service is permanently available, the CSSF recommends using it before go-live, and if nothing comes back, escalate to edesk@cssf.lu.

6. Three scenarios

The failure modes here are administrative rather than technical, which is what makes them expensive: they stay invisible until a date arrives.

Scenario one: the newly authorised e-money institution with no Advanced User. Authorisation lands in the autumn; the first period closes in January. Facts to rule: eDesk needs LuxTrust authentication per individual, an Advanced User must exist before any specific role can be granted, and that appointment is endorsed by the CSSF on identification documents and a signed mandate. What the reporting lead does: order authentication means for two named people in the week authorisation is granted, submit the advanced user request immediately, then map roles to obligations. Outcome: credentials exist before the first period does, rather than a January discovery that the request takes days at the regulator’s end.

Scenario two: the secret key that was never written down. An IT Expert creates an access, copies the bucket name and access key into the runbook, and closes the browser. Facts to rule: the secret key displays only once, and the remedy for losing it is a credential reset, not a lookup. What the analyst does: treat “Create access” as a one-shot operation performed with the secret store already open, and record the scope it covers. Outcome: a five-minute setup rather than an unplanned change — reset-and-reconfigure touches the automation, and is always needed mid-window.

Scenario three: the return that was uploaded and rejected. A quarterly file is pushed to submission by a job that logs a clean transfer; two months later a query arrives about missing data. Facts to rule: verification happens after collection and produces positive or negative feedback, rejected data must be corrected and resubmitted, and both folders are cleaned after 20 days. What the team does: schedule a read of feedback, alert on negative results, copy each feedback file into the evidence store on arrival, and treat “no feedback retrieved” as an exception rather than silence. Outcome: a rejection surfaces within a day instead of a green dashboard sitting on a return the CSSF never accepted.

7. What still travels by other routes

eDesk and its S3 interface have not absorbed everything. A body of Luxembourg reporting still reaches the CSSF through externally operated transmission channels, and those carry their own security regime: files must be encrypted to the standards in Circular CSSF 23/833, and the entity must register its LuxTrust SSL certificate with the CSSF beforehand. The CSSF publishes the encryption certificates and the technical naming conventions; following them is the filer’s responsibility.

So the reporting map has two columns, and the ordering that holds up is: obligations first, then the channel each uses, then the eDesk role or certificate that channel needs, and only then the people. Built people-first, the matrix always has holes. Formats vary by procedure and come from the procedure’s own guidance, never from assumption: the incident-notification route accepts structured .json through S3 as an alternative to the eDesk form, while the Register of Information goes as plain CSV inside a .zip on a predefined folder structure and naming convention, with the entity’s LEI communicated to the CSSF in advance.

8. FAQ

9. What to do, today

• Confirm the entity has an endorsed Advanced User. If not, submit the request now — documents, mandate and endorsement are none of them same-day.
• Order LuxTrust authentication means for two named individuals per filing responsibility, so leave and turnover do not stop a submission.
• Write the role map beside the obligation map: who holds IT Expert, IT Incident Notifier and DORA Reporting, and which return each unlocks.
• Create S3 accesses with the secret store already open, and record bucket, key location and scope per report type — the submission folder may need creating manually for each.
• Instrument monitoring on the feedback folder rather than the transfer client’s exit code, and copy every feedback file into your own evidence store on receipt: the 20-day cleanup means the bucket is not an audit trail.
• Run the Echo connectivity check before the first production submission, and again after any credential reset.
• For obligations still travelling by externally operated channels, check the encryption standard in Circular CSSF 23/833 and confirm your LuxTrust SSL certificate is registered with the CSSF.

Related: CSSF legal reporting for payment and e-money institutions · Reporting channels compared across the EU · How a DORA register of information is built · The CSSF AML/CFT data collection