Data governance · KPI definitions
DashboardRisk and finance dataKeep KPI definitions consistent across every dashboard with one semantic model
When finance, risk and the business each compute the same ratio their own way, the board pack argues with itself. Here is a setup where every dashboard reads one governed definition, and drift is caught before the next meeting.
Valnora & Elric team13 min read
- Team
- Risk and finance data office
- Manual steps today
- 5
- Build steps
- 10
- Review points
- 5
The problem
Ask three teams in a bank for the non-performing loan ratio and you can get three numbers. Credit risk excludes one category, finance uses month-end balances, and the business-line pack uses an average. Each number is defensible. Together they make the committee pack argue with itself, and the meeting starts with reconciliation instead of decisions.
The cause is rarely the data. It is that every report carries its own formula, written into a panel, a query or a spreadsheet, and nothing checks them against an agreed definition. Supervisors care about this too: the Basel Committee’s BCBS 239 principles expect banks to produce accurate, complete risk data and reports that reconcile.
For example, a data office governing 120 KPIs might spend 60 hours a month tracing why the same KPI differs between packs, and two to three weeks to settle each disputed definition.
How risk and finance data office works today
Today, done by hand · Risk and finance data office
- 01Each function builds its own reports, with KPI formulas written into the report or a spreadsheet.
- 02Before a committee meeting, analysts compare the same KPI across packs and find different numbers.
- 03A reconciliation meeting traces each number back to its query and filters.
- 04Someone agrees a fix by email, and one report is changed while the others are not.
- 05A definitions document exists, but nobody checks reports against it.
Where it breaks
- Non-performing loan ratio, cost-to-income and margin are computed with different filters, dates or exclusions.
- Definition changes are agreed informally, so there is no record of who approved what and when.
- New dashboards copy formulas from old ones, spreading the differences further.
- Nobody knows which KPIs have an owner, so disputes have no one to settle them.
- Supervisors and auditors ask how a reported figure reconciles, and the answer takes weeks.
What the change could be worth
A bank risk and finance data office governing about 120 KPIs used across committee and management reports.
| Assumption | Value |
|---|---|
| Hours a month reconciling conflicting KPI figures today | 60 h / month |
| Hours a month with governed definitions | 20 h / month |
| Loaded cost of an analyst hour | 90 USD |
| Days to settle a disputed definition today | 15 days |
| Days to settle with the change workflow | 5 days |
| Share of KPIs on a governed definition today | 45% |
| Share of KPIs on a governed definition after | 85% |
Modelled from the assumptions above to show how the outcome is calculated; not a customer result. Your results depend on your volumes and process.
These figures are an illustrative scenario computed from the assumptions shown, not a customer result. In it, moving from 45% to 85% of KPIs on governed definitions cuts reconciliation from 60 to 20 hours a month, about $43k of analyst time a year, and settles disputed definitions three times faster.
The outcome you want
One governed definition per KPI, with an owner and an approved version. Every committee dashboard reads it. Legacy reports are checked against it, drift raises an alert with a written explanation, and changes go through an approval that leaves a record.
Acceptance criteria
- Every KPI on a governed dashboard reads a governed metric, not a formula written into the panel.
- Each governed metric has a named owner, a plain-language definition and an approved version in the KPI register.
- Legacy reports are inventoried and each KPI is marked as matching, differing from or unclear against the governed definition.
- A differing definition raises an alert and a written drift note within a day.
- Definition changes go through an approval step with an impact note, and the decision is stored.
- Coverage of governed definitions is tracked on a dashboard with a target.
The solution end to end
The setup puts the definitions in the semantic model and Metrics, tracks every use of them in a register table, and uses two workflows, rules, monitors, a governance dashboard and the Data Steward Relay to keep them consistent.
Data sources and the semantic model. Warehouse tables from your data sources are modelled once as entities: Loan, Account, Customer, Cost centre. Each entity has its attributes, relationships and synonyms, and shares conformed dimensions such as date, business line and region, so every dashboard filters the same way.
Governed metrics. Each KPI is a governed metric with a type. Gross loan balance is an aggregate sum. The non-performing loan ratio and cost-to-income are ratios of two metrics. Net interest margin is calculated from other metrics. Every panel that shows the KPI reads that metric.
The KPI register. A table holds one row per KPI per report: the legacy definition, the governed metric and definition, a match status, the owner and the approved version.
Definition inventory workflow. Once a month, a workflow reads report specifications from SharePoint, Confluence or Google Sheets. One Agent block extracts each KPI definition. A second compares it with the governed definition and marks it Matches, Differs or Unclear with a reason. A Table block writes the result to the register.
Definition change workflow. When someone wants to change a definition, a second workflow lists every report that uses the metric, drafts an impact note, and pauses on a Human block for the metric owner and data governance. The approved version and effective date go into the register, and the owner then edits the metric.
Rules and monitors. Rules flag KPIs that differ from the governed definition and KPIs without an owner. Governed coverage is a metric too, the average of a 1-or-0 Mapped column. Monitors warn when any KPI differs and when coverage falls below target.
The Relay. The Data Steward template gives you a Relay that runs at Observe with a daily check at 07:00. Here it also starts when the drift monitor alerts. It reads the semantic model, the metrics and the register, and drafts a note for the data steward: what differs, which reports copy it, and which governed metric to use. At Observe its writes are blocked, so it changes nothing and contacts no one.
Chat. Chat can query the KPI register, so anyone can ask for a KPI’s approved definition and owner. It does not query metrics or dashboards directly.
One definition per KPI, from warehouse to committee pack
Data · Semantic model and metrics
- 01Warehouse tablesLoans, accounts, customers and ledger from your connected data sources.
- 02Semantic modelEntities, relationships, conformed dimensions and synonyms, defined once.
- 03Governed metricsNPL ratio, cost-to-income, margin and balances, each with an owner.
Workflow · Definition inventory
- 04Monthly scheduleRuns after the close.
- 05Read report specsSharePoint, Confluence or Google Sheets blocks read legacy definitions.
- 06Extract and compareAgent blocks extract each KPI and mark it Matches, Differs or Unclear.
- 07KPI registerOne row per KPI per report, with owner and version.
Workflow · Definition change
- 08Change requestStart block takes the metric, the change and the reason.
- 09Impact noteLists the reports that use the metric and what will move.
- 10Owner approvalHuman block; the Resume Form records the decision and effective date.
Dashboard · KPI governance
- 11Governance dashboardCoverage, differing KPIs, unowned KPIs and approved changes.
- 12Governance rulesFlag differing and unowned KPIs in the register.
- 13Drift monitorWarning when any KPI differs from its governed definition.
Relay · Data Steward
- 14Starts on alertBegins when the drift monitor fires; also runs a daily check at 07:00.
- 15Drift noteExplains the difference, the governed metric to use and who owns it.
- 16Steward actsThe data steward confirms and follows up with the report owner.
Build it
Start with the semantic model and the handful of KPIs that appear in committee packs. The register, workflows and Relay matter only once there is a governed definition to compare against.
Configure it step by step
- 01
Model the business entities
Semantic model → New entity
- Name: Loan. Table: your loans table from the warehouse. Synonyms: facility, credit line.
- Attributes & dimensions: product, stage, business line, region, origination date.
- Relationships: Loan to Customer, Loan to Branch. Repeat for Account, Customer and Cost centre.
- Conformed dimensions: Date, Business line and Region, shared by every entity.
- 02
Define the governed metrics
Metrics → New metric
- Gross loan balance: Metric type Aggregate, Sum of balance, Display Currency.
- Non-performing loan ratio: Metric type Ratio, non-performing balance ÷ gross loan balance, Display Percent.
- Cost-to-income ratio: Ratio of operating cost to operating income. Net interest margin: Calculated, per your finance policy.
- Tie each measure in the semantic model to its governed metric.
- 03
Create the KPI register
Tables → New table
- Columns: KPI, Report, Report owner, Legacy definition (Text), Governed metric, Governed definition (Text), Match status (Select), Mapped (Number, 1 or 0), Differs (Number, 1 or 0), Metric owner, Approved version, Last reviewed (Date).
- Import CSV the KPIs from your current definitions document as the first rows.
- 04
Build the definition inventory workflow
Workflows → new workflow → Schedule block
- Run frequency: Monthly, after the close.
- SharePoint, Confluence or Google Sheets blocks read report specifications and formula documents.
- Agent block extracts each KPI with its numerator, denominator, filters and source.
- A second Agent block compares it with the governed definition and returns Matches, Differs or Unclear with a reason.
- Table block, Upsert Row, writes the result to the KPI register.
- 05
Build the definition change workflow
Workflows → new workflow → Start block
- The Start block takes the metric, the proposed change and the reason.
- Table block, Query Rows, lists the reports in the register that use the metric; an Agent block drafts an impact note.
- Human block: Display Data shows the change and impact; Resume Form has Decision (Approve / Reject) and Effective date.
- After Resume execution, a Table block records the new approved version; the metric owner then edits the metric in Metrics.
- 06
Write the governance rules
Rules → New rule
- Rule type: Flag (true / false). "Differs from governed": Match status is Differs.
- Flag: "Unowned KPI": Metric owner is empty.
- Rule type: Classification (labels) on Match status for colour coding in tables. Save each with Create rule.
- 07
Add coverage metrics and monitors
Metrics → New metric, then Monitors → New monitor
- Governed coverage: Aggregate, Average of Mapped, Display Percent. KPIs that differ: Aggregate, Sum of Differs.
- Monitor: Rule match on "Differs from governed", Severity Warning, Check Daily.
- Monitor: Metric threshold on Governed coverage, Fire when it falls below your target, Severity Info. Create monitor.
- 08
Build the KPI governance dashboard
Dashboards → New dashboard → Build
- KPI cards: Governed coverage, KPIs that differ, unowned KPIs, changes approved this period.
- Horizontal bar of differing KPIs by report owner; Table panel of the register with rule columns.
- Settings → Row security if business lines should only see their own reports.
- 09
Rebuild business dashboards on governed metrics
Dashboards → open dashboard → Build
- Replace panel formulas with the governed metric for each KPI.
- Use Compare with: Previous period or Same period last year on the panel, not a new metric.
- Set Mapped to 1 in the register once a report reads the governed metric.
- 10
Set up the Data Steward Relay
Relays → New Relay
- Specialization: Data Steward. Name: KPI steward. Create draft.
- What it can use: Other resources with Resource type Semantic model, Metric and Table (the KPI register).
- Permissions: Autonomy Observe. New responsibility: Trigger When a monitor alerts, Monitor set to "Differs from governed". Then Publish.
What it produces
A legacy definition is found in a report spec, compared with the governed metric, and turned into a drift note the steward can act on.
What the solution produces
Legacy definition found in a report spec (illustrative)
Record- Report
- Retail risk monthly pack
- KPI
- NPL ratio
- Legacy definition
- Loans 90+ days past due ÷ total loans, excluding restructured loans, month-end balances.
- Source
- Report specification v7, section 3
KPI register row after comparison (illustrative)
Record- Governed metric
- Non-performing loan ratio, approved version 3
- Match status
- Differs
- Reason
- The governed definition includes restructured loans that meet the non-performing criteria; the report excludes them.
- Metric owner
- Head of credit risk reporting
Drift note from the Data Steward Relay (illustrative)
MemoThe retail risk pack computes NPL ratio without restructured loans, so it reads lower than the governed metric.
Two other reports copy the same formula: the branch summary and the regional review.
Suggested fix: switch those panels to the governed metric and annotate the first month after the change.
Owner to confirm: head of credit risk reporting. No changes have been made.
Where people stay in charge
Where people stay in charge
- Gate 1The metric owner and data governance approve every definition change through the Human block before the register version changes.
- Gate 2Only the metric owner edits a governed metric, after the approval is recorded.
- Gate 3Agent comparisons of legacy and governed definitions are proposals; the steward confirms each Differs or Unclear status.
- Gate 4The Data Steward Relay drafts drift notes for the steward; it does not contact report owners or change anything.
- Gate 5Committee packs are signed off by the KPI owner once the governance dashboard shows no open differences for their KPIs.
The dashboard
KPI governance
KPIs that differ
| KPI | Report | Difference | Status |
|---|---|---|---|
| NPL ratio | Retail risk pack | Excludes restructured loans | Differs |
| Cost-to-income | Business line MI | Excludes one-off costs | Differs |
| Net interest margin | Treasury pack | Average balance basis unclear | Unclear |
The governance dashboard answers four questions for the head of data: how much of the KPI estate is governed, what differs today, what has no owner, and what changed this period. The coverage line against its target is the measure to report upward. When a definition changes, annotate the affected business charts so readers know why a line moved.
Controls and audit
Every workflow run records each block’s inputs, outputs and errors in Logs, so you can show how a legacy definition was read and why it was marked as differing. Approvals of definition changes are stored with the decision and effective date, and the Relay’s activity is in the audit log. Workflows run from a deployed version.
Roles and permission groups decide who can edit metrics and committee dashboards. Row security limits each business line to its own reports. Sign-in runs through your identity provider with SSO and SCIM. Self-host Agent Serve if warehouse data must stay in your environment, with your own model keys or self-hosted models. Zero data retention is available with supported model providers. Some provider features keep data on the provider’s side by design, such as Gemini Deep Research, so they are outside zero data retention.
Controls and governance
Roles and permission groups
Admin, write and read roles per workspace, plus permission groups that limit which models, blocks and integrations a team can use.
Row-level access
Row-level policies narrow what each person sees in tables, dashboards, exports and scheduled reports.
Audit trail
Proposals, approvals, declines and executed actions are written to the workspace audit log, which admins can export.
Run logs
Every workflow run records each block’s inputs, outputs and errors, so a reviewer can trace how a result was reached.
Deployed versions
Workflows run from a deployed version, so a change is reviewed before it reaches production runs.
SSO and SCIM
Sign in through your identity provider with SAML 2.0 or OIDC, and provision people with SCIM.
Self-hosting
Run Agent Serve in your own cloud or data centre, next to the systems it reads.
Zero data retention
Zero data retention with supported model providers, backed by your own provider keys and agreements or self-hosted models. Some provider features keep data by design, such as Gemini Deep Research, so they are outside zero data retention.
More on how Agent Serve handles access, data and audit on the security page.
Roll it out
Pilot with the ten KPIs that appear most often in committee packs. Model them, name owners, inventory their legacy uses and move one committee dashboard across before widening scope. Put the success measures on the governance dashboard: governed coverage against target, KPIs that differ, unowned KPIs and days to settle a disputed definition.
Pilot, measure, expand
- Weeks 1–3
Govern the first ten KPIs
- Model the loan and account entities and define the ten KPIs that appear in committee packs.
- Load the KPI register and name an owner for each.
Done when: Ten governed metrics with owners and approved definitions.
- Weeks 4–6
Inventory and drift alerts
- Run the inventory workflow over legacy report specifications.
- Turn on the rules, monitors and the Data Steward Relay.
Done when: Every legacy use of the ten KPIs is marked and differing ones have a drift note.
- Weeks 7–12
Move dashboards across
- Rebuild committee dashboards on governed metrics.
- Route all definition changes through the change workflow.
Done when: Committee packs read only governed metrics for the in-scope KPIs.
| Risk | How to handle it |
|---|---|
| The inventory Agent misreads a complex legacy definition. | It returns Unclear when unsure, includes its reasoning, and the steward confirms every Differs or Unclear before anyone acts. |
| Owners disagree on the right definition. | The change workflow records both views in the impact note, and data governance makes the call in the Human block step. |
| People keep building panels with their own formulas. | Track Governed coverage with a monitor and use permission groups to limit who can edit committee dashboards. |
| A metric changes and historical figures shift without explanation. | Record the effective date in the register, and annotate affected charts with the change so readers see why the line moved. |
Timings are an illustrative plan, not a commitment; your pilot sets the pace.
Before you start
What you need
- Read access to the warehouse tables behind your committee and management reports
- A short list of the KPIs that matter most, starting with those in committee packs
- Your current definitions document or data dictionary, even if out of date
- Report specifications or formula documents in SharePoint, Confluence or Google Sheets
- A named owner for each KPI and a data steward to run the register
- An agreed approval path for definition changes
- A coverage target, such as 85% of committee KPIs on governed definitions
Questions teams ask
Questions teams ask
What is a semantic model, in plain terms?
It is a shared map of your business: which tables hold loans, accounts and customers, how they join, which dimensions such as date and business line they share, and which measures they carry. Dashboards and agents read that map instead of each writing their own joins and formulas.
Can metrics compute month-to-date or year-on-year figures?
Not yet. Metrics do not have month-to-date, year-on-year or window functions. Dashboards handle period comparisons: a panel can compare with the previous period or the same period last year, using the same governed metric.
Does the Data Steward Relay change metrics or tables?
No. It runs at the Observe autonomy level, reads the semantic model, metrics and the KPI register, and drafts notes. At Observe its writes are blocked; a Relay’s writes to tables go through a workflow it runs, and only people edit metrics.
Can someone ask Chat what a KPI means?
Chat can query tables, so it can answer from the KPI register: the definition, the owner and the approved version. It does not query metrics or dashboards directly. On a dashboard, Explain this chart describes what a panel shows.
Does this detect unusual movements in the KPIs themselves?
Not as anomaly detection. Monitors fire on thresholds you set for a metric, or when a rule matches a number of rows. This setup uses them for definition drift and coverage; you can add threshold monitors on the KPIs as well.
How does this relate to BCBS 239?
BCBS 239 sets principles for accurate, complete and reconcilable risk data and reporting at banks. A governed definition per KPI with a recorded approval history supports that work, but it does not by itself make a bank compliant.
Related reading: data lineage for regulators and branch performance BI. Request access