A customer sees Paid. The processor sees Authorised. Settlement is pending, servicing has not posted, collections still sees overdue, Risk has increased DPD and Finance sees no ledger movement. Potentially every view is correct—at a different stage of the same financial event.
The persistent error is to ask, “What is the payment status?” as though one field could answer every downstream question. The better questions are: Which event occurred, when did it become economically effective, when did it become final, and which state should this decision consume?
A payment is an event. A balance is a state.
Something happened
A payment record describes an amount, event time, status, source, account and reference. It is evidence of occurrence—not a complete customer position.
What is true now
A balance is the accumulated result after relevant drawdowns, payments, interest, fees, reversals and corrections have been applied.
Payment received is an event. Account current is a derived state. Payment amount alone cannot tell us whether arrears were covered, how cash was allocated, whether the payment is final or whether another event reversed it.
Do not ask every system to agree on one balance at every moment. Make every system agree on the event history and the rules used to derive its state.
“Paid” contains a lifecycle, not a binary fact
| Stage | What it establishes | What it does not establish |
|---|---|---|
| Instruction | The customer submitted a payment request | Funds availability, settlement or balance reduction |
| Authorisation | A payment mechanism accepted the transaction | Settlement or posting |
| Processing | The transaction is moving through an operational path | Accounting recognition |
| Settlement | Funds became economically settled under the relevant architecture | That servicing or ledger state has updated |
| Posting | Servicing or accounting applied the payment | That the payment can never return or reverse |
| Final / reversed | Subsequent evidence confirms or offsets the event | That history should be silently overwritten |
Instant settlement does not repair a batch risk warehouse. Conversely, an instant signal should not automatically create cure when finality or allocation remains unresolved. Freshness and correctness sit on a decision-specific frontier.
One payment can produce five legitimate institutional states
Customer state
I instructed the payment and received confirmation.
Operational state
The processor accepted or completed its work.
Settlement state
Funds have—or have not—settled.
Accounting state
The account and ledger have—or have not—posted.
Risk state
The event has—or has not—met the policy for analytical recognition.
These states should reconcile; they need not be identical at every instant. Collections may stop contact after sufficiently confirmed settlement, Finance may wait for posting, and Risk may use a controlled effective-payment state. The governance question is not which team owns “the truth”, but which definition and minimum finality each decision requires.
| Time | Observed event | Customer / Operations | Servicing / Finance | Risk / Collections |
|---|---|---|---|---|
| 08:15 | Instruction | Customer believes paid | €500 remains outstanding | Overdue state unchanged |
| 08:16 | Authorised | Processor accepted | No posting | Policy may treat as provisional only |
| 13:00 | Settled | Operational cash confirmed | Still not posted | Collections hold may be justified |
| 22:45 | Posted | Account updated | Balance and ledger movement recorded | Warehouse still stale |
| 01:30 next day | Risk refresh | No new customer event | Posted state available | DPD and features recalculate |
| 07:00 | Queue generated | — | — | Collections consumes refreshed state |
DPD is downstream from payment semantics
False delinquency
The customer paid before collections evaluation, but the event has not reached the DPD source. System DPD is positive while the economic state is already changing. The result can be an inappropriate contact, false EWS alert, missed-payment feature or complaint.
False cure
A provisional payment is recognised and the account appears current. The payment later returns or reverses. A temporary technical cure was mistaken for durable recovery.
A €500 payment against €900 arrears is real but does not cure. A partial payment can reduce exposure and collections priority while leaving DPD unchanged. An excess payment may reduce principal, cover future dues or create credit depending on product rules. Allocation to fees, interest, principal or due items changes arrears even when payment amount is constant.
This is why Cure & Re-Default Analytics must consume reconstructed account state, and why Behavioural Credit Scoring and Early Warning Systems must separate genuine deterioration from processing latency. A promise can likewise appear broken before its matching payment posts; see Promise-to-Pay Analytics.
Six timestamps answer six different questions
TeventWhen the underlying event occurred
TauthorisationWhen the mechanism accepted it
TsettlementWhen economic settlement occurred
TpostingWhen account or ledger state updated
TriskWhen methodology recognises it
TdecisionWhen downstream action was produced
Processing time is vital for latency and pipeline monitoring, but it does not automatically carry economic meaning. Risk-effective time is a policy definition, not a synonym for arrival or posting time. Decision records must say which state and information set were available at that instant.
| State | Meaning | Use |
|---|---|---|
| Stateᵏⁿᵒʷⁿₜ | What the institution legitimately knew at T | Backtesting, decision replay, operational accountability |
| Stateʳᵉˢᵗᵃᵗᵉᵈₜ | What later evidence says was economically true at T | Correction, data-quality analysis, economic reconstruction |
If arrival time is later than effective time, historical DPD may change. Both original and corrected state should be preserved. Model validation that silently substitutes corrected future information into the past creates hindsight leakage.
Correct history with events, not silent mutation
Where the architecture supports it, preserve the original event and append a linked correction, return, chargeback or reversal. Silent overwriting weakens auditability, lineage and reproducibility. Accounting posting is itself an event, distinct from—and reconciled to—the economic payment event.
A stable event identity allows deduplication, lineage and reversal linkage. Retry, message duplication or file resend must not apply the same payment twice. Identity must map the event to customer, account, facility and schedule item; otherwise cash can exist in suspense while the loan balance remains unchanged.
Correct financial history by adding corrective events, not by silently rewriting what happened.
Reconciliation should explain differences, not erase them
- Payment source
- Canonical payment event
- Identity / allocation
- Settlement & finality
- Servicing state
- Accounting posting
- Analytical account state
- DPD / cure / features
- Collections / risk / ECL decisions
- Reconciliation
A canonical event can preserve source complexity while shielding consumers from vendor-specific statuses. Useful attributes include event identity, customer/account/facility mapping, event type, amount, event, processing and effective times, controlled status and reversal reference. Canonical does not mean simplistic; it means a stable semantic contract.
| Status | Interpretation | Control response |
|---|---|---|
| Pending settlement | Lifecycle progression remains incomplete | Observe within expected window |
| Pending expected posting | Settled but servicing or ledger has not yet updated | Hold or inform selected consumers |
| Pending allocation | Cash exists but account mapping or allocation remains unresolved | Surface to operations and customer-treatment controls |
| Unexplained mismatch | Difference exceeds expected timing or semantics | Investigate as anomaly |
| Corrected | A linked corrective event resolved the difference | Retain lineage and both historical states |
The expected latency window is decision- and architecture-specific. Finance, Risk and Operations should not manually investigate predictable timing differences every day. That is the reconciliation tax created by hidden infrastructure debt.
When two systems disagree
- Are they using the same event set?
- Are they using the same effective time?
- Are different but valid state rules being applied?
- Is one state missing, duplicating or misallocating an event?
A €250 payment removes three false signals without weakening accounting control
Consider a fictional consumer lender using a PSP, SaaS servicing platform, accounting system, risk warehouse and collections platform. A €250 payment settles at 14:00; servicing posts it overnight; the collections queue runs at 18:00.
| Consumer | Existing architecture at 18:00 | Improved architecture at 18:00 |
|---|---|---|
| Collections | Account appears overdue; message generated | Settled event creates a bounded payment hold |
| Promise-to-pay | Promise marked broken | Payment is matched as settled, pending posting |
| Behavioural risk | Missed-payment feature worsens | Feature records pending-effective payment, not a confirmed miss |
| Accounting | Waits for overnight posting | Still waits for controlled posting |
| Next morning | All systems reconcile after customer harm risk | Posting reconciles the event and closes provisional states |
The improved design does not pretend the ledger has posted. It fans one governed event into consumer-specific state: servicing, Risk, Collections and Finance reconciliation. Three false signals disappear while Finance retains posting control.
In a bank, payment rails and core controls may be mature while last-mile risk consumption remains fragmented. A non-bank may combine PSP, statement feed, SaaS servicing, collections and accounting providers. APIs change the transport, not the semantic problem: both need identity, finality, timestamps and reconciliation.
Implementation starts with decision-specific finality
| Consumer | Possible minimum evidence | Why |
|---|---|---|
| Customer notification | Early acknowledgement | Confirm receipt without claiming final posting |
| Collections hold | Sufficiently confirmed settlement | Avoid inappropriate contact while preserving expiry and exceptions |
| Ledger | Formal posting | Protect accounting authority and control |
| LGD realised recovery | Final cash flow and allocation | Protect recovery timing and discounting |
- Capture event
- Identify account
- Preserve timestamps
- Determine finality
- Allocate payment
- Derive state
- Apply risk logic
- Trigger decision
- Reconcile
- Payment feed
- Normalisation
- Deduplication
- Identity resolution
- Settlement / finality
- Allocation
- Account-state builder
- DPD engine
- Risk / collections
- Accounting reconciliation
Payment errors reach beyond collections. Recovery dates and allocation distort IFRS 9 LGD; delinquency, SICR, behavioural PD and exposure can affect ECL and EAD. Payment infrastructure is therefore a Credit Risk, CFO and engineering control—not back-office plumbing.
A Payment State & Reconciliation Agent can support decision readiness
A future bounded Agent could ingest approved payment events, normalise status, preserve event/processing/posting times, detect duplicates, link reversals, map account and facility, surface unallocated cash, compare settlement with posting, reconstruct payment state, identify likely false delinquency or inconsistent cure and explain differences to human reviewers.
Its role is payment-state integrity + reconciliation + decision-readiness support. It must not autonomously modify ledger postings, reverse transactions or take adverse customer action.
This methodology prepares the Engineering sequence: canonical financial event models; event, processing and posting time; idempotency; account-state reconstruction; late events; reversals; a reliable DPD engine; and reconciliation across Risk, Finance and Collections. Those are engineering briefs—not fabricated live routes.
The practical sequence is simple: Capture Event → Identify Account → Preserve Time → Determine Finality → Allocate → Derive State → Decide → Reconcile. The hard part is preserving each distinction all the way to the decision.
