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

---

Article Update — The Search for F21’s Replacement

Updated August 2026 — The following section has been added in response to questions from readers and practitioners following original publication. Part A covers three additional points sourced directly from the Alliance Access 7.8.60 Configuration Guide (SWIFT, January 2026). Part B adds a new section — requested explicitly by a reader — on what the SWIFTNet network actually sends, and how the gateway layer converts it before the back-office sees anything.

Part A — Three Points from the Alliance Access 7.8.60 Configuration Guide

The Alliance Access 7.8.60 Configuration Guide, published by SWIFT in January 2026, provides documentary confirmation on three points that extend what the original article covered about the DataPDU and PseudoAckNack.

A1.  NetworkDeliveryStatus Carries Seven Values, Not Two

The original article described NetworkAcked and NetworkNacked as the two states a bank’s back-office monitors in the DataPDU TransmissionReport. The Configuration Guide documents seven possible values:

NetworkDeliveryStatus Value	What It Means Operationally
NetworkAcked	SWIFT accepted custody of the message. SnFInputTime is set. Debit can be booked.
NetworkNacked	SWIFT received the message and rejected it. Message entered the network but was refused.
NetworkRejectedLocally	Alliance Access rejected the message before sending it to SWIFT. Message never left the bank’s middleware.
NetworkAborted	Transmission started but a communication error occurred before the ACK was received. Outcome unknown.
NetworkTimedOut	Message sent but no ACK received within the allowed time. Outcome unknown.
NetworkWaitingAck	Transient state — emission is in progress.
Network_N_A	Alliance Access has not yet attempted to send the message.

The distinction that matters most operationally is between NetworkNacked and NetworkRejectedLocally. NetworkNacked means SWIFT received the message and rejected it at the network level — the message physically reached SWIFTNet. NetworkRejectedLocally means Alliance Access itself blocked the message before emission — it never left the bank’s infrastructure and SWIFT has no record of it. These require entirely different exception paths: one is a SWIFT-side rejection requiring investigation of the message content against CBPR+ rules; the other is a local middleware configuration or format issue that never involved SWIFT.

NetworkAborted and NetworkTimedOut are grey-zone states. In both cases the message was dispatched toward SWIFT but the custody outcome is genuinely unknown. These are investigation scenarios, not rebook scenarios. Rebooking without confirming outcome risks duplicate payment.

A2.  PseudoAckNack Is a Configurable Parameter, On by Default for Upgrades

The PseudoAckNack is not automatically included in every DataPDU. It is controlled by a named configuration parameter in Alliance Access called Include PseudoAckNack. The Configuration Guide documents its default values as:

• Yes — for banks upgrading from an existing Alliance Access installation
• No — for banks on a fresh Alliance Access installation

This is the precise explanation for a pattern visible across the industry: banks that migrated from older Alliance Access versions still receive the PseudoAckNack because the upgrade preserved the existing setting. Banks on new MX-native Alliance Access installations do not receive it by default. The switch was left on for upgraders and is off for new deployments.

For banks on an upgrade path that want to complete their transition to native MX processing: turning off Include PseudoAckNack in Alliance Access is the specific configuration change that ends reliance on the backward-compatibility layer. The back-office must then be updated to process NetworkDeliveryStatus and SnFInputTime natively before making this change.

There is also a secondary parameter, Include PseudoAckNack/BIC, which allows generation to be controlled at per-BIC8 granularity. This enables a phased transition where PseudoAckNack is disabled for specific counterparty BICs while remaining active for others.

A3.  SWIFT Explicitly States That PseudoAckNack Does Not Require Processing

The Configuration Guide contains this statement directly in the section describing the AckNack element:

“These are Alliance Access or SwiftNet specific data elements that Alliance Access provides to the application for completeness. Further processing of these elements is not required.”

The same section confirms that the AckNack element containing the PseudoAckNack is not defined in the official DataPDU XSD schema. The schema for the DataPDU is at SAA_XML_v1_0.xsd within the Alliance Access release tree. PseudoAckNack sits outside it.

This is the authoritative documentary position: SWIFT’s own product documentation tells banks not to build processing logic on the PseudoAckNack. It is a convenience artefact for backward compatibility, not a signal designed for machine processing. The correct signals to process are NetworkDeliveryStatus and SnFInputTime in the TransmissionReport.

