Microsoft Fabric and Power BI delivery for banking, built around the capacity collision at month end, a small number of certified semantic models, and row-level security that comes from your entitlements rather than from a report setting.
The unification Fabric offers is real and it is the reason to adopt it. It also means that a Data Factory pipeline, a Spark notebook somebody ran at nine in the morning, a semantic model refresh and two hundred interactive report sessions all draw from the same pool of compute.
Fabric capacity is bought as a number and behaves as an architecture. Understanding what draws from it, and when, is the difference between a platform that holds up at month end and one that is throttled on the morning the board pack is read.
Capacity was sized on average consumption
And the month-end peak is not an average.
Engineering and reporting share one capacity
So a notebook can degrade the board pack.
Reports outnumber semantic models many times over
Which means the metric definitions outnumber the metrics.
Direct Lake quietly fell back to DirectQuery
Performance dropped and nothing raised a flag.
Row-level security was built report by report
So it cannot be tested, audited or maintained.
Workspaces grew organically
And the access model is now whatever they became.
The migration recreated the old estate
Same reports, same disputes, new licence cost.
The cheapest moment to reduce a reporting estate is while moving it, and it is the moment almost every programme skips, because lift and shift is faster to plan and easier to approve.
What it delivers is the same number of reports, the same disputed metrics and the same unexplained differences, now running on a platform with a visible monthly cost. The platform then takes the blame for problems it inherited.
Step 1
Inventory the estate and find what is actually used
Step 2
Rationalise before designing anything
Step 3
Establish the measures and who owns each definition
Step 4
Design the capacity model against the month-end collision
Step 5
Design the workspace topology as the operating model
Step 6
Design the OneLake and lakehouse layout, including shortcuts
Step 7
Integrate the sources, on the platform patterns rather than beside them
Step 8
Build a small number of certified semantic models
Step 9
Drive row-level security from entitlements, and test it
Step 10
Build the reports against certified models only
Step 11
Validate numbers against the ledger and the source systems
Step 12
Deploy with monitoring, capacity management and retirement
Fabric presents a set of components that overlap, which is a strength in a product and a problem in a design. Most of the cost and most of the disappointment in a Fabric programme comes from using the wrong component for a workload because both of them worked in the demonstration.
Data foundation
OneLake as the single logical store, with a deliberate decision per source about whether data is copied in or referenced through a shortcut
Lakehouse for engineering, large-volume transformation and anything that benefits from file-level and Spark access
Warehouse for structured modelling and workloads that want a relational engine and conventional SQL access patterns
Data Factory for ingestion and orchestration, including the banking sources that cannot be read continuously, with pipelines, Dataflow Gen2 and notebook-based engineering each used where they fit rather than as a house standard
Real-time intelligence where consumption is genuinely event-driven, and not where the business definition is end-of-day
Modelling and consumption
Certified semantic models implementing each measure once, with the security model carried inside them
Measure development and optimisation in DAX, which is where a banking calculation becomes executable and where most report performance is won or lost
Direct Lake storage mode where it fits, designed explicitly for its fallback conditions
Power BI reports and dashboards per audience: an executive view, an owner view and an analyst view are three deliverables
Paginated and operational reporting where a pixel-accurate or printable output is the actual requirement, which in banking it often is
Governance and platform engineering
Workspace topology designed as the access, deployment and capacity model rather than allowed to accumulate
Deployment pipelines and source control, so a change to a model is a release rather than an edit in production
Row-level and object-level security driven from Microsoft Entra ID groups and a security dimension
Capacity management and cost attribution, monitored as a discipline with a named owner
Catalogue, classification and lineage tooling where you hold the licensing for it, including Microsoft Purview, assessed against what your tenant actually supports rather than assumed
These are the workloads Fabric and Power BI are bought for in a bank. The third column is the point of the table, because each one is decided by a different design choice rather than by the reporting layer everybody looks at.
| Workload | What it needs from the platform | The design choice it turns on |
|---|---|---|
| Executive reporting | A small set of figures with drill paths | One certified model, and capacity headroom at close |
| Branch and unit performance | Wide distribution, scoped per unit | Row-level security from entitlements, not per report |
| Financial dashboards | Numbers that tie to the general ledger | Reconciliation as acceptance, and close state visible |
| Customer analytics | Large volumes, behavioural detail | Lakehouse plus Direct Lake, shaped to avoid fallback |
| Loan portfolio reporting | Vintage, yield and concentration views | Time intelligence and effective-dated attributes |
| Operational reporting | High refresh, high concurrency, printable | Capacity separation, and paginated where it belongs |
OneLake removes the copies, and most of the benefit of Fabric follows from that: one store, one governance surface, one lineage, no reconciliation between four extracts of the same table.
The consequence is less discussed. When everything reads the same copy, an error in that copy reaches every consumer at once, and there is no stale duplicate sitting somewhere that would have made the difference visible. One copy raises the standard the ingestion and modelling layers have to meet.
What each piece contributes
OneLake as the logical store, with shortcuts used deliberately so that what is referenced and what is materialised is a recorded decision rather than a developer preference
Data Factory for ingestion and orchestration, with dependency awareness so a late banking feed does not produce a partial position
Lakehouse for engineering and volume, Warehouse for relational modelling and conventional SQL consumption, chosen per workload rather than as a standard
Direct Lake for serving, designed and monitored for its fallback conditions
Microsoft Entra ID as the identity and entitlement source for workspace access, row-level security and object-level security
A retained raw layer, because a restating source is the normal case in banking and one copy does not mean one version of history
Enterprise integration
Core banking, lending, cards, deposits and payment systems, within what each source can actually provide
General ledger and the enterprise resource planning estate, which is where the numbers have to tie
Customer relationship management, servicing and channel systems
Existing warehouses and marts during a transition period, which is almost always longer than planned
On-premises sources through a gateway, which is usually the component that constrains refresh design in a bank and is rarely sized for it
Built on the integration patterns described on our Banking Data Platform Engineering page rather than reinvented here
Which regulations apply to a given dataset or report, how it is classified, where it may be hosted and what controls are required are determined by your compliance, legal, risk and information security functions, based on your operating markets. We do not interpret those requirements and this page does not state which apply to you.
Technology supports a compliance programme. It does not independently establish compliance, and no platform makes an institution compliant.
Workspace and access
- Workspace topology designed as the access model, with roles assigned to groups rather than to individuals
- Microsoft Entra ID as the single source of identity and entitlement, with no parallel list maintained for reporting
- Row-level and object-level security carried in certified models and tested against defined personas after every change
- Direct source access restricted, so consumption goes through models that carry the security rather than around them
Lineage and trust
- Lineage from a published visual back through the model, the warehouse or lakehouse, and the ingestion, traversable rather than documented
- Endorsement and certification applied, with a named owner and a stated scope per certified asset
- Reconciliation to the general ledger and to source systems as a continuous control, as described on our Banking Data Platform Engineering page
Data protection and records
- Sensitivity labelling applied so that classification travels with an export rather than stopping at the report boundary
- Export and sharing policy decided per model and per audience, because this is where row-level security ends
- Residency and processing location established before build, including the hosting region of each capacity
Change and audit
- Source control and deployment pipelines, so a change to a certified model is a release with a reviewer
- Audit trails over access, sharing, export, model changes and capacity administration
- A tenant-level settings baseline, reviewed deliberately, since several of those settings are the difference between a governed estate and an open one
Platform monitoring here usually means refresh success, which answers the least interesting question. The measures below cover performance, cost and whether the estate is earning its keep, because an unused report consumes capacity exactly like a used one.
| Failure | How it presents |
|---|---|
| Throttling at month end | Executives report slowness and refreshes succeed |
| Direct Lake started falling back | A model got slower and nothing changed in the report |
| An unscheduled notebook ran | Unexplained reporting degradation for one morning |
| A model grew past its design | Refresh lengthening gradually with no single cause |
| Model sprawl resumed | New reports arriving with new models attached |
| Row-level security broke after a reorganisation | Nobody reported it, which is the concerning part |
| Reports nobody opens still refresh | Capacity consumed on an estate serving no decision |
| Gateway became the constraint | On-premises refreshes queueing behind each other |
The outcomes below follow from three choices: rationalise before migrating, build a small number of certified models, and design the capacity for the month-end collision.
Unified analytics in practice rather than in architecture, measured by how many places a given number can come from
Faster reporting where the time actually sits, which is usually preparation and review rather than refresh duration
Trusted KPIs, because each measure is implemented once in a model with a named owner
Manual effort reduced in the handoffs between systems, which is where the spreadsheets live
A platform that holds up at close, because the capacity was designed for that week
A smaller estate with attributable cost, since what nobody opens is retired rather than migrated
We will take your inventory and one month of capacity telemetry and establish four things: how much of the estate is actually used, how many definitions of your key measures exist, what is colliding at close, and what a rationalised target looks like. You get the findings whether or not we build anything.
CaliberFocus implements Microsoft Fabric and Power BI for banks that will be asked to defend the number on the dashboard. We rationalise the estate before migrating it, build a small number of certified semantic models, size and separate capacity for the month-end collision, monitor Direct Lake fallback, and drive row-level security from your entitlements.
- Capacity designed for the month-end collision, not the average
- A small number of certified semantic models instead of dashboard sprawl
- Row-level security driven from Microsoft Entra ID and tested by persona
- Direct Lake fallback monitored and alerted on, not discovered at close
Security & Compliance
