Knowing Where a Payment Plan Stands

The question this paper answers

An account is marked Failed. A complaint arrives eleven months later asking why. We open the system and find a balance field, a payment total, an arrears flag, and a scattering of timestamps. Somewhere in the servicing code there is a rule that set that flag, and somewhere else there is a rule that read it. Reconstructing the reasoning means reading the code and inferring what must have run, in what order, against data that has since been overwritten.

The arrangement had a condition at every point in its life. The system never represented it.

That is the specific defect this paper names: the operational state of a repayment arrangement existing only as an emergent property of procedural updates. It is not a data quality problem and it is not a logging problem. Adding an audit log to a procedural implementation records what the code did, which is not the same as recording what the arrangement was.

We argue that the arrangement should occupy an explicit named state at all times, that transitions between those states should be governed by rules with configured thresholds rather than interpreted conditions, and that this is achievable without any change to how payments are captured. The model in this paper is deliberately indifferent to where satisfaction information comes from. It consumes instalment allocation as an input. A companion paper, Computing Obligation Satisfaction from Balance Snapshots, defines how that allocation is derived when payment events are not observable.

What this system owns and what it does not

Inputs

Input	Description	Availability
Arrangement definition	Instalment schedule: amount and due date per instalment. Failure threshold $X$ in days. Grace window $G$ in days	At creation, immutable thereafter
Allocation update	For instalment $k$ , the current value of $p ai d_{k}$ , with the observation time that produced it	Event driven. May be irregular
Allocation gap signal	Assertion that no reliable allocation information has been received since a given time	Where the allocation source can report its own staleness
Cancellation instruction	Manual termination, including termination on renegotiation	Ad hoc
Clock	Current date for elapsed time evaluation	Always available

Outputs

Output	Description
Arrangement state	Exactly one of six named states
Instalment states	One state per instalment in the schedule
Transition history	Ordered record of every state change, its triggering input, and the guard that admitted it
Diagnostic flags	Named conditions requiring attention outside the state machine

Explicit non-inputs

Payment transactions. The machine never sees money move. It sees allocation values change.
Balance. The outstanding balance is not an input to any transition in this model. This is deliberate and is the main structural claim of the paper.
Customer contact history, affordability data, or any collections decisioning input.
Interest and fee calculations.

Non-goals

The machine does not derive allocation, does not decide what to do about a Failed arrangement, and does not price or restructure debt. It answers one question: given the allocation known so far and the elapsed time, what state is this arrangement in, and how did it get there?

Bounding assumptions

Allocation updates are monotonic in observation time. An update carrying an earlier observation time than the last accepted update is rejected.
A renegotiated agreement terminates this obligation and creates a new one. There is no in place renegotiation transition.
The instalment schedule is fixed at creation. Dynamic rescheduling is out of scope.

Representing the arrangement

We represent the arrangement as a system:

$O = (S, E, T, s_{0})$

Where $S$ is the state space, $E$ the input events, $T$ the transition rules, and $s_{0} = Created$ .

$s t a t e (O, t) \in S$

State changes occur only when a defined event arrives and its guard is satisfied. Nothing else changes state. That single constraint is what makes the history reconstructable, because a state that can only change through a recorded transition cannot change silently.

The arrangement state space

$S_{A} = {Created, Active, Broken, Failed, Completed, Cancelled}$

State	Meaning
Created	Established, first instalment not yet due, monitoring not started
Active	Every instalment due to date is fully allocated
Broken	At least one due instalment is under allocated, failure threshold not exceeded
Failed	Failure threshold exceeded
Completed	Every instalment in the schedule is fully allocated
Cancelled	Terminated by instruction, including termination on renegotiation

Finite:

$∣ S_{A} ∣ < \infty$

Mutually exclusive:

$\forall t, \exists! s \in S_{A} : s t a t e (O, t) = s$

Collectively exhaustive:

$\forall t, s t a t e (O, t) \in S_{A}$

Terminal:

$S_{T} = {Completed, Failed, Cancelled}$

No transition leaves a terminal state. An allocation update arriving against a terminal arrangement is recorded and flagged, not applied. An arrangement whose state can change after termination is not terminal, and every reachability argument below would fail.

The instalment state space

$S_{I} = {Pending, Due, PartiallyPaid, Paid, Missed}$

State	Condition
Pending	Due date in the future, $p ai d_{k} = 0$
PartiallyPaid	Due date in the future, $0 < p ai d_{k} < am o u n t_{k}$
Due	Due date reached, within grace window $G$ , $p ai d_{k} < am o u n t_{k}$
Missed	Due date plus $G$ elapsed, $p ai d_{k} < am o u n t_{k}$
Paid	$p ai d_{k} = am o u n t_{k}$ , regardless of date

Two points determine whether this set is genuinely MECE.

