Customer, Facility, Account and Exposure

One borrower has a term loan, revolving facility, payment account and collections case across four systems. The systems expose C1091, P8831, A19092 and F4017. A naïve model treats all four identifiers as “the customer.”

They are not equivalent. Confusing them produces missing or duplicated exposure, wrong affordability, siloed limits and broken collections routing.

Identity, party, role, facility and account answer different questions

A facility carries economic terms. An account records movements or balances according to a servicing or ledger role. The mapping is not universally one-to-one, especially in legacy or multi-system designs.

Role belongs on a relationship, not inside identity

type PartyRole =
  | "PRIMARY_BORROWER"
  | "CO_BORROWER"
  | "GUARANTOR"
  | "ACCOUNT_HOLDER"
  | "PAYER";

type FacilityPartyRelationship = {
  facilityId: string;
  partyId: string;
  role: PartyRole;
  validFrom: Date;
  validTo?: Date;
  confidence: "CONFIRMED" | "PROBABLE" | "UNRESOLVED";
};

A single facility.customer_id cannot represent one primary borrower, one co-borrower and one guarantor. The relationship object captures role, validity and—where necessary—confidence and lineage.

A guarantor relationship may carry guarantee coverage and legal obligation, but should not be mechanically converted into borrower exposure. Graph thinking is useful even when implemented in ordinary relational tables; a graph database is not required.

A relational model can preserve the graph explicitly

CREATE TABLE party (
  party_id   TEXT PRIMARY KEY,
  party_type TEXT NOT NULL
);

CREATE TABLE facility (
  facility_id  TEXT PRIMARY KEY,
  product_type TEXT NOT NULL
);

CREATE TABLE facility_party (
  facility_id TEXT NOT NULL REFERENCES facility(facility_id),
  party_id    TEXT NOT NULL REFERENCES party(party_id),
  role        TEXT NOT NULL,
  valid_from  TIMESTAMPTZ NOT NULL,
  valid_to    TIMESTAMPTZ,
  PRIMARY KEY (facility_id, party_id, role, valid_from)
);

CREATE TABLE account (
  account_id   TEXT PRIMARY KEY,
  facility_id  TEXT NOT NULL REFERENCES facility(facility_id),
  account_role TEXT NOT NULL,
  valid_from   TIMESTAMPTZ NOT NULL,
  valid_to     TIMESTAMPTZ
);

Illustrative account roles include SERVICING, SETTLEMENT, LEDGER and CARD. One technical account is not automatically a separate lending exposure. Referential failures—such as an account without a facility—should quarantine rather than silently disappear.

type FacilityState = {
  facilityId: string;
  limitMinor?: bigint;
  drawnMinor: bigint;
  blockedMinor?: bigint;
  pendingMinor?: bigint;
  undrawnMinor?: bigint;
  arrearsMinor: bigint;
  dpd: number;
  asOf: Date;
};

Exposure is a point-in-time facility state, not a customer column

Limit is primarily a facility property. Customer-level limit or exposure is a projection across relevant relationships. Term-loan outstanding and revolving utilisation follow different semantics; do not force incompatible products into one utilisation ratio.

The model must preserve drawn and undrawn separately so EAD inputs trace to canonical facility state. A single opaque EAD value cannot support lineage, recalibration or alternative scenarios.

Different decisions project the same economic model differently

type PartyCreditState = {
  partyId: string;
  totalDrawnMinor: bigint;
  totalCommittedMinor: bigint;
  maxDpd: number;
  activeFacilityCount: number;
  asOf: Date;
};

Party state is rebuildable projection, not authoritative primitive state. Max DPD, total drawn and total committed can be useful, but their aggregation rules must match the decision and deduplicate canonical facilities.

Canonical IDs preserve economic continuity across systems

CREATE TABLE source_identifier (
  canonical_object_type TEXT NOT NULL,
  canonical_id          TEXT NOT NULL,
  source_system         TEXT NOT NULL,
  source_id             TEXT NOT NULL,
  valid_from            TIMESTAMPTZ NOT NULL,
  valid_to              TIMESTAMPTZ,
  UNIQUE (source_system, source_id, valid_from)
);

An old-core customer 44192 and new-core customer A9917 can both map to canonical party P00127. Technical keys may change; historical economic identity must not.

