pacs.028.001.05 — FI to FI Payment Status Request

ISO name	FIToFIPaymentStatusRequestV05
Registration status	Registered
Year	2019
Version	5

Overview

The 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.

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

Key data elements

• GrpHdr — Group Header with message identification and creation timestamp.
• TxInf — Transaction Information identifying the payment to enquire about.
• OrgnlGrpInf — Original Group Information referencing the source message.
• OrgnlInstrId — Original Instruction Identification from the source payment.
• OrgnlEndToEndId — Original End to End Identification for traceability.

Business context

• Lets teams ask for status on a payment that is still in flight.
• Helps operations teams investigate delayed or missing payments.
• Works with pacs.002 when a passive status update is not enough.
• Fits exception handling and SLA monitoring.

Key data elements	Business context
GrpHdr — Group Header with message identification and creation timestamp	Lets teams ask for status on a payment that is still in flight
TxInf — Transaction Information identifying the payment to enquire about	Helps operations teams investigate delayed or missing payments
OrgnlGrpInf — Original Group Information referencing the source message	Works with pacs.002 when a passive status update is not enough
OrgnlInstrId — Original Instruction Identification from the source payment	Fits exception handling and SLA monitoring
OrgnlEndToEndId — Original End to End Identification for traceability	The sending institution asks the receiving institution for the status of one payment. The answer usually comes back in pacs.002.

CBPR+ and scheme context

• Replaces older manual status-enquiry patterns.
• Links the request to the original payment identifiers.
• UETR and gpi tracking can reduce how often teams need to send it.
• Often appears in automated payment-operations tooling.

Message flow

The sending institution asks the receiving institution for the status of one payment. The answer usually comes back in pacs.002.

Version commentary

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

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

Version-diff table

Version range	Why it matters	Implementation takeaway
pacs.028.001.05	Current implementation in pacs008	Suitable for current status-request modelling.
pacs.028.001.06	Later catalogue revision	Check the newer catalogue revision for future interoperability planning.

Scheme-specific notes

• pacs.028 is the active status-request partner to pacs.002. Use it when a team must ask for status instead of waiting for an update.
• It works best when the scheme, counterparty agreement, or internal operations model defines clear timing and escalation rules.

When to use this message

Use pacs.028 when a team must ask another institution for the current status of an earlier payment.

When not to use this message

Do not use pacs.028 as a routine substitute for pacs.002 status reporting.

Implementation notes

• Send status requests only when operations needs them. Too many requests add traffic without helping resolution.
• Set timeout and escalation rules so investigations do not stall after the request is sent.
• Store the reason for the request with the original payment identifiers so the case stays auditable.

Common failure modes

• Sending the request too early.
• Using pacs.028 without a clear exception workflow.
• Not linking the answer back to the original case record.

Worked XML fragment

<FIToFIPmtStsReq>
  <GrpHdr>
    <MsgId>REQ-2026-0009</MsgId>
  </GrpHdr>
  <TxInf>
    <OrgnlInstrId>PAY-2026-8841</OrgnlInstrId>
    <OrgnlEndToEndId>E2E-INV-2026-001</OrgnlEndToEndId>
  </TxInf>
</FIToFIPmtStsReq>

Field commentary

• MsgId: The request itself needs an auditable identifier distinct from the underlying payment.
• OrgnlInstrId: Use the exact source identifier from the original instruction to maximize matching accuracy.
• OrgnlEndToEndId: Including customer traceability helps operations teams reconcile the enquiry faster.

Decision flow

Need to ask for status because unsolicited updates are not enough?
Yes -> Use pacs.028.
No -> Need to send status instead of request it?
Yes -> Consider pacs.002 instead.
No -> Keep the case in normal operational monitoring.

Compare pacs.028 vs pacs.002

Dimension	pacs.028.001.05	Comparison message
Primary purpose	Request status	Report status
Who starts the interaction	The institution asking for status	The institution sending the status
Operational posture	Exception-driven enquiry	Event-driven reporting
Wrong assumption to avoid	That it should be sent routinely for every payment	That it eliminates the need for proactive case management

Implementation FAQ

Should pacs.028 be sent after every payment?

Usually no. It works best as a targeted exception tool, not as blanket traffic.

What makes pacs.028 useful?

Clear timeout, escalation, and reconciliation rules around the original payment case.

Primary references

• ISO 20022 message definitions catalogue for pacs.028.001.05
• Swift CBPR+ ISO 20022 usage-guidelines announcement
• Swift CBPR+ migration roadmap PDF

Related messages

Message type	Description	Overview
pacs.002.001.12	FI to FI Payment Status Report	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.
pacs.008.001.13	FI to FI Customer Credit Transfer	The pacs.008 message is the main customer credit-transfer instruction between financial institutions. It carries party, amount, and remittance data.
pacs.009.001.10	Financial Institution Credit Transfer	The pacs.009 message moves funds between financial institutions on their own behalf. It supports funding, cover payments, and liquidity management.