pacs.002ISO 20022

pacs.002 — FI to FI Payment Status Report

Reports the status of a previously received interbank payment message — typically a pacs.008 or pacs.009 — back toward its sender. It can accept, reject, or report intermediate statuses, with coded reasons for negative outcomes. It is the interbank sibling of pain.002: it reports on payments, it never moves money.

DIRECTION: Sent by the agent (or clearing and settlement mechanism) that received an interbank payment message, back to the agent that sent it.

Contributor Shubham Mathure16 July 2026

WHO IS INVOLVED

Instructed agent / CSMValidates the received payment message and reports acceptance, rejection, or an intermediate status, with reason codes where negative.
Instructing agentConsumes the status, updates the payment's state, and triggers repair, customer notification, or exception workflows.
Debtor agentAs the originator of the chain, ultimately learns from the status flow whether the payment reached the creditor agent — and must translate interbank statuses into customer-facing ones.

KEY FIELDS

This is a curated teaching subset — the full pacs.002 message definition contains many more elements, including instructing/instructed agent identification, original transaction references, and charges. Requirement flags summarise the single context named on each field; status reporting behaviour is heavily scheme- and agreement-specific, so check the official ISO 20022 message definition and the rules that govern your rail.

Key fields of pacs.002
FIELD	NAME	PRESENCE	WHAT IT MEANS
`GrpHdr/MsgId`	Message identification	MANDATORYBase ISO 20022 message definition	A unique reference for this status report itself, assigned by the agent sending it.
`GrpHdr/CreDtTm`	Creation date and time	MANDATORYBase ISO 20022 message definition	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	CONDITIONALBase ISO 20022 message definition — mandatory within the group-level block when that block is used	The MsgId of the payment message this report answers — the pointer back to what is being reported on.
`OrgnlGrpInfAndSts/OrgnlMsgNmId`	Original message name identification	CONDITIONALBase ISO 20022 message definition — mandatory within the group-level block when that block is used	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	OPTIONALBase ISO 20022 message definition	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	CONDITIONALBase ISO 20022 message definition — used when individual transactions are reported	The EndToEndId of the payment being reported on, echoed back so the status can be matched to the right transaction.
`TxInfAndSts/OrgnlUETR`	Original UETR	CONDITIONALBase ISO 20022 message definition — echoed when the original payment carried a UETR	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	CONDITIONALBase ISO 20022 message definition — every practical usage guideline requires a status on each reported transaction	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	CONDITIONALBase ISO 20022 message definition — expected whenever the status is negative	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	OPTIONALBase ISO 20022 message definition	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.

FIELD BY FIELD — FULL STRUCTURE

The whole pacs.002 laid out as a parent-child tree: every field in its nesting, with a sample value and what it means. Expand a branch to drill in. Values are fictional (SYNTHETIC / TRAINING ONLY); this is a curated practitioner view, not the full schema.

