The architectural problem
A consequential problem in financial systems appears when the system responsible for managing an obligation does not observe every transaction that changes that obligation.
Consider a repayment arrangement. The system knows that a customer has agreed to a sequence of instalments and must determine whether each instalment has been kept or missed. In an ideal architecture, every relevant payment would arrive as an authoritative event:
The arrangement engine could allocate the payment, update the appropriate instalment, and evaluate the arrangement.
The real operating environment was more difficult. Transactions could occur outside the arrangement process, payment events were not necessarily available to the component responsible for monitoring the arrangement, and the authoritative financial system could instead expose a later balance position.
The architectural problem was therefore not simply:
How should a repayment schedule be implemented?
It was:
How can a system make deterministic decisions about the state of a financial obligation when it cannot completely observe the events that produced the current financial position?
That distinction is consequential. A conventional event-driven implementation implicitly assumes that its event history is sufficiently complete to explain current state. When that assumption fails, absence of an event can easily be mistaken for absence of payment.
The architectural decision
The architecture separates financial observation from obligation state.
Rather than treating individual transactions as the sole source from which arrangement state could be determined, the obligation itself is represented explicitly as a stateful domain object.
At time (t), its operational state can be represented as:
where:
is the arrangement lifecycle state;
is the state of its instalments;
is the observed financial balance;
contains the monitoring condition required to evaluate the arrangement.
The arrangement has a finite lifecycle:
and transitions are governed explicitly rather than inferred from arbitrary combinations of mutable fields.
For example:
and, where the missed condition remains unresolved for the configured failure period (X),
A missed instalment therefore does not immediately mean a failed arrangement. Failure is a separate domain transition with its own temporal condition.
Likewise:
and:
This makes the financial relationship—not the transaction stream—the principal object being modeled.
Two forms of observability
A significant part of the architecture is that it does not pretend all financial observations have equivalent information content.
When transaction monitoring is available, a due instalment can be evaluated using observed transaction activity. Monitoring can consequently derive:
or:
Those outcomes can drive arrangement transitions.
But where transaction monitoring is unavailable, the architecture does not infer a missed payment merely from the absence of a transaction.
On the monitoring date, it can establish only that:
The financial outcome must instead be established from subsequent authoritative financial information.
This distinction prevents absence of evidence from being encoded as evidence of absence.
That is a small-looking architectural distinction with significant financial consequences.
Balance reconciliation as deterministic allocation
The second architectural decision was therefore to make balance movement an alternative observable signal.
Given two authoritative balance observations,
the system derives:
A positive delta represents net reduction in the observed balance.
Rather than simply recording that reduction against the arrangement as a whole, it is allocated deterministically against outstanding instalments.
For instalment (I_k):
where (u_k) is its unpaid amount.
The instalment is updated:
and the remaining observable movement becomes:
The operation continues sequentially until either:
or there are no eligible outstanding instalments.
The architecture therefore does not need to invent a missing payment event. It reconciles what can actually be observed.
Why the problem was technically non-trivial
The difficult part was not generating payment dates. It was preserving a coherent financial model across different levels of state and different qualities of evidence.
There are at least four interacting concerns:
while financial observations arrive through another path:
These paths must converge without producing contradictory financial outcomes.
That requires several invariants.
For each instalment:
Allocation cannot create an overpaid instalment merely because a balance movement exceeds the current obligation.
At arrangement level, exactly one lifecycle state must hold:
Duplicate observations must not produce repeated economic effects. The desired property is:
where an already-consumed observation cannot be allocated twice.
The architecture must also distinguish an economic observation from a domain conclusion. A balance decrease is evidence of financial movement; it is not intrinsically an InstalmentKept event. The deterministic allocation and monitoring rules determine whether that observation is sufficient to reach that conclusion.
This separation is important because interest, fees, and similar adjustments can also change an account balance. They are therefore modeled as exogenous financial changes rather than arrangement-state transitions in their own right. Reversals, restructures, settlements, and renegotiations require explicit treatment rather than being silently interpreted as ordinary payments.
The deeper architectural property: convergence
The resulting architecture has a useful property beyond ordinary deterministic state machines.
Let:
denote the arrangement engine's reconstructed state and (S_t^*) the state justified by the authoritative financial observations available for the obligation.
The architecture seeks to make reconciliation a convergence process:
as sufficient authoritative observations become available.
This is more precise than claiming that the system can recover the unknowable historical sequence of transactions. Two different transaction histories can produce the same net balance movement. The architecture does not claim to reconstruct those hidden events.
It reconstructs the obligation state that is justified by the available financial evidence.
That distinction is central.
The architecture therefore separates three concepts that are frequently collapsed:
A robust financial system should not require the first to be perfectly observable in order to compute the third, provided the second eventually contains sufficient authoritative information.
How the project benefited
The immediate benefit was that arrangement behaviour could be defined independently of the mechanism through which financial activity became observable.
A transaction-aware implementation could evaluate instalments directly. A system without transaction visibility could use balance reconciliation. Both could feed the same obligation model rather than requiring separate interpretations of what an arrangement meant.
That produced several architectural benefits.
Deterministic behaviour. The same state, observation, configuration, and ordering rules produce the same resulting obligation state.
Auditability. A decision such as Active → Broken → Failed can be explained through the instalment condition, monitoring result, configured failed-days threshold, and corresponding financial observations rather than reconstructed from scattered mutable fields.
Reduced coupling. The arrangement lifecycle does not need to be structurally coupled to one particular payment-event source.
Explicit uncertainty. Where transaction evidence is unavailable, the model represents an instalment as due rather than manufacturing certainty by classifying it prematurely as missed.
Replayability. Given the initial obligation, configuration, ordered observations, and reconciliation rules, the resulting state can be recomputed.
Policy separation. Rules such as the number of failed days before Broken → Failed, payment frequency, tolerance, and schedule construction can vary without redefining the fundamental lifecycle model.
The architectural lesson
The consequential decision was not the choice of a state-machine implementation.
It was deciding what the state machine represents.
A transaction is an occurrence. A balance is an observation. An instalment is an expected obligation. Monitoring is an evaluation. An arrangement state is a conclusion about the relationship between counterparties.
Treating those concepts as interchangeable creates accidental complexity and, more importantly, can create incorrect financial conclusions.
The resulting architecture establishes a stronger principle:
When the events that produced a financial position are only partially observable, model the obligation explicitly, distinguish observation from inference, and make reconciliation a deterministic process for converging on the state justified by authoritative financial evidence.
That principle extends beyond repayment arrangements. It applies wherever a system must maintain contractual or financial state while observing only part of the activity occurring around it.