Part B — What SWIFTNet Actually Sends: The Gateway Layer Explained

A reader asked a precise question after the article was published: if Alliance Access generates the DataPDU and creates the PseudoAckNack, what does Alliance Access actually receive from SWIFTNet? And what is the role of the gateway in the picture?

This section answers that question completely, including what happens when a bank uses a different gateway product — such as Bottomline Technologies, common in North American banking.

VISUAL 6: The bank’s back-office never speaks to SWIFTNet directly. It speaks to the gateway. The gateway translates.

B1.  The Gateway Layer: What It Is and Why It Exists

Between SWIFTNet and a bank’s back-office sits a gateway. This gateway is responsible for:

• Connecting to SWIFTNet using the SWIFTNet Link (SNL) API
• Receiving raw SWIFTNet responses in SWIFT’s proprietary network namespaces
• Converting those responses into a format the back-office understands
• Surfacing messages, notifications, and acknowledgements to the payment engine

The two most widely deployed gateways globally are SWIFT’s own Alliance Access (SAA) and Bottomline Technologies’ SWIFT connectivity platform. Both absorb the same SWIFTNet signals. Both translate them into their own formats. Neither passes SWIFTNet’s raw SNL structures directly to the back-office.

B2.  What SWIFTNet Actually Sends

SWIFTNet uses two proprietary XML namespaces for its network-level signals. These are defined in the SWIFTNet Link (SNL) API:

• Sw: — urn:swift:snl:ns.Sw — for store-and-forward delivery notifications
• SwGbl: — urn:swift:snl:ns.SwGbl — for status and error reporting

There are three distinct signals SWIFTNet sends to the gateway:

Signal 1: Custody ACK — Message Accepted by SWIFTNet SnF

When SWIFT stores a pacs.008 in the receiver’s SnF queue, there is no explicit ACK message sent. The custody confirmation is the presence of SnFInputTime in the SnF response at the SNL layer. Its presence means SWIFT has accepted responsibility for delivery. Its absence, or the presence of a fatal SwGbl:Status, means rejection.

Signal 2: Network NAK — Message Rejected by SWIFTNet

When SWIFT rejects a message, the gateway receives a SwGbl:Status structure:

<SwGbl:Status>
  <SwGbl:StatusAttributes>
    <SwGbl:Severity>Fatal</SwGbl:Severity>
    <SwGbl:Code>Sw.Gbl.NetworkTransmissionError</SwGbl:Code>
    <SwGbl:Text>error description</SwGbl:Text>
    <SwGbl:Action>Retry Message</SwGbl:Action>
    <SwGbl:Details>
      <SwGbl:Code>specific error code</SwGbl:Code>
    </SwGbl:Details>
  </SwGbl:StatusAttributes>
</SwGbl:Status>

This is SWIFTNet’s native rejection format. No F21. No field 451. No field 405. SWIFT communicates rejection through SwGbl:Severity (Fatal or Transient) and SwGbl:Code.

Signal 3: Delivery Notification — Receiver Accepted or Rejected

After the message is delivered to the receiver’s queue and the receiver responds, SWIFTNet sends this structure to the gateway:

<Sw:NotifySnFRequestHandle>
  <Sw:SnFRef>SWITCH90-2005-05-25T15:51:14.9525.238697Z</Sw:SnFRef>
  <Sw:SnFRefType>InterAct</Sw:SnFRefType>
  <Sw:AcceptStatus>Accepted</Sw:AcceptStatus>
  <Sw:AckSwiftTime>2005-05-25T15:48:33Z</Sw:AckSwiftTime>
  <Sw:AckInfo>Acked</Sw:AckInfo>
</Sw:NotifySnFRequestHandle>

Sw:AcceptStatus carries Accepted, Rejected, or Failed. This is what SWIFTNet sends for delivery confirmation. It is in Sw: namespace. Not ISO 20022. Not SAA. Not F21.

VISUAL 7:   SWIFT sends SwGbl:/Sw: namespace structures. Alliance Access converts them to Saa: namespace DataPDU. The F21 format inside PseudoAckNack is generated by SAA, not sent by SWIFT.

B3.  How Alliance Access Converts the SWIFTNet Signals