Document—The root of an ISO 20022 message — the business payload, which a Business Application Header (head.001) accompanies as a separate document.
- FIToFIPmtStsRpt—FI-to-FI Payment Status Report — the body of a pacs.002: one bank telling another the outcome of a payment (accepted, settled, rejected).
  - GrpHdr—Group header — data that applies to the whole message: its identity, when it was created, how many transactions it carries, and shared settlement data.
    MsgIdDEMO-PACS002-001MandatoryA unique reference for this status report itself, assigned by the agent sending it.
    Use case
    Quoted when a status report or return refers back to this whole message; changes at every interbank hop.
    Example
    DEMO-PACS008-001
    CreDtTm2026-07-12T09:01:03ZMandatoryWhen this report was created. Several reports about the same payment can arrive as its status evolves — order matters.
    Use case
    A processing timestamp for the message — distinct from the requested execution or settlement date.
    Example
    2026-07-12T09:01:00Z
    Watch out
    Processing status reports out of order can overwrite a final status with an earlier interim one.
    InstgAgt—Instructing Agent — the bank sending this message on this leg.
    FinInstnId—Financial Institution Identification — how a bank is identified, usually by its BIC.
    BICFIDEMOGB2LXXXBusiness Identifier Code (financial institution) — the 8- or 11-character BIC naming a bank.
    Use case
    The primary way a bank is identified across the chain; 8 characters for the institution, 11 to name a branch.
    Example
    DEMODEFFXXX
    InstdAgt—Instructed Agent — the bank receiving this message on this leg.
    FinInstnId—Financial Institution Identification — how a bank is identified, usually by its BIC.
    BICFIDEMODEFFXXXBusiness Identifier Code (financial institution) — the 8- or 11-character BIC naming a bank.
    Use case
    The primary way a bank is identified across the chain; 8 characters for the institution, 11 to name a branch.
    Example
    DEMODEFFXXX
  - OrgnlGrpInfAndSts—Original Group Information and Status — identifies the original message a status report refers to, and its group-level status.
    OrgnlMsgIdDEMO-PACS008-001ConditionalThe MsgId of the payment message this report answers — the pointer back to what is being reported on.
    OrgnlMsgNmIdpacs.008.001.08ConditionalWhich message type is being answered — for example pacs.008 including its version — so the receiver knows the definition the original followed.
    GrpStsACCPOptionalA status for the original message as a whole, before any transaction-level detail.
    Watch out
    Where batches exist, a group-level acceptance does not guarantee every transaction inside survived — read the transaction level.
  - TxInfAndSts—Transaction Information and Status — the status of one original transaction, keyed by its original references.
    OrgnlInstrIdDEMO-INSTR-001Original Instruction Identification — the InstrId of the transaction this status/return refers to.
    OrgnlEndToEndIdDEMO-E2E-001ConditionalThe EndToEndId of the payment being reported on, echoed back so the status can be matched to the right transaction.
    OrgnlTxIdDEMO-TX-001Original Transaction Identification — the TxId of the transaction this status/return refers to.
    TxStsACCPConditionalThe 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).
    Use case
    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.
    Watch out
    Treating ACSP as final. Settlement in process is not settlement completed — the difference matters when releasing funds or confirming to customers.
    AccptncDtTm2026-07-12T09:01:02ZOptionalWhen the reporting agent accepted the payment for processing — a precise timestamp for the moment the status refers to.
    Use case
    In time-bound schemes, this timestamp is evidence in any later dispute about whether deadlines were met.

Sources for the field structure4

Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pain/pacs/camt message-definition elements
Defines the current versions of all ISO 20022 message definitions, including the pain, pacs, and camt messages taught on this site. · Checked 2026-07-12
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
Official requirement
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group) · cross-border agent chain and structured-data usage
Defines how ISO 20022 messages (including pacs.008, pacs.009, pacs.002, pacs.004, and camt investigation messages) are used and validated for cross-border payments on the Swift network. · Checked 2026-07-12
Full guidelines require MyStandards access; content here relies on public summaries. MT-to-CBPR+ translation rules are published on Swift's translation portal.
Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · FIN block structure
Defines the MT message standards (including MT101, MT103, MT202/202 COV, and the MT9xx statement messages) exchanged over the Swift FIN network, maintained through annual standards releases. · Checked 2026-07-12
Full field-level specifications live in the Swift Knowledge Centre User Handbook behind a swift.com login; content here relies on public summaries. Swift ended MT-to-ISO 20022 coexistence for in-scope cross-border payment instructions (for example MT103 and MT202) in November 2025; MT statement messages are being phased out on a separate timeline.
Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
This site's own simplified teaching models. · Checked 2026-07-12
What this simplifies: One-line plain-language descriptions of the commonly-populated elements — a practitioner view, not the authoritative ISO 20022 / MT schema, which defines many more optional elements.
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.

COMMON ERRORS

