PAYMENTS SIGNAL REFERENCE ARCHITECTURE · SYNTHETIC / TRAINING ONLY

Accounting, ledger posting, settlement evidence, and reconciliation data lineage

Follow one payment from business state to balanced entries, external settlement evidence, customer reporting, and a closed reconciliation break.

Payments Signal reference architecture v1 · reviewed 2026-07-23

Reference architecture—not a scheme mandate. This blueprint separates business state, accounting intent, product books, settlement books, external evidence, and reconciliation because those distinctions prevent unsafe retries. Real institutions may use several sub-ledgers, general ledgers, nostro platforms, data warehouses, and finance controls; legal posting rules and correction authority vary.

Audience and purpose

Payment architects, finance-platform engineers, business analysts, controllers, treasury teams, and operations teams.

Components

Payment state and accounting trigger

Turns an authorised business-state transition into one immutable accounting intent.

Kind
service
Owner
Payment engine and product owner
Responsibilities
  • Name the business event before posting
  • Emit one stable accounting trigger for each eligible transition
Inputs
  • Authorised business instruction and correlated state
Outputs
  • Versioned result, status, and audit evidence
Controls
  • State-transition guard
  • Idempotency key
  • Authorised product rule
Failure modes
  • Trigger emitted twice
  • Posting requested before the business state is final enough
Recovery
  • Suppress the duplicate by business key
  • Restore from the event journal and replay only the missing intent
Non-functional requirements
  • Durable correlation through stable business and technical identifiers
  • Capacity and availability matched to the service-level objective
  • Auditable state changes, configuration, and operator actions

Accounting rule and event classifier

Selects the balanced debit and credit pattern for product, event, currency, fee, and settlement context.

Kind
application
Owner
Finance architecture and product accounting
Responsibilities
  • Resolve a versioned posting rule
  • Keep principal, fee, tax, position, and suspense treatment explicit
Inputs
  • Authorised business instruction and correlated state
Outputs
  • Versioned result, status, and audit evidence
Controls
  • Effective-dated rule
  • Four-eyes change approval
  • Balanced-template validation
Failure modes
  • Wrong rule version
  • Unbalanced or incomplete posting template
Recovery
  • Stop before posting
  • Correct the rule under change control and replay the original intent
Non-functional requirements
  • Durable correlation through stable business and technical identifiers
  • Capacity and availability matched to the service-level objective
  • Auditable state changes, configuration, and operator actions

Idempotent posting service

Creates a balanced journal atomically and returns a durable posting reference.

Kind
service
Owner
Core ledger engineering
Responsibilities
  • Post all journal legs atomically
  • Return the same outcome for a repeated business key
Inputs
  • Authorised business instruction and correlated state
Outputs
  • Versioned result, status, and audit evidence
Controls
  • Balanced journal
  • Optimistic concurrency
  • Duplicate-key constraint
Failure modes
  • Partial journal
  • Uncertain response after commit
  • Ledger unavailable
Recovery
  • Query by business key before retry
  • Resume from the last committed journal boundary
Non-functional requirements
  • Durable correlation through stable business and technical identifiers
  • Capacity and availability matched to the service-level objective
  • Auditable state changes, configuration, and operator actions

Customer and product ledger

Records the institution's customer liability, receivable, fee, and product-position entries.

Kind
ledger
Owner
Core banking and finance
Responsibilities
  • Maintain balanced sub-ledger entries
  • Expose booked, pending, blocked, and available balances distinctly
Inputs
  • Authorised business instruction and correlated state
Outputs
  • Versioned result, status, and audit evidence
Controls
  • Double-entry balance
  • Account status
  • Value-date and currency control
Failure modes
  • Wrong account
  • Incorrect value date
  • Balance projection differs from booked entries
Recovery
  • Use a controlled correcting journal
  • Never overwrite the original financial entry
Non-functional requirements
  • Durable correlation through stable business and technical identifiers
  • Capacity and availability matched to the service-level objective
  • Auditable state changes, configuration, and operator actions

Nostro, settlement, and position books

Records expected and confirmed movement in the external settlement asset.

Kind
ledger
Owner
Treasury and finance
Responsibilities
  • Separate expected cash from confirmed cash
  • Track nostro, clearing, and settlement positions by value date and currency
Inputs
  • Authorised business instruction and correlated state
