pacs.002.001.12 — FI to FI Payment Status Report ​

ISO nameFIToFIPaymentStatusReportV12
Registration statusRegistered
Year2019
Version12

Overview ​

The pacs.002 message reports the status of an earlier payment instruction. It tells another institution whether the payment was accepted, rejected, pending, or settled.

Reviewed 23 March 2026. ISO catalogue date: 2025-02-27.

Key data elements ​

  • GrpHdr — Group Header with message identification and creation timestamp.
  • OrgnlGrpInfAndSts — Original Group Information and Status for bulk-level reporting.
  • TxInfAndSts — Transaction Information and Status for individual transaction outcomes.
  • StsRsnInf — Status Reason Information with structured reason codes.
  • OrgnlTxRef — Original Transaction Reference linking back to the source instruction.

Business context ​

  • Confirms settlement or rejection of credit transfers, direct debits, and returns.
  • Supports reconciliation between instructing and instructed agents.
  • Used in CBPR+ flows for pacs.008 and pacs.009 status reporting.
  • Supports group-level and transaction-level status reporting.
Key data elementsBusiness context
GrpHdr — Group Header with message identification and creation timestampConfirms settlement or rejection of credit transfers, direct debits, and returns
OrgnlGrpInfAndSts — Original Group Information and Status for bulk-level reportingSupports reconciliation between instructing and instructed agents
TxInfAndSts — Transaction Information and Status for individual transaction outcomesUsed in CBPR+ flows for pacs.008 and pacs.009 status reporting
StsRsnInf — Status Reason Information with structured reason codesSupports group-level and transaction-level status reporting
OrgnlTxRef — Original Transaction Reference linking back to the source instructionThe instructed agent sends pacs.002 back to the instructing agent to confirm acceptance, settlement, or rejection of a payment instruction such as pacs.008 or pacs.009.

CBPR+ and scheme context ​

  • Replaces MT199 and field 79 status text in MT messages.
  • CBPR+ mandates pacs.002 for all payment status communication.
  • Structured reason codes replace free-text rejection explanations.
  • SWIFT gpi tracking integration requires pacs.002 for end-to-end transparency.

Message flow ​

The instructed agent sends pacs.002 back to the instructing agent to confirm acceptance, settlement, or rejection of a payment instruction such as pacs.008 or pacs.009.

Version commentary ​

ISO 20022 last updated this business area on 2025-02-27. This site documents pacs.002.001.12. The latest catalogue version is pacs.002.001.15.

Use this page for the version that pacs008 implements today, and review the newer catalogue version for roadmap planning.

Version-diff table ​

Version rangeWhy it mattersImplementation takeaway
pacs.002.001.12Current implementation in pacs008Use this when matching the current project templates and validation assets.
pacs.002.001.13-15Later catalogue revisionsReview later ISO revisions before new interoperability work.

Scheme-specific notes ​

When to use this message ​

Use pacs.002 when the receiving institution needs to report the status of an earlier payment instruction.

When not to use this message ​

Do not use pacs.002 to alter settlement or reverse funds.

Implementation notes ​

  • Map external statuses into pacs.002 reason and status codes early.
  • Keep original message identifiers intact.
  • Treat pending and rejected outcomes differently downstream.

Common failure modes ​

  • Conflating technical acceptance with business acceptance.
  • Dropping transaction-level status details when a group status exists.
  • Using pacs.002 as a substitute for exception-management workflows.

Worked XML fragment ​

xml
<FIToFIPmtStsRpt>
  <GrpHdr>
    <MsgId>STS-2026-0001</MsgId>
    <CreDtTm>2026-03-01T09:15:00Z</CreDtTm>
  </GrpHdr>
  <TxInfAndSts>
    <OrgnlInstrId>PAY-2026-8841</OrgnlInstrId>
    <TxSts>RJCT</TxSts>
    <StsRsnInf>
      <Rsn><Cd>AC01</Cd></Rsn>
    </StsRsnInf>
  </TxInfAndSts>
</FIToFIPmtStsRpt>

Field commentary ​

  • MsgId: Use a new identifier for the status report itself.
  • OrgnlInstrId: Keep the original instruction identifier intact.
  • TxSts: Map this carefully to internal workflow states.
  • StsRsnInf: Structured reason codes are more useful than free text.

Decision flow ​

text
Need to communicate status of an earlier instruction?
Yes -> Use pacs.002.
No -> Need to ask another institution for status?
Yes -> Consider pacs.028 instead.
No -> Stay in the payment or exception flow.

Compare pacs.002 vs pacs.028 ​

Dimensionpacs.002.001.12Comparison message
Primary purposeReport statusRequest status
Who starts the interactionThe institution sending the statusThe institution asking for status
Operational postureEvent-driven reportingException-driven enquiry
Wrong assumption to avoidThat status reporting replaces investigation workflowsThat every payment needs an explicit status request

Implementation FAQ ​

Is pacs.002 a payment message? ​

No. It reports status for an earlier instruction rather than moving value itself.

Should pacs.002 replace internal workflow states? ​

No. It should inform them, but internal case states still need their own operational logic.

Primary references ​

Message typeDescriptionOverview
pacs.008.001.13FI to FI Customer Credit TransferThe pacs.008 message is the main customer credit-transfer instruction between financial institutions. It carries party, amount, and remittance data.
pacs.009.001.10Financial Institution Credit TransferThe pacs.009 message moves funds between financial institutions on their own behalf. It supports funding, cover payments, and liquidity management.
pacs.028.001.05FI to FI Payment Status RequestThe pacs.028 message asks another institution for the status of an earlier payment. It is a targeted status query for delayed, unclear, or missing payment updates.

Last updated: