The Search for F21’s Replacement: How Payment Acknowledgements Work in the ISO 20022 World

Every SWIFT practitioner who learned MT knows what the F21 does. Almost nobody knows what replaced it in MX. This article answers the question with actual message examples.

The Question That Stayed Unanswered for Years

When I moved from implementing MT-based payment systems to building CBPR+ rails on Volpay, one of the first things I looked for was the acknowledgement message. In the MT world it was clean: send an MT103 to SWIFT, and SWIFT sends back a message with the basic header {1:F21…}. Field 451 contains a zero or a one. Zero means SWIFT has your message. One means it does not. Job done.

In the ISO 20022 world, I went looking for the equivalent. I read SWIFT rulebooks. I read CBPR+ usage guidelines. I found references to xSYS messages. But nothing pointed to a single, named ISO 20022 message that said: this is the network-level acknowledgement for a pacs.008. I asked practitioners at banks, fintechs, and consultancies across the industry. Most did not know. A few pointed at pacs.002. Others pointed at the DATA PDU with a pseudo ACK embedded inside it.

Then I looked at client implementations. Many were using the DATA PDU approach, which contains the old F21 message embedded inside it. I suspected this was a transitional arrangement and not the correct design. But I could not prove it because I did not yet understand the architecture.

The Lynx Canada rulebooks helped somewhat. They referenced xSYS messages clearly in the context of acknowledgements, but their focus was on pacs.002 as the confirmation for accounting finality, which is a different question from what I was asking.

The answer eventually came, and it is not what most people expect: there is no ISO 20022 message equivalent to the F21. The architecture changed. What was a named message type in FIN became a transport-layer event in the MX world. Once you understand why, the whole acknowledgement model becomes clear.

This article explains exactly that with real message examples at each step.

What Is a Payment Acknowledgement and Why Does It Matter?

An acknowledgement is a custody signal. It tells the sender whether the network has accepted responsibility for the message. Nothing more, nothing less.

In practice, most payment operations teams conflate three different events:

• Custody: Did the network receive and accept my message?
• Delivery: Did the network deliver it to the receiving bank?
• Settlement status: Did the receiving bank process or reject the payment?

Each is a separate event, happening at a different point in time, with different operational consequences. Treating a custody signal as proof of delivery, or treating a delivery notification as settlement confirmation, is one of the most common sources of reconciliation failure in payment back-offices.

[VISUAL 1: Three-checkpoint timeline: Custody / Delivery / Settlement with the signal that answers each]  Three different events. Three different points in time. Three different operational implications.

How FIN Handled It: The F21 Properly Explained

In the FIN world, SWIFT owned both the transport layer and the messaging standard. The network and the message format were one proprietary system. That is why everything in FIN looked like a named message type, including network signals.

What F21 Actually Is

The F21 is not a field number. It is the combination of two identifiers in the FIN basic header block:

{1:F21BANKGB2LXXXX0017000245}

• F  =  Application identifier: FIN application
• 21 =  Service identifier: the ACK/NAK service message type

When a bank sends an MT103, SWIFT’s Slice Processor validates it and immediately returns this header with a text block containing Field 451. The response is called the TIRACK (FIN), Transmission Input Received Acknowledgement. It fires within milliseconds, before any business processing.

Real F21 ACK and NAK Examples

The following are actual format examples from the SWIFT FIN System Messages specification:

F21 ACK — Message accepted (Field 451 = 0):

{1:F21VNDZBET2BXXX0001000002}
{4:{177:9703051517}
{451:0}
{108:TEST3}}

F21 NAK — Message rejected (Field 451 = 1):

{1:F21VNDZBET2AXXX0027000595}
{4:{177:9703151159}
{451:1}
{405:Y01}}

Field 177 = the Slice Processor timestamp (when SWIFT safe-stored the message). Field 451 = 0 means accepted, custody established, debit can be booked. Field 451 = 1 means rejected, with Field 405 providing the rejection reason code.

The Full MT Signal Stack

Signal	What It Tells the Bank
F21 ACK  (Field 451 = 0)	SWIFT has accepted custody. Debit can be booked.
F21 NAK  (Field 451 = 1 + Field 405)	Message rejected. Never entered SWIFT. Fix and resend.
MT010  Non-Delivery Warning	SWIFT has the message but cannot reach the receiver within the set timeframe.
MT011  Delivery Notification	Message delivered to receiver queue. Sending bank obligation met.
MT012  Sender Notification	Used in FIN Copy flows. Copy destination received and authorised.
MT019  Abort Notification	SWIFT cannot deliver. Message permanently cancelled. Rebook required.