Advance allocation is possible, because an allocation source may satisfy instalments ahead of their due dates. PartiallyPaid is therefore scoped to future dated instalments only. A past due instalment carrying partial allocation is Due inside the grace window and Missed outside it. The partial value in $p ai d_{k}$ survives both transitions and is never reset.

Missed is not terminal. This matters more than it appears. If Missed were forward terminal, an instalment could never reach Paid after being missed, the arrears clearance guard below could never be satisfied, and the Broken to Active transition would be formally unreachable. The recovery path that repayment arrangements exist to support would be absent from the model that claims to describe them.

Permitted progressions:

$P e n d in g \to D u e \to P ai d$ $P e n d in g \to P a r t ia l l y P ai d \to D u e \to P ai d$ $P e n d in g \to D u e \to M i sse d$ $P e n d in g \to D u e \to M i sse d \to P ai d$

Any movement that decreases $p ai d_{k}$ is a reversal. Reversals originate outside this machine and are covered in the companion paper. This machine accepts a decreased $p ai d_{k}$ only when the allocation update is explicitly marked as a reversal, and re-evaluates the arrangement state accordingly.

The rules that move it

The two guards

Everything in the transition matrix rests on two conditions. Both are computed, not judged.

Let $D_{t}$ be the set of instalments whose due date has passed at time $t$ .

$s a t i s f i e d (t) ⟺ \forall k \in D_{t} : p ai d_{k} = am o u n t_{k}$

$co m pl e t e (t) ⟺ \forall k : p ai d_{k} = am o u n t_{k}$

Arrears cleared means every instalment due to date is fully allocated. Completion means the whole schedule is. Note what $co m pl e t e (t)$ does not reference: the outstanding balance. An earlier version of this model required balance zero for completion, which meant that interest applied after the final instalment left the arrangement permanently Active, with no unsatisfied instalment to generate an elapsed clock and no exit. The arrangement has done what it undertook to do when the schedule is satisfied. A residual balance is a separate obligation and belongs to a different instance of this machine.

The distinction between the two guards is also what makes partial recovery unambiguous. A partial payment against a Broken arrangement does not restore Active, however large, because $s a t i s f i e d (t)$ is defined on full allocation of every due instalment. Two implementations reading this cannot diverge on the point.

The event set

Event	Description
ArrangementCreated	Obligation established, machine initialised at Created
FirstInstalmentDue	Monitoring begins
AllocationUpdated	One or more $p ai d_{k}$ values have changed
MonitoringEvaluation	Scheduled elapsed time evaluation
AllocationGapDeclared	Allocation source reports it cannot currently supply reliable values
AllocationGapCleared	Reliable allocation resumes
ArrangementCancelled	Termination instruction

The transition matrix

Current	Event	Guard	Next
Created	FirstInstalmentDue	none	Active
Created	ArrangementCancelled	none	Cancelled
Active	AllocationUpdated	$co m pl e t e (t)$	Completed
Active	AllocationUpdated	$\neg co m pl e t e (t)$ , $s a t i s f i e d (t)$	Active
Active	AllocationUpdated	$\neg s a t i s f i e d (t)$	Broken
Active	MonitoringEvaluation	$\neg s a t i s f i e d (t)$ , $e l a p se d D a y s \leq X$	Broken
Active	MonitoringEvaluation	$\neg s a t i s f i e d (t)$ , $e l a p se d D a y s > X$	Failed
Active	MonitoringEvaluation	$s a t i s f i e d (t)$	Active
Broken	AllocationUpdated	$co m pl e t e (t)$	Completed
Broken	AllocationUpdated	$s a t i s f i e d (t)$ , $\neg co m pl e t e (t)$	Active
Broken	AllocationUpdated	$\neg s a t i s f i e d (t)$	Broken
Broken	MonitoringEvaluation	$e l a p se d D a y s > X$	Failed
Broken	MonitoringEvaluation	$e l a p se d D a y s \leq X$	Broken
Active, Broken	AllocationGapDeclared	none	unchanged, monitoring suspended
Active, Broken	AllocationGapCleared	none	unchanged, monitoring resumed
Active, Broken	ArrangementCancelled	none	Cancelled

$e l a p se d D a y s$ is measured from the due date of the oldest instalment that is not fully allocated. $X$ is set in the arrangement definition. It is configuration, not operator discretion, which is the whole basis of the determinism claim.

The Active to Failed row deserves comment because it is easy to omit. An arrangement can pass the failure threshold without ever being observed in Broken, if no monitoring evaluation ran during the intervening period. Without that row the arrangement has no defined transition and holds Active while being materially failed. Direct escalation is correct rather than a shortcut, because Broken is defined by the threshold not being exceeded, and an arrangement that has already exceeded it was never entitled to occupy it.

Idempotency

$δ (δ (s, e), e) = δ (s, e)$

