In Short: What Is Different About Building in Financial Services?
Three things become requirements rather than good practice: you must be able to prove where a number came from, access control must reflect real boundaries between desks and entities, and retention is a legal question. None are technically exotic. What differs is that they have to hold under examination, which changes how you design and how long sign-off takes.
Prove It, Do Not Assert It
In most sectors, "can we trust this number?" is answered by reputation. Under regulatory scrutiny it has to be answered with evidence.
That changes the architecture in a specific way: lineage has to be a property of the platform, not a document someone maintains. A maintained document is out of date within a quarter and worthless in an examination.
Purview lineage across Fabric traces a figure from the report, through the semantic model, back through the transformation layers to the source system. The practical test is simple: pick a number on a board pack and ask how long it takes to show its full derivation. If the answer involves opening Power Query and reading code, you do not have lineage - you have a person who knows.
The corollary is that transformation logic must live somewhere traceable. Logic buried in Power Query on one dataset is invisible to lineage tooling. It belongs in the Silver and Gold layers where it can be inspected, tested and traced.
Access Control That Matches the Org Chart
Financial services firms have real boundaries: desks that must not see each other's positions, entities that must be reported separately, client teams walled from one another.
The wrong implementation is a report per audience. It appears simplest and it fails predictably - twelve near-identical reports drift, one gets a fix the others do not, and eventually someone sees something they should not because a copy was made from the wrong template.
The right implementation is row-level security at the data layer, driven dynamically from your organisational structure. One report, filtered per user by rule rather than by which copy they opened. Combined with role-based access through Microsoft Entra, permissions follow people as they change roles - and offboarding actually offboards.
Design this before building reports. Retrofitting RLS onto an estate built without it is substantially harder than including it from the start, because the model often needs reshaping to support it.
Retention Is a Legal Question
Elsewhere, retention is a storage cost conversation. Here it is an obligation in both directions: some records must be kept for defined periods, and some must not be kept beyond them.
Two implications:
Retention must be enforced, not documented. Lifecycle rules that actually delete, applied per data category, with the deletion evidenced. A policy stating seven years is worth nothing if the lakehouse holds nine.
Deletion in an append-only architecture needs designing. Lakehouses are built to accumulate. If personal data must be erasable, that requirement shapes how you partition and structure tables - decide it during design, not when the request arrives. Our GDPR guide covers this in more depth.
Data Residency
Fabric capacities are region-specific, and OneLake data sits in the capacity's region. For a firm operating across the UK, EU and South Africa, residency is an architecture decision made once and expensive to revisit.
Settle it during design: which data must stay where, whether you need capacities in multiple regions, and how cross-region reporting works if you do. This question tends to arrive late in projects where nobody asked it early, and it can invalidate work already done.
What to Build First
The instinct in regulated firms is to start with the regulatory report, because it is the one with a deadline. That is usually the wrong first project - it is the hardest, the most scrutinised, and the least forgiving of a platform still finding its shape.
A better first workload is something internally valuable and externally unexamined: client profitability, cost-to-serve, desk performance. It proves the platform, establishes the governance patterns, and builds trust - and it does so where a mistake is embarrassing rather than reportable.
Move to regulatory reporting once the foundation, the lineage and the access model have been exercised in anger.
Timelines, Honestly
A financial services implementation takes longer than an equivalent build elsewhere, and the difference is almost entirely governance rather than engineering.
Access design needs agreement across desks. Lineage needs validating. Sign-off involves risk and compliance functions with their own cycles. A first workload is still weeks; a platform covering regulated reporting is a phased programme measured in quarters.
Plans that ignore this are not faster, they are just wrong earlier.
Where Solv Systems Comes In
We build Fabric platforms for regulated firms across the UK, EU and South Africa, which means UK GDPR and POPIA are familiar ground rather than something we look up.
Practically, we design access control and lineage before we build reports, keep transformation logic where it can be traced, and produce the evidence trail as a by-product of the architecture rather than a document maintained alongside it. The test we hold ourselves to is whether you can answer an examiner's question with a report rather than a project.
Sources and Further Reading
Frequently asked
Three things: you must be able to prove where a number came from, access control has to reflect real organisational boundaries between desks and entities, and retention is a legal question rather than a storage one. None are technically exotic - what differs is that they are requirements rather than good practice, and they have to hold under examination.
The platform provides the capabilities - lineage through Purview, granular access control, audit logging, classification and retention. Whether your implementation is compliant depends on how it is designed, not on the product. Buying Fabric does not make you compliant any more than buying a filing cabinet makes you organised.
Lineage has to be a property of the platform rather than a document someone maintains. Purview traces a figure from report back through the semantic model and transformation layers to the source system. The practical test is whether you can answer 'where did this number come from' with a report rather than an investigation.
At the data layer, not per report. Dynamic row-level security driven by your organisational structure means one report serves everyone and each person sees only their entitlement. Building separate reports per desk creates a maintenance problem and, eventually, an inconsistency that someone notices at the wrong moment.
Fabric capacities are region-specific and OneLake data sits in the capacity region, so residency is an architecture decision made at the start. For firms operating across the UK, EU and South Africa this needs settling during design, because moving a capacity region later is disruptive.
Longer than an equivalent build elsewhere, and the difference is governance rather than engineering. Access design, lineage validation and sign-off cycles add time. A focused first workload is still weeks; a platform spanning regulated reporting is a phased programme measured in quarters.
