ANNOTATED SAMPLE

pacs.002 payment status — rejection

The other face of the status report: a fictional negative pacs.002 rejecting a transfer before settlement — the beneficiary account is closed, so nothing has to be unwound.

Contributor Shubham Mathure16 July 2026

Illustrative, non-production example. Values are fictional and the message is not validated for any specific network, scheme, or implementation guide.

 1<?xml version="1.0" encoding="UTF-8"?>
 2<!-- Illustrative non-production data -->
 3<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.002.001.10">
 4  <FIToFIPmtStsRpt>
 5    <GrpHdr>
 6
 7
 8      <InstgAgt><FinInstnId><BICFI>DEMOGB2LXXX</BICFI></FinInstnId></InstgAgt>
 9      <InstdAgt><FinInstnId><BICFI>DEMODEFFXXX</BICFI></FinInstnId></InstdAgt>
10    </GrpHdr>
11    <OrgnlGrpInfAndSts>
12      <OrgnlMsgId>DEMO-PACS008-002</OrgnlMsgId>
13      <OrgnlMsgNmId>pacs.008.001.08</OrgnlMsgNmId>
14      <GrpSts>RJCT</GrpSts>
15    </OrgnlGrpInfAndSts>
16    <TxInfAndSts>
17      <OrgnlInstrId>DEMO-INSTR-002</OrgnlInstrId>
18      <OrgnlEndToEndId>DEMO-E2E-002</OrgnlEndToEndId>
19      <OrgnlTxId>DEMO-TX-002</OrgnlTxId>
20      <TxSts>RJCT</TxSts>
21      <StsRsnInf>
22        <Orgtr><Id><OrgId><AnyBIC>DEMOGB2LXXX</AnyBIC></OrgId></Id></Orgtr>
23        <Rsn><Cd>AC04</Cd></Rsn>
24        <AddtlInf>NON-PRODUCTION EXAMPLE - ACCOUNT CLOSED</AddtlInf>
25      </StsRsnInf>
26    </TxInfAndSts>
27  </FIToFIPmtStsRpt>
28</Document>

EVERY ANNOTATED FIELD

GrpHdr/MsgId Message identification — mandatory

A unique reference for this status report itself, assigned by the agent sending it.

GrpHdr/CreDtTm Creation date and time — mandatory

When this report was created. Several reports about the same payment can arrive as its status evolves — order matters.

⚠ Processing status reports out of order can overwrite a final status with an earlier interim one.

OrgnlGrpInfAndSts/OrgnlMsgId Original message identification — conditional

The MsgId of the payment message this report answers — the pointer back to what is being reported on.

OrgnlGrpInfAndSts/OrgnlMsgNmId Original message name identification — conditional

Which message type is being answered — for example pacs.008 including its version — so the receiver knows the definition the original followed.

OrgnlGrpInfAndSts/GrpSts Group status — optional

A status for the original message as a whole, before any transaction-level detail.

⚠ Where batches exist, a group-level acceptance does not guarantee every transaction inside survived — read the transaction level.

TxInfAndSts/OrgnlEndToEndId Original end-to-end identification — conditional

The EndToEndId of the payment being reported on, echoed back so the status can be matched to the right transaction.

TxInfAndSts/OrgnlUETR Original UETR — conditional

The unique tracking identifier of the original payment, repeated in the status report.

Tracking services correlate statuses to payments by UETR, which makes this the most reliable matching key when references collide.

TxInfAndSts/TxSts Transaction status — conditional

The status code for the payment. Common values from the ISO external code set: ACCP (accepted after basic checks), ACSP (accepted, settlement in process), ACSC (accepted, settlement completed), and RJCT (rejected).

Which positive statuses are actually sent is a matter of scheme rules and bilateral agreement — some parties report only rejections. In SCT Inst, the positive or negative pacs.002 is the make-or-break confirmation of the whole instant payment.

⚠ Treating ACSP as final. Settlement in process is not settlement completed — the difference matters when releasing funds or confirming to customers.

TxInfAndSts/StsRsnInf/Rsn/Cd Status reason code — conditional

A coded reason from the ISO external code sets explaining a rejection — account problems, regulatory reasons, technical failures, and so on.

Reason codes drive what happens next: repair and resend, route differently, notify the customer, or escalate. The EPC publishes guidance on which codes SEPA participants use for which situations.

⚠ Building workflows on the status alone and ignoring the reason forces every reject into one undifferentiated manual queue.

TxInfAndSts/AccptncDtTm Acceptance date and time — optional

When the reporting agent accepted the payment for processing — a precise timestamp for the moment the status refers to.

In time-bound schemes, this timestamp is evidence in any later dispute about whether deadlines were met.

FULL pacs.002 REFERENCE →