Account registers compared — five EU markets
Every EU market maintains a central record of who holds which accounts, and no two collect it the same way. Some are event-driven registers fed on opening and closure. One is a periodic file. One is not a data submission at all but a live connection that authorities query directly. A firm operating in several markets therefore needs four different build patterns for what looks like one obligation — and the differences are architectural, not cosmetic.
1. The comparison
| Market | Mechanism | Shape |
|---|---|---|
| Spain | Fichero de Titularidades Financieras | A periodic file cycle to the financial intelligence unit |
| France | FICOBA | Event-driven — opening, modification, closure, in versioned XML |
| Italy | Archivio dei rapporti finanziari | Both — a monthly event communication and an annual balances return |
| Netherlands | Verwijzingsportaal Bankgegevens | A connection, not a submission — with an availability requirement |
| Spain, additionally | Modelo 196 | A monthly account information return to the tax administration |
2. Four build patterns
The mechanism dictates the architecture, and getting this wrong is expensive to unwind:
- Event-driven register. Needs a change feed off the account lifecycle, with an explicit list of which declared fields are change-relevant. Emitting on every customer-record change produces noise; emitting only on open and close produces silent drift, because modification is a separately declarable event in France.
- Periodic file. Needs a pinned population snapshot at a reference date, and the ordinary reporting pipeline discipline around it.
- Both, in parallel. Italy’s design requires two distinct feeds from one model — an event feed for openings and closings with connected subjects and their roles, and a population-and-balances feed keyed to 1 January and 31 December. Serving both from one extract is the commonest structural error in that regime.
- Live connection. Needs uptime engineering and an availability control. There is no file, so there is nothing to reconcile and nothing to archive — the control is that the service answers.
3. Perimeter: the cross-border question
The most valuable thing to compare is not the format but who is caught, because that is where firms wrongly scope themselves out.
Two of these regimes reach firms with no local establishment. France’s obligation under Article 1649 A of the Code général des impôts expressly covers establishments operating under the freedom-of-services provisions of the Code monétaire et financier for their operations with French residents. Spain’s monthly account return expressly covers foreign entities operating in Spain under the freedom to provide services in respect of accounts held by Spanish residents.
In both cases the trigger is the customer’s residence, not the firm’s. A passporting EMI with no branch is inside both.
4. What is common to all of them
Whatever the mechanism, the payload is the same in substance and so are the failure modes:
- Identity data is the whole build. These are identity records attached to accounts. There are no balances to reconcile in most of them and no arithmetic to check — so the quality bar sits entirely on holder identification, and every one of these regimes fails in the same place: customers whose identification data was never captured to the standard the register requires.
- Roles are harder than holders. Where connected persons must be declared with their role — as in Italy — the mapping from internal product vocabulary to the register’s role codes is a versioned artefact that should exist before the first submission.
- Specifications are versioned independently of the law. France’s XML cahier des charges, Italy’s technical specifications and Spain’s formats all change without the underlying instrument changing.
5. Building once for several markets
Facts: an EMI serves customers in Spain, France, Italy and the Netherlands from one platform.
What the analysis produces: one internal model of account, holder, connected persons and lifecycle events — and four renderings. The model must carry customer residence as a maintained attribute, because that is what decides scope in at least two markets, and it must carry role as a first-class field rather than deriving it at report time.
What the practitioner does: builds the event feed once, since three of the four regimes consume events, and treats the periodic and connection variants as different consumers of the same model. The reconciliation that matters is between the account population in the core ledger and the population reflected in each register — differences in either direction are the finding, and for the connection-based regime it is the only detective control available.
FAQ
Which markets catch firms with no establishment?
France and Spain both frame their obligations around the customer’s residence — French residents for FICOBA, Spanish residents for the monthly account return — so a passporting firm with no branch is inside both.
Which is the odd one out?
The Netherlands. The reference portal is a mandatory connection with an availability requirement rather than a data submission, so it needs uptime engineering rather than a reporting pipeline.
What is the single highest-risk data field?
Holder identification. These registers are identity records attached to accounts, so identification quality is the whole quality question.
Related: FICOBA · The Italian archive · Modelo 196
