Building a Golden Customer Record Without Creating Another Data Silo

CRM, core lending, cards, payments, collections and accounting all hold part of a customer's state. A transformation programme copies name, phone, balances, limits, risk and delinquency into GOLDEN_CUSTOMER. For a few months, the table looks elegant.

The institution has not removed fragmentation. It has created another copy of it—one that can remain available while returning plausible, stale state.

Authority belongs to fields and domains—not to whichever system displays the value

Define Authority(field), not Authority(all customer data) = System X. A CRM does not own loan balance because it displays a copy; a risk platform does not own legal name because its feature store carries one.

type GovernedValue<T> = {
  value: T;
  sourceSystem: string;
  effectiveAsOf: Date;
  availableAsOf: Date;
  observedAt?: Date;
  qualityStatus: string;
};

This envelope need not leak into every application DTO. It must exist where governance, replay and evidence require it.

Anchor domains to a canonical party; keep economic objects explicit

The canonical partyId is a stable anchor. Relationships, roles, facilities, accounts, guarantees, events and state remain separate objects linked to it. They are not scalar columns waiting to be flattened into a 500-field customer row.

This normalised foundation follows economic semantics and update ownership. Source records and canonical mappings are durable evidence; caches and projections are disposable products of that evidence.

One governed foundation should produce several decision-specific views

type CurrentCustomerCreditView = {
  partyId: string;
  totalDrawnMinor: bigint;
  totalCommittedMinor: bigint;
  maxDpd: number;
  behaviouralPd?: number;
  lastPaymentAt?: Date;
  generatedAt: Date;
};

Every field above is derived or referenced. A materialised SQL view, cached API response or warehouse table may make it fast; materialisation does not turn it into source truth. If corrupted, discard and rebuild it.

A generated timestamp hides the freshness that matters

A projection generated at 16:00 can contain exposure as of 15:59, behavioural PD as of 06:00, bureau data from yesterday and verified income from last month. That may be valid for one decision and unacceptable for another—but only if the difference is explicit.

Define RequiredFreshness(field, decision). Collections may require current payment and DPD state; a periodic ECL process may accept a controlled snapshot. Mixed cadence is architecture to govern, not a defect to disguise behind one timestamp.

The golden layer must distinguish what was known from what is now restated

Known state uses only relationships known at T, facts available at T and risk scores generated by T. Restated state reconstructs corrected economic history for reconciliation, incidents and retrospective analysis. A current golden view must never leak a future identity merge or backdated correction into historical decision replay.

SCD Type 2 can preserve value validity, but not necessarily when a late correction or identity resolution became known. Use bitemporal effective and availability semantics where decision reproducibility justifies them.

Compose through a state service; materialise where latency demands it

interface CustomerStateService {
  getCurrent(partyId: string): Promise<CustomerState>;
  getKnownState(partyId: string, asOf: Date): Promise<CustomerState>;
  getRestatedState(partyId: string, asOf: Date): Promise<CustomerState>;
}

The service can compose identity, facility, payment, risk and collections domains live. Yet synchronous fan-out couples latency and availability. For high-volume decisions, keep write domains authoritative and serve cross-domain queries from an event-fed customer read model.

async function onFacilityStateChanged(event: FacilityStateChanged) {
  await customerProjection.refreshFacility(
    event.partyId,
    event.facilityId
  );
}

Illustrative events such as FACILITY_OPENED, PAYMENT_SETTLED, DPD_CHANGED and BEHAVIOURAL_PD_UPDATED drive targeted updates. Incremental speed must coexist with a deterministic full rebuild.

Newest is not truth: resolve conflicts through explicit authority

If CRM says phone A and collections says phone B, MAX(updated_at) is not governance. A recently copied wrong value can have a newer timestamp than its authoritative source.

type FieldAuthorityRule = {
  field: string;
  preferredDomains: string[];
};

Centralise legitimate precedence rather than scattering it through application code. A conflict may resolve to qualityStatus = UNRESOLVED. Material workflows can refer, use an approved fallback or delay action according to governance; there is no universal credit policy.

Derived values earn authority through definition, version and inputs

type DerivedMetric<T> = {
  value: T;
  calculationVersion: string;
  effectiveAsOf: Date;
  calculatedAt: Date;
  inputRefs: string[];
};

Facility-level state remains the evidence. Behavioural PD remains a risk-domain output. The customer projection references or aggregates them; it does not independently remodel them. For totalDrawn = €11,000, lineage should identify F1 = €8,000 and F2 = €3,000, the facility-state versions and the path Party → Relationship → Facility.

getFieldLineage(
  partyId,
  fieldName,
  asOf
)

A customer-state version is an input manifest—not one global counter

{
  "identityVersion": "i42",
  "relationshipVersion": "r88",
  "facilityProjectionVersion": "f310",
  "riskVersion": "pd_4.2"
}

Independent domains move independently. Store the exact manifest with a material decision so the institution can reproduce D(T). Include schemaVersion and a compatibility strategy in the consumer contract; silently renaming or removing decision fields destroys that reproducibility.

interface CustomerCreditViewContract {
  partyId: string;
  asOf: Date;
  stateMode: "KNOWN" | "RESTATED";
  values: Record<string, unknown>;
  freshness: Record<string, Date>;
  lineageVersion: string;
}

Invalidate projections through declared dependencies, then update dependent fields atomically

A phone change need not recompute exposure. A facility change must update facility drawn, total drawn and utilisation together so no consumer observes contradictory state. Explicit dependency events enable targeted work without partial inconsistency.

Monitor lag for critical fields. A stopped consumer that still serves yesterday's projection is more dangerous than a hard failure because the response remains plausible. Expose lastSuccessfulUpdate and sourceEffectiveAsOf to policy where needed; fail-open or fail-closed remains decision-specific.

Rebuildability proves that the golden view is derived

Periodically aggregate authoritative facility state and compare it with projected exposure. Differences must be zero or explained by an intentional schema or logic version change. If a customer view cannot be rebuilt deterministically, it has quietly become another source system.

Do not allow random edits to a projection. Correct the owning domain or use an explicit, sparse override event containing field, reason, scope, expiry and relevant approval. Temporary overrides need validUntil so they cannot become hidden permanent truth.

A deterministic fixture should prove authority, time, identity and rebuild

Monitor provenance and freshness—not merely pipeline uptime

No universal thresholds apply. Break conflicts down by field, source pair, product and migration cohort. A sudden projection shift may come from source, authority-rule, identity-resolution or facility-state change; attach infrastructure versions so monitoring can distinguish these from borrower behaviour or model drift.

The Entimema architecture governs facts before composing decisions

A bank can connect an existing customer-master programme to facilities, payments, risk and decision projections without replacing it. A non-bank can prevent its warehouse, BI or CRM “master customer” from becoming another reconciliation point. Streaming every domain is unnecessary; explicit mixed cadence is preferable to false freshness.

A Golden Customer State Integrity Agent can investigate integrity without editing truth

A controlled agent can monitor projections, identify conflicting values, verify field authority, detect stale critical components and missing lineage, compare read models with authoritative domains, trigger evidence-led rebuild validation, find duplicate exposure aggregation and compare known with restated customer state.

Continue with Why Customer ID Is Not Enough, Customer, Facility, Account and Exposure, Event Time vs Processing Time vs Posting Time, Reconstructing Account State and the Insight The Single Customer View Is Usually a Fiction. Canonical financial event modelling, joint-borrower handling, point-in-time customer-state reconstruction and cross-platform identity resolution remain future research directions—not fabricated routes.