FATCA/CRS filing in the Netherlands — portal or Digipoort

The Dutch tax authority will not let you file FATCA and CRS data until it has invited you to — and the invitation only arrives after a registration most firms discover too late. Filing FATCA and CRS in the Netherlands is a seven-step administrative sequence before it is a data exercise. There are two delivery channels, and the choice between them is made for you by whether you already hold a government certificate. The deadline for the international dataset is 1 August, not the earlier date that governs the domestic bank-product deliveries. This piece sets out the channels, the registration and nil-report mechanics, the feedback loop, and what changes when an e-money institution arrives in the perimeter.

1. Two channels, and which one you get

The Belastingdienst operates two routes for FATCA and CRS account data, and they are not interchangeable in practice.

• The portal route. An account-based upload portal for institutions whose only delivery obligation is FATCA and/or CRS. The tax authority’s own documents name it two ways — the FATCA/CRS step card calls it the Portaal FATCA/CRS (PFC), while the digital-messaging support pages call the same account-based route the Portaal Financiële Instellingen (PFI). Expect both names in correspondence; they describe one route.
• Electronic message exchange (EBV), over Digipoort. The machine-to-machine route. It requires a PKIoverheid certificate and registration with the gateway operator, which is why it is normally only chosen by firms that already deliver other bank-product data down the same pipe.

A third portal exists for a different product category: insurance-product deliveries go to the Portaal aanleveren Verzekeringsproducten (PAV), not to the FATCA/CRS portal. Payment, savings, investment and net-annuity products belong to the bank-and-investment-products category and therefore to the portal or EBV route described above.

2. The deadline is 1 August, and the domestic dates are different

The Netherlands sets separate deadlines for national and international bank-product data, and a firm that builds one annual calendar around the earliest date will over-engineer, while a firm that builds it around the latest will miss two.

The option to deliver FATCA/CRS early, alongside the February national deliveries, is genuinely useful for a firm with one extraction pipeline: it collapses two runs into one. It is a trap for a firm whose reportable-account population is still being remediated in the spring, because bringing the international dataset forward by six months removes the buffer that exists precisely for classification disputes.

3. Registration, and the code you will need again

Registration is a separate act from filing and runs through the FATCA/CRS registration portal. The form offers three choices: register for FATCA or for FATCA and CRS together; register for CRS only; or deregister. One registration covers both regimes — a firm delivering FATCA and CRS registers once.

Two mechanics are worth capturing in your own records rather than trusting to an inbox:

• The meldingscode. A correctly completed registration returns a notification code. You need it later to deregister, and it is reissued only inside the original confirmation e-mails.
• Multi-entity registration. A firm registering for several group entities, or an administrative office filing on behalf of several institutions, uploads a list of those entities with the registration. Templates are offered in spreadsheet and open-document format at the upload field.

Approval produces a portal account, and account activation is stated to take up to five working days. The tax authority then sends an invitation letter specifying the kind of information it wants — for institutions on Bonaire, St Eustatius and Saba, an e-mail instead. FATCA delivery also presupposes a GIIN obtained from the US tax authority; that registration happens on the US side and its identifier is needed to submit through the Dutch channel.

Worked example — an e-money institution newly in scope. An EMI is brought into the CRS population by the extension of the standard to specified electronic money products. It has no Dutch delivery history and no government certificate. Rule: delivery is only possible after registration, portal-account activation and the invitation letter; the EBV route requires a PKIoverheid certificate and gateway registration. What the team does: registers for CRS only, accepts the portal route rather than starting a certificate procurement it cannot finish in time, records the meldingscode in the compliance register rather than in a mailbox, and treats the five-working-day activation window and the invitation letter as two named dependencies on the project plan. Outcome: the administrative path is complete before the first file is generated, which is the reverse of the usual order and the reason most first-year filings slip.

4. Submission and the processing report

After the file is uploaded, the tax authority returns a verwerkingsverslag — a processing report — within a stated maximum of 72 hours. It says whether the delivery was accepted or whether a correction is needed on part of the file. That report, not the upload, is the acceptance.

The operational consequence is a monitoring obligation that outlives the submission window. A delivery made on 31 July with a processing report arriving on 2 August is a delivery whose correction cycle starts after the deadline. Firms that treat the upload as the milestone routinely discover the rejection in the following week, and by then the remediation is late rather than merely inconvenient.

For low volumes the tax authority offers keying applications rather than file generation: an input application for the bank-and-investment-products category and a separate one for life and income insurance. They produce the delivery from manually entered data, which is a reasonable answer for a firm with a handful of reportable accounts and no reason to build an export.