All these signals came from a single system. Banks built their back-offices around this single-source model over decades. That is precisely why the transition to MX is not just a format change — it is an architectural change.

[VISUAL 2: MT FIN signal stack — vertical flow from MT103 send through F21 ACK/NAK branch, then MT010/011/012/019 at lifecycle points, enclosed in a single FIN system boundary]  In FIN, one system owned both transport and message format. Every network signal was a recognisable message type.

The DATA PDU: Where the Architecture Splits

In the MX world, the immediate acknowledgement a bank receives is not a named ISO 20022 message. It arrives as a DATA PDU — a structured XML document generated by SWIFT Alliance Access (SAA) middleware when it processes the SWIFTNet network response for a pacs.008 sent via FINplus.

This is a crucial architectural distinction. The DATA PDU is not generated directly by the SWIFTNet network. It is generated by Alliance Access (SAA) (the SWIFT messaging interface) , after it receives the SWIFTNet SnF (Store and Forward) acknowledgement. SAA wraps the network response into its own DataPDU format and delivers it to the bank’s back-office application.

Namespace: urn:swift:saa:xsd:saa.2.0  —  This is the SAA (Alliance Access) namespace, not SWIFTNet. The DataPDU is an SAA middleware concept. Banks using custom SNL integrations or third-party interfaces will see the raw SWIFTNet SnF response instead.

DATA PDU Example — Received for a pacs.008 on FINplus

The following is an DATA PDU example received by a bank as the acknowledgement for a pacs.008 sent on FINplus . Key elements are annotated:

<?xml version="1.0" encoding="UTF-8" ?>
<Saa:DataPDU xmlns:Saa="urn:swift:saa:xsd:saa.2.0"
  xmlns:Sw="urn:swift:snl:ns.Sw"
  xmlns:SwInt="urn:swift:snl:ns.SwInt"
  xmlns:SwGbl="urn:swift:snl:ns.SwGbl"
  xmlns:SwSec="urn:swift:snl:ns.SwSec">
  <Saa:Revision>2.0.2</Saa:Revision>
  <Saa:Header>
    <Saa:TransmissionReport>
      <Saa:SenderReference>REF ABCD1234</Saa:SenderReference>
      <Saa:ReconciliationInfo>
        swi04002-2026-06-04T08:16:12.32514.7305524Z
      </Saa:ReconciliationInfo>
      <!-- THE ACK STATUS -->
      <Saa:NetworkDeliveryStatus>NetworkAcked</Saa:NetworkDeliveryStatus>
      <Saa:OriginalInstanceAddressee>
        <Saa:X1>ABCDUSAAXXX</Saa:X1>
      </Saa:OriginalInstanceAddressee>
      <Saa:ReportingApplication>SWIFTNetInterface</Saa:ReportingApplication>
      <Saa:NetworkInfo>
        <Saa:Priority>Normal</Saa:Priority>
        <Saa:IsPossibleDuplicate>false</Saa:IsPossibleDuplicate>
        <!-- SERVICE = FINplus -->
        <Saa:Service>swift.finplus</Saa:Service>
        <Saa:Network>SWIFTNet</Saa:Network>
        <Saa:SWIFTNetNetworkInfo>
          <Saa:RequestType>pacs.008.001.08</Saa:RequestType>
          <Saa:SWIFTRef>swi04002-2026-06-04T08:16:12.32514Z</Saa:SWIFTRef>
          <Saa:SNLRef>SNL35201-2026-06-04T08:20:10.237Z</Saa:SNLRef>
          <!-- UETR OF ORIGINAL PAYMENT -->
          <Saa:Reference>fdd98f08-5fed-41f1-bfa5-04b1a7a86707</Saa:Reference>
          <!-- CUSTODY TIMESTAMP -->
          <Saa:SnFInputTime>0402:2026-06-04T08:16:12</Saa:SnFInputTime>
          <Saa:ResponsePayloadAttributes>
            <Saa:PayloadAttribute>
              <Saa:Name>type</Saa:Name>
              <!-- EMPTY RESPONSE = PURE PROTOCOL SIGNAL, NO BUSINESS PAYLOAD -->
              <Saa:Value>swift.emptyresponse</Saa:Value>
            </Saa:PayloadAttribute>
          </Saa:ResponsePayloadAttributes>
        </Saa:SWIFTNetNetworkInfo>
      </Saa:NetworkInfo>
      <Saa:Interventions>
        <Saa:Intervention>
          <Saa:IntvCategory>TransmissionReport</Saa:IntvCategory>
          <Saa:Contents>
            <Saa:AckNack>
              <!-- PSEUDO ACK/NAK: F21 FORMAT EMBEDDED FOR LEGACY BACK-OFFICE -->
              <PseudoAckNack>
                {1:F21DCBAUSBBAXXX0013830000001794}
                {4:{177:2606041118}{451:0}{311:ACK}{108:CUSTREF123}}
              </PseudoAckNack>
            </Saa:AckNack>
          </Saa:Contents>
        </Saa:Intervention>
      </Saa:Interventions>
    </Saa:TransmissionReport>
  </Saa:Header>
