Why This Matters in Everyday Financial Life
When people make a payment on a loan, credit account, or payment arrangement, they usually expect a simple outcome: the amount owed should go down and the next payment should be clear. Behind the scenes, however, many financial systems do not always receive detailed payment information. In some integrations, systems only receive periodic updates of the total amount due rather than the individual payment events that caused the balance to change. When that happens, the system must infer how the reduction should be applied across scheduled instalments or overdue amounts.
To keep customer balances predictable and fair, systems use deterministic allocation rules that interpret the change in total balance and distribute that value across obligations in a consistent order. This ensures that the same balance change always produces the same outcome. For customers, this translates into more stable account statements, clearer “next payment due” indicators, and fewer situations where a payment appears to have been applied inconsistently. Good system design in this area helps prevent disputes, reduces confusion during customer service interactions, and makes account behaviour easier to explain.
If you are interested in how this works at the system level, including the constraints, allocation model, and edge cases involved, you can explore the deeper technical explanation in the full article on Arrears Delta Apportionment and how it is implemented in balance-only integrations.
Summary
Arrears Delta Apportionment is a deterministic model that allocates inferred net reductions in total due across instalments when only balance snapshots are available.
It replaces transaction reconstruction with controlled state convergence based solely on balance deltas.
This model is designed for integrations where the only available signal is a periodic arrears balance snapshot. Because no transaction-level data is available, the system does not attempt to reconstruct payments. Instead, it allocates inferred net reduction in total due between trusted snapshots.
Allocation is performed incrementally using:
- a strict baseline
- a delta calculation
- a sequential waterfall across instalments
Negative balance movement does not reverse prior allocations. Instead, it is recorded explicitly as state.
Overpayments, missed status, and next-payable logic are derived consistently from the same temporal reference. Metadata is persisted to ensure idempotency, replay safety, and auditability.
The result is a constraint-driven, state-convergent allocation approach that remains deterministic even when signals are incomplete, delayed, or partially missing.
Problem
In some collections integrations, the only available input from the host banking system is a periodic arrears balance snapshot.
In this environment I cannot observe:
- payment transactions
- posting order
- reversals
- fee application
Yet I am still required to allocate value across an instalment schedule deterministically.
This model addresses that constraint.
Instead of reconstructing payment history, the system converges on the only signal that can be trusted:
Balance movement between two known points in time.
Explicit Limitations of Arrears-Only Integrations
In an arrears-only integration I receive:
- total arrears balance or outstanding balance
- balanceProcessedDate
I do not receive payment events.
When the balance decreases between two trusted snapshots, I infer that net value has been applied to the account.
However, that value is not a known payment.
If arrears moves from:
£1,000 to £850
I cannot determine:
- whether a single £150 payment occurred
- whether multiple payments occurred
- whether fees offset payments
- whether reversals occurred
All I can prove is:
Total due reduced by £150 relative to the prior trusted state.
Therefore what I allocate is not a payment event.
It is net arrears reduction.
Terminology: Arrears Delta Apportionment
The name makes three structural realities explicit.
1. Arrears
The signal is total due, not transactional cash flow.
2. Delta
The allocatable value is the difference between two balances, not a payment instruction.
3. Apportionment
That delta is deterministically allocated across obligations according to defined rules.
When arrears decrease:
- value becomes eligible for allocation through a strict waterfall.
When arrears increase:
- the system does not reverse prior allocations
- the increase is recorded as explicit state.
Therefore the model does not apportion payments.
It performs deterministic allocation of inferred net arrears reduction across a contractual schedule.
System Constraints
The system operates under the following non-negotiable constraints.
The only reliable fact is that balance moved between two trusted snapshots.
All decisions must be evaluated relative to
balanceProcessedDate, not system clock time.Previously applied allocation must not be implicitly reversed based on balance increase alone.
The system must tolerate duplicate file delivery and reprocessing without problemsz.
Every run must persist enough metadata to reconstruct allocation deterministically.
These constraints shape the entire model.
Reframing the Problem as State Convergence
Because transaction data is unavailable, the system cannot answer:
What payments happened?
Instead it asks a provable question:
How much has the balance moved since the last trusted state?
This reframes the system from transaction reconstruction** to **state convergence.
Only balance deltas are admissible inputs.
Everything else becomes derived state.
State Model
Before defining transitions, the state must be explicit.
Arrangement-Level State
arrangementCreatedDatebalanceAtArrangementCreationlastApportionedBalanceunappliedNegativeDeltaoverpaidAmount
Instalment-Level State
sequenceNumberdueDatescheduledAmountunpaidAmountpaidAmountisMissednextUnpaid
Tolerance
A configurable tolerance defines what counts as effectively zero unpaid.
This protects against rounding drift.
State Invariants
These invariants must always hold.
paidAmount + unpaidAmount = scheduledAmount- Only one instalment may have
nextUnpaid = true paidAmountcannot decrease through delta processing- Negative delta does not mutate instalment state
- Allocation order is strictly ascending
sequenceNumber
Allocation Lifecycle
Step 1 — Validate Snapshot
If:
balanceProcessedDate < arrangementCreatedDate
Exit without mutation.
Host state must not back-propagate into a schedule that did not exist.
Step 2 — Determine Baseline
If this is the first run:
baseline = balanceAtArrangementCreation
Otherwise:
baseline = lastApportionedBalance
Step 3 — Compute Delta
delta = baseline - currentBalance
Delta represents net arrears movement since last trusted state.
Only this value is eligible for allocation.
The system never recomputes from scratch.
It only applies incremental movement since last convergence.
Positive Delta Allocation
If:
delta > 0
The balance decreased.
This is interpreted as net payment value available for allocation.
remaining = delta
For instalments in ascending sequenceNumber:
allocate = min(remaining, unpaidAmount)
paidAmount += allocate
unpaidAmount -= allocate
remaining -= allocate
If after all instalments:
remaining > 0
Then:
overpaidAmount += remaining
The waterfall is strict.
- no skipping
- no reordering
- no retroactive adjustments
Given identical state and delta, allocation is identical.
Negative Delta Handling
If:
delta < 0
The balance increased.
This could represent:
- fee application
- reversal
- correction
The signal does not identify which.
Therefore the system does not infer.
Instead:
unappliedNegativeDelta += abs(delta)
Instalment state remains unchanged.
Previously applied allocation is never implicitly undone.
Status Re-evaluation
After allocation, contractual status must be recalculated.
All evaluation uses the same reference:
balanceProcessedDate
Missed Instalments
For each instalment:
if dueDate <= balanceProcessedDate
and unpaidAmount > tolerance
then isMissed = true
else isMissed = false
Next Payable Instalment
Find the first instalment where:
unpaidAmount > tolerance
Set:
nextUnpaid = true
All others are set to false.
This ensures exactly one authoritative next instalment.
Persisted Metadata
Balance-only allocation is only safe if decisions can be reconstructed.
Each run must persist:
baselinedeltaappliedDeltaoverpaidAmountunappliedNegativeDeltabalanceProcessedDatelastApportionedBalance
Persistence must be atomic.
If baseline updates without allocation, future deltas become corrupted.
Edge Case Stress Tests
Duplicate Snapshot Replay
If the same snapshot is processed twice:
delta = 0
No mutation occurs.
The model is idempotent.
Out-of-Order Snapshot
Older snapshots arriving after newer ones distort delta.
Constraint:
reject if balanceProcessedDate < lastProcessedDate
Balance Oscillation
If balance decreases then later increases:
- positive delta allocates
- negative delta accumulates
unappliedNegativeDelta
Instalments remain stable.
Overpayment Beyond Schedule
If:
delta > totalUnpaid
All instalments are fully paid.
Remaining value becomes overpaidAmount.
Schedule Mutation
If instalment structure changes without baseline reset, allocation becomes misaligned.
Constraint: If there is is to be a mutation of the and aky key component then they should be a baseline reset
Baseline Corruption
If lastApportionedBalance is incorrect, all future deltas compound the error.
Baseline must only update after successful atomic allocation.
When to Use
This model is appropriate when:
- only arrears balance snapshots are available
- transaction-level data is unavailable
- idempotent processing is required
- allocation must be deterministic and auditable
- instalments follow sequential contractual ordering
When Not to Use
Do not use this model when:
- full transaction feeds are available
- allocation rules require dynamic prioritization
- automatic retroactive reversals are required
- instalment schedules mutate frequently
- allocation must map to specific payment events
In those cases a transaction-driven allocation model is structurally superior.
Known Failure
The model is deterministic but not immune to structural mis-alignment.
Primary risks include:
- corrupted
lastApportionedBalance - out-of-order snapshot processing
- instalment structure mutation
- tolerance misconfiguration
- unresolved accumulation of
unappliedNegativeDelta - baseline updates without atomic allocation
All of these failure posibilities are detectable.
Hard Constraints
If any of the following constraints are violated, determinism collapses.
- Deterministic ordering of instalments
- Delta-only allocation
- No implicit reversal
- Atomic persistence
- Chronological snapshot processing
- All derived values stored as explicit state
These are structural rules, not implementation details.
Structural Validation Questions
Before production deployment, these questions must be answerable.
Can I prove
lastApportionedBalancereflects a fully persisted allocation state?Have I enforced monotonic processing of
balanceProcessedDate?What explicit process resolves
unappliedNegativeDelta?Under what conditions is the baseline reset?
Does tolerance prevent rounding drift without masking real arrears?
Can I replay any historical allocation using only persisted metadata?
If any answer is unclear, the implementation contains structural risk.
Summary
Given only a daily arrears balance snapshot, I cannot reconstruct transactions.
However, I can define a deterministic state progression that converges safely on balance movement.
Payment apportionment in arrears-only integrations is therefore not transaction matching.
It is:
Controlled, constraint-driven state convergence based on the only signal that can be trusted.
Worked Example
A concrete example makes the model easier to reason about.
Assume an arrangement with four instalments.
| Sequence | Due Date | Scheduled | Paid | Unpaid |
|---|---|---|---|---|
| 1 | 2026-01-05 | £100 | £0 | £100 |
| 2 | 2026-02-05 | £100 | £0 | £100 |
| 3 | 2026-03-05 | £100 | £0 | £100 |
| 4 | 2026-04-05 | £100 | £0 | £100 |
Arrangement-level state at creation:
{
"arrangementCreatedDate": "2026-01-01",
"balanceAtArrangementCreation": 400,
"lastApportionedBalance": 400,
"unappliedNegativeDelta": 0,
"overpaidAmount": 0
}
At this point, total arrears is £400.
Snapshot 1: Balance Decreases A new trusted snapshot arrives:
{
"balanceProcessedDate": "2026-02-10",
"currentBalance": 250
}
Baseline:
Baseline = 400
Delta:
delta = baseline - currentBalance
delta = 400 - 250
delta = 150
Because delta > 0, £150 is eligible for allocation.
Allocation waterfall:
- Instalment 1 receives £100
- paid = £100
- unpaid = £0
- remaining = £50
2.Instalment 2 receives £50
- paid = £50
- unpaid = £50
- remaining = £0
Updated instalment state:
| Sequence | Due Date | Scheduled | Paid | Unpaid | isMissed | nextUnpaid |
|---|---|---|---|---|---|---|
| 1 | 2026-01-05 | £100 | £100 | £0 | false | false |
| 2 | 2026-02-05 | £100 | £50 | £50 | true | true |
| 3 | 2026-03-05 | £100 | £0 | £100 | false | false |
| 4 | 2026-04-05 | £100 | £0 | £100 | false | false |
Why is instalment 2 missed?
Because:
dueDate <= balanceProcessedDate
unpaidAmount > tolerance
Persisted arrangement-level state becomes:
{
"baseline": 400,
"delta": 150,
"appliedDelta": 150,
"overpaidAmount": 0,
"unappliedNegativeDelta": 0,
"balanceProcessedDate": "2026-02-10",
"lastApportionedBalance": 250
}
Snapshot 2: Balance Decreases Again
Another trusted snapshot arrives:
{
"balanceProcessedDate": "2026-03-07",
"currentBalance": 120
}
New baseline:
baseline = lastApportionedBalance = 250
Delta:
delta = 250 - 120 = 130
Allocation waterfall:
- Instalment 2 receives £50
- paid = £100
- unpaid = £0
- remaining = £80
2.Instalment 3 receives £80
- paid = £80
- unpaid = £20
- remaining = £0
Updated instalment state:
| Sequence | Due Date | Scheduled | Paid | Unpaid | isMissed | nextUnpaid |
|---|---|---|---|---|---|---|
| 1 | 2026-01-05 | £100 | £100 | £0 | false | false |
| 2 | 2026-02-05 | £100 | £100 | £0 | false | false |
| 3 | 2026-03-05 | £100 | £80 | £20 | true | true |
| 4 | 2026-04-05 | £100 | £0 | £100 | false | false |
Persisted arrangement-level state:
{
"baseline": 250,
"delta": 130,
"appliedDelta": 130,
"overpaidAmount": 0,
"unappliedNegativeDelta": 0,
"balanceProcessedDate": "2026-03-07",
"lastApportionedBalance": 120
}
Snapshot 3: Balance Increases
A later snapshot arrives:
{
"balanceProcessedDate": "2026-03-08",
"currentBalance": 140
}
base line:
baseline = 120
Delta:
delta = 120 - 140 = -20
Because delta < 0, the model does not reverse instalment state.
Instead:
unappliedNegativeDelta += 20
Updated arrangement-level state:
{
"baseline": 120,
"delta": -20,
"appliedDelta": 0,
"overpaidAmount": 0,
"unappliedNegativeDelta": 20,
"balanceProcessedDate": "2026-03-08",
"lastApportionedBalance": 140
}
Instalment state remains unchanged. This is deliberate.
The signal does not tell us whether the increase came from:
- a fee
- a reversal
- a correction
- some other adjustment So the model records the increase explicitly instead of inventing a reversal.
Snapshot 4: Overpayment Case
Assume a later trusted snapshot:
{
"balanceProcessedDate": "2026-04-10",
"currentBalance": 0
}
Current baseline:
baseline = 140
Delta:
delta = 140 - 0 = 140
Current unpaid across instalments:
- Instalment 3 unpaid = £20
- Instalment 4 unpaid = £100
Total unpaid = £120
Allocation waterfall:
- Instalment 3 receives £20
- unpaid becomes £0
- remaining = £120
2.Instalment 4 receives £100
- unpaid becomes £0
- remaining = £20 All instalments are now fully paid.
Remaining £20 becomes:
overpaidAmount += 20
Final arrangement-level state:
{
"overpaidAmount": 20
}
This shows an important property of the model:
Excess positive delta is not discarded. It is captured explicitly as state.
Worked Example: What This Demonstrates
This example shows five important properties of the model.
- Allocation is incremental, not full recomputation.
- The waterfall is strictly sequence-based.
- Negative delta is recorded, not inferred as reversal.
- Status evaluation uses balanceProcessedDate, not processing time.
- Overpayment is preserved explicitly instead of being silently truncated.
State Diagram: Meaning of Each Stage
SnapshotReceived
A host snapshot arrives with:
- arrears balance
- balance processed date At this point, nothing is trusted yet.
ValidateSnapshot
The snapshot is accepted only if it is structurally safe to process. Examples of rejection conditions:
- it predates arrangement creation
- it is older than the last trusted processed snapshot This protects the state model from back-propagation and out-of-order mutation.
DetermineBaseline
The system chooses the reference point against which balance movement will be measured.
[-] first run: use balanceAtArrangementCreation [-] later runs: use lastApportionedBalance
This step is critical because all later logic depends on baseline integrity.
ComputeDelta
The system calculates:
delta = baseline - currentBalance
This is the only allocatable input.
The model does not reconstruct historical transactions or replay the schedule from scratch.
PositiveDelta
If * delta > 0 *, arrears has reduced.
That reduction is treated as value eligible for instalment allocation.
The model proceeds into the contractual waterfall.
AllocateWaterfall
The system allocates delta sequentially across instalments in ascending sequence number.
This is where the model converges positive balance movement into contractual payment state.
NegativeDelta
If ** delta < 0 **, arrears increased.
The model refuses to guess whether this increase reflects:
- fees
- reversals
- adjustments
So it does not mutate instalments.
RecordNegativeDelta
The increase is captured explicitly as:
unappliedNegativeDelta
This preserves visibility without silently undoing prior state.
ZeroDelta
If delta = 0, no balance movement occurred relative to baseline.
The allocation state remains unchanged.
This is what makes duplicate snapshot replay safe.
RecalculateStatuses
After delta handling, the system recalculates:
- missed instalments
- next unpaid instalment
These are derived from the same temporal reference:
balanceProcessedDate
This keeps payment state and contractual status aligned.
PersistState
All changes must be persisted atomically.
That includes:
- updated arrangement metadata
- updated instalment state
- baseline progression
- audit metadata
If this step is not atomic, future delta calculations become unsafe.
Converged
At this point, the system has safely incorporated the latest trusted snapshot into a deterministic state.
This is the new trusted point for the next run.