5. The nil year is an action, not an absence

A registered institution with no reportable accounts for the year does not simply stay silent. It uses the same registration portal to record that it has no reportable accounts, giving the reason and the meldingscode issued at registration. That declaration is valid for one year; a firm that is nil for three consecutive years performs the act three times. Permanent removal from the delivery population is a separate request by e-mail, and a firm that stops delivering FATCA data must also deregister on the US side.

Worked example — the quiet institution. A small payment institution concludes in March that none of its account holders are resident for tax purposes in a partner jurisdiction. Rule: the nil declaration runs through the registration portal with reason and meldingscode, and expires after a year. What the compliance officer does: files the nil declaration, then books a recurring annual control rather than closing the item, because the obligation reappears in the next cycle whether or not the population changed. Outcome: the firm is not treated as a non-responding registered institution in year two — the most common way a nil filer acquires a compliance finding.

6. Which account holders, and which jurisdictions

The Dutch CRS obligation rests on the Wet uitvoering Common Reporting Standard, in force since 1 January 2016; data for 2016 and later years has been passed to partner administrations since September 2017. FATCA delivery rests on the intergovernmental agreement between the Netherlands and the United States, and the receiving authority is the US tax administration.

CRS data is only delivered for account holders whose country of tax residence is on the exchange list — published by the tax authority on its digital-messaging support pages and inside the delivery portals. Two points follow that are easy to get wrong in the extraction logic:

• An account holder can be tax resident in more than one jurisdiction, so residence is a set, not a field.
• The exchange list is the filter. A self-certified residence in a jurisdiction that is not on the list does not produce a reportable account, and treating every foreign residence as reportable inflates the file with records the administration will not forward.

Institutions on Bonaire, St Eustatius and Saba are inside the Dutch delivery framework, and the step card restricts them to the portal route.

7. What arrives next: DAC8 and CARF

Two extensions sit immediately behind the current campaign, and they are separate projects that share a timetable.

• The CRS extension to e-money. Specified electronic money products come inside the CRS definition of a financial account, which brings e-money institutions into the reporting population — and therefore into the registration and portal sequence described above.
• Crypto-asset reporting. The Netherlands states that crypto-asset service providers must hold the relevant customer information from 1 January 2026, and that from 2027 it must be reported annually to the tax authority by 31 January. A separate duty requires the provider to inform its customers which data is being reported, by 31 January following the calendar year.

The January reporting date is the planning headline: it is six months earlier in the year than the FATCA/CRS date and lands in the same weeks as the domestic February deliveries. A firm doing both should not assume the crypto return will travel down the CRS channel — the delivery mechanics for the crypto framework are still being built out, and the two returns have different populations, different messages and, in the Netherlands, different deadlines.

8. Three CRS campaigns, three calendars

For a group filing in more than one member state, the deadline spread is the single most expensive detail, because a group-level milestone built on the latest date misses the earlier ones by weeks.

Worked example — one data layer, three submissions. A group with Dutch, French and Spanish entities plans a single CRS programme. Rule: three separate obligations to three administrations, with deadlines on 1 August, 15 July and 31 May. What the programme lead does: builds the reportable-account population once from the 31 December snapshot, then runs three country rendering-and-submission tracks with their own test cycles, sequencing the Spanish track first because it closes earliest. Outcome: the expensive half — identifying and validating reportable accounts — is done once, and the cheap half is done three times, which is the correct shape. Building three full pipelines duplicates the costly work and still misses 31 May.

9. FAQ

10. What to do, today

• Check whether you are registered at all, and whether the invitation letter for the current campaign has arrived. No invitation means the administrative chain is broken upstream of your data.
• Find the meldingscode and store it in the compliance register. You need it for a nil declaration and for deregistration, and it is only reissued inside the original e-mails.
• Decide the channel deliberately. No PKIoverheid certificate means the portal route; an existing Digipoort connection makes EBV cheaper, but then the processing report arrives on that channel and must be monitored there.
• Move the submission date earlier than 1 August by at least the 72-hour feedback window plus a correction cycle.
• Treat the exchange list as the filter in the extraction, and model tax residence as a set rather than a single field.
• Open the crypto-asset workstream separately if you are in that population, with a 31 January reporting date and a customer-notification duty of its own.

Related: CRS/DAC2 filing in France · Modelo 289 — Spain’s CRS return · CRS for e-money institutions · The Dutch reporting calendar