Building a Reliable DPD Engine

A loan owes €500 on 1 August. The borrower pays €300 on 10 August and €200 on 20 August. At 31 August, is the account current, partially delinquent, cured—or 30 days past due?

The answer depends on the due-item structure, allocation, effective dates, calendar, materiality and grace policy. A standalone dpd field cannot establish any of those semantics.

Start with versioned contractual obligations

type DueItem = {
  dueItemId: string;
  dueDate: string;
  contractualAmountMinor: bigint;
  currency: string;
  scheduleVersion: string;
  effectiveFrom: string;
};

A schedule is an ordered set of due items. Restructure, reschedule, payment holiday, maturity change or correction creates new effective-dated schedule state; it must not overwrite the schedule that governed a historical decision.

Each obligation remains individually reconstructible. Total arrears alone cannot reveal which due date remains open, so it cannot fully explain DPD.

A payment event does not identify the obligation it satisfied

type DueAllocation = {
  paymentEventId: string;
  dueItemId: string;
  amountMinor: bigint;
  allocationVersion: string;
};

One payment can create several allocation rows. An illustrative oldest-due-first rule applies €300 to the 1 August €500 item, leaving €200. That is not a universal hierarchy; the engine injects a governed, versioned policy and preserves the realised result.

The oldest relevant unpaid obligation anchors DPD

The threshold, inclusivity and day-count convention are policy inputs—not universal assumptions. If no relevant overdue item exists, current-state representation normally returns DPD = 0 rather than a negative number.

DPD policy belongs in explicit versioned inputs

Many DPD methods operate at date granularity. Do not use a 23h59m timestamp difference to create a day transition. Store machine instants consistently, then derive contractual dates in the correct business timezone.

A payment effective at 23:58 local on 31 August may be stored as 1 September UTC. A naïve DATE(utc_timestamp) creates false delinquency. Preserve source zone and convert before deriving business date.

interface DpdPolicy {
  version: string;
  materialityMinor: bigint;
  daysBetween(
    dueDate: LocalDate,
    asOfDate: LocalDate
  ): number;
  isGraceEligible(dueItem: DueItemState, asOfDate: LocalDate): boolean;
}

Partial, excess and advance payments have explicit state

DPD can move 45 → 14 when payment clears the oldest instalment but leaves a more recent one unpaid. This step-down matters to roll rates. Cross-account payments require facility-aware allocation; customer-level payment totals cannot determine facility DPD.

Payment finality is also explicit: authorised, settled, posted and reversible are different states. Some systems may justify provisional operational DPD and confirmed DPD, but the trade-off and consumer contract must be visible.

Cure and reopen emerge from rebuilt obligations

Technical cure can be defined when no relevant overdue due item remains and DPD returns to zero under the approved policy. An explicit ACCOUNT_CURED event may support downstream orchestration, but it must remain explainable from the underlying state.

Late payments create known and restated DPD

A decision made at known DPD = 5 remains historically reproducible even if a backdated payment later makes restated DPD = 0. Do not overwrite the decision, model input or known-state series.

Contract changes transform schedule state explicitly

Default can use DPD among several criteria, but Default ≠ DPD. The DPD engine derives delinquency state; it is not the full default or accounting-stage engine.

Raw DPD, bucket, facility and customer state are distinct

Store raw DPD separately from a policy-versioned delinquency bucket. Bands such as CURRENT, EARLY, MID and LATE are illustrative; changing thresholds must not rewrite raw historical DPD.

Joint borrower identity does not change facility DPD. Behavioural scoring, roll rates, vintage curves, collections, PTP analysis and ECL consume this state differently, so the engine must expose levels and versions rather than one overloaded field.

The calculation function consumes reconstructed due-item state

type DelinquencyState = {
  accountId: string;
  asOfDate: string;
  arrearsMinor: bigint;
  oldestUnpaidDueDate?: string;
  daysPastDue: number;
  scheduleVersion: string;
  allocationVersion: string;
  dpdLogicVersion: string;
  bucketPolicyVersion: string;
  stateMode: "KNOWN" | "RESTATED";
};

function calculateDpd(
  asOfDate: LocalDate,
  dueItems: DueItemState[],
  policy: DpdPolicy
): number {
  const overdue = dueItems
    .filter((x) => x.remainingMinor > policy.materialityMinor)
    .filter((x) => !policy.isGraceEligible(x, asOfDate))
    .filter((x) => x.dueDate < asOfDate);

  if (overdue.length === 0) return 0;
  const oldest = overdue
    .map((x) => x.dueDate)
    .sort(compareDates)[0];
  return policy.daysBetween(oldest, asOfDate);
}

The example assumes comparable local dates and simple policy hooks. Production code must define inclusive boundaries, missing dates, contractual calendars and validated schedule state. The function recomputes after payment, reversal, adjustment or restructure; it never applies arithmetic such as dpd -= 30.

Golden streams make DPD arithmetic inspectable

Values assume calendar-day difference and no grace; they are fictional test semantics, not a universal convention.

The second stream proves DPD step-down: payments clear older obligations and expose newer unpaid dates. It also proves that payment amount and total arrears alone are insufficient.

Replay and migration tests protect the definition

Apply invariants only where product semantics permit. Before a system migration, replay representative historical accounts through old and new logic, compare distributions and investigate every material difference. Otherwise infrastructure change can masquerade as credit-risk drift.

Reconcile definitions; do not force-match outputs

Classify timing, schedule, allocation, reversal, materiality/grace and source defects. Monitor DPD distribution, zero-to-positive transitions, cure, reopen and reconciliation-difference rates without universal thresholds.

Sudden DPD collapse, spikes at one exact value, unusually high cure after batch or repeated next-day reopen can indicate infrastructure rather than borrower behaviour. Nightly-only transitions can also create artificial daily patterns.

The Entimema DPD architecture makes every day traceable

A DPD Integrity & Delinquency Reconstruction Agent can explain state

A future controlled agent can reconstruct due items, match payments, identify unexplained arrears, compare servicing and derived DPD, trace payment/reversal transitions, find false cure or delinquency candidates, detect schedule mismatch, compare known/restated DPD and monitor migration drift.

Continue with Reversals, Chargebacks and Corrections, Late-Arriving Events and Backdated Corrections, Reconstructing Account State, Idempotency in Event Processing, Event Time vs Processing Time vs Posting Time, The Payment Is Not the Balance, Early Warning Systems, Behavioural Credit Scoring, Collections Prioritisation, Cure & Re-Default Analytics and Promise-to-Pay Analytics. Credit data models, point-in-time features and cross-function reconciliation are future research directions, not fabricated routes.