Outputs
  • Versioned result, status, and audit evidence
Controls
  • Settlement-account ownership
  • Currency and value-date balance
  • No unsupported finality claim
Failure modes
  • Expected settlement never arrives
  • Statement entry has no internal expectation
Recovery
  • Open a reconciliation case
  • Reclassify or reverse only with confirmed evidence
Non-functional requirements
  • Durable correlation through stable business and technical identifiers
  • Capacity and availability matched to the service-level objective
  • Auditable state changes, configuration, and operator actions

External statement and settlement evidence

Preserves network status, settlement confirmations, and account reports without treating a transport acknowledgement as settlement.

Kind
data-store
Owner
Payments operations and treasury
Responsibilities
  • Ingest and correlate external evidence
  • Retain the source message, timestamp, and account context
Inputs
  • Authorised business instruction and correlated state
Outputs
  • Versioned result, status, and audit evidence
Controls
  • Authenticity
  • Sequence and completeness
  • Message-to-account correlation
Failure modes
  • Missing statement
  • Late status
  • Duplicate report
  • Conflicting evidence
Recovery
  • Request or retrieve the missing statement
  • Keep the case open until the settlement state is proven
Non-functional requirements
  • Durable correlation through stable business and technical identifiers
  • Capacity and availability matched to the service-level objective
  • Auditable state changes, configuration, and operator actions

Reconciliation and break engine

Matches business events, journals, network evidence, settlement books, and statements at the same grain.

Kind
control
Owner
Finance and payments operations
Responsibilities
  • Run deterministic multi-way matching
  • Classify timing, data, amount, duplicate, and ownership breaks
Inputs
  • Authorised business instruction and correlated state
Outputs
  • Versioned result, status, and audit evidence
Controls
  • Completeness totals
  • Stable match keys
  • Ageing and materiality
  • No silent write-off
Failure modes
  • False match
  • Unmatched cash
  • Aged break without owner
Recovery
  • Undo the false match with audit evidence
  • Route the break to its accountable team
Non-functional requirements
  • Durable correlation through stable business and technical identifiers
  • Capacity and availability matched to the service-level objective
  • Auditable state changes, configuration, and operator actions

Break case, reporting, and close control

Coordinates investigation, correction, attestation, and customer or regulatory reporting.

Kind
operations
Owner
Reconciliation operations and finance control
Responsibilities
  • Assign one accountable owner
  • Close only when books and external evidence agree
Inputs
  • Authorised business instruction and correlated state
Outputs
  • Versioned result, status, and audit evidence
Controls
  • Maker-checker correction
  • Ageing escalation
  • Evidence-backed close
Failure modes
  • Premature close
  • Correction fixes one ledger but opens another break
Recovery
  • Reopen from immutable evidence
  • Re-run downstream reconciliation and reporting
Non-functional requirements
  • Durable correlation through stable business and technical identifiers
  • Capacity and availability matched to the service-level objective
  • Auditable state changes, configuration, and operator actions

Interfaces

Accounting intent

acct-payment-state → acct-rule-engine

Carry the authorised business event and stable key.

Contract
event · asynchronous
Controls
  • Authentication and authorisation
  • Integrity and replay protection
  • Correlation and audit evidence
Failure treatment
A missing event leaves business state ahead of accounting; replay from the journal.

Balanced posting command

acct-rule-engine → acct-posting-service

Submit the effective-dated journal template.

Contract
posting · synchronous
Controls
  • Authentication and authorisation
  • Integrity and replay protection
  • Correlation and audit evidence
Failure treatment
Reject an unbalanced or unknown rule before the ledger boundary.

Product journal

acct-posting-service → acct-product-ledger

Post customer and product entries atomically.

Contract
posting · synchronous
Controls
  • Authentication and authorisation
  • Integrity and replay protection
  • Correlation and audit evidence
Failure treatment
Query by business key before any retry after an uncertain response.

Settlement journal

acct-posting-service → acct-settlement-books

Record expected or confirmed external cash movement.

Contract
posting · synchronous
Controls
  • Authentication and authorisation
  • Integrity and replay protection
  • Correlation and audit evidence
Failure treatment
Preserve expected-versus-confirmed distinction when evidence is late.

Settlement confirmation

acct-external-evidence → acct-settlement-books

Update confirmed settlement only from qualifying evidence.

