Event-Driven Decision Triggers in Lending Systems

Within 90 seconds, one revolving draw creates an authorisation, posted drawdown, utilisation update, feature-store update, behavioural score refresh and customer-state projection. A naïve platform treats each technical event as a new reason to run the same limit or EWS decision.

Triggers originate from events, state, features, time or combinations

Event-driven does not mean event-only. Timers remain necessary for time-since-payment, scheduled reviews and unresolved watch states.

Dependency intersection eliminates unrelated rescoring

type DecisionDependency = {
  decisionType: string;
  inputKeys: string[];
};

// Trigger only when intersection is non-empty:
// ChangedInputs ∩ DecisionDependencies

Collections priority may depend on DPD, payment state, promise state and exposure. A CRM address update is a data change but not a dependency, so it produces no rescore.

No universal threshold applies. Prefer triggering on a state transition to repeatedly triggering on a raw value while it remains in the same zone.

Debounce, coalescing, hysteresis and cooldown act at different stages

A trigger window groups related drawdown, utilisation and feature updates into one EXPOSURE_STATE_CHANGED context. Debounce consumes latency, so:

Hysteresis triggers above a high boundary and clears below a lower boundary, preventing oscillation. Cooldown occurs after action and may be overridden only by a materially distinct deterioration defined in policy.

One economic change needs one stable trigger identity

type DecisionTrigger = {
  triggerId: string;
  decisionType: string;
  entityId: string;
  causeEventIds: string[];
  createdAt: Date;
};

Causal grouping maps several technical events to one trigger. Duplicate delivery of the same trigger produces one decision execution—or an explicitly safe equivalent—through idempotent consumption.

Link decisionRunId to triggerId. This makes deduplication auditable rather than an invisible cache behaviour.

A decision run is not an action instruction

Risk episodes retain context without multiplying cases

The first WATCH → ALERT transition may create one review task. Later ALERT → ALERT changes append evidence. A new case may be justified only after closure, cure, cooldown expiry or materially distinct deterioration under versioned episode rules.

For a payment settlement, collections may move CONTACT → HOLD and suppress planned contact once. A later causal reversal can create the distinct HOLD → CONTACT_ELIGIBLE transition.

Reject or re-evaluate decisions that become stale while executing

If a run is already in flight, queue, merge or cancel/restart a new trigger according to latency and engine design. Before action, compare input state version, current version and decision age. A materially stale result cannot execute merely because it finished successfully.

Trigger policy is a versioned part of model operationalisation

type TriggerPolicy = {
  decisionType: string;
  version: string;
  dependencies: string[];
  debounceMs?: number;
  cooldownMs?: number;
};

Changing rescore frequency can alter realised decisions even when the model is unchanged. Store triggerPolicyVersion with replay evidence.

Before running, guard data freshness, source health, feature completeness and duplicate/in-flight state. Expensive features, external calls and human review strengthen the case for selective triggers. Conceptually, re-evaluate only when Value(redecision) > Cost(redecision).

Event-driven rescoring changes which customers are observed

High-activity or deteriorating borrowers generate more events and therefore more scores. Monitoring only rescored cases overrepresents them and creates operational selection effects.

Periodic full reevaluation also audits trigger recall. If baseline scoring finds a material change without a prior trigger, the dependency or trigger policy is incomplete.

Replay requires the trigger context—not only the final score

type TriggerManifest = {
  triggerId: string;
  decisionType: string;
  causeEvents: string[];
  stateVersion: string;
  triggerPolicyVersion: string;
  createdAt: Date;
};

Decision manifests store the trigger ID alongside model, feature and policy versions. Outcome events such as review completion, payment received or limit changed close the monitoring loop.

The same orchestration pattern supports collections, limits and EWS

A golden trigger stream proves one economic change creates at most one intended action

High trigger volume is not success

Also track raw-event compression, trigger/decision/action lag and entity concentration. A well-designed system can reduce total runs while improving intervention timing. Shadow new policy, compare counts and decision/action deltas, then canary with rollback that preserves event history.

The Entimema architecture filters changes before decisions and actions

A Decision Trigger Integrity Agent can diagnose orchestration without changing policy

A controlled agent can monitor event-to-trigger mapping, detect storms and duplicates, measure no-change rescoring, compare baseline scoring for missed triggers, flag stale decisions and repeated episode actions, compare policy versions and trace event → trigger → decision → action lineage.

Continue with Real-Time Utilisation and Exposure Monitoring, Streaming Behavioural Features for Early Warning, From Batch ETL to Event-Driven Credit Risk Architecture, Building a Credit Risk Feature Store, Point-in-Time Customer State Reconstruction, Decision Engine Monitoring and Collections Prioritisation. Backpressure recovery, real-time collections state and production EWS monitoring remain future research directions—not fabricated routes.