Trusted data by design: governed, modelled, and ready for the decisions that depend on it.

Governance fails when it stays on a slide, so I make it operational. I set up the operating model (owners, stewards, custodians and a council) with an activity-level RACI, so every decision has a name against it. The rules live in a data governance policy, and each governing body is chartered with a Terms of Reference that fixes its mandate, membership and authority. Then I make it measurable: a Council KPI scorecard for the strategic enterprise view, and working-group KPIs for the operational data quality that feeds it. A maturity assessment shows where to invest next.

• Operating ModelWord · four pillars, roles, decision rights, archetypes
  Download
• RACI matrixExcel · activity-level accountabilities + maturity link
  Download
• Data Governance PolicyWord · policy work sample (sanitised)
  Download
• Terms of ReferenceWord · completed example: Data Governance Council (sanitised)
  Download
• Council KPI scorecardWord · strategic KPIs ratified by the Council
  Download
• Working-group KPI scorecardWord · operational KPIs owned by working groups
  Download

Trustworthy data starts with one agreed version of the truth, and that is where I focus most here: master and reference data. I build the golden record for core entities such as customer, clean and match duplicates so the business gets a single trusted view, and standardise reference data (at Société Générale, on the FpML standard) so codes and products mean the same thing everywhere. Around that I set up the business glossary and a data catalog, so every critical term has an agreed definition and a named owner. Done well, this is what lets regulatory and finance reporting rely on the numbers.

• Business Glossary & Data CatalogExcel · definitions linked to physical data, owners, classification, lineage
  Download
• MDM Approach & Operating ModelWord · single client view: sources, matching, survivorship, stewardship
  Download
• Reference Data RegisterExcel · code lists with one golden source (ISO, FpML)
  Download

My approach to data quality is end to end, and I own the framework rather than the code. I start by profiling the data to understand what is really in it (volumes, gaps, ranges), then define the rules in a rules library: each business rule, across the six dimensions (completeness, uniqueness, validity, consistency, timeliness, accuracy), is paired with a technical check that carries a severity and a threshold. Those checks run in a data quality tool (Collibra Data Quality), which holds the failing rows for the stewards to fix and rolls everything into a weighted DQ scorecard. Finally I publish a dashboard in two views, because the audiences are different: a business view answers "can we trust this data?", while a Data Engineering view shows which checks fail, on which tables, and what is past its freshness SLA. Same numbers, read two ways.

• DQ Profiler (SQL)SQL · profiling queries with sample output
  View PDF Download
• DQ ScorecardExcel · weighted score by dimension & severity
  Download
• DQ Rules LibraryExcel · business rules linked to technical rules
  Download
• DQ DashboardHTML · Business and Data Engineering views, opens in a browser
  Download

Good data architecture is a small set of principles applied consistently, and decisions you can still explain a year later. I design the target architecture as a layered platform (sources, ingestion, curated, serving, consumption) with governance, security and metadata as cross-cutting concerns, set the standards the delivery teams build to, and record every significant choice as an Architecture Decision Record (ADR). I have also built the warehouse and BI end of that platform, from data warehouse and datamarts through to the reporting layer.

• Architecture Principles & ADRWord · 7 principles + decision-record template
  Download

Most of my integration work is the regulatory reporting data supply chain: ingest raw data, transform and enrich it, build the data models, then produce the regulatory returns (Basel and COREP/FINREP, liquidity, and APAC regulators), with traceability from source to submitted return. Where data crosses teams or firms, I make the interface an explicit agreement: a data contract that fixes schema, semantics, quality and ownership, expressed in the Open Data Contract Standard (ODCS), and an open exchange standard like FpML so a product or counterparty means the same thing everywhere. I have also run post-merger integration, reconciling Credit Suisse and UBS data across two legacy environments. More recently I have worked hands-on in OpenMetadata, cataloguing assets, defining a business glossary term and authoring a data contract.

• Open Data Contract Standard (ODCS)YAML · interface contract: schema, semantics, quality & SLA
  View PDF Download
• FpML Exchange SampleXML · ISDA standard, a product & customer standardised for sharing
  View PDF Download
• OpenMetadata Labs entryHands-on: a catalog asset, glossary term & data contract I filled in
  Open ↗

# Open Data Contract Standard: the interface, agreed
apiVersion: v3.1.0
kind: DataContract
id: customer-master-apac
schema:
  - name: customer
    properties:
      - { name: customer_id, required: true, unique: true }
quality:
  - { property: customer_id, rule: completeness, mustBe: 100 }
slaProperties:
  - { property: freshness, value: 24, unit: hours }

Protection should match sensitivity, no more and no less. I run a four-level data classification with cumulative controls (access, encryption, masking, logging, retention) and govern access through an RBAC matrix reviewed quarterly against joiner, mover and leaver events. As a statutory Data Protection Officer I have built the privacy operation too: the DPO office, breach notification, privacy impact assessments, data-subject requests, and staff training and guidance, including special-category health data during the COVID period. It is grounded in GDPR, Swiss FADP and APAC privacy law, and in my CIPP/E and CIPP/A certifications.

• Classification & Protection PolicyWord · 4 levels + control matrix + incident response
  Download
• Access Control MatrixExcel · roles × assets × classification (RBAC)
  Download

A good data model is its own documentation, and I work the full range. I build enterprise and conceptual models for a domain (Risk and Finance, for example), then design relational databases end to end from conceptual to logical to physical, choosing the right shape for the workload: normalised models for OLTP systems and dimensional star schemas for OLAP reporting. I apply strict conventions (surrogate keys, conformed dimensions, explicit grain, SCD Type 2 history, lineage) and embed a data section as a standard in every business and technical specification, so data design is part of delivery, not an afterthought.

• Dimensional Model (DDL)SQL · OLAP star schema with SCD2 & conventions
  View PDF Download
• Modelling & Naming StandardsWord · relational levels, OLTP vs OLAP, conventions
  Download

-- Grain: one row per customer per version. History via eff_from / eff_to.
CREATE TABLE dim_customer (
    customer_sk    BIGINT       NOT NULL PRIMARY KEY, -- surrogate key
    customer_id    VARCHAR(20)  NOT NULL,             -- natural key
    legal_name     VARCHAR(200) NOT NULL,
    country_code   CHAR(2)      NOT NULL,             -- ISO-3166
    -- SCD Type 2 control columns
    eff_from       TIMESTAMP    NOT NULL,
    eff_to         TIMESTAMP    NOT NULL DEFAULT '9999-12-31',
    is_current     BOOLEAN      NOT NULL DEFAULT TRUE,
    record_source  VARCHAR(30)  NOT NULL              -- lineage
);