ISO 20022 Payment Status Codes: What ACSP, ACCP, and RJCT Really Mean

ISO 20022 payment statuses are four-letter codes with precise, cumulative meanings: each rung of the accepted ladder guarantees strictly more than the one before, and only ACSC means the money actually arrived. Misreading one rung for another is how customers get told their payment landed when it is still in flight.

ISO 20022 payment status codes describe how far a payment has progressed through its lifecycle, and they travel in the status report messages: the pacs.002 between banks and the pain.002 back to the customer, the matched pair explained in PAIN vs pacs. The codes come from the standard’s external code sets, and the ones that matter daily form a short list every payments analyst should know cold, because each code is a specific guarantee, and the differences between adjacent codes, ACSP versus ACSC in particular, are exactly where customer communication and status mapping go wrong. One caveat governs everything below: schemes constrain which statuses they use and when, so the usage guidelines in scope, not the base standard, are always the final word.

The status codes, in lifecycle order

Code	Name	What it guarantees
RCVD	Received	The message arrived. Nothing has been validated yet.
ACTC	AcceptedTechnicalValidation	Syntax and schema checks passed. The message is well-formed.
ACCP	AcceptedCustomerProfile	Technical validation plus customer profile checks passed. Accepted for processing.
ACWC	AcceptedWithChange	Accepted, but the instruction was modified (for example, a corrected element). Consumers must read what changed.
PDNG	Pending	Neither accepted nor rejected: a check or dependency is outstanding.
ACSP	AcceptedSettlementInProcess	All checks passed and settlement has been ordered. Money is on its way.
ACSC	AcceptedSettlementCompleted	Settlement completed. The end of the happy path.
ACWP	AcceptedWithoutPosting	Accepted and settled toward the creditor’s bank, but not yet posted to the creditor’s account.
PART	PartiallyAccepted	For batches: some transactions accepted, some not. Consumers must inspect per-transaction statuses.
RJCT	Rejected	The payment will not proceed. Always read the accompanying reason code.
CANC	Cancelled	Cancelled before settlement, typically following a cancellation request (camt.056).

Two structural points make the table usable. First, the accepted family is a ladder: ACTC, ACCP, ACSP, ACSC each subsume the guarantees of the previous rung, so a payment reported ACSP has necessarily passed everything ACCP promised. Second, statuses exist at two levels in the report messages, the group (the whole file or batch) and the individual transaction, and PART at group level is precisely the signal that the two levels disagree, the batch fan-out reality covered in payment message flows.

Which distinctions actually cause incidents?

ACSP versus ACSC is the expensive one. ACSP says settlement is in process; ACSC says it completed. A channel that renders ACSP as “payment completed” tells the customer money arrived while it is still moving, and if the settlement leg then fails, the customer was lied to by a status mapping. The correct rendering of ACSP is “in progress,” and this single mapping decision is worth a test case in any migration. It is the ISO 20022 version of the 202-versus-200 distinction: received-and-processing is not done.

RJCT versus a return is the other. RJCT happens before settlement: the payment is refused and never moves. Money that already settled and must come back travels as a return (pacs.004), a new movement in the opposite direction, with its own reason codes, the territory of returns, reversals, and recalls. Modeling both as one generic “failed” state, a mistake called out in PAIN vs pacs, collapses two different operational realities: a rejection needs a corrected resubmission, a return needs reconciliation of money that moved twice.

RCVD versus everything after it matters at the front door. RCVD is an acknowledgment of arrival, nothing more, and it is often what a customer-facing 202 actually corresponds to. What the customer sees during the window between RCVD and a meaningful status is a real requirements decision, and the window itself is the asynchronous seam every payment platform has.

How does an analyst work with statuses in practice?

Treat the status set as a state machine and make it explicit: which statuses your platform emits, in which order, triggered by what, and which transitions are illegal, RJCT after ACSC should be impossible, and a test that proves it is blocked belongs in the pack. Then verify the ladder against reality rather than the spec: query the status column and you will routinely find statuses in the database that the documentation never mentioned, and the gap is your finding. Finally, own the mapping table from scheme status to customer-facing message with the same rigor as a reason code mapping: every status, its rendering, and the moment it is safe to say “done”, which is ACSC, and only ACSC.

The takeaway

ISO 20022 statuses travel in pacs.002 and pain.002 and form a precise ladder: RCVD acknowledges, ACTC and ACCP accept, ACSP means settling, ACSC means settled, and RJCT refuses with a reason code attached. The incidents live in the gaps between adjacent rungs, above all in rendering ACSP as final. Learn the ladder, model it as a state machine, verify it against the running system, and let the scheme’s usage guidelines arbitrate the details.