No single MT equivalent ↔ pacs.002
1 pair on this page · Use case: Status
Business purpose
pacs.002 (FIToFIPaymentStatusReport) is sent by an instructed agent to the previous party in the payment chain to report the outcome of a payment instruction — a CBPR+-mandatory negative/rejection status (RJCT), plus an optional set of positive/interim status codes used bilaterally (RCVD, ACTC, ACCP, ACWC, ACSP, ACSC, ACWP, ACCC, PDNG).
What does NOT map cleanly
No designated pre-ISO-20022 MT business equivalent exists. The legacy workaround for rejection was to return the same original MT103/MT202 message, unchanged, with a reject code inserted into free-text field 72 — reusing the payment message itself as an ad hoc status carrier, not a separate status message. MT199 (a Category 1 Free Format Message with no fixed schema or status-code taxonomy) was and still is used ad hoc for status communication — J.P. Morgan states it will continue using MT199 'in most instances' to reject CBPR+ transaction legs while migrating to pacs.002 'as industry adoption increases,' which is itself evidence MT199 is a stopgap, not a designated equivalent. MT012 (Sender Notification) and MT019 (Abort Notification) are SWIFT FIN network-layer system messages confirming whether the network accepted or aborted delivery of a message — they answer 'did my message reach the network,' not 'did the receiving bank accept, execute, or reject the payment,' and must not be presented as business-level status equivalents. A pacs.002 does not move funds and cannot itself be used to initiate a return — that is pacs.004's job.
Migration notes
CBPR+ makes the negative pacs.002 (RJCT) mandatory as the only sanctioned way to notify a sender that a payment was rejected. Despite the mandate, MT199 workarounds persist in practice during the transition, per J.P. Morgan's own stated approach.
Sources
- BNY — ISO 20022 Learning Guide Module 6: A Deep Dive on pacs.004 & pacs.002 ·Today, there is no dedicated FIN equivalent of the pacs.002 message. To perform a rejection of an MT103 or MT202, an agent would return the original message to the sender using the reject code in Field 72. RJCT is mandatory as per CBPR+ rules — meaning it is the only way the sender should be informed that the transaction has been rejected. (confirmed)
- J.P. Morgan — ISO 20022 FAQs ·J.P. Morgan will continue to use the MT199 in most instances to reject payment requests for CBPR+ transaction legs, moving to the pacs.002 negative Customer Status Report as industry adoption increases; a pacs.004 is a movement of funds, whereas pacs.002 is a rejection message and does not create a funds movement, and it is not permitted to initiate a return with a pacs.002 (confirmed)
- Axway — SWIFT FIN connectivity technical documentation (secondary/vendor corroboration; SWIFT's own primary FIN System Messages handbook was not directly accessible for this entry) ·MT012 (Sender Notification) and MT019 (Abort Notification) are SWIFT FIN network system messages confirming message receipt/abort at the network transport layer, distinct from a business-level payment status report — consistent with SWIFT's general ACK/NAK mechanism, where an ACK is a notification that the FIN interface accepted the message as valid and entered it into the network, not confirmation that the underlying payment was executed (estimated)