Payment State Machine Simulator

One payment, USD 25,000 from a London corporate to Tanaka Trading Pte Ltd in Singapore, reference INV-8841, payment ID PAY-20261105-8841, UETR a3e1f2b4-5c6d-4a7e-9b1c-2d3e4f5a6b7c. The machine starts at Received. Click any state to see what it means, what event caused entry, what data is held, what happens next, and what can go wrong. Then fire events from the injector and watch the machine accept the event or reject it with a reason.

Four states look alike and are not the same. Accepted is message acknowledgement: the payment passed technical validation (ACTC) and customer-profile checks (ACCP), usually confirmed by pacs.002 ACCP, and no money has moved. Clearing Accepted is settlement in process: the clearing system took the message into its cycle and settlement is in process, usually with pacs.002 ACSP, and still no money has moved. The full ladder is ACTC, ACCP, ACSP, ACSC, ACCC, in that order. Settled is settlement finality: value moved finally and irrevocably between banks. Credited is beneficiary credit: the beneficiary bank posted the funds to the beneficiary account. Acceptance is not settlement, and settlement is not beneficiary credit.

Current state: Received

Main flow

Flow order: Received, Validated, Accepted, Clearing Accepted, Settled, Credited, Reconciled. Queued and Held sit on side paths off Accepted and Validated.

Exception states

Received

What it means. The payment instruction has arrived at the hub and is recorded, but nothing has been checked yet.

What caused entry. Customer submits the instruction through a channel. The hub records it with a payment ID.

What data is held. Instruction reference, debtor and creditor details, amount, currency, value date, idempotency key.

What happens next. Validation runs. A pass moves it to Validated, a fail moves it to Rejected, a duplicate match moves it to Duplicate.

What can go wrong. An unvalidated payment could carry a wrong account or amount, so no funds move from this state.

Event injector

Fire an event. If it is valid from the current state, the machine moves and tells you why. If it is invalid, the machine stays put and tells you why the event cannot fire here.

Recovery and investigation events: these complete the machine so a held, queued, credited or unknown payment can finish.

No event fired yet. The machine is at Received. Try "validate OK" to move to Validated, or try "settlement confirm" to see an invalid event rejected with its reason.

Out-of-order events

Messages do not always arrive in order. These demos show what the system does when an event arrives before the event it depends on.

Duplicate instruction handling

The same instruction can arrive twice, for example when a channel retries after a timeout. The idempotency key decides whether it is a new payment or a duplicate.

Timeout and unknown outcome

When a confirmation never arrives, the payment moves to Unknown. The bank must investigate before it acts, because the money may already have moved.

Event log

Machine starts at Received. Payment PAY-20261105-8841 created.

Valid transitions

Current state	Event	Next state	Why it is valid
Received	validate OK	Validated	The instruction passes structural and business validation, so the payment can move to screening.
Received	validation fail	Rejected	A validation check fails, for example an invalid BIC, so the payment is rejected before any funds move.
Received	duplicate detected	Duplicate	The idempotency key or reference matches an earlier payment, so this instruction is a duplicate and is dropped.
Validated	screening clear	Accepted	Screening returns clear, so the payment is accepted for processing.
Validated	screening hit	Held	Screening finds a possible match, so the payment is held for manual review.
Validated	validation fail	Rejected	A late business validation fails, so the payment is rejected.
Held	screening clear	Accepted	Compliance reviews the match and clears it as a false positive, so the payment is accepted.
Held	screening hit confirmed	Rejected	Compliance confirms the match, so the payment is blocked and rejected.
Accepted	correspondent offline	Queued	The selected correspondent cannot accept the message, so the payment waits in the queue.
Accepted	clearing accept	Clearing Accepted	The clearing system accepts the message for its clearing cycle.
Accepted	clearing reject	Rejected	Clearing rejects the message, so the payment is rejected.
Queued	correspondent back online	Accepted	The correspondent returns, so the queued payment goes back to Accepted and is sent on.
Queued	timeout	Expired	The queued payment's window closed before it was ever sent, so nothing moved and the outcome is known: it expired un-sent. It is not Unknown, because Unknown is only possible after transmission.
Clearing Accepted	settlement confirm	Settled	Settlement posts finally and irrevocably, so the payment is Settled.
Clearing Accepted	settlement timeout	Unknown	No settlement confirmation arrives in time, so the outcome is unknown.
Clearing Accepted	clearing reject	Rejected	Clearing withdraws its acceptance, so the payment is rejected.
Settled	beneficiary credit confirm	Credited	The beneficiary bank posts the funds to the supplier account.
Settled	credit fail	Returned	The beneficiary bank cannot credit the account, so the creditor agent returns the funds via pacs.004 (for example AC04, closed account) and the payment is Returned, with the funds back with the originator.
Credited	reconciliation match	Reconciled	End of day reconciliation matches instruction, clearing, settlement and ledger, so the payment is Reconciled.
Credited	recall received	Recalled	The originator recalls the payment and the beneficiary bank agrees, so the payment is Recalled.
Unknown	investigation finds settled	Settled	The investigation proves settlement posted, so the payment is Settled.
Unknown	investigation finds failed	Failed	The investigation proves settlement never posted, so the payment is Failed.
Accepted	timeout	Expired	The accepted payment's window closed before it was sent, so nothing moved and the outcome is known: it expired un-sent. Unknown is only possible after transmission.
Settled	recall received	Returned	The originator sends a camt.056 cancellation request before the beneficiary is credited, and the creditor agent returns the funds via pacs.004, so the payment is Returned.
Clearing Accepted	timeout	Unknown	No settlement confirmation arrives in time after the payment was sent to clearing, so the outcome is unknown until a pacs.028 investigation proves it.