Repeated inputs must not compound. This holds naturally here because every guard is evaluated against absolute allocation values rather than increments. Applying the same allocation update twice yields the same $p ai d_{k}$ and therefore the same state. An implementation that models allocation as a delta applied to a running total loses this property and must deduplicate upstream instead.

What must always hold

Single occupancy. The arrangement occupies exactly one arrangement state and each instalment occupies exactly one instalment state, at every point in time, including mid transition. Transitions are atomic across the arrangement and its instalments.

Allocation integrity. $0 \leq p ai d_{k} \leq am o u n t_{k}$ for every instalment. The machine rejects any allocation update violating this bound rather than clamping it, because a value outside the bound indicates an error in the allocation source that clamping would conceal.

Forward progression except under declared reversal. Instalment states advance through their permitted progressions. Backward movement occurs only when the allocation update is explicitly marked as a reversal, and every such movement appears in the transition history with its trigger.

Terminal immutability. For $s \in S_{T}$ , no event produces a transition. Late inputs are recorded and flagged.

Monitoring suspension preserves state. During a declared allocation gap, no MonitoringEvaluation transition fires. The arrangement holds whatever state it had. This exists because elapsed time alone is not evidence of non payment when the allocation source has gone quiet, and failing an arrangement on the absence of evidence is the most damaging error this machine can make.

Where it is probed

These are adversarial cases. Each attacks a specific boundary.

Threshold crossed during an allocation gap. The gap suspends monitoring, then clears, and the oldest unallocated instalment is now well past $X$ . Rule: on AllocationGapCleared, allocation updates are processed before any monitoring evaluation runs. If the backlog satisfies the instalments, no failure occurs. If it does not, the next evaluation escalates on true elapsed time. Order of processing is fixed, not incidental, because reversing it fails arrangements that were in fact being paid.

Cancellation instruction arrives for an already Failed arrangement. Rule: no transition. Flag PostTerminalInstruction. Cancelling a failed arrangement is an operational wish, not a state change, and honouring it would make Failed non terminal.

Allocation update reduces $p ai d_{k}$ without a reversal marker. Rule: reject the update, hold state, flag UnmarkedRegression. The allocation source must assert a reversal explicitly. Inferring one from a decreased value would let any upstream data error silently un-pay a customer.

Schedule fully allocated while an instalment is still Missed. Possible when a late allocation completes a missed instalment and the rest of the schedule simultaneously. Rule: $co m pl e t e (t)$ is evaluated after all instalment states are recomputed, not during. The arrangement reaches Completed and the instalment reaches Paid in the same atomic transition.

Zero instalment schedule. An arrangement created with an empty or zero value schedule satisfies $co m pl e t e (t)$ vacuously at creation. Rule: reject at creation. A schedule with no instalments is not an arrangement, and admitting it would let the machine emit Completed for an obligation nobody ever undertook.

Two allocation updates carrying the same observation time. Rule: process in receipt order and record both. Because guards read absolute values, the outcome is the later value regardless of order, and both appear in history.

The artefact

A six state arrangement machine with a five state instalment lifecycle, two computed guards, a fifteen row transition matrix, five invariants, and a fixed processing order for gap recovery.

When to use it

The lifecycle of a repayment arrangement must be auditable months or years after the fact.
More than one system or team must agree on whether an arrangement is broken.
Arrangement condition currently exists as flags and fields rather than as a named state.
Recovery from a broken arrangement is a real business path rather than a theoretical one.

When not to use it

The schedule changes dynamically in response to customer circumstances. Fixed schedules are assumed throughout, and dynamic rescheduling needs a versioning model above this one.
The obligation is not schedule bound. Revolving facilities have no instalment lifecycle.
Arrangement outcome is genuinely a matter of operator discretion in your organisation. This machine will describe your process incorrectly, and forcing it to fit will produce configuration that lies.

Constraints on use

Requires $X$ and $G$ as configuration in the arrangement definition. $G$ is easy to omit because it is only visible at the Due to Missed boundary, and omitting it makes that boundary interpreted rather than computed.
Requires an allocation source that can supply absolute $p ai d_{k}$ values, mark reversals explicitly, and declare its own staleness. A source that cannot declare staleness leaves the suspension invariant unenforceable.
Requires atomic transitions across the arrangement and its instalments. Partial application breaks single occupancy.
Requires that terminal states are never revised, including by late corrections.

What this leaves open

The machine depends on an allocation source that can assert three things: absolute values, explicit reversals, and its own staleness. Not every servicing integration can do all three. Where staleness cannot be declared, the suspension invariant degrades to a time based heuristic, and the protection against failing an arrangement on missing evidence weakens correspondingly. We do not have a way to recover that guarantee from within this machine.

Termination on renegotiation preserves determinism but severs continuity. The new arrangement carries no structural link to the one it replaced, so a customer who renegotiates twice appears as three unrelated obligations. This is a real cost and we think the answer is an obligation versioning layer above the machine rather than a transition inside it, but we have not built that layer.