Asks another financial institution for the status of a previously sent payment, direct debit or eligible related instruction. It requests a status report; it neither changes the payment nor proves an outcome.
DIRECTION: Sent by one agent to another, directly or through a clearing and settlement system, under a bilateral or scheme agreement that supports the request.
Version + profile: pacs.028 is a message-family identifier, not a complete version. The numeric .001.xx definition and field rules depend on the scheme, service, usage guideline, and implementation version named in each context; sample namespaces show only the illustrated version.
EVIDENCE AT ARM'S REACH
Start with the exact message version, then apply the scheme or network profile that governs your implementation.
An XSD checks XML structure. A usage guideline adds profile rules, conditional fields, code restrictions, and business controls. XSD-valid does not mean scheme-compliant.
Fedwire message versions, usage guidelines, implementation guidance, testing material, and the controlled route to proprietary schemas.
Curated field requirements, contexts, operational meaning, and implementation cautions.
crc32:4b947ac9Verified profile constraints with versioned evidence and explicit operating conditions.
crc32:6f8b5902Positive and negative lifecycle tests linked to verified profile rules.
crc32:3b72999aDiscovery, controls, testing and operational-readiness checks for the profile.
crc32:d31e7e73Outcome-focused profile acceptance criteria with honest release gates.
crc32:0bf84f8fVersion, transformation, cutover and reconciliation controls.
crc32:e22fb314Evidence that must be obtained from the owner before production readiness can be claimed.
crc32:3955f552Generated mapping, field-matrix, test, checklist, acceptance-criteria, migration, manifest, checksum, and source-inventory bundle.
crc32:b811f27bCurated teaching subset. ISO defines the message, but its use is governed by a bilateral agreement, scheme or service profile; do not assume every rail accepts unsolicited pacs.028 requests.
| FIELD | NAME | PRESENCE | WHAT IT MEANS |
|---|---|---|---|
GrpHdr/MsgId | Message identification | MANDATORY | Unique reference for the status request. |
GrpHdr/CreDtTm | Creation date and time | MANDATORY | When the requester created the status request. |
OrgnlGrpInf/OrgnlMsgId | Original message identification | CONDITIONAL | Identifies the original message group whose status is requested. |
OrgnlGrpInf/OrgnlMsgNmId | Original message name | CONDITIONAL | Identifies the ISO message definition of the original instruction. |
TxInf/StsReqId | Status request identification | OPTIONAL | Reference for a transaction-level status request. |
TxInf/OrgnlInstrId | Original instruction identification | CONDITIONAL | Identifies the original transaction at instruction level. |
TxInf/OrgnlUETR | Original UETR | CONDITIONAL | Network reference used to locate the original payment where present. |
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pacs.028 FIToFIPaymentStatusRequest message definition
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
Payments Signal editorial teaching models — Payments Signal
What this simplifies: One group/transaction status-request use case; bilateral service rules are omitted.
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.
Share an operational observation or ask a concrete payments question. Your name and message are public; your email remains private.
Loading the discussion…