Financial Message Transfer for FIN messages (FMT FIN)

You can configure FTM SWIFT so that LTs can send and receive FIN messages internally, by means of IBM MQ distributed queues, rather than via the SIPN, thereby reducing the overall cost of transmission. The ability to transfer FIN messages in this way is called Financial Message Transfer for FIN messages, abbreviated to FMT FIN.

When FMT FIN capability is configured:
  • The SIPN FIN service (DNF_ILC_FIN) is able to send FIN messages via the SIPN as before, but is also able to send FIN messages internally. The path taken by a particular message depends on its message type, on its contents, and on values configured for the receiving destination (BIC8):
    • System messages (that is, messages with MT numbers that begin with 0) and Standing Settlement Instruction (SSI) messages (that is, MT670 and MT671 messages) are always sent via the SIPN FIN.
    • For other messages:
      • If its message type and FIN service name correspond to values configured for the receiving destination, the message is sent internally.
      • If the FMT flag in its RFH2 header is set, it is sent internally regardless of its message type and FIN service name.
      • Otherwise, it is sent via the SIPN.
    After FMT FIN capability is configured, applications that use the SIPN FIN service can continue to run unchanged.
  • The FMT FIN service (DNF_PF_IS) sends all FIN messages it receives internally, regardless of the message contents. Applications that are to send all messages internally can use this service.
The means by which FIN messages are transferred using FMT FIN is similar to those by which they are transferred using SIPN FIN, except that messages are not passed via an SFD to the SIPN. Instead:
  • If the sending and receiving LTs belong to the same instance, they are routed directly from the OAMS to the IAMS within the same FTM SWIFT database, as shown in Figure 1.
  • If the sending and receiving LTs belong to different instances, they are routed from one instance to the other using IBM MQ distributed queuing, as shown in Figure 2.
As when using SIPN FIN, when FIN messages are sent internally using FMT FIN:
  • Acknowledgment messages and delivery notifications are generated and sent to the appropriate applications.
  • Message validation, audit, and message warehouse services are started.
  • PKI digests are calculated and verified.
  • Errors are handled by routing the corresponding messages to exception queues or backout queues.
However, unlike when using SIPN FIN, when FIN messages are sent internally using FMT FIN:
  • RMA authorisations are ignored.
  • Signature calculation and signature verification are not performed.
  • The session number is always 0000.
  • ISNs and OSNs are counted for each LT separately, and have a range from 1 to 999999. After the upper limit of 999999 is reached, the numbering begins again with 1.
  • All generated timestamps are represented in GMT.

You can configure FTM SWIFT so that each FIN message received by the FMT FIN service is routed to a specific LT (BIC9) depending on its destination (BIC8), service code (user header field 103), and FIN message type. The LT determines the OU and target application to which the FIN message is delivered.

Figure 1 and Figure 2 illustrate how the SIPN FIN service handles FMT FIN messages.

Figure 1. Sending FMT FIN messages when the sending and receiving LTs belong to the same instance
Figure showing sending FMT FIN messages when the sending and receiving LTs belong to the same instance

When the sending and receiving LTs belong to the same instance:

  1. A sending application passes a FIN message that is to be sent internally to one of the FIN send services (DNF_ILC_FIN or DNF_PF_IS)  1 .
  2. The FIN send service places an ISN FIN message into the OAMS  2 . If the FIN message requested an intermediate ISN ACK, the FIN send service creates one and passes it to the sending application.
  3. Until the sending LT is enabled and started to send FMT FIN messages (this is done by issuing the fmtenable and fmtstart -mode send commands), the FIN send service does not process the FIN message further. After the sending LT is enabled and started to send FMT FIN messages, the FIN send service:
    • Generates the final ISN ACK and places it into the OAMS  2 
    • Generates the corresponding OSN message and places it into the IAMS  3 
    • Generates a delivery notification and places it into the IAMS  3  (but only if the FIN message requested a delivery notification)
  4. If (or after) the receiving LT is enabled and started to receive FMT FIN messages (this is done by issuing the fmtenable and fmtstart -mode receive commands), the DNF_ILS_FIN service retrieves the OSN message from the IAMS and passes it to the receiving application  4 .
  5. If a delivery notification was placed into the IAMS, after the sending LT is started to receive FMT FIN messages (this is done by issuing the fmtstart -mode receive command), the DNF_ILS_FIN service retrieves the delivery notification from the IAMS and passes it to the sending application.
  6. The DNF_ILS_ACK service passes the ISN ACK to the sending application  5 .
Figure 2. Sending FMT FIN messages when the sending and receiving LTs belong to different instances
Figure showing sending FMT FIN messages when the sending and receiving LTs belong to different instances

When the sending and receiving LTs belong to different instances:

  1. A sending application passes a FIN message that is to be sent internally to one of the FIN send services (DNF_ILC_FIN or DNF_PF_IS)  1 .
  2. The FIN send service places an ISN FIN message into the OAMS  2 . If the FIN message requested an intermediate ISN ACK, the FIN send service creates one and passes it to the sending application.
  3. Until the sending LT is enabled and started to send FMT FIN messages (this is done by issuing the fmtenable and fmtstart -mode send commands), the FIN send service does not process the FIN message further. After the LT is enabled and started to send FMT FIN messages, the FIN send service:
    • Generates the final ISN ACK and places it into the OAMS  2 
    • Generates a corresponding OSN message and sends it to the receiving instance, to a queue that is used exclusively for FMT FIN messages from remote instances  3 
    The successful MQPUT operation to the queue at the receiving instance is equivalent to, and triggers the same post-transfer processing as, the receipt of an ACK from the SIPN.
  4. After the MQPUT operation, the DNF_ILS_ACK service passes the ISN ACK from the OAMS to the sending application  4 .
  5. The DNF_PF_IR service at the receiving instance retrieves the OSN message from the queue  5 . If configured, it also records audit data for the inbound message. The DNF_PF_IR service places the message into the IAMS of the receiving instance  6 .
  6. If (or after) the receiving LT is enabled and started to receive FMT FIN messages (this is done by issuing the fmtstart -mode receive command), the message placed into the interface queue of the DNF_ILS_FIN service  7 .
  7. The DNF_ILS_FIN service at the receiving instance retrieves the OSN message  8  and checks whether:
    • The message type of the message is allowed for the receiving destination
    • The sending message broker is authorized to send FMT FIN messages to the receiving destination
    If the message passes both of these checks, DNF_ILS_FIN updates the message in the IAMS  9  and creates an entry in the message warehouse (if this is configured); otherwise, the message is rejected.
  8. If the OSN message indicates that the sending application requested a delivery notification, DNF_ILS_FIN creates a new OSN message that contains the delivery notification and passes it to the interface queue of the DNF_PF_IR service of the sending instance.
  9. DNF_ILS_FIN passes the message to the receiving application  10 .