Regulatory Metric Lineage Register

In banking and financial services, the same figure often appears in a board pack, a regulatory return and a risk console, and it is meant to be the same number in all three. This concept illustrates a metric register inside SemanticFed's governed model, where each regulatory and board metric has one definition, one owner and one version history, and where it can be traced back to the sources it reads and forward to everything that reads it.

Disagreement usually starts quietly. One team counts delinquency from the statement date and another from the due date; one includes charged-off accounts and another does not. Each is defensible alone, yet together they produce a board pack and a return that disagree. Regulated customer data adds a second constraint, since rows held in an in-region customer database may not leave that region. The design makes a change to a published metric a proposed, reviewed and versioned event instead of a silent edit.

The illustrated page sits under Ontology, inside a credit risk model, with a Banking & Financial Services chip, a published version badge on the Metric register heading and a Propose change action. The register table lists each metric with its owner, version, number of sources, residency and number of consumers; the sample rows cover card balances thirty and ninety days past due, total loan exposure, a seven-day deposit outflow and a net charge-off rate, owned by credit risk, finance and treasury. The selected thirty-days-past-due metric has its lineage drawn below: the core banking system and the card platform's warehouse feed an accounts fact, a locked in-region customer database feeds a delinquency dimension, and both lead to the metric, defined as the sum of balances thirty or more days past due, excluding charged-off accounts.

Beside the lineage, a definition history records why each of the last three versions changed: adding the in-region source, counting from the due date rather than the statement date, and excluding charged-off accounts, with a named approver on the latest. A Policies applied panel shows national identifiers and account numbers masked for analysts and a cross-region rule of aggregates only. Downstream, the lineage names a BigConsole board risk console, a FluidGrids month-end metrics job and the regulatory return pack. In the design, BigConsole presents the published figure to the board, the FluidGrids job feeds that console, and the owner sees every consumer before proposing a change. The same register pattern is designed to serve sustainability and ESG reporting teams, whose disclosed figures need the same single definition, change history and traceable sources.