Invalid transitions

Current state	Event	Why it is invalid
Received	settlement confirm	Settlement needs clearing acceptance first. A payment that has only just been received has not been accepted by clearing, so there is nothing to settle.
Received	clearing accept	Clearing acceptance comes after the payment is accepted and routed. A newly received payment has not reached clearing yet.
Received	beneficiary credit confirm	Beneficiary credit needs settlement first. Nothing has settled, so there is no credit to confirm.
Validated	settlement confirm	The payment is validated but not yet accepted, and clearing has not accepted it, so settlement is impossible.
Validated	clearing accept	Clearing accepts only a payment that has been accepted for processing. Validation alone is not acceptance.
Accepted	settlement confirm	Cannot settle a payment that has not been accepted by clearing. Clearing acceptance must come first.
Accepted	beneficiary credit confirm	Beneficiary credit needs settlement finality first. An accepted payment has not settled.
Queued	settlement confirm	A queued payment has not been sent to clearing, so it cannot settle.
Clearing Accepted	beneficiary credit confirm	Beneficiary credit needs settlement first. Clearing acceptance is not settlement.
Settled	clearing accept	The payment is already past clearing. Clearing acceptance belongs before settlement, not after it.
Credited	settlement confirm	The payment already settled before it was credited. Settlement cannot happen twice.
Reconciled	any event	Reconciled is terminal. The payment is complete and closed. A new payment needs a new instruction.
Rejected	validate OK	Rejected is terminal for this instruction. A rejected payment is not revived as the same message. But an internal validation or screening hold that is repaired (corrected BIC, completed mandatory field) is re-released as a NEW instruction with a fresh InstrId and the same EndToEndId; an interbank RJCT after sending normally needs a new instruction from the customer.
Duplicate	validate OK	Duplicate is terminal. The duplicate was dropped. Only the original payment continues.
Failed	settlement confirm	Failed is terminal. The payment did not settle and will not settle now. A new instruction is needed.
Unknown	clearing accept	An Unknown payment must be investigated first. Clearing acceptance cannot be applied until the investigation proves where the payment stands.
Held	settlement confirm	A held payment is waiting on a screening decision. It cannot settle while compliance still holds it.
Expired	any event	Expired is terminal. The payment window closed with no answer, so the payment is closed.
Received	timeout	Timeout to Unknown is impossible from Received: nothing has been sent, no funds have moved, and the outcome is known (not sent). A payment that is never sent expires or is cancelled, it does not become Unknown.
Validated	timeout	Timeout to Unknown is impossible from Validated: nothing has been sent, so the outcome is known (not sent).
Held	timeout	Timeout to Unknown is impossible from Held: nothing has been sent, so the outcome is known (held, not sent). A held payment that passes its deadline is failed or expired, not Unknown.
Accepted	timeout	Timeout to Unknown is impossible from Accepted before transmission: if nothing was sent, the outcome is known (not sent) and the payment expires. Unknown is only possible after the payment was sent.
Settled	credit fail	Credit failure after settlement does not send the payment to Failed: the creditor agent returns the funds via pacs.004 and the payment moves to Returned.
Credited	return received	A return cannot happen after credit. A return (pacs.004) is what the creditor agent sends when it CANNOT credit, i.e. before credit. After credit, funds come back only by recall (camt.056) with the beneficiary bank's agreement.