Payment operations, exceptions, investigations, reconciliation, reporting, and case management

Canonical payment and lifecycle view

Combines business, message, rail, settlement, posting, return, and investigation states without collapsing them into one flag.

Kind

data-store

Owner

Payment platform and operations data owner

Responsibilities

• Preserve every state transition and source
• Show last confirmed state and uncertainty explicitly

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Stable identifiers
• Source precedence
• No inferred settlement from delivery

Failure modes

• Conflicting statuses
• Late event moves state backward
• Missing lineage

Recovery

• Quarantine conflict
• Rebuild from immutable events
• Escalate unresolved settlement state

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

Operational monitoring and work queues

Turns failed controls, ageing items, deadline risk, and service degradation into owned work.

Kind

application

Owner

Payment operations and service management

Responsibilities

• Prioritise by financial and customer risk
• Separate noise from an actionable payment case

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Queue completeness
• Ageing and cut-off
• Owner and escalation
• No silent suppression

Failure modes

• Alert storm
• Important item buried
• Unowned queue

Recovery

• Apply documented degradation controls
• Rebuild queue from source events
• Escalate by materiality and deadline

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

Payment case and evidence workspace

Keeps one case linked to the payment, messages, journal entries, statements, customer communication, decisions, and deadlines.

Kind

operations

Owner

Payment investigations

Responsibilities

• Create one accountable case
• Record evidence, hypothesis, action, and decision separately

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Least privilege
• Immutable audit trail
• No sensitive data in free-form exports

Failure modes

• Duplicate cases
• Evidence copied out of context
• Case closed without settlement proof

Recovery

• Merge without losing history
• Reopen from retained evidence
• Escalate data exposure

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

Repair, retry, replay, and release control

Chooses an allowed recovery action from the last confirmed business and settlement state.

Kind

control

Owner

Payment operations with product and control authority

Responsibilities

• Distinguish retry from replay, repair, reversal, return, recall, and cancellation
• Require the right authority and evidence for value-affecting action

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Idempotency
• Maker-checker
• Settlement-state guard
• Original identifier linkage

Failure modes

• Duplicate payment
• Unauthorised manual repair
• Reversal after final settlement

Recovery

• Stop further action
• Trace every attempt
• Use the applicable return or investigation process

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

Network and counterparty investigations

Exchanges status requests, cancellation requests, responses, claims, and supporting information with counterparties.

Kind

gateway

Owner

Payment investigations and correspondent operations

Responsibilities

• Choose the correct message and process
• Track request, response, timeout, and ownership

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Counterparty and route authority
• Message profile validation
• Case correlation
• Deadline

Failure modes

• Request sent to wrong party
• Duplicate recall
• Response not linked

Recovery

• Correct route with a new linked action
• Do not erase the original request

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

Payment, settlement, and account reconciliation

Matches instruction, status, settlement, posting, statement, fee, and return evidence.

Kind

control

Owner

Payments reconciliation and treasury operations

Responsibilities

• Classify timing versus financial breaks
• Keep unmatched cash and unmatched instruction distinct

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Completeness totals
• Stable matching grain
• Ageing
• No unsupported net-off

Failure modes

• False match
• Aged nostro break
• Return not linked to original

Recovery

• Undo false match
• Open a case with exact value and evidence
• Correct through approved books

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, management, and regulatory reporting

Produces accurate status, advice, statements, service metrics, incident information, and required reports from governed state.

Kind

service

Owner

Operations reporting, product, finance, and compliance

Responsibilities

• Use the authoritative state for each report
• Explain provisional, rejected, returned, recalled, and settled states plainly

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Data lineage
• Report completeness
• Access and privacy
• Revision control

Failure modes

• Customer told paid while settlement is unknown
• Statement omits correction
• Metrics hide deferred cases

Recovery

• Correct and reissue with lineage
• Notify affected owners
• Preserve the original report

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

Incident command and service recovery

Coordinates technical recovery, payment-state control, stakeholder decisions, communication, and post-incident action.

Kind

operations

Owner

Service owner and incident commander

Responsibilities

• Name one incident authority
• Separate platform recovery from payment and settlement recovery

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Situation log
• Change freeze
• Recovery checkpoint
• Business validation before reopen

Failure modes

• Systems restored but queues replay unsafely
• Conflicting teams act on the same payment
• Customer communication outruns evidence

Recovery

• Pause value-affecting automation
• Reconcile from the last consistent boundary
• Reopen in controlled stages

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

Operational event and ageing signal

ops-state-view → ops-monitoring

Create owned work from governed state and time thresholds.

Contract

event · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Rebuild the queue from source state after delivery failure.

Case trigger

ops-monitoring → ops-case

