Interface layer

The interface layer (IL):
  • Provides the interfaces that applications use to employ the SIPN FIN services
  • Provides the interface for operator commands to control LTs and sessions
  • Checks that the length of and the character set used by each message are correct
  • Performs additional processing such as message validation and message authentication, if this has not already been done
The interface layer consists of the following message flows:
DNF_ILC_FIN
This message flow:
  • Receives, from an application, outbound messages that are to be sent via the SIPN
  • Adds, if required, a unique end-to-end transaction reference (UETR) to the message, and includes it in the intermediate response that is sent back to the sending application. For more information, see LT configuration attributes UETRGenerate and UETRResponse.
  • Refers to the application service profile (ASP) of the SWIFTNet FIN service to determine whether the message type is valid and whether the message requires signing (authentication) and authorization.
  • Validates each message, if requested
  • Performs an authorization check based on the authorisations contained in the RMDS (see Authorisations).
  • Calculates a message digest and, if FINCopy is to be used, a FINCopy digest. These digests are included in the intermediate response that is sent back to the sending application, if this is configured. For more information, see FINCopy and FINInform.
Subsequent processing depends on whether an error occurs:
  • If so, DNF_ILC_FIN issues a response that describes the error. Depending on how FTM SWIFT is configured, this response is sent either to the sending application or to an exception queue (see Exception handling).
  • If not, DNF_ILC_FIN stores the message, including the calculated digests and an indicator that the authorization check was performed, in the outbound application-message store (OAMS), which is described in FTM SWIFT processing database, and issues a response to the sending application. The message is sent as soon as the corresponding session achieves the appropriate status.
As the DNF_ILC_FIN processes the message, it updates the status of the message in the message warehouse.
DNF_ILS_ACK
When the SFD receives an acknowledgment from the SIPN, it puts it into the OAMS and triggers the DNF_ILS_ACK message flow. The DNF_ILS_ACK message flow retrieves the acknowledgment from the processing database, and passes it back to the sending application. This message flow also provides the sending application with the following:
  • The digests used for authentication
  • The unique end-to-end transaction reference (UETR) if required (see LT configuration attribute UETRResponse)
DNF_ILS_FIN
This message flow receives, from the SFD, inbound messages from the SIPN and routes them to the receiving application. One receiver queue is defined for each LT. This message flow also:
  • Refers to the ASP of the SWIFTNet FIN service to determine whether the message type is valid and whether the message requires signing (authentication) and authorization.
  • Performs an authorization check based on authorisations in the RMDS.
  • Authenticates the message by verifying the message digest, FINCopy digest (if any), and signatures contained in the message.
  • Provides the results of the authorization verification, digest verification, and signature verification to the target application.
  • For an MT398 message, it reconstructs the embedded message, flags the reconstructed message for signature verification, and triggers the signature verification service for the reconstructed message.
  • For a message that failed signature verification due to a recoverable error, if requested, it flags the message for signature reverification.
DNF_ILC_CMD
This message flow processes the commands used to control an LT. These commands can be entered by an operator using the CLI, or by a program using an API. For a login, select, quit, and logout command, DNF_ILC_CMD checks the corresponding record in the LT status table (DNF_LTSS), and prepares the appropriate SWIFT message. For a login command, it triggers the message flow DNF_FSM_STA, which starts the SFD process. It passes query commands to the message flow DNF_FSM_QRY, which accesses both the DNF_LTSS table and the shared memory of the SFD associated with the session.

The IL can be deployed any number of times. By deploying the IL more than once, you can process FIN messages in parallel.