Convergence delay in pre-collections

Problem

A customer attempts a payment on Friday at 20:00. The payment workflow fails partway through. The transaction outcome does not propagate to the account entity until Monday at 09:00.

The instalment was due on Friday. The grace period is three days. By the time the system knows the payment failed, the grace period has thirteen hours left, and the next pre-collections action has already been queued against an account state that predates the failure.

The customer had three days to fix this. The system gave them thirteen hours, and nobody decided that.

The problem is that downstream actions are scheduled against account state that has not converged. Payment execution, transaction reconciliation, and entity update resolve on independent timelines, and the interval between them is neither modelled nor bounded. During that interval, every consuming system operates against the last confirmed state and has no way to know it is stale.

The failure being detected is secondary. What shapes the outcome is when the system becomes confident enough to act, and that is currently an emergent property of workflow latency rather than a designed one.

I want to be precise about what is wrong here, because "late detection" undersells it. The system is not late. It is acting on time against information that is late, which is a different condition and needs a different fix. Making the pipeline faster narrows the interval without ever closing it, and leaves the same defect at a smaller scale.

What the Delay Actually Consumes

Grace periods are specified against due dates and consumed against convergence times, and nobody reconciles the two.

In the opening scenario the specification says three days. The delivered value is thirteen hours. That reduction is invisible because no system computes it, and it varies per account with workflow latency, so two customers with identical failures on the same day receive materially different windows.

The consequences follow from that arithmetic rather than from anything discretionary.

Messages arrive out of sequence with their intent. A reminder written for day one of a grace period arrives on day three, carrying a tone calibrated for a situation that has already moved past it.

Intent becomes unreadable. During the unconverged interval there is no rule distinguishing a customer who has not been told from a customer who has been told and has not responded. Both present as inactive. Every model consuming a responsiveness signal is reading noise for the duration.

Behaviour becomes latency-sensitive. An account converging after eight hours and one converging after forty-eight receive different treatment for the same underlying failure. That sensitivity is not modelled anywhere, so it surfaces only in incident reconstruction.

System Boundary

Inputs. Payment attempt notification, carrying attempt time and identifier. Transaction outcome, carrying identifier and result. Entity update confirmation, carrying identifier and applied time. Instalment due date and grace period from the arrangement. Convergence deadline $D$ , as configuration. System clock.

Outputs. Knowledge state per payment attempt. Convergence timestamp. Actionability determination. Effective grace expiry.

Non-inputs. The internal progress of the payment workflow. Partial or intermediate transaction states. Customer contact history. Anything the payment platform knows but has not emitted.

Non-goals. This model does not make the pipeline faster, does not decide what action to take, and does not write messaging. It determines what the system knows about a payment attempt, when it knew it, and whether that is sufficient to act.

Assumptions. Attempt notification precedes outcome, which precedes entity update. Each carries a stable attempt identifier. Any of the three may be delayed without bound.

The Model: Two Clocks and Six States

The structural error underneath all of this is that the system keeps one clock. Everything is anchored to due date, which is when things were supposed to happen. Nothing is anchored to convergence time, which is when the system found out.

The model separates them.

$t_{e v e n t} = when the payment attempt occurred$ $t_{co n v er g e d} = when the system reached a settled knowledge state$ $Δ_{co n v} = t_{co n v er g e d} - t_{e v e n t}$

$Δ_{co n v}$ is the quantity the current architecture never computes and every downstream problem derives from.

Knowledge states

The state belongs to a payment attempt, not to the account. An account may carry several attempts in different states.

$S_{K} = {NoAttempt, Attempted, Resolving, Settled, Failed, Indeterminate}$

State	Condition
`NoAttempt`	No attempt notification received for the period
`Attempted`	Attempt notified, no outcome received
`Resolving`	Outcome received, entity update not yet confirmed
`Settled`	Outcome successful and entity update confirmed
`Failed`	Outcome unsuccessful and entity update confirmed
`Indeterminate`	Convergence deadline $D$ elapsed without reaching Settled or Failed

Settled, Failed, and Indeterminate are converged. Attempted and Resolving are not. Indeterminate is the state that makes the model deterministic: without it, an attempt whose outcome never arrives has no defined state, and the system falls back to acting on stale information, which is the original defect.

Transitions

Current	Event	Guard	Next
NoAttempt	AttemptNotified	none	Attempted
Attempted	OutcomeReceived	none	Resolving
Attempted	Clock	$t - t_{e v e n t} > D$	Indeterminate
Resolving	EntityUpdateConfirmed	outcome = success	Settled
Resolving	EntityUpdateConfirmed	outcome = failure	Failed
Resolving	Clock	$t - t_{e v e n t} > D$	Indeterminate
Indeterminate	OutcomeReceived or EntityUpdateConfirmed	within reconciliation window $W$	Settled or Failed per outcome
Indeterminate	OutcomeReceived or EntityUpdateConfirmed	beyond $W$	Indeterminate, flagged

$D$ is the convergence deadline, supplied as configuration.

Indeterminate is recoverable within $W$ , because late information is still information. Beyond $W$ it is not applied, because by then the system has acted and reversing the knowledge state would contradict a decision already communicated. The late signal is flagged for reconciliation instead.

Actionability

$a c t i o nab l e (a) ⟺ s t a t e (a) \in {Settled, Failed, Indeterminate}$

No action is scheduled against an attempt in Attempted or Resolving. This is the rule the current architecture lacks, and it is one line.

Indeterminate is actionable deliberately. An attempt that never resolves cannot block indefinitely, because a customer who genuinely has not paid then receives no contact at all. What changes is the action available, defined below.

