DNB Digitaal Loket Rapportages — the reporting channel

DNB Digitaal Loket Rapportages — DLR — is where a Dutch payment or e-money institution’s regulated returns actually land, and it is only half of the channel story. The other half is a separate portal for formal supervisory correspondence, and firms that discover the split late spend their first reporting cycle sending things to the wrong place. This piece sets out what DLR carries and what it does not, how access is granted, why the XBRL discipline is stricter than it first appears, and — with worked examples — where reporting projects actually lose time.

1. What DLR is, and what it replaced

DLR — Digitaal Loket Rapportages, in English DNB’s Reporting Service — is the electronic channel through which supervisory and statistical returns are submitted to De Nederlandsche Bank. It is reached through Mijn DNB (My DNB), the umbrella login under which DNB now presents its digital services, and the reporting application itself is hosted on DNB’s own applications domain.

DLR is the successor to the older e-Line DNB environment. The migration was not a single switch: DNB phased it in per report type, which is why documentation and firm-side runbooks written at different times can describe different channels for the same institution. If an internal procedure still names e-Line, it is describing a retired route.

2. The split that catches firms out: DLR is not DLT

DNB operates a second portal, the Digitaal Loket Toezicht (DLT), the Digital Supervision Portal. The division of labour is clean once you know it, and invisible until you do:

The practical test is whether the submission is a return or a request. A quarterly prudential template is a return and belongs in DLR. A change of a managing director, an application to add a payment service, a declaration of no objection for a qualifying holding — these are formal supervisory messages and belong in DLT. Both sit behind the same Mijn DNB front door, which is exactly why they get confused.

3. Access: eHerkenning, and the delegation question

Access to DLR runs on eHerkenning, the Dutch national scheme for business identity — not DigiD, which is the citizen-facing scheme and cannot be used to file on behalf of an institution. The distinction matters operationally: eHerkenning is issued to the legal entity and then used to authorise named individuals, so the reporting entitlement is an administered permission, not a personal login someone can hand over.

DNB’s own framing is that an institution authorises staff members or others to submit reports on its behalf through eHerkenning. That last clause is the one worth planning around: it is the basis on which a group reporting team in another country, or an outsourced reporting provider, can file for the Dutch entity. The entitlement is grantable and revocable, and the assurance level required is set by DNB and published on its access pages — confirm it against the current guidance rather than an internal note, because eHerkenning levels have been tightened across Dutch public services over time.

Two consequences follow. Lead time is real: eHerkenning is obtained through recognised suppliers, and the authorisation chain from entity to named filer takes longer than most launch plans assume. And leaver risk is real: when a named filer leaves, the entitlement survives them unless someone revokes it.

4. What a PSP actually files through DLR

The reporting catalogue depends on the firm’s category, and DNB publishes per-category documentation rather than one universal list. For payment institutions, electronic money institutions and crypto-asset service providers, the documentation families that matter are:

• Prudential reporting manuals, published separately for payment service providers, electronic money institutions and crypto-asset service providers
• Data-entry templates for PSP and CASP returns
• The IT Risk & Cyber Questionnaire
• Integrity risk questionnaires
• Fraud reporting templates — see our PSD2 fraud reporting walkthrough for what those figures have to reconcile against
• Statistical returns in the ECB framework — BSI, MIR and AnaCredit
• Instant Payments Regulation reporting and, for firms in scope, prudential returns in the COREP family

The presence of CASP manuals and templates alongside the PSP set is worth noting on its own: crypto-asset service provider reporting under MiCA is administered through the same channel, so a firm holding both a payments and a CASP authorisation files two catalogues through one portal, on two calendars.

5. The XBRL discipline, stated accurately

DLR is built around XBRL, and DNB publishes a general requirements document for XBRL reports that functions as the technical contract for submissions. It is the right first read for anyone building a pipeline, because it constrains choices the business layer usually makes without knowing it.

