Tag: FINplus

SWIFT MX Message Terms Explained with Examples for ISO20022 Payments

ISO20022 MX has become the global standard for cross-border payments. But the system also produces long technical logs filled with fields most bankers see daily—yet rarely understand. This guide breaks down the most common SWIFT MX message terms with safe, clean, fictional examples.

1. Requestor DN (Distinguished Name)

The Requestor DN identifies the bank that initiates the MX message on the SWIFT network.

Example (fictional):
ou=cf-bnklpkka, o=swift

Breakdown:

  • bnklpkka → BIC of the sending bank (fictional)
  • ou= → organisational unit
  • o=swift → SWIFT domain

Meaning:
The message was pushed into SWIFT by the institution coded BNKLPKKA.

2. Responder DN

Shows which institution processed or received the message.

Example (fictional):
ou=cf-qtrfpkka, o=swift

Meaning:
The responding bank is coded QTRFPKKA (fictional BIC).

This field is helpful in reconciliation and payment investigations.

3. Service Name (finplus)

Indicates which SWIFT network service handled the message.

Example:
Service Name: finplus

Usage:

  • finplus → ISO20022 MX service
  • swiftnet → general messaging
  • retailplus → retail connections (fictional)

FINplus is now mandatory for all cross-border ISO20022 traffic.

4. Non-Repudiation Indicator

Shows whether SWIFT Non-Repudiation Service (NRS) is applied.

Example:
Non-repudiation Indicator: False

Meaning:
The message is not signed with non-repudiation cryptographic evidence.

If this were True, SWIFT could prove the origin of the message in compliance investigations.

5. SWIFT Reference (Generated by SWIFT)

A unique tracking ID created by SWIFT FINplus.

Example (fictional & safe):
swi0203027-09-18T14:22:45.983472_5598217Z

Breakdown:

  • 2027-09-18 → date of processing
  • T14:22:45.983472 → timestamp
  • _5598217Z → internal SWIFT sequence

This reference is used when tracing or recalling payments.

6. SWIFT Request Reference (Generated by the sending bank)

Unlike the SWIFT reference, this ID is generated by the bank’s own interface.

Example (fictional):
SNL5824420270918T142245B910_8821735

Purpose:

  • Internal reconciliation
  • Investigations of stuck or rejected messages
  • Reference between core banking and SWIFT gateway

Think of it as the “local tracking number” before SWIFT assigns its own.

7. CBT Reference (Cross-Border Transfer Reference)

This is the ID used inside the bank’s internal systems, usually a UUID.

Example (fictional):
7fa91372-89c1-4c61-a4c9-902d51b4e8dd

Used by:

  • AML screening
  • Treasury settlement
  • Payment repair teams
  • Nostro reconciliation

Every bank generates its own long-form internal identifiers.

8. Store-and-Forward Input Time

The moment the message entered SWIFT’s Store-and-Forward queue.

Example (fictional):
2027-09-18T14:22:45

This timestamp is essential for:

  • cut-off time disputes
  • SLA monitoring
  • operational reconciliation

9. Signing DN (Certificate Identity)

This identifies the certificate that signs the MX message.

Example (fictional):
cn=mxusr05, o=bnklpkka, o=swift

Meaning:

  • mxusr05 → SWIFT user/application signing the message
  • bnklpkka → fictional sending bank
  • o=swift → SWIFT network

Digital signatures ensure message security and authenticity.

10. Message Header (ISO20022 Type)

Identifies the MX message schema used.

Example:
pacs.009.001.10

Explanation:

  • pacs.009 → Financial Institution Credit Transfer
  • 001.10 → version 10 of the schema

Other common headers:

  • pacs.008 → Customer Credit Transfer
  • pacs.004 → Return
  • camt.029 → Investigation response
  • camt.056 → Cancellation request

11. AppHdr Block

Displayed as:
<AppHdr xmlns="urn:iso:std:iso:20022:tech:xsd:head.001.001.02">

Contains:

  • Sender BIC
  • Recipient BIC
  • Business Message Identifier
  • Definition Identifier
  • Creation timestamp

It is the “envelope” that carries routing and identification data.

Conclusion

Understanding SWIFT MX message terms helps operations officers, compliance teams, treasury staff, and payment processors handle ISO20022 transactions with confidence. Each term in the FINplus log has a specific purpose that supports security, traceability, and accurate settlement across the global financial network.