Effective grace

$g r a c e_{e f f ec t i v e} = max (d u eD a t e + g r a ce, t_{co n v er g e d} + g r a c e_{min})$

Grace runs from the later of its contractual expiry and the point at which the system could first have told the customer anything. $g r a c e_{min}$ is the minimum usable window, configured.

Applying this to the opening scenario: due Friday, three days grace, converged Monday 09:00, $g r a c e_{min}$ of two days gives an effective expiry of Wednesday 09:00 rather than Monday 13:00. The customer receives a usable window because the system now knows it consumed one.

Invariants

No action on unconverged state. No pre-collections action is scheduled for an attempt in Attempted or Resolving. This holds regardless of elapsed time, which is why Indeterminate must exist.

Grace is not consumed by convergence delay. $g r a c e_{e f f ec t i v e}$ never expires earlier than $t_{co n v er g e d} + g r a c e_{min}$ .

Convergence is timestamped. Every attempt reaching a converged state records $t_{co n v er g e d}$ . An attempt that converged without a recorded timestamp cannot be reconstructed and is treated as a defect.

Responsiveness is only measured post-convergence. No inactivity signal is emitted for an attempt whose convergence occurred less than the notification interval ago. A customer cannot be recorded as unresponsive to a message that had not been sent.

One state per attempt. Each attempt occupies exactly one knowledge state. Account level condition is derived from its attempts, never held independently.

Action Under Indeterminate State

Indeterminate means the system does not know whether the payment succeeded. Acting as though it failed is wrong roughly half the time, and this is where most implementations quietly revert to guessing.

The rule is that Indeterminate permits only actions that are correct under either outcome.

Action	Settled	Failed	Indeterminate
No contact	Yes	No	No
Neutral notification acknowledging uncertainty	Acceptable	Acceptable	Yes
Arrears messaging	No	Yes	No
Escalation or strategy assignment	No	Yes	No
Failure counted toward arrangement threshold	No	Yes	No

A message that says the system is checking a recent payment and asks the customer to confirm is correct whether or not the payment succeeded. Arrears messaging is not. The distinction is structural rather than editorial: one class of action is outcome-independent and the other is not.

Edge Cases

Entity update arrives before transaction outcome. Assumption violated. Hold in Resolving and flag OutOfOrderConvergence. Do not infer the outcome from the entity update, since the update reflects what was applied rather than what was decided.

Outcome received, entity update never arrives. Escalates to Indeterminate at $D$ . This is the most common real shape of the problem and is why $D$ must be measured from $t_{e v e n t}$ rather than from outcome receipt.

Duplicate outcome for one attempt. Deduplicate on attempt identifier. Repeated delivery must not re-enter Resolving from a converged state.

Second attempt while the first is Resolving. Two attempts, two states, independently tracked. Account level actionability requires all attempts in the period to be converged. A customer retrying is the case most likely to break implementations that hold state at account level.

Late convergence after action was taken. Within $W$ , the state corrects and the correction is recorded alongside the action already taken. Reconciling the two is outside this model, but the record makes it possible, which it currently is not.

Attempt notification never arrives, outcome does. Create the attempt on outcome receipt with $t_{e v e n t}$ set to the outcome's stated attempt time. Flag the missing notification.

$D$ elapses during a non-working period. $D$ is measured in elapsed time, not business hours, because the customer's grace period is too. Configuring them on different clocks reintroduces the mismatch this model exists to remove.

Artefact

A six-state knowledge model per payment attempt, an actionability predicate, an effective grace expression anchored on convergence, an action matrix for the indeterminate state, and five invariants.

When to use

Payment execution, transaction outcome, and account entity update are separate systems with independent latency.
Downstream actions are scheduled on a timetable derived from due dates.
Grace periods or intervention windows are short relative to convergence latency.
Nobody currently measures the interval between a payment event and the system's knowledge of it.

When not to use

Payment outcome and account state update are atomic. There is no interval to model.
Convergence latency is reliably an order of magnitude shorter than the grace period. The model adds state for an interval that does not materially consume the window.
Actions are triggered by human review rather than scheduling, since a reviewer inspecting the account is performing the convergence check informally.

Constraints

Requires a stable attempt identifier across all three signals. Without it, attempts cannot be tracked independently and account level state is the only option, which is what fails on retry.
Requires $D$ , $W$ , and $g r a c e_{min}$ as configuration. The value of $D$ is not derived by this model. See Unresolved Tensions.
Requires downstream consumers to honour the actionability predicate. Publishing knowledge state to a scheduler that ignores it provides nothing.
Requires $D$ and grace to be measured on the same clock.

What Remains Open

Reconciling a correction against an action already taken. Within $W$ , the knowledge state can correct after a message has been sent. The model records both but does not define what to do about the contradiction, because the answer depends on what was said and to whom. That belongs to a communications model above this one.

$D$ has no derivation, and this is a determinism gap rather probably nt a surfaced tension associated with the model. Set too short, attempts escalate to Indeterminate routinely and the neutral message becomes the default customer experience. Set too long, action is deferred past the point of usefulness and the window closes unused. The model supplies no rule for choosing between them, so two practitioners implementing this specification against the same platform would reach different escalation behaviour and neither could justify their value.

Account level derivation is stated, not defined. The model tracks attempts and asserts that account condition derives from them, but where a period contains a settled attempt and an indeterminate one, the derivation rule is a commercial decision rather than a structural one. It is named here rather than resolved.

Find a specification.

Deciding Before the System Agrees: Convergence delay in pre-collections