type IdentityLink = {
  canonicalPartyId: string;
  sourceSystem: string;
  sourceId: string;
  confidence: "CONFIRMED" | "PROBABLE" | "UNRESOLVED";
};

Do not turn uncertain matches into confirmed truth. Material decisions may require controlled review or a governed fallback. Relationship confidence can also matter—for example, uncertain migrated guarantor mappings.

False splits, false merges and duplicate facilities change risk

A canonical facility is the economic credit contract represented once, no matter how many core, processor or warehouse copies exist. Preserve all source facility identifiers as lineage. Two canonical facilities mapping to one source facility is an explicit integrity signal.

Attach events and episodes to the object they change

Attaching every event only to “customer” erases the aggregate where financial state changes. Facility exposure can combine facility and account events through governed reducers.

CollectionsCase ≠ Facility. A facility may have several cases over time; a case may cover several facilities in some architectures. Likewise, a delinquency or default episode is an explicit historical object rather than the facility itself.

type DelinquencyEpisode = {
  episodeId: string;
  facilityId: string;
  startDate: Date;
  endDate?: Date;
};

Relationships and facility terms are point-in-time state

SELECT f.facility_id, fp.role
FROM facility_party fp
JOIN facility f
  ON f.facility_id = fp.facility_id
WHERE fp.party_id = :party_id
  AND fp.valid_from <= :as_of
  AND (fp.valid_to IS NULL OR fp.valid_to > :as_of);

The next join must select facility state available/effective at the same time. Joining a 2024 decision to current_customer_facility_map introduces future relationship knowledge.

Co-borrowers can be added, guarantees released, accounts closed and limits changed. Late identity corrections may require both valid and system time so PartyState^known(T) preserves the actual decision while PartyState^restated(T) reflects corrected economic mapping.

If a duplicate party is merged later, historical corrected exposure can rise without portfolio growth. This is infrastructure-induced risk drift; model validation must distinguish production-known from corrected exposure.

Build the decision graph at the decision time

1. Resolve canonical party identity and confidence.
2. Select party–facility relationships valid and known at T.
3. Select active canonical facilities without duplicate source representations.
4. Reconstruct point-in-time facility and account state.
5. Derive the exposure view for affordability, limit, EAD or collections.
6. Retain object, relationship, state and policy versions in the decision manifest.

The objective is not one golden physical database. It is one semantic model, stable canonical IDs, governed relationships and reproducible state across distributed authoritative systems.

A golden customer graph proves attribution without double counting

Fixture: P1 is primary on term facility F1 and revolving F2; P2 is co-borrower on F1. A1 services F1; card account A2 services F2. F1 draws €8,000. F2 has a €5,000 limit and €3,000 drawn.

Attribution can deliberately sum beyond portfolio exposure because one facility relates to several parties. The two measures must never be confused.

Test graph integrity, cardinality and time

Data contracts should specify stable party identity, facility economic uniqueness, relationship role/validity and account-to-facility role. These are semantic controls, not optional documentation.

Observe mapping failure before interpreting portfolio movement

Reconcile summed canonical facility exposure to relevant source/control totals, then reconcile party attribution against source relationship views. Differences should resolve to timing, mapping, scope or explicit attribution—not remain unexplained.

A sudden fall in facilities per party can be a mapping break rather than deleveraging. An exposure jump after an identity merge can be corrected infrastructure rather than new lending. Track source, product, migration cohort and relationship version before interpreting business trend.

The Entimema credit data architecture separates identity from exposure

An Identity & Exposure Integrity Agent can validate the graph

A future controlled agent can monitor party/facility/account mappings, find orphans and duplicate facilities, detect likely double counting, compare source and canonical identities, reconstruct party exposure, compare known/restated customer state and trace relationship changes into historical decisions.

Continue with Building a Reliable DPD Engine, Reconstructing Account State, Idempotency in Event Processing, Event Time vs Processing Time vs Posting Time, The Single Customer View Is Usually a Fiction, The Hidden Infrastructure Debt of Modern Lending, The Payment Is Not the Balance, Credit Limit Assignment, Affordability Decisioning, Behavioural Credit Scoring and IFRS 9 EAD. Entity resolution, golden records, connected exposures and point-in-time customer reconstruction remain future research directions, not fabricated routes.