Open one case with priority, owner, and source evidence.

Contract

operator · operator

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Deduplicate without removing previous decisions.

Authorised recovery request

ops-case → ops-repair

Request a bounded repair, retry, replay, release, return, or reversal.

Contract

control · operator

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Reject action without authority or settlement evidence.

Recovery state event

ops-repair → ops-state-view

Record the action and resulting state once.

Contract

event · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Reconcile after uncertain action rather than issuing another.

Investigation or cancellation message

ops-case → ops-network-case

Exchange a correlated request with the correct counterparty.

Contract

message · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Age and escalate missing or contradictory responses.

Counterparty response

ops-network-case → ops-state-view

Add sourced external state without overwriting internal evidence.

Contract

message · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Keep contradictions visible until resolved.

Payment and posting lineage

ops-state-view → ops-recon

Provide the instruction, state, journal, settlement, and return chain.

Contract

event · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Stop matching when lineage or completeness is missing.

Reconciliation break

ops-recon → ops-case

Create a material, aged, evidence-rich financial case.

Contract

operator · operator

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Do not auto-close an unmatched cash movement.

Governed reporting state

ops-state-view → ops-reporting

Publish customer and management reporting from authoritative state.

Contract

api · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Correct reports with traceable revisions.

Incident recovery authority

ops-command → ops-repair

Constrain replay and reopening during a service incident.

Contract

control · operator

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Block bulk replay until the last consistent checkpoint is proven.

Investigate an uncertain payment

Follow an operational signal to a safe, reconciled close without guessing whether money moved.

1. Expose the uncertainty — Last confirmed state identified. The view keeps accepted, sent, delivered, settled, posted, and reported states separate.
2. Create owned work — Case required. Age, cut-off, value, customer impact, and settlement uncertainty determine priority.
3. Assemble the evidence — Investigation opened. Messages, identifiers, books, statements, and previous actions share one case.
4. Ask the right counterparty — External response pending. The correct request travels to the party that can evidence the missing state.
5. Choose the safe action — Recovery authorised. Settlement and idempotency guards decide whether repair, retry, return, or no value action is safe.
6. Reconcile every layer — Financial state aligned. Instruction, settlement, journal, statement, fee, and linked return agree.
7. Close and report — Case closed with evidence. Customer and management reporting reflect the proven final state.

Status arrives after manual action

A late network status contradicts the assumption used for a manual repair.

Last confirmed state

The manual action is recorded; the late external state is newly evidenced.

Settlement

Settlement must be re-evaluated from source evidence.

Funds and entries

There may now be two linked value movements or one duplicate attempt.

Next owner

Payment investigations

Safe action

Freeze further action and reconcile both the original and manual attempt.

Evidence required

• Original message
• Late status
• Manual action reference
• Statements and journals

Recovery

• Reconstruct the timeline
• Contain duplicates
• Use return or correction rules
• Correct reporting

Payment engine recovers before ledger

The orchestration service is healthy but posting outcome remains uncertain.

Last confirmed state

Payment processing reached the posting boundary.

Settlement

External settlement may or may not have followed.

Funds and entries

A journal may already exist.

Next owner

Incident command and ledger operations

Safe action

Keep value-affecting replay disabled until the journal and settlement boundary are reconciled.

Evidence required

• Business key
• Ledger transaction log
• Network state
• Recovery checkpoint

Recovery

• Prove journal state
• Recover downstream queues in order
• Release controlled replay

Recall is mistaken for reversal

An operator expects a cancellation request to undo a settled payment automatically.

Last confirmed state

The original payment may already be settled.

Settlement

A recall request does not itself reverse settlement.

Funds and entries

Funds remain where settlement and beneficiary posting placed them until an accepted return or other process moves value.

Next owner

Payment investigations

Safe action

Send the correct request only with authority; track the response and any separate return.

Evidence required

• Original settlement state
• Recall authority
• camt.056 or MT request
• camt.029 or response
• Return evidence

Recovery

• Record request and response
• Link any pacs.004 or other return
• Reconcile both movements

Should every technical alert create a payment case?

• Risk-based case creation — Reduces noise while retaining rules that prove why a payment needs human ownership.
• One case per alert — Maximises visibility but can bury settlement-risk work in duplicate noise.

Create cases from governed state, materiality, deadline, and financial uncertainty—not from raw log volume alone.

Who may authorise bulk replay after an outage?

• Incident command plus business control — Coordinates platform recovery with payment, ledger, and settlement evidence.
• Application team alone — Restores throughput faster but can duplicate value when downstream state is unknown.

Require a last-consistent checkpoint, idempotency proof, reconciliation plan, rollback boundary, and named business authority.