Contract
message · asynchronous
Controls
  • Authentication and authorisation
  • Integrity and replay protection
  • Correlation and audit evidence
Failure treatment
Quarantine duplicate, out-of-sequence, or conflicting reports.

Internal book extract

acct-product-ledger → acct-reconciliation

Provide immutable journal and balance detail.

Contract
file · batch
Controls
  • Authentication and authorisation
  • Integrity and replay protection
  • Correlation and audit evidence
Failure treatment
Stop the run when extract completeness totals fail.

Settlement-book extract

acct-settlement-books → acct-reconciliation

Provide expected and confirmed position detail.

Contract
file · batch
Controls
  • Authentication and authorisation
  • Integrity and replay protection
  • Correlation and audit evidence
Failure treatment
Keep unmatched items open by value date and currency.

External evidence feed

acct-external-evidence → acct-reconciliation

Match network and account evidence to internal expectations.

Contract
message · asynchronous
Controls
  • Authentication and authorisation
  • Integrity and replay protection
  • Correlation and audit evidence
Failure treatment
Do not infer settlement from a delivery acknowledgement.

Reconciliation break

acct-reconciliation → acct-case-reporting

Assign a classified break with its evidence.

Contract
operator · operator
Controls
  • Authentication and authorisation
  • Integrity and replay protection
  • Correlation and audit evidence
Failure treatment
Age and escalate an unowned or unresolved break.

Authored traces

Payment to balanced books

Follow a payment from its accounting trigger to a reconciled external settlement record.

  1. Authorise the accounting event — Business state confirmed. The payment transition produces one immutable accounting intent.
  2. Select the journal rule — Balanced template selected. The effective product and event rule names every debit and credit.
  3. Post once — Journal committed. The posting service commits atomically under the payment's stable business key.
  4. Update product books — Customer and product books updated. Customer liability and product entries are now booked.
  5. Receive settlement evidence — External outcome evidenced. The network status and account report are preserved with their source context.
  6. Match every layer — Reconciled. Business state, journal, settlement position, and statement agree.
  7. Close with evidence — Control closed. The close record identifies the match, reviewer, and retained evidence.

Stress cases

Duplicate accounting trigger

The same business event is delivered twice.

Last confirmed state
The first accounting intent is recorded.
Settlement
External settlement is unchanged.
Funds and entries
The first balanced journal remains authoritative.
Next owner
Core ledger engineering
Safe action
Query the posting result by business key; do not issue a second journal.
Evidence required
  • Business key
  • Event sequence
  • Existing journal reference
Recovery
  • Return the existing result
  • Record the duplicate as an operational metric

Ledger response is uncertain

The ledger commits but the response is lost.

Last confirmed state
The posting command was accepted; the response is unknown.
Settlement
External settlement may not yet have occurred.
Funds and entries
A journal may already exist.
Next owner
Core ledger operations
Safe action
Look up the immutable business key before deciding whether any replay is safe.
Evidence required
  • Ledger transaction log
  • Business key
  • Journal balance
Recovery
  • Confirm the existing journal
  • Resume downstream processing without reposting

Statement does not match the settlement book

A confirmed account entry has no matching internal expectation.

Last confirmed state
The external statement entry is authentic but unmatched.
Settlement
The statement is evidence that cash moved on the external account.
Funds and entries
Internal settlement books remain incomplete.
Next owner
Treasury reconciliation
Safe action
Open a break; do not manufacture an expectation or reverse customer books without investigation.
Evidence required
  • Original statement
  • Account and value date
  • Network references
  • Internal journals
Recovery
  • Classify the break
  • Correct through an approved journal
  • Re-run all affected reconciliations

Design decisions

When does a business state become eligible for accounting?

  • Earlier reservation — Shows exposure and available balance sooner, but needs explicit pending and release treatment.
  • Later final posting — Reduces reversals but can hide intraday exposure and customer availability.

Name reservation, pending, booked, value-dated, and settled states separately; do not overload one status.

Should reconciliation correct books automatically?

  • Rule-bound auto-correction — Can close known low-risk timing classes quickly, but every rule needs limits and audit evidence.
  • Operator-approved correction — Adds review time but is safer for ambiguous cash and material breaks.

Automate deterministic matches; require controlled approval where ownership, settlement, or financial impact is uncertain.

Sources and disclosed synthesis