Financial Data Model: Structure, Standards and Implementation
A financial data model is a standardised structure of business concepts and the relationships between them. It spans a semantic, a logical and a physical layer, and it allows regulatory reports to be generated automatically while ensuring data quality. In practice, this structure builds on standards such as DPM and BIRD, as well as local systems, so for financial institutions it becomes the foundation for preparing for both current and forthcoming regulatory requirements. Below you will find practical implementation steps and a checklist to help you prepare for integration.
In brief:
- A financial data model has three layers: a semantic vocabulary, a logical schema of relationships and the physical data storage solutions.
- The DPM and BIRD regulatory standards shape the data structure and validation rules, while DORA requires testing and the precise identification of contracts.
- To get started, you need to draw up a data map, create a glossary of business terms and put validation rules in place at the point of data entry.
- Once the model is stable, reports can be generated automatically in Power BI, integrating data from Rivilė, Finvalda or other systems.
Contents
- Three-tier architecture: the semantic, logical and physical model
- Regulatory standards: the impact of DPM, BIRD and DORA
- Implementation plan: from data map to REGATA integration
- Checklist: party, instrument, contract, balance, transaction
- Analitika360: from data model to automated report
- Editorial insight: what to do first over the next 12–24 months
- Ready-made reporting solutions once your data model is in order
- FAQ
- Sources
Three-tier architecture: the semantic, logical and physical model
A data model works on three levels, each serving a different purpose. The semantic level defines the business vocabulary: what a “contract”, a “transaction” or a “customer” means in the organisation’s context, regardless of how the data will be stored. This level acts as the metadata foundation on which all the lower structures rest.
The logical level (LDM) turns business concepts into structured relationships: entities, attributes and their dependencies. This is precisely the principle applied in the BIRD LDM documentation, which defines what a financial institution must report to its supervisor, irrespective of the particular database technology.
The physical level is the concrete implementation: tables, fields, indexes and the chosen database technology. This is where the range of choices is widest, because two different banks can share the same logical structure yet have entirely different physical storage.
- Semantic level: a vocabulary of business terms and their definitions.
- Logical level: a structure of entities and relationships, independent of technology.
- Physical level: the specific database implementation and storage solutions.
By separating the logic from the implementation, an organisation can change its physical infrastructure without breaking its business rules or validation logic.
Regulatory standards: the impact of DPM, BIRD and DORA
Regulatory data models are not a theoretical construct: they directly determine how an organisation must structure its data for reporting. The EBA DPM data dictionary defines business concepts, their relationships and the validation rules, which are then translated into XBRL taxonomies. The DPM methodology has been in use since the 2010s and has become the standard for managing regulatory reporting data over the long term, while the DPM Alliance governance framework coordinates support for this metamodel across European institutions.
BIRD complements this framework at the logical level. The BIRD LDM principles rest on normalisation, explicitness and subtyping, which help reduce duplication and catch errors before the data reaches the report-building stage.
DORA (the Digital Operational Resilience Act) adds a new layer: Registers of Information (RoI) on contractual arrangements with ICT service providers. EBA’s preparatory material on DORA shows that the dry runs carried out revealed practical errors relating to identifiers and formatting.
DORA has applied since the start of 2025, setting new requirements for financial institutions’ registers of contracts with ICT service providers, as confirmed by the EBA. This means financial institutions should already have their LEI identifiers in order and their RoI registers up and running.
- DPM: a dictionary of business concepts and validation rules, the basis for XBRL taxonomies.
- BIRD LDM: a logical model that reduces duplication through normalisation.
- DORA RoI: a register of contractual relationships that requires accurate identifiers.
It pays to introduce validation rules right at the point of entry, since most errors stem from missing mandatory fields rather than from complex logic at later stages.
Implementation plan: from data map to REGATA integration
Preparing for regulatory reporting happens in stages, and each stage has its own technical solution.
- Inventory and data map. List all your data sources and draw up a map showing where every field used in a report comes from.
- Building a glossary. Prepare a vocabulary of business terms with metadata so that the semantic level is clear to every team, not just the IT department.
- Deciding on the logical level. Decide whether you will use the logical model (LDM), the Input Layer or the Enriched Input Layer structure for integration, and a separate structure for building reports.
- Implementing validation rules. Put the rules in place at the point of data entry so that errors are caught before the data reaches the reports.
- Preparing formats. Prepare the data in XBRL, CSV or JSON, in line with the requirements of the REGATA system of Lietuvos bankas, the Bank of Lithuania, which supports these formats and API integrations.
- API testing. Test the connection to REGATA in the test environment before moving to the production system.
- Dry run and error analysis. Carry out a trial run and collect the most common errors: missing LEI codes, empty mandatory fields and non-compliant formats.
Professional tip: Start applying validation rules in your data entry forms rather than at the report generation stage; that way you cut the number of errors with a tenth of the effort.
Lietuvos bankas notes that implementing REGATA is part of its Data Management Maturity Programme, which encourages a shift from a push to a pull model of data submission. This means organisations need designated data owners and clear data maps, not merely the technical infrastructure.
Checklist: party, instrument, contract, balance, transaction
A practical data model in a financial organisation usually rests on five core groups of entities. Each has its own mandatory attributes and relationships with the other groups.
- Party: identifiers, LEI code, legal form, country of residence.
- Instrument: type, currency, maturity, interest terms.
- Contract: parties, dates, terms, related instrument.
- Balance: balances, valuation date, accounting category.
- Transaction: date, amount, related contract and parties.
The most common cause of validation errors is a missing or incorrect LEI identifier, followed by empty mandatory fields and inconsistent date formats. Every record should have a clear audit trail (lineage): when the data was created, who changed it and at what stage it reached the final report. Versioning lets you trace how the model has changed over time and is especially important when preparing for inspections.
Analitika360: from data model to automated report
Once they have built a data model, organisations face a further challenge: how to turn that structure into a report used day to day that managers, accountants and analysts can understand. The market offers Power BI report packages designed for analysing data from the Rivilė and Finvalda accounting systems, integrating them with other sources such as SharePoint, Excel or CRM systems.
Such systems can make it possible to track revenue, expenses, profit, balance sheet and debt metrics in real time, and the reports can refresh automatically without any further input from the user. This means an organisation that has already sorted out its data map and validation rules can carry that structure straight over into a visual, continuously updated set of reports.
For different industries, such as restaurant chains or logistics companies, the content of the reports can be tailored to specific processes, which reduces the separate manual work that generic, one-size-fits-all solutions usually demand.
Editorial insight: what to do first over the next 12–24 months
Most organisations invest in technology first, rather than in a glossary and the appointment of data owners. That is a mistake: physical infrastructure changes faster than business concepts, so the first priority should be a clear semantic layer and SLAs with data owners, and only then API solutions for REGATA or similar systems.
— Analitika360
Ready-made reporting solutions once your data model is in order
Once the data model and validation rules are working reliably, the next logical step is to turn this structure into visible metrics that managers can review daily rather than waiting for month-end reports. Analitika360’s ready-made Power BI report packages for Rivilė and Finvalda users let you get started without a lengthy implementation project: Rivilė Basic and Finvalda Basic cost €59 a month, while more advanced functionality is available in the Finvalda PRO package.
For companies that need broader integration with several data sources, the pricing page sets out the Rivilė PRO plan and the rate for bespoke projects, charged at €70 an hour. If you would like to see how your data would look in a ready-made report, take a look at the Finvalda PRO package and choose the plan that suits your accounting system.
FAQ
What is a financial data model and what is it used for?
A financial data model is a structure that defines business concepts, their relationships and rules on three levels: semantic, logical and physical. It is used to standardise data so that it can be relied on for regulatory reporting and internal analysis.
What is the difference between DPM and BIRD?
DPM is the EBA’s data dictionary, which defines concepts and validation rules that are translated into XBRL taxonomies. BIRD, for its part, provides a logical model (LDM) setting out how that data should be structured before it is submitted to the supervisor.
How does DORA affect data model requirements?
DORA requires financial institutions to maintain Registers of Information (RoI) on their ICT service providers, as the EBA states. This means the data model must include accurate identifiers, such as the LEI code, and a clear structure of contractual relationships.
What is REGATA and how does it relate to the data model?
REGATA is the new-generation data system of Lietuvos bankas, supporting the XBRL, CSV and JSON formats as well as automated report submission via API. Organisations preparing for this system need a well-ordered data map and designated data owners.
How much does a Power BI report package from Analitika360 cost?
The Rivilė Basic and Finvalda Basic plans cost €59 a month, while PRO versions such as Finvalda PRO cost €89 a month. Bespoke projects are charged at €70 an hour, as required, as described on the pricing page.