In-depth guide · Technology
The data model of family wealth
Updated: · Leutrim Miftaraj, FLIORE · Editorial standards · Other languages: Deutsch · Français · Español
Short answer
A sound data model represents family wealth as a network: persons and legal entities are objects, roles and participations are dated relationships with percentages, accounts and assets belong to legal entities, and valuations carry a date, source and currency. Modelling history, master data and original currencies correctly from the start lets consolidation, beneficial owners, reports to authorities and family reports all derive from the same source.
Why the model decides
Whether a family office answers questions in minutes or in days is decided by its data model. If persons sit in several spreadsheets, participations are stored as text in a column and valuations have no date, neither the wealth per family branch nor the list of beneficial owners can be calculated reliably. A good model represents reality in such a way that every recurring question can be answered from the same data – without re-entering anything.
The core objects
| Object | Main attributes | Relationships |
|---|---|---|
| Person | Name, date of birth, nationalities, residences, tax residences with TIN, identity documents with expiry date | Roles in legal entities, powers of attorney |
| Legal entity | Legal form, seat, register number, LEI, classification for CRS and FATCA | Participations, officers, accounts |
| Role | Type (shareholder, founder, trustee, beneficiary …), valid from–to | Links a person or legal entity with a legal entity |
| Participation | Share of capital, share of votes, valid from–to | Legal entity in legal entity, person in legal entity |
| Account and portfolio | Bank, IBAN, currency, holder | Belongs to a legal entity or a person |
| Asset | Type, identifier, original currency | Held through an account or directly |
| Valuation | Date, value, currency, source, method | Belongs to an asset |
| Document | Type, version, valid until, confidentiality | Linked to a person, legal entity or transaction |
Principles
- One person, one record: master data is kept once and used everywhere, not copied per mandate.
- Relationships instead of text: roles and participations are records of their own with percentages and validity, not free-text fields.
- Preserve history: changes end old entries with a date instead of overwriting them – only then can one say who was entitled when.
- Keep the original currency: conversion happens in the analysis, not when storing.
- The origin of every figure: valuations with date, source and method.
- Audit trail: every change with person and time.
Two time axes
One distinction is particularly valuable for family offices: the time during which a fact applied, and the time at which it was recorded. If a share transfer from March is only recorded in June, an analysis as at April must be able to show the new position – while it remains traceable what a report in April actually showed. Keeping the validity date and the recording time separate answers both questions.
From the model to the answers
- Consolidated wealth: calculate through participations with their percentages, convert valuations at the reporting date into the reporting currency.
- Beneficial owners: evaluate roles and participations according to the rules of each legal system.
- AEOI/CRS: classification of legal entities, controlling persons from roles, tax residences with TIN.
- Deadlines: expiry dates of identity documents, powers of attorney and documents, review intervals from the risk rating.
- Reports: views per person, family branch, structure or asset class.
Worked example (simplified)
A family office used to keep participations in a spreadsheet with an «owner» column. When a son received 20 per cent of the holding company as a gift, the entry was overwritten. A year later the bank asked who had been the beneficial owner at the time of an earlier transaction – the answer could only be reconstructed from emails. In the new model the old participation ends with a date and the new one begins; the query as at a given date returns the answer in seconds.
Typical modelling mistakes
Most data problems in family offices go back to a few modelling mistakes that feel harmless at first and become expensive later:
- Owner as a text field: whoever writes «Smith family» in a column can neither calculate percentages nor determine beneficial owners.
- Copied persons: the same person exists in three mandates with different addresses – which one applies?
- Overwritten history: a share transfer replaces the old entry, and the earlier position is lost.
- Converted values stored: values are saved in the reporting currency, the original currency is lost and later analyses become wrong.
- Valuations without date and source: no one knows any longer how current a figure is.
- Documents without links: files in folders instead of being linked to a person, legal entity and expiry date.
In FLIORE
FLIORE follows these principles: persons are kept once and linked to mandates through dated roles, participations carry percentages and validity, values keep their original currency and valuations their date, and every change is in the audit trail. Consolidation, risk assessment, the AEOI/CRS pre-check and reports are calculated from this.
At a glance
| Core objects | Person, legal entity, role, participation, account, asset, valuation, document |
|---|---|
| Most important principle | Preserve history instead of overwriting |
| Two time axes | Validity and recording time kept separate |
Terms on this page
- Beneficial owner
- The natural person who ultimately owns or controls a company, foundation or trust, or on whose behalf a transaction is carried out.
- Tax residence
- The country in which a person is subject to unlimited tax liability because of residence, stay or other criteria.
- Consolidated wealth
- The overall view of a family's wealth across all banks, structures and currencies in one reporting currency.
- Audit trail
- An unalterable log that records who created, changed, approved or deleted which data and when.
Frequently asked questions
Why not simply one spreadsheet per bank?
Because questions are asked across banks, structures and persons. Spreadsheets per bank force manual merging and create contradictions.
Why do roles need validity dates?
To be able to say who was founder, trustee or beneficial owner at a given point in time – a typical question from banks, authorities and auditors.
What is an LEI?
The Legal Entity Identifier is a globally unique 20-character code for legal entities. It makes unambiguous identification easier, for example in securities trading.
How are capital and voting shares handled?
Separately where they differ, for example with shares carrying enhanced voting rights. For the wealth view the capital counts; for control, often the votes.
Should documents sit in the same system?
Yes, linked to a person, legal entity or transaction. Expiry dates can then be monitored and documents for banks compiled in a targeted way.
What happens on a change of system?
A clean model can be exported and migrated in full. The more structured the data, the lower the migration effort.
How detailed should assets be recorded?
As detailed as reports and taxes require: liquid securities individually with an identifier, illiquid investments per participation with a valuation, tangible assets per object. Finer recording without benefit only increases the maintenance effort.
Who maintains the master data?
A clearly responsible person per type of data, with the four-eyes principle for sensitive changes such as bank details. Every change is logged with person and time.
How are contradictory data from different banks handled?
With a designated authoritative source per type of data and a reconciliation: holdings come from the custodian bank, master data from the family office, valuations of illiquid investments from the respective valuation source. Differences are clarified and documented.
Sources
- GLEIF – Legal Entity Identifier (ISO 17442)
- ISO 20022 – message standard
- OECD – Common Reporting Standard (data fields, TIN)
- ISO – currency codes (ISO 4217) and country codes (ISO 3166)
- FATF – Guidance on Beneficial Ownership
This page provides orientation and does not replace legal or tax advice. The cited legal sources in their applicable version are authoritative.
Read more
More on Operations, security & technology
FLIORE in your family office
See structures, compliance and consolidated wealth with your own questions – in a personal demo.