Treating an interim positive status (ACSP) as final confirmation.Consequence: Customers are told the payment completed while settlement can still fail, producing corrections, complaints, and in the worst case funds released against money that never arrived.Avoid it: Model the status lifecycle explicitly — interim and final states are different states — and confirm to customers only on the statuses your scheme defines as final.
Not correlating the report to the original payment via OrgnlEndToEndId and OrgnlUETR.Consequence: Statuses pile up in manual queues, rejects are repaired against the wrong transaction, and instant-payment confirmations time out unmatched.Avoid it: Persist outbound references and UETRs at send time and match incoming reports on them automatically, with the UETR as the primary key.
Acting on the status code while ignoring the reason code.Consequence: A payment rejected for a fixable data error is retried unchanged and rejects again; one rejected for a regulatory reason is retried when it must not be.Avoid it: Route on the combination of status and reason: map the external reason codes to distinct repair, retry, notify, and escalate workflows.
Assuming every rail reports the same way — expecting positive confirmations where the scheme only sends rejects.Consequence: Monitoring either floods with false alarms about 'missing' confirmations or, worse, stays silent when a real one is missing.Avoid it: Configure per-rail expectations: which statuses arrive, when they are due, and what silence means on that particular rail.

USAGE CONTEXTS

SCT Inst confirmationIn SEPA instant payments, the pacs.002 is the confirmation that decides the customer outcome: the beneficiary PSP must answer positively or negatively within the execution window the rulebook defines. A positive confirmation means the beneficiary has been or will immediately be credited; a negative one carries the reject reason.
SEPA SCT rejectsIn the classic SCT scheme, pacs.002 carries interbank rejects — for example from the clearing and settlement mechanism before settlement. Positive statuses are not the norm there; the absence of a reject and the arrival of settlement do that work.
Cross-border status reporting (CBPR+)CBPR+ defines pacs.002 for interbank status reporting alongside UETR-based tracking. How much of the positive lifecycle a correspondent reports varies by agreement — never infer success purely from silence.

SEE IT IN A PLAYABLE FLOW

Sources for this reference5

Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pacs.002 FIToFIPaymentStatusReport message definition
Defines the current versions of all ISO 20022 message definitions, including the pain, pacs, and camt messages taught on this site. · Checked 2026-07-12
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 · Payment transaction status and status reason code sets
Defines the externally maintained code lists (for example category purpose, status reason, and return reason codes) referenced by ISO 20022 payment messages. · Checked 2026-07-12
Updated quarterly (end of February, May, August, and November) in XLSX, XSD, and JSON formats; always check the latest published version for valid codes.
Scheme-specific rule2025 version 1.0 (EPC115-06)
SEPA Credit Transfer Inter-PSP Implementation Guidelines ↗ — European Payments Council · Inter-PSP implementation guidelines — status report usage
Specifies how the ISO 20022 inter-PSP messages (pacs and camt) are used to implement the 2025 SCT rulebook between scheme participants. · Effective 2025-10-05 · Checked 2026-07-12
Based on version 1.1 of the 2025 SCT rulebook. Companion Customer-to-PSP guidelines cover the pain.001 initiation leg.
Scheme-specific rule
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group) · pacs.002 usage guideline
Defines how ISO 20022 messages (including pacs.008, pacs.009, pacs.002, pacs.004, and camt investigation messages) are used and validated for cross-border payments on the Swift network. · Checked 2026-07-12
Full guidelines require MyStandards access; content here relies on public summaries. MT-to-CBPR+ translation rules are published on Swift's translation portal.
Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
This site's own simplified teaching models. · Checked 2026-07-12
What this simplifies: The key-field list is a curated subset, and the status values named (ACCP, ACSP, ACSC, RJCT) are the most commonly met codes from a longer external code set. Reporting obligations differ sharply between schemes and bilateral agreements; this page describes patterns, not any single rulebook.
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.