One widespread misconception deserves correcting: the rule is not “no CSV”. xBRL-CSV is a serialisation of XBRL, and DNB’s own validation notices address XBRL and xBRL-CSV filings together. What is not accepted is an arbitrary spreadsheet export — a CSV that is not an XBRL serialisation against the published taxonomy. The distinction sounds pedantic until a project is scoped on the wrong side of it.

Validation is where most cycles are lost, and DNB has publicly worked on tightening and optimising the validation of XBRL reports, including the treatment of filing indicators. Filing indicators are the mechanism by which a report declares which templates it is actually reporting, and getting them wrong produces a submission that is technically valid and substantively incomplete — the worst failure mode, because it can pass.

6. Worked example: the access chain nobody owns

Facts: a payment institution is authorised in the Netherlands in September. Its group reporting team sits in another Member State and will prepare the returns. The first statistical reference date falls at the end of the following quarter. Nobody has yet obtained eHerkenning.

What the rules say: DLR access requires eHerkenning issued to the entity, with authorisations then granted to the individuals — staff or others — who will submit on its behalf. Neither the eHerkenning issuance nor the authorisation chain is instant, and neither is inside DNB’s gift to accelerate.

What the practitioner does: treat access as a critical-path item running in parallel with the reporting build, not as a step after it. Start eHerkenning issuance immediately on authorisation; identify the named filers and their alternates; grant the group-team authorisations explicitly; and confirm the whole chain by making a submission in a non-live capacity well before the first reference date. Then add revocation to the leaver checklist — the entitlement outlives the employment.

7. Worked example: the return that went to the wrong portal

Facts: an e-money institution replaces a member of its management board in March and, in the same week, files its quarterly prudential template. The reporting analyst uploads both the template and the board-change notification through the Reporting Service.

What the rules say: the prudential template is a supervisory report and belongs in DLR. The board change is a formal message under supervisory legislation — a notification feeding a fit-and-proper assessment — and belongs in DLT. The reporting channel has no obligation to reject an out-of-scope document, and an unfiled notification does not announce itself.

What the practitioner does: re-file the notification through DLT immediately and date-stamp the correction, since the original submission does not stop the notification clock. Then fix the cause rather than the instance: maintain a single register of outbound obligations with a channel column, and require the channel to be named in the procedure for each one. This is the same discipline as our comparison of EU reporting channels recommends generally — the channel is part of the obligation, not an implementation detail.

8. Worked example: a clean submission that was still wrong

Facts: a firm submits an XBRL return that passes validation without error. Two months later DNB raises a query: a template the firm is required to report appears empty.

What the rules say: filing indicators declare which templates a submission is reporting. If an indicator is set to indicate a template is not being reported, the absence of data in it is consistent and validation has nothing to complain about. The technical layer cannot distinguish “correctly not applicable” from “wrongly omitted”.

What the practitioner does: add a control that is independent of validation — a reconciliation of the filing indicators actually submitted against the firm’s own mapped obligation list for that reference date, reviewed by a person who did not build the file. Acceptance by the channel is evidence of technical conformity only, and treating it as evidence of completeness is how these queries arise. Our note on reconciling regulatory returns covers the wider pattern.

9. FAQ

10. What to do, today

• Reporting lead: start eHerkenning issuance and the authorisation chain the week authorisation is granted — it is critical path, not a follow-up task.
• Compliance officer: build the outbound obligation register with a channel column, and settle DLR versus DLT for every item before the first cycle.
• Reporting engineer: read DNB’s general requirements for XBRL reports before designing the pipeline, and pin taxonomy versions to reference dates rather than to submission dates.
• Controller: add a filing-indicator reconciliation against the mapped obligation list, reviewed by someone who did not build the file. Channel acceptance proves conformity, not completeness.
• Operations: put eHerkenning entitlement revocation on the leaver checklist.

Related: DNB BSI / MIR · IPR statistical report · EDITRAN in Spain · The Dutch reporting calendar · Reporting channels compared · MESRAP — the Dutch balance-of-payments return