</Saa:DataPDU>

 Breaking down what this tells us:

• NetworkDeliveryStatus = NetworkAcked is the custody confirmation. SWIFT has accepted the pacs.008 into the SnF queue.
• Service = swift.finplus confirms this is a FINplus acknowledgement, not a FIN acknowledgement.
• SnFInputTime = 0402:2026-06-04T08:16:12 is the exact custody timestamp. This is the functional equivalent of Field 177 in the old F21. It is the moment SWIFT stored the message.
• Reference = fdd98f08-5fed-41f1-bfa5-04b1a7a86707 is the UETR of the original pacs.008. The UETR flows through to the acknowledgement.
• ResponsePayloadAttributes = swift.emptyresponse confirms there is no business response in this signal. It is a pure protocol custody confirmation.
• PseudoAckNack contains the embedded F21 format with {451:0} (ACK). This is SAA generating backward-compatible content for legacy back-office systems that still expect the old format.

The Pseudo ACK/NAK is generated by SAA middleware , not by SWIFTNet. SAA embeds the F21 structure inside the DataPDU so that bank back-office systems built to process F21 messages can continue to operate without modification. This is the transitional arrangement. The correct signal to process is NetworkDeliveryStatus + SnFInputTime, not the PseudoAckNack.

[VISUAL 3: Architecture diagram showing how SWIFT Alliance Access SAA middleware generates the DataPDU with NetworkAcked status from the SWIFTNet SnF response]

[VISUAL 3A: Layered architecture: SWIFTNet SnF response (SwInt XML) feeds into SAA middleware which generates DataPDU (urn:swift:saa:xsd:saa.2.0). DataPDU delivered to bank back-office. Label shows two layers: SWIFTNet layer and SAA middleware layer.]  The DataPDU is SAA’s output, not SWIFTNet’s direct output. This distinction matters when migrating away from SAA or using third-party interfaces.

FINplus and the New Acknowledgement Architecture

FINplus is SWIFT’s store-and-forward service for ISO 20022 messages. The FINplus Service Description states: the communication flow is delivered through the SwiftNet store-and-forward platform that guarantees delivery of emitted messages to the correspondent.

The key custody signal in FINplus is the SnFInputTime — the timestamp generated by SWIFT the moment it stores the pacs.008 in the receiver’s queue. As the real DataPDU example above shows, this appears in the Saa:SnFInputTime element when SAA surfaces it to the bank application. For banks using Alliance Access, the DataPDU containing NetworkAcked and SnFInputTime is the practical equivalent of the F21 ACK.

There is no named ISO 20022 message that functions as the F21 ACK. The custody signal is a transport-layer event. In practice, Alliance Access banks see this as the DataPDU with NetworkDeliveryStatus = NetworkAcked. Banks using other interfaces or direct SNL connections will see the raw SWIFTNet SnF response in SwInt XML format.

The xSYS Messages: System-to-Participant Signals

The xSYS messages are proper ISO 20022 messages  with Business Application Header (head.001), Document element, ISO 20022 namespace, and published XSD. But they are generated by SWIFT’s own infrastructure (the SWIFTNet service layer or Transaction Manager) and sent to participants. They are system-to-participant signals, not bank-to-bank business messages.

xSYS Message	Function	MT Equivalent
xsys.010	Non-Delivery Warning	MT010
xsys.011	Delivery Notification (must be requested)	MT011
xsys.012	Failed Delivery / Abort Notification	MT019
xsys.001 to xsys.003	Y-Copy authorisation / refusal	MT096 / MT097
xsys.008 / xsys.009	Queue Status Request / Report	MT074 / MT075
xsys.015 / xsys.016	Retrieval Request / Report	MT020 / MT021

