Handling Joint Borrowers, Multiple Facilities and Connected Exposures

Facility F1 has €100,000 drawn and two borrowers: P1 is primary; P2 is co-borrower. A naïve customer table writes €100,000 against each party. The institution's one economic exposure becomes €200,000 when those customer rows are summed.

The facility is the economic anchor; relationships carry the roles

Facility ID anchors economic uniqueness. Never clone a facility because it has several borrowers. A party can link to F1, F2 and F3; F1 can link to P1 and P2. The true cardinality is Party ↔ Facility.

type CreditRelationshipRole =
  | "PRIMARY_BORROWER"
  | "CO_BORROWER"
  | "GUARANTOR"
  | "COLLATERAL_PROVIDER"
  | "AUTHORISED_SIGNATORY";

type PartyFacilityRelationship = {
  partyId: string;
  facilityId: string;
  role: CreditRelationshipRole;
  validFrom: Date;
  validTo?: Date;
};

A single facility.customer_id cannot express this model. Duplicated facilities, comma-separated IDs and secondary-borrower columns only move the ambiguity into application code.

CREATE TABLE facility_party_relationship (
  facility_id TEXT NOT NULL,
  party_id TEXT NOT NULL,
  role TEXT NOT NULL,
  valid_from TIMESTAMP NOT NULL,
  valid_to TIMESTAMP,
  PRIMARY KEY (facility_id, party_id, role, valid_from)
);

Role is not ownership. A guarantor, collateral provider and borrower can all link to one facility without carrying the same economic or legal meaning.

Relationship state is effective-dated and bitemporal where corrections matter

Guarantors can be released, borrowers substituted and facilities legally assigned. Never overwrite the current edge. For a decision at T, Relationships(T) must contain only edges valid then.

If P2's link was discovered later, the original affordability or limit decision retains the graph known then. Corrected analysis can quantify the counterfactual impact without rewriting actual history. That change is identity or infrastructure correction—not new borrower behaviour.

Facility state exists once; attribution is a versioned decision function

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

Store attributionPolicyVersion with material decisions. A separate attribution view can carry party ID, facility ID, role, policy and attributed amount without ever overwriting facility exposure.

Portfolio exposure sums canonical facilities—not party rows

-- Wrong: F1 appears once for every relationship
SELECT SUM(f.drawn_minor)
FROM facility_state f
JOIN facility_party_relationship r
  ON r.facility_id = f.facility_id;

-- Economic total: one row per canonical facility
SELECT SUM(drawn_minor)
FROM facility_state;

SUM(DISTINCT amount) is not a safe repair: two legitimate facilities can carry the same amount. Economic uniqueness belongs in canonical facility identity and the grain of facility_state, not in an ad hoc SQL trick.

Never call both total_exposure. Under full association, summed party exposure can exceed portfolio exposure and still be a valid association measure—provided its semantics are explicit.

One relationship foundation produces bounded decision projections

Joint payment behaviour belongs to F1; do not duplicate payment events into two economic histories. Both borrowers may receive has_joint_facility_delinquency = true, and a party projection may derive:

Multiple term loans, revolving lines, overdrafts and cards remain individual facilities beneath the customer view. Aggregate compatible product classes deliberately: term-loan and revolving utilisation do not have interchangeable denominators.

A guarantee is an edge with coverage—not a cloned borrower balance

type GuaranteeRelationship = {
  partyId: string;
  facilityId: string;
  guaranteedAmountMinor?: bigint;
  guaranteedPercent?: number;
};

Derive GuaranteeExposure(T) from current facility state and effective guarantee terms. Adding guarantor P3 can change a guarantee-risk or collections view while leaving drawn facility exposure unchanged. A collateral provider is another distinct role; a collections case remains a separate domain object.

Connected exposure is graph-shaped even when stored in SQL

An identity edge says two records represent the same party. A household, control, group or guarantee edge connects different parties or objects. Never use relationship evidence to merge identities. Direct contractual edges and inferred relationships must retain different provenance and confidence.

Bound traversal by decision: affordability may traverse joint obligations; exposure may use directly linked facilities; group risk may use approved economic relationships. Avoid unbounded production traversal and uncontrolled connected-component expansion.

CREATE TABLE party_relationship (
  relationship_id TEXT PRIMARY KEY,
  from_party_id TEXT NOT NULL,
  to_party_id TEXT NOT NULL,
  relationship_type TEXT NOT NULL,
  valid_from TIMESTAMP NOT NULL,
  valid_to TIMESTAMP,
  source_system TEXT NOT NULL,
  confidence TEXT
);

Relational edge tables are often sufficient. Use graph thinking before graph tooling, and keep party–party edges separate from party–facility roles when a generic edge table would erase important constraints.

Resolve parties and facilities independently before aggregating

Core F100, card-platform 8821 and warehouse contract 4511 may all represent canonical facility CF-001. If facility resolution fails, perfect party identity still double counts exposure. Conversely, correct facility mapping cannot repair a false party merge.

Every attributed exposure remains traceable to one canonical facility; no anonymous aggregate can enter the decision view.

Every edge and attribution needs evidence, time and version

Late corrections can change affordability, limits or risk. Preserve the actual decision manifest, calculate counterfactual impact under the corrected graph and classify the change as infrastructure where appropriate.

Feature, validation and EAD grains must declare relationship semantics

A feature specifies whether it uses unique economic exposure, party-attributed exposure or associated-facility count. Facility-level EAD remains the economic modelling object; party and group EAD views aggregate it without duplicating EAD per relationship.

Train/validation splitting can leak the same joint-facility outcome when P1 is in training and P2 in validation. Depending on the target, split by facility, party or governed connected component. There is no universal choice, but the choice must match the prediction grain.

Default scope can be facility, customer or broader relationship state according to methodology. Store an explicit default_scope; do not propagate one generic Boolean. Likewise, facility DPD is underlying state and customer or group delinquency is a projection.

A golden fixture makes the association/economic split undeniable

Invariant tests protect the model from semantic double counting

Reconcile economic totals and relationship attribution separately

Reconcile facility economic total to its authoritative source. Reconcile party attribution to the effective relationship graph. Do not force customer-association totals to equal portfolio totals when full association is intentional.

Watch the graph for inflation, orphans and explosive connectivity

No universal thresholds apply. If associated exposure rises while portfolio exposure is unchanged, inspect relationship mapping or attribution policy before calling it credit growth. If one rule change links thousands of parties into a component, stop and investigate a graph or matching failure.

The Entimema architecture preserves relationships without cloning money

A Connected Exposure Integrity Agent can detect relationship failures without declaring connectedness

A controlled agent can monitor party–facility relationships, identify shared or orphaned facilities, detect economic double counting, reconstruct party-associated and unique portfolio exposure, compare attribution versions, surface late corrections, identify affected decisions and flag suspicious connected-component growth.

Continue with Building a Golden Customer Record, Why Customer ID Is Not Enough, Customer, Facility, Account and Exposure, Building a Reliable DPD Engine, Reconstructing Account State, The Single Customer View Is Usually a Fiction, Affordability Decisioning, Credit Limit Assignment and IFRS 9 EAD & Credit Conversion Factors. Point-in-time customer reconstruction, real-time utilisation and a time-respecting feature store remain future research directions—not fabricated routes.