When Alliance Access receives the SWIFTNet signals above, it executes a specific conversion process documented in the Configuration Guide:

SWIFTNet Sends (SwGbl:/Sw: namespace)	Alliance Access Converts To (Saa: namespace DataPDU)
SnFInputTime present, no fatal SwGbl:Status	NetworkDeliveryStatus = NetworkAcked SnFInputTime passed through PseudoAckNack: {451:0} ACK
SwGbl:Severity = Fatal SwGbl:Code = Sw.Gbl.NetworkTransmissionError	NetworkDeliveryStatus = NetworkNacked PseudoAckNack reason code T02 (Transmission error) PseudoAckNack: {451:1} NAK
All other SwGbl error cases	NetworkDeliveryStatus = NetworkNacked PseudoAckNack reason code T03 (Unknown) PseudoAckNack: {451:1} NAK
Sw:NotifySnFRequestHandle Sw:AcceptStatus = Accepted	DataPDU DeliveryNotification Sw:AcceptStatus passed through in Saa:Body
Sw:NotifySnFRequestHandle Sw:AcceptStatus = Rejected or Failed	DataPDU DeliveryNotification with failure detail Triggers internal Delivery Report routing

The PseudoAckNack is constructed by Alliance Access from an internal structure called the emission appendix. Alliance Access maps the SwGbl error codes to the old FIN reason codes (T02, T03) and generates the F21 format string. The Configuration Guide is explicit: this generation happens inside Alliance Access, not in SWIFTNet.

B4.  Bottomline Technologies: A Different Gateway, the Same Principle

North American banks, and a number of institutions globally, use Bottomline Technologies as their SWIFT connectivity gateway rather than Alliance Access. The role is identical: Bottomline connects to SWIFTNet via the SNL API, receives the same SwGbl:Status and Sw:NotifySnFRequestHandle structures, and translates them for the payment engine and back-office.

The critical difference is the output format. Where SAA outputs DataPDU in the Saa: namespace (urn:swift:saa:xsd:saa.2.0), Bottomline outputs its own proprietary notification messages defined in Bottomline’s own specifications. These are not publicly documented and vary by integration type and configuration. A bank’s payment team working with Bottomline will see Bottomline-specific message structures, not DataPDU, for acknowledgement and delivery notification.

SWIFTNet sends the same signals regardless of which gateway a bank uses. What changes is how the gateway converts and surfaces those signals to the back-office. A BA designing acknowledgement handling must always design against the gateway’s output format, not against SWIFTNet’s native SNL structures.

This has a practical consequence: if a bank switches gateway — from Alliance Access to Bottomline, or vice versa — the back-office acknowledgement integration must be rebuilt entirely, even though SWIFTNet’s behaviour does not change at all.

B5.  The Fundamental Principle

The back-office never communicates with SWIFTNet directly. The entire acknowledgement flow that practitioners discuss — DataPDU, NetworkAcked, PseudoAckNack, DeliveryNotification — is the gateway’s language, not SWIFTNet’s language.

Layer	Who Generates It	Format / Namespace	Audience
SWIFTNet network signal	SWIFTNet	Sw: and SwGbl: (SNL proprietary)	Gateway only
DataPDU TransmissionReport	Alliance Access (SAA)	Saa: (urn:swift:saa:xsd:saa.2.0)	Back-office on SAA banks
PseudoAckNack inside DataPDU	Alliance Access (SAA) — generated, not received	F21 MT format string inside Saa: XML	Legacy back-office on SAA banks
Delivery Notification (DataPDU)	Alliance Access (SAA)	Saa: namespace, Sw: in body	Back-office on SAA banks
Proprietary notification messages	Bottomline Technologies	Bottomline proprietary format	Back-office on Bottomline banks
xsys.012 Abort Notification	SWIFT Transaction Manager	ISO 20022 (xsys namespace)	All participants via FINplus
pacs.002 Payment Status	Receiving bank or RTGS	ISO 20022 (pacs namespace)	Sending bank

The only signal in this table that travels directly from SWIFT infrastructure to the bank application without a proprietary gateway wrapper is the xsys.012 Abort Notification — because it is delivered as a proper FINplus business message to the bank’s MX queue, not as an SNL-layer network response.

---

▶  Watch the Full Walkthrough on YouTube

https://youtu.be/l6bI_8wkIFM

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