An important point on xsys.011: it is the Delivery Notification — the equivalent of MT011 — not the custody ACK. It arrives later, after SWIFT has successfully delivered the pacs.008 to the receiver’s queue. It must be explicitly requested. Without the configuration, no xsys.011 is generated even if delivery succeeds.

In Alliance Access implementations, the delivery notification does not arrive as a standalone xsys.011 message. It arrives as a DataPDU with <Saa:DeliveryNotification> as the header type , the same DataPDU container used for the TransmissionReport ACK, just with a different inner header. The xsys.011 is what exists at the SWIFTNet layer; SAA wraps it in DataPDU format for the partner application, exactly as it wraps the network ACK in TransmissionReport format.

[VISUAL 4: Side-by-side MT vs MX signal mapping. Left: F21 ACK, MT010, MT011, MT019. Right: DataPDU NetworkAcked (SnFInputTime), xsys.010, xsys.011, xsys.012. Arrows connecting equivalents. Red annotation on F21 row: ‘No named ISO 20022 equivalent’.]  The F21 custody function is now a transport-layer event surfaced through the DataPDU. The delivery lifecycle signals became ISO 20022 xSYS system messages.

Transaction Manager: The New Actor in the Acknowledgement Story

In the MT world, SWIFT’s role was to deliver messages. The network validated format, ensured security, and routed to the correct destination. It did not apply business rules to payment content.

Transaction Manager changed that.

Transaction Manager (TM) is SWIFT’s built-in processing engine for CBPR+ cross-border traffic. It sits between sender and receiver and applies business-level validation after the network custody ACK. Understanding TM is essential to acknowledgements in MX because it introduced a second point where a message can succeed or fail , after custody has already transferred.

The Two-Stage Processing Model

Stage 1 is network validation. When a pacs.008 enters FINplus, the network validates format, schema compliance against CBPR+ usage guidelines, UETR uniqueness, and RMA relationship. Fail here and the bank receives a NAK in the DataPDU (NetworkDeliveryStatus = NetworkNacked). No custody. Fix and resend.

Stage 2 is Transaction Manager validation. After the network ACK, TM applies business rules. Three outcomes are possible:

TM Outcome	What Happens	Signal to Sender
Processed	TM validates, applies data integrity rules, routes message to receiver	xsys.011 Delivery Notification (if requested)
Bypassed	TM cannot apply rules — delivers via sender’s original channel without TM enrichment	No abort — receiver still gets the message
Aborted	TM finds irreconcilable business inconsistency — message not delivered	xsys.012 with TM-specific error code

It is possible to receive a positive DataPDU (NetworkAcked) and then receive an xsys.012 abort from Transaction Manager. SWIFT accepted the message and confirmed custody. Then TM found a business problem it could not resolve. These are two separate events in time, and back-office systems that treat NetworkAcked as a final success signal are wrong by design.

When Does TM Abort?

TM aborts occur almost exclusively in cover payment scenarios — where a pacs.008 and pacs.009 COV carry mismatched data elements, or where the wrong message type is used in a cover flow. For straightforward single-leg pacs.008 customer credit transfers, TM aborts are rare. Most TM issues result in bypass, not abort.

When TM aborts, it generates xsys.012 with specific error codes (Sw.TM.xxx, SwGbl.xxx). For FIN senders, the MT019 abort carries service code {619:TMR} identifying TM as the source. TM also adds a TDOK indicator in the InterAct header of messages it successfully processes and delivers, so the receiving bank knows the payment has been governed by TM’s data integrity rules.

[VISUAL 5: Two-stage flow: pacs.008 → Stage 1 Network Validation (pass = DataPDU NetworkAcked, fail = DataPDU NetworkNacked) → Stage 2 TM (Processed = delivery + optional xsys.011, Bypassed = delivery no TM, Aborted = xsys.012). Custody boundary line between Stage 1 and 2.]  After the DataPDU NetworkAcked, Transaction Manager applies business validation. A NetworkAcked followed by xsys.012 is a real scenario requiring its own exception path.

CBPR+ vs Domestic Rails: Where pacs.002 Fits

The network signals — DataPDU NetworkAcked, xsys.010, xsys.011, xsys.012 — are the same whether a payment travels over CBPR+ or a domestic RTGS. What differs is the business-level status signal.

In CBPR+ Correspondent Banking

