Data point model — the layer everyone skips
The data point model is the layer most reporting projects skip, and the layer most reporting failures come from. The European Banking Authority describes it as a structured representation of the data, identifying all the business concepts and their relations as well as the validation rules, containing the technical specifications needed to develop an IT reporting solution. In other words: it is the meaning, and the taxonomy is only the encoding of it.
1. A cell is not a cell
The central idea is that a reported figure is not identified by its position in a template. It is identified by a combination — a metric plus the dimensions that qualify it: the counterparty sector, the country, the currency, the maturity band, the accounting portfolio, and so on. The template is a human-readable presentation of those combinations, not their definition.
Two practical consequences fall out immediately:
- The same data point can appear in more than one template. If it does, it must be the same number, and the validation rules will say so.
- Visually similar cells can be different data points. Two rows labelled the same way in different templates may differ in one dimension, and mapping them to the same source query is a silent error.
2. What to do with it
| Step | What good looks like |
|---|---|
| Inventory | A list of the data points actually in scope for your firm, not the whole framework |
| Map | Each in-scope data point traced to a source field and a transformation, dimension by dimension |
| Document the gaps | Where the source cannot produce a dimension, that is a data-collection change — not a reporting workaround |
| Version the mapping | The mapping is an artefact with a framework version attached, and it changes when the framework does |
The mapping document is the deliverable that survives staff turnover, vendor changes and framework releases. Where it does not exist, the knowledge lives in whoever last built the extract — and framework releases become archaeology rather than change management.
3. Why dimensions are where the work is
Most source systems store the metric happily. What they often cannot produce is the dimensional detail: counterparty sector on the right classification, residence at the right level, the accounting portfolio, the correct instrument category. That is why a reporting programme is usually a data-collection programme wearing a reporting label, and why the honest sequence is to fix the source rather than derive the dimension in the reporting layer.
A derived dimension is not automatically wrong — but it needs the same documentation as any other transformation, because a supervisory query about a single figure will eventually ask how each of its qualifiers was determined.
FAQ
Is the DPM the same as the taxonomy?
No. The DPM is the structured representation of the concepts, relations and validation rules; the XBRL taxonomy expresses that model in a technical format for transmission.
Do we need the DPM if we have the templates?
The templates show the presentation. The model shows what each cell actually is, dimension by dimension — which is what a correct mapping needs.
What is the single most useful artefact to maintain?
A versioned mapping from in-scope data points to source fields and transformations. It is what makes a framework release a change project rather than a rebuild.
Related: XBRL taxonomies · Validation rules · The AnaCredit data model
