Specifications

Systems Architecture: Convergent Financial State Under Partial Observability

This architectural piece examines how financial systems can maintain deterministic obligation state when they cannot observe every transaction that affects it. It develops an architecture that separates financial observations from obligation state, uses explicit lifecycle transitions and deterministic balance reconciliation, and enables the system to converge on the state justified by authoritative financial evidence without reconstructing or inventing missing events. The approach provides a foundation for deterministic behaviour, auditability, replayability, reduced coupling, and explicit handling of uncertainty.

Deterministic Resegmentation: Constraining Host Account Updates for Reproducible Queue Outcomes

When a collections platform resegments accounts from host updates, the same update can produce different segments or queues across services, replays or rule changes. I argue that reproducible allocation depends on three defined pieces: a versioned constraint schema that fixes what each field means, an admission rule that uses per-account sequence numbers to handle duplicates, late arrivals, conflicts and rejections, and a unique-match decision table that maps every admitted state to exactly one allocation. The model includes assertable invariants, a reconciliation mechanism that returns held accounts to a correct state, and a fixture set for conformance testing. It also sets out when the pattern applies, when it does not, and which conditions remain open.

Knowing Where a Payment Plan Stands

When someone agrees to clear their arrears in instalments, that plan is in some condition at every moment: on track, behind, beyond saving, or finished. Most systems never write that condition down. They update a balance, tick an arrears box, and move on. The plan's condition ends up scattered across fields and code, which is why nobody can answer the question a complaint raises a year later: why was this marked as failed? This paper argues the plan should always sit in one clearly named condition, and that moving between those conditions should follow written rules with agreed thresholds rather than someone's interpretation on the day. It sets out six conditions a plan can be in, five conditions each instalment can be in, and exactly what has to be true for the plan to move from one to another. Two points do most of the work. A plan only returns to good standing when every instalment due so far is fully paid, so a large part payment does not quietly restore it. And a plan that has gone quiet because we have stopped receiving information is not the same as a plan that has stopped being paid, so the clock stops rather than running the customer into failure on silence. The paper deliberately never looks at the outstanding balance. Whether instalments have been satisfied comes in from elsewhere, which is what the second paper covers.

Working Out What Someone Paid When All You See Is a Balance

The money is collected by a platform we do not run. We never see the payments. What arrives is a single figure, now and then: what is currently owed. Last month it was 2,400 and today it is 2,150, so something has moved it by 250, and we have to decide what that means before we can say whether any instalment has been paid. Then the balance goes up, and that is where most approaches quietly go wrong. A rise is not a payment, but it is also not nothing. It might be interest, a fee, a correction, or a payment that has been reversed, and each of those needs handling differently. Treat them all the same and a customer who paid on time can have their paid instalments silently undone by an interest charge. This paper sets out how to decide what a balance movement actually was before doing anything with it. The rule is that the system checks for a record explaining the movement, and where there is no record it says so and stops rather than guessing. It then defines how to spread a genuine payment across instalments, how to unwind one properly when a payment is reversed, and what must always remain true throughout so that nobody ends up over-credited or wrongly un-credited. It also says plainly where this stops working. The approach depends on being told about interest, fees, and reversals. Where that information is missing it does not quietly approximate. It raises its hand and asks for help, which is the intended behaviour rather than a shortcoming.

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

Payment outcomes are often detected later than they occur, so pre-collections systems act on assumptions that have already expired. Grace periods shorten without anyone redesigning them, and customers are contacted about arrears they may have already cleared. Treating detection timing as an explicit part of the model keeps responses aligned with what the system actually knows at the time.

Deriving the Convergence Deadline: Closing the determinism gap in convergence-aware pre-collections