The receiving bank sends a pacs.002 back to the originating bank as a payment status report. In the Transaction Manager Service Description, pacs.002 positive is described as an optional CBPR+ supported message that is bilateral in nature and not processed by TM. In practice, pacs.002 negative (RJCT) is the consistent use case. For positive status, the Universal Confirmations framework active since Standards Release 2022  requires SUPE and PSPA institutions receiving pacs.008 on FINplus to confirm the outcome, driving broader adoption of positive status reporting.

In all cases, pacs.002 in CBPR+ is a business-level payment status message. It is not the network ACK. It is sent by the receiving bank, not by SWIFT.

In Domestic RTGS and Clearing Systems

In domestic RTGS schemes, the RTGS infrastructure acts as the system operator. The Y-Copy mechanism  which uses xsys.001 through xsys.003 for authorisation and refusal flows gives the RTGS the ability to intercept and control payment instructions before they reach the receiver. When the RTGS settles a payment, it generates a pacs.002 as the settlement result. This pacs.002 carries legal weight in the domestic context: it is the settlement finality confirmation. In this context it functions differently from the bilateral pacs.002 in CBPR+. Copy services and RTGS flows will be covered in detail separately.

A pacs.002 from a CBPR+ correspondent is a payment status report. A pacs.002 from an RTGS is the settlement event. They carry different operational weight and must be handled differently in booking logic.

What Actually Changed in System Design

1.  The Custody Signal Is No Longer a Named Message Type

In MT: the back-office received an F21 message and parsed Field 451. In MX: Alliance Access delivers a DataPDU and the correct field to parse is Saa:NetworkDeliveryStatus = NetworkAcked, combined with Saa:SnFInputTime as the custody timestamp. The structure is different. The semantic is the same. Back-offices that process the PseudoAckNack Field 451 inside the DataPDU are using backward-compatible content and missing the native MX signals.

2.  NAK Error Codes Changed

F21 NAK codes (H-codes, Y-codes) do not map directly to FINplus NAK codes (SwiftNet Sw.xxx error codes). The PseudoAckNack collapses this distinction. Processing the native DataPDU allows exception routing by error code category: format errors, UETR errors, RMA errors, CBPR+ usage guideline violations, each routed to the correct queue automatically.

3.  Delivery Notification Is Now Opt-In

In FIN, MT011 behaviour was configured at service level. In FINplus, delivery notification must be explicitly requested. Payment flows requiring confirmed delivery to the receiver’s queue must specify this as a functional requirement. Without the configuration, no xsys.011 is generated even when delivery succeeds.

4.  Abort Handling Requires Three Paths, Not One

MT019 meant one thing: rebook. xsys.012 in MX means three things:

• Network delivery failure (Sw.SnF.xxx codes): message expired or max retries reached. Rebook.
• TM abort in cover scenario (Sw.TM.xxx codes): investigate message consistency before rebooking. All subsequent legs for the same UETR bypass TM.
• TM delivery failure after processing: investigate the transaction copy state first. Do not rebook blindly.

A single abort-equals-rebook rule is incorrect in the MX world. Error code categorisation is the new operational discipline.

5.  UETR Is the New Correlation Reference

In MT, systems correlated acknowledgements using MIR (Message Input Reference) and MUR (Message User Reference). In MX, the UETR is the primary end-to-end reference. As the real DataPDU example shows, the UETR appears as Saa:Reference in the acknowledgement, confirming it flows from the original pacs.008 through to the custody signal. All internal systems must carry the UETR through the full transaction lifecycle.

The Transition State: Where Banks Are Today

November 2025 marked the end of the MT coexistence period for interbank payment messages. Network-level migration is complete. Back-office migration is not.

State	Description	Risk
State 1: Native MX	Back-office parses DataPDU NetworkDeliveryStatus and SnFInputTime natively. UETR is the primary correlation reference. xsys.012 errors categorised by error code. Delivery notification configured per flow.	Low — correct design
State 2: PseudoAckNack Dependent	Back-office parses Field 451 inside the PseudoAckNack element. Functional but misses native MX error codes and UETR correlation. xsys.012 aborts not differentiated by source.	Medium — reconciliation gaps and imprecise exception routing
State 3: FIN Still Active for Some Flows	Some message types remain on FIN. TM interoperability means FIN senders may trigger TM processing. MT019 aborts from TM carry {619:TMR} which most legacy systems do not parse, making TM aborts invisible.	High — TM aborts invisible to back-office

Frequently Asked Questions

▶  Watch the Full Walkthrough on YouTube

https://youtu.be/l6bI_8wkIFM

Prefer video? Full walkthrough on the PaymentTalks YouTube channel. Link above.