SEPA / Learning brief
ACK, NACK, and the Payment Status Report (pacs.002)
Your notes
In simple terms / 01
What this means in plain language
An ACK (acknowledgement) confirms a message was accepted and a NACK (negative acknowledgement) reports it was rejected, while the pacs.002 payment status report tells the sender whether the payment itself was accepted, rejected, or is still pending, with reason codes.
When a payment message is sent, the sender needs to know two different things: was the message received correctly, and was the payment itself accepted. An ACK (acknowledgement) is a positive reply that a message was received and passed basic checks; a NACK (negative acknowledgement) is the opposite, reporting that the message was rejected, usually with an error code explaining why. These operate at the network level and say nothing about whether the payment will succeed. The pacs.002, or PSR (payment status report), works at the business level. Sent in reply to a payment such as a pacs.008, it reports the payment's status, accepted, accepted and settled, pending, or rejected, and when something is rejected it carries a reason code drawn from a shared list. Keeping the two apart is important: a message can be acknowledged by the network yet still be rejected by the receiving bank for a reason such as a closed account. The pacs.002 is where that outcome is reported.
Complete lesson / 02
Understand the full idea, step by step
Think of posting a parcel. The counter clerk confirming they received your parcel is one kind of yes. The recipient signing for it days later is another kind entirely. Payments have exactly this split: a confirmation that a message was received and readable, and a separate verdict on whether the payment itself was accepted. Mixing the two up is how operations teams tell customers the wrong thing.
ACK / NAK — acknowledgement / negative acknowledgement
At the network layer, an ACK (acknowledgement) confirms that a message was received and passed technical validation — it is well-formed, authenticated, and accepted for onward handling. A NAK (negative acknowledgement) says the message was refused at that technical level: malformed, failed a structural check, or otherwise unprocessable. Both are about the envelope, not the payment. An ACK means "your message is good", never "your payment is done".
Payment status report — the business verdict on the payment, carried by pacs.002
The pacs.002 payment status report is the business layer answer: was the payment itself accepted, rejected, or still pending? Its status field carries values such as ACCP (accepted) or RJCT (rejected), and when rejected it names a reason code. This is the verdict that tells Bank Alfa whether Asha Traders' money will actually reach the supplier — a different question from whether the message was well-formed.
| ACK / NAK | pacs.002 status report | |
|---|---|---|
| Layer | Network / technical | Business / payment |
| Question answered | Was the message received and readable? | Was the payment accepted or rejected? |
| Typical values | ACK, NAK | ACCP, RJCT, PDNG (pending) |
| A negative means | The message could not be processed | The payment was refused — with a reason code |
| What a positive proves | Transport succeeded | The payment reached that business status |
ISO 20022 — ILLUSTRATIVE, NON-PRODUCTION
This pacs.002 is the business verdict. Its status field is what Maya reads to know the payment's fate; when the value is RJCT rather than accepted, a reason code accompanies it. The message references the original payment so the status attaches to the right transaction — it carries a verdict, never money.
Can a payment be accepted by the network yet still rejected as a payment?
Yes — and this is the whole point of keeping the layers apart. The network can ACK a message because it is perfectly well-formed and authenticated, while the pacs.002 that follows says RJCT because a control flagged the payment, the account cannot be credited, or a scheme rule blocks it. "The message went through" and "the payment went through" are two different facts. A clean ACK with a later RJCT is an ordinary, correct sequence, not a contradiction.
COMMON CONFUSION
“We got an ACK, so the payment succeeded — tell the customer it is done.”
An ACK only confirms the message was received and readable. The payment's fate is a separate answer that arrives in the pacs.002 status report. Treating an ACK as success is how a customer gets told "paid" for a payment that a later RJCT actually refused.
REMEMBER IT
Two yeses, two questions. ACK answers "did my message arrive?" — the envelope. pacs.002 ACCP answers "was my payment accepted?" — the contents. You need both, and you never let the first stand in for the second.
FOR NOW, REMEMBER
- ACK/NAK live at the network layer: they confirm a message was received and readable, or refused as unprocessable.
- The pacs.002 payment status report lives at the business layer: it says the payment was accepted (ACCP), rejected (RJCT), or pending.
- A payment can be network-accepted (ACK) yet business-rejected (RJCT) — the two layers answer different questions.
- Never report a payment as successful on the strength of an ACK alone; wait for the business status.
TRY IT YOURSELF
Bank Alfa's system shows an ACK for Asha Traders' payment message, and minutes later a pacs.002 with status RJCT and a reason code. What is the accurate reading?
These status messages become even more consequential when there is no overnight batch to hide a slow answer in. Next: SEPA Instant, where acceptance, settlement, and the final yes all have to happen in seconds, any hour of any day.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
An ACK (acknowledgement) and NACK (negative acknowledgement) report whether a message was received and well-formed, not whether the payment succeeded.
- 02
The pacs.002 payment status report (PSR) reports the business outcome, accepted, settled, pending, or rejected, of a submitted payment.
- 03
Rejections carry a reason code from a shared external list, so both banks read the cause the same way.
Practical use cases / 04
Where you would use this
A payments operations team watches for a NACK to learn immediately that a message was malformed and must be corrected and resent.
A bank reads the pacs.002 status to update a customer on whether a transfer was accepted, settled, or rejected.
A reconciliation process uses pacs.002 reason codes to route rejected payments to the right repair or return workflow.
Worked example / 05
Put the idea into a real situation
Illustrative example: a fictional bank, Meridian Trust, submits a pacs.008 customer credit transfer of EUR 9,750.00 to a fictional beneficiary bank, Kestrel Union Bank. The network first returns an ACK confirming the message was well-formed. Kestrel Union Bank then checks the beneficiary account, finds it was closed, and replies with a pacs.002 payment status report carrying the status RJCT (rejected) and the reason code AC04 (closed account). Because the payment had not yet settled, this is a reject rather than a return. Meridian Trust routes the EUR 9,750.00 to a repair queue, contacts the payer for corrected details, and resubmits a new pacs.008 the same day.
Evidence & review / 07
Evidence & review
ISO 20022 payment messaging generally; illustrated with the SEPA context. Exact acknowledgement mechanics depend on the network and clearing system.
What this brief simplifies: Treats the network/technical acknowledgement and the business pacs.002 as two clean layers. In practice the specific acknowledgement message and where each check runs vary by infrastructure; status and reason code values follow the ISO 20022 external code set.
Sources for this brief4
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pacs.002 FIToFI payment status report; status codes ACCP/RJCT/PDNG
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
- Official requirement
ISO 20022 External code sets ↗ — ISO 20022 Registration Authority · Transaction status and reason codes
Updated quarterly (end of February, May, August, and November) in XLSX, XSD, and JSON formats; always check the latest published version for valid codes.
- Official requirement
Business application header (BAH) ↗ — ISO 20022 Registration Authority · Business Application Header and message-level acknowledgement handling
Several BAH versions exist (head.001.001.01 through .03); each usage community, such as CBPR+, specifies which version applies.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.