Concept 01
Banking & Finance Case Study
Scenario: Global Retail Bank — Regulatory Reporting Unification
A global retail bank operates across 22 countries with 14 core banking systems (Temenos, Flexcube, FIS), a separate CRM (Salesforce), a risk engine (Moody’s), and three legacy mainframe systems dating to the 1980s. The regulatory team produces BCBS 239, Basel III, and IFRS 9 reports — all requiring the same entity data reconciled across every source.
Problem: each reporting team maintained its own reconciliation queries. CUSTOMER_ID in the core banking system was a 12-digit numeric; in Salesforce it was an alphanumeric prefixed with “CRM—”; on the mainframe it was a 6-digit legacy code. Three different keys for the same person. Risk models and regulatory reports produced different customer counts depending on which source they used.
DV2 Solution: Same-As Link (LINK_CUSTOMER_SAME_AS)
A Same-As Link is a Data Vault pattern that records that two different business keys represent the same real-world entity. It links two Hub rows in the same Hub table — connecting the core banking CUSTOMER_HK to the Salesforce CUSTOMER_HK to the mainframe CUSTOMER_HK via a Golden Record satellite.
-- Same-As Link: two Hub rows that represent the same real-world customer -- Used to reconcile customer IDs across 14 core banking systems CREATE TABLE LINK_CUSTOMER_SAME_AS ( LINK_CUSTOMER_SAME_AS_HK CHAR(32) NOT NULL, -- hash of both HKs concatenated HUB_CUSTOMER_HK_MASTER CHAR(32) NOT NULL, -- the surviving / golden record HK HUB_CUSTOMER_HK_DUPLICATE CHAR(32) NOT NULL, -- the matched / subordinate HK LOAD_DATE TIMESTAMP NOT NULL, RECORD_SOURCE VARCHAR(100) NOT NULL, -- MDM system that determined match CONSTRAINT pk_lnk_cust_same PRIMARY KEY (LINK_CUSTOMER_SAME_AS_HK) ); -- Satellite on Same-As Link: match quality metadata CREATE TABLE SAT_L_CUSTOMER_SAME_AS_MATCH_DETAIL ( LINK_CUSTOMER_SAME_AS_HK CHAR(32) NOT NULL, LOAD_DATE TIMESTAMP NOT NULL, HASH_DIFF CHAR(32) NOT NULL, RECORD_SOURCE VARCHAR(100)NOT NULL, MATCH_SCORE DECIMAL(5,4), -- 0.0000 to 1.0000 MATCH_METHOD VARCHAR(50), -- EXACT_SSN, FUZZY_NAME_DOB, etc. MATCH_CONFIDENCE VARCHAR(20), -- HIGH / MEDIUM / LOW REVIEWED_BY VARCHAR(100), -- human reviewer ID if manual REVIEW_DATE TIMESTAMP, CONSTRAINT pk_sat_match PRIMARY KEY (LINK_CUSTOMER_SAME_AS_HK, LOAD_DATE) );
Key Regulatory Outcomes
- BCBS 239 compliance: single lineage-traceable customer entity across all 14 source systems. Regulators can trace any aggregate figure back to individual source rows.
- Basel III LCR reporting: the Link between ACCOUNT and CUSTOMER with Effectivity Satellites enables a point-in-time view of which accounts were associated with which customers on any reporting date — critical for High-Quality Liquid Assets calculations.
- GDPR right-to-erasure: because all customer attributes are in Satellites, a Data Erasure satellite can be inserted to flag that a customer’s PII must be masked in mart queries — without deleting any raw vault rows (preserving regulatory audit trail).
Architect lesson: in banking, the audit trail is a first-class regulatory requirement, not a nice-to-have. Data Vault’s insert-only design means every regulatory examiner question about historical data states can be answered by querying the Raw Vault directly. The vault IS the audit log — there is no separate audit table to maintain.