A customer’s payment fails on Friday night. Your system does not find out until Monday morning. Somewhere in between, it has to stop waiting and do something. How long should it wait? Most systems answer that with a number someone picked. Thirty minutes, four hours, a day. Nobody can say why, and the number decides real outcomes: wait too long and you miss the window where a quick nudge would have fixed things; act too soon and you chase customers whose payments were fine all along. This paper shows how to work the number out instead of choosing it. Two things bound it. One is what your platform actually does, measured from how long payments really take to resolve. The other is what you owe the customer, from the grace period you promised them. The deadline is whichever of those is tighter. The finding worth reading for is what happens when they conflict. Sometimes your platform is slower than the grace period allows, and no waiting time works: any number you pick breaks one promise or the other. The arithmetic hides this, because it still hands you a plausible-looking answer. So the model refuses to start instead, and tells you the only three ways out. Accept that you will chase more people. Give customers longer. Or fix the platform. Most organisations in that position are already living with the first option. They just have not noticed, and cannot say how often it happens. There is also one implementation detail that will bite you. Once you calculate a waiting time, you have to freeze it against each payment as it starts. Recalculate later and change the deadline for work already underway, and your system quietly loses the ability to explain its own past decisions. Everything still passes its tests. Read this if something in your system waits, then acts, and nobody can tell you where the waiting time came from.

Revised: Arrears Delta Apportionment

When the only signal from a host system is a periodic arrears balance, you cannot reconstruct payments. What you can prove is that the balance moved between two trusted snapshots, and this model allocates that movement across an instalment schedule deterministically. A falling balance is offset against any accumulated increase, then allocated through a strict sequential waterfall. A rising balance is never treated as a reversal; it is recorded as explicit state and extinguished by the next reduction. Status is derived from the snapshot date rather than the clock, and every run persists enough metadata to replay the allocation exactly.

Beyond Ledgers: Financial Obligations as Convergent State Machines

Instalment Allocation Using Balance Deltas Instead of Transactions

This article explains how to allocate instalments when systems only receive periodic balance snapshots rather than transaction data. Instead of assuming payment events, it calculates the change between balance snapshots and applies that inferred movement safely across instalments. By anchoring calculations to a trusted baseline and evolving state incrementally, the model preserves determinism, auditability, and consistent account behaviour even when the underlying events are not visible.

How Payment Processing Logic Shows Up in Everyday Accounts

Some debt collection systems only receive periodic updates of the total balance rather than detailed payment events. When the balance changes, the system must infer how that reduction should be applied across instalments. Deterministic allocation logic ensures the outcome is consistent, so balances, missed payment indicators, and the next amount due appear clearly on statements, apps, and customer service screens. The linked article explains the Arrears Delta Apportionment model used to implement this approach.

When Balances Are All You Have

Some servicing integrations only receive periodic balance snapshots from a host system rather than detailed payment events. When the balance changes, the system must infer how that reduction should be applied across instalments. This article explains how to design allocation logic under that constraint by treating balance changes as inferred net movement instead of confirmed payments. Deterministic allocation ensures balances, missed payment indicators, and next amounts due remain predictable and explainable, even when systems exchange only limited information.

How Balance Allocation Logic Affects What Customers See on Their Accounts

Some financial systems only receive periodic balance snapshots rather than individual payment events. When the balance decreases, the system must infer how that reduction should be applied across instalments. Deterministic allocation rules ensure the balance change is applied consistently. The full article explains the Arrears Delta Apportionment model used in balance-only integrations.

Arrears Delta Apportionment

Arrears Delta Apportionment is a deterministic model for allocating reductions in total due across instalments when only periodic balance snapshots are available. Instead of reconstructing payments, it interprets balance deltas between snapshots and incrementally allocates the inferred reduction using a baseline, delta calculation, and a sequential waterfall. Metadata ensures idempotency and auditability, allowing the system to remain predictable even with limited or delayed signals.

Observability Strategies for Production Systems

Logging, metrics, and tracing that actually help when things break. Building observability into debt-collections or fintech systems from day one.

Payment Processing Patterns in Lending Systems

Understanding idempotency, retry logic, and reconciliation patterns when handling payments at scale in lending platforms.

Event-Driven Architecture Patterns

Mental models for building event-driven systems. Understanding event sourcing, CQRS, eventual consistency, and when to use them in fintech contexts.