This transaction processes incoming messages of different formats. A file can contain one or more messages in the respective format.

The processing of partial messages, like in SWIFT MT 700 and MT 701 messages, is supported. This means individual partial messages belonging together are accounted as one complete message and will be provided for further processing.

The application currently supports technical message formats (refer table in below section) in the processing of incoming messages.

Other message interfaces can be defined in compliance with the bank.

The messages are usually stored as text files in the subdirectories of the “Data” partition.

Thus, relative path names for defining the output directories are relative to the partition “Data”. If necessary for organizational reasons, absolute path names can also be defined. In doing so, the usage of the prefix 'db': (files in databases) is also possible. Optionally, incoming messages can be sent in separate directories per entity or in a common directory for the entire installation.

The transaction carries out the following steps:

1. Reading a message from one of the specified directories.
2. Deciding dependent on the subdirectory, which message format is at hand.
3. If a file contains more than one block of messages with its own header and footer, which is possible with DTA, DTE and DTG messages, the file is split into several files each containing one block. The file name is formed from the original file name followed by a number and the extension. The original file is moved to the archive directory arc once the sub-files have been created.
4. Splitting a file containing multiple messages into one message in each case. If the file contains header blocks, each single message is preceded with this information, i.e. a physical incoming file can have multiple senders. The sender is included in one of the A tags. A physical file is split up into as many physical files as there are different senders.
5. Segmenting each message to individual fields, according to the syntax rules described in each respective TAG file. The TAG file is stored in partition “Ini”.
6. Combining messages split into multiple messages (e.g. 700 and 701), according to the SWIFT length limitation to one individual message as soon as the last message of a sequence was found (regardless of the incoming sequence). If a SCORE message contains the Tag 23X with the channel 'FACT' (FileAct), messages are only combined when all sub-messages and the file referenced in Tag 23X have been received.
7. If the requirements are not fulfilled, this can result in shortening extra-long SWIFT messages at the end of the message. Those truncated messages are forwarded to the customers via the application. At the same time, a warning will be displayed by the system, stating that the L/C data is incomplete.
8. If the block that contains the unmapped fields is maybe also too small for the inserted text (max. 65 characters per 100 lines), the content of the respective tag will be removed from “Unmapped”. Furthermore, an error message is written into “Unmapped”, informing the user that the incoming message has to be checked.
9. Deciding about the transaction to be executed for this message, according to the rules laid down in the rule “SRVSWI.DetermineMT”. Example: The decision as to which transaction will ultimately be assigned to the incoming directory is done in module SRVSWI in rule “DetermineMT()”. In the simplest case it is derived from the message type. If it is not obvious which transaction is to be associated with a message type, tags of the message can be used for further analysis / identification.
   Handling erroneous Reference Numbers: The own reference number (OWNREF) may NEVER be used as the target for mapping. If an own reference number is found in SWM that is not to be ignored and that is unequal to the current reference, it is stored in the “unmapped” field and an error text will be displayed.
10. Displaying the data fields in transactions fields, like defined in the mapping (see “Maintaining Field Mappings for Incoming Messages”).
11. If the file name is too long, the file will be copied as file with a file name of max. 28 characters. The header includes a timestamp.
12. Generating a “SMH - Structured Message Header” entry for the message (SMH set).
13. Printing (if correctly specified) of a formatted and/or an unprocessed copy of the message on the exactly specified printer.
14. Generating an entry in the list of pending tasks.
15. Moving the file (if no error occurred) into the subdirectory “arc” (e.g. “swtin/arc”) of the partition; otherwise into the subdirectory “error” of the partition.
    Note: A file may contain more than one message. If an error occurs during the processing of the message content, but as the case may be, other messages have already been processed correctly in this file - the file will be moved (and/or copied) to “arc” (for archiving the successfully processed messages) as well as to “error” (for not successfully processed messages).

By using the switches -I <Name of the ini file> in the command line of the processing system, various instances of this transaction can be started (e.g. one that starts SWIFT from 8 a.m. until 6 p.m. every 10 minutes and another instance for TradeConnect messages, that will only be started once a day).

For message types SWIFT XML, also called Swift MX, (e.g. ISO20022 CBPR+ XML payment messages), the new service SRVSXI has been introduced. This service is used for importing incoming messages, e.g. Pacs.008, Pacs.009 and Technical Ack/Nack MX transmission messages (as a result of a technical validation if the message is compliant as per Swift MX rulebooks). Examples: Incoming Pacs.008 messages are routed to the transaction CPTSET (similar to incoming MT103) and incoming Pacs.009 messages to transaction SPTROU (similar to MT202). The technical Ack/Nack acknowledgement message is not mapped to a contract but received only to register the Ack/Nack status of the contract.

For the processing of incoming items to function properly, it is necessary to enter a default entity in SWITSK.INI. This default entity is used if no other entity was assigned to the user. Access takes place as follows:

If a message can be assigned to a contract, the entity of the contract is used.

If no contract is available:

• In case of SWIFT messages the recipient BIC is used to identify the entity. At first, the BIC out of II_BIC is converted into an 11-character BIC, if it has 12 characters. Subsequently, an address with this BIC will be searched, that is specified as “Own Address” (Own) in an entity. In case there are multiple addresses with this BIC, the address flagged as a “Primary Address” will be used. The entity is determined from the address found.

• In case of DTA, DTE, DTG and TradeConnect messages, the DTA/DTE/DTG-ID or the TID of the recipient entity is determined from the content of tag 'A2' of the message. If this field only consists of numbers, its content will be interpreted as bank clearing code, otherwise as BIC. Subsequently, an address with this bank clearing code or with this BIC, bank clearing code or TID is searched, which has been specified as “Own Address” in an entity. In case there are multiple addresses with this BIC, the address flagged as the “Primary Address” will be used. The entity is determined from the address found.

If no entity was identified in this way, the default entity specified in SWITSK.INI in section [Settings] under 'DefaultETY=' is used.

This logic for assigning entities can be customized for individual projects within the rule “SWITSK.DetermineETY”.

If a contract is available, the user group of the user responsible for the contract is selected. In all other cases the default user group of the selected entity is used as user group.

Tag 23X in SCORE messages can be used to indicate that a file (logically, this is seen as an attachment to the message) - in any format whatsoever - is attached to the message (which itself consists of several part-messages) that is transported outside the SWIFT FIN service. If the delivery channel indicated in Tag 23X is SWIFT FileAct, the application collates the various sub-messages and the attachment. The message only appears in the in-tray when the last sub-message and the attachment have been received.

Technical procedure:

When all the SCORE messages have been received, the collation process checks whether there is an SMX record in which sender, receiver and file name details match those contained in Tag 23X.

• If not, this SMX record (excluding the SMH record) is added together with a reference to the relevant SCORE message so that SRVSFI can collate the messages when the attachment arrives.
• If yes, an additional reference is entered in the SMX record that subordinates the SMH record identifying the attachment to the first SCORE message and creates an entry in the in-tray (SPT).

Messages received via FILEACT are processed by the SRVSFI service. An SMH record - with a CORTYP of 'FIL' and a message type of 'FILEACT' - is generated for each incoming file. In addition, a check is run to see whether there is already an SMX record in which sender, receiver and filename match the incoming file.

• If not, this SMX record (excluding the SMH record) is added so that SRVSFI can collate the messages when the attachment arrives.
• If yes, this SMX record is used. If an additional reference to a relevant SCORE message with Tag 23X (generated by SRVSWI) is found in the SMX record, the SMH record for the attachment is subordinated to the SMH record of the first SCORE message, the parts of the SCORE message are collated and processed and an entry generated in the in-tray (SPT).

The trigger formats “Swift Alliance Access XML v2 as Trigger” and “Swift Alliance Access XML v2 PDU via MQ” support the reception of FILEACT attachments via XMLv2 messages.

Swift Alliance Access XML v2 as Trigger

• The defined input directory expects two files. The XMLv2 (or data pdu) file triggers the processing. The <body> element expects the physical name of the attached file. If this file does not exist, the message received will be moved to the error directory, and skipped. If it does exist, both files will be moved to the archive directory. The file attached may be renamed according to the <LogicalFileName>.

Swift Alliance Access XML v2 via MQ

• When using this trigger, data PDU files will be fetched by the MQ process. The XMLv2 file and the attachment file will be extracted from the data PDU files. Further processing steps are identical to the “Swift Alliance Access XML v2 as Trigger” scenario.

Incoming Email messages that contain a signature but for which no certificate or public key has been saved can be imported without any fields.

To this end, in file “emlmod.ini” in Section [System], the entry IGNSIGFLG='Y' must be set.

When a flag is set, errors in verifiying the signature in multipart/signed elements are ignored - the negative verification result is only registered in the raw text extracted.

Managers running in foreground mode always need to be started manually.

For some incoming message types, it is possible to send a notification E-Mail to a specified recipient. This E-Mail will contain a link, so that the correct transaction for the incoming message will be started.

If 'Send E-Mail' is checked a notification E-Mail will be generated.
The send method can be:

• Customer specific ( Customer specific programming is required )
• Pickup directory ( Copy E-Mail to this directory. File will be picked up from software outside DNG )
• SMTP ( Send E-Mail over SMTP )
• Unix sendmail( send mail with Unix sendmail )

In the pickup directory E-Mail files will be generated.

In the SMTP block SMTP settings have to be specified.

For Windows System the Convert Lineend to 0D0A normally has to be checked.

The Command has to be a URL of the DNG HTML5 client with server and port.

Fields for the E-Mail:

• From E-Mail
• Default to E-Mail
• Subject
• E-Mail text

The E-Mail text should contain the Tag <URL>. This tag will be replaced by the command, extended with a SPT.INR and a transaction name. When the receiver of the E-Mail clicks on this URL the HTML5 client is started and after login it is chained directly into the transaction for the incomming message.

SWITSK has a possibility to fetch e-mails from the remote mailbox via standard POP3/IMAP interface.
Currently, this feature is enabled for SmartForms and EasySend message types. To turn it on - the checkbox Use Mailbox has to be ticked
When it's activated - the mailbox will be checked for new e-mails during the regular update of SWITSK.

Connection settings can be found under button E-mail Settings. Once clicked - the following pop-up with the standard mail client configuration will appear:

The following descriptions apply to all configuration panels for the message formats.

Manager for Incoming Messages
Incoming SWIFT
TradeConnect
Telex
DTA Import L/C
DTA Export L/C
DTA Guarantees
Email
Bolero
SWIFT FileAct + XMLv2
allNETT
allNETT STT
SmartForms
EasySend
Incoming Invoices
SWIFT XML
RIVO
RIVO STT

This is the main panel which displays all the 'Incoming messages' which are available in their respective target directories. User is provided with the selection criteria to select the required service/message types which are to be listed and the incoming messages are displayed for those selected service types.

This is the configuration panel for Incoming SWIFT and SCORE messages. Option is available to specify the incoming target directories for SWIFT and SCORE messages, along with the required file extension for those message files. Additionally, user could also configure for Printing setup and activate Local authentication hash by providing their key details.

This configuration panel is for TradeConnect messages for TCWEB. Option is available to specify the incoming target directories for TradeConnect messages, along with the required file extension for those message files. The data structure is merged with DTA for LC messages and DTG for Guarantee messages. Additionally, user could also configure for Printing setup and activate Local authentication hash by providing their key details.

This configuration panel is for incoming Telex messages (electronic communication message, which was widely used before SWIFT). Option is available to specify the incoming target directories for Telex messages, along with the required file extension for those message files. Also the user could configure the printer setup.

This is the configuration panel for Incoming DTA message for Import LC. Option is available to specify the incoming target directories for DTA Import LC messages, along with the required file extension for those message files. Additionally, user could also configure for Printing setup and activate Local authentication hash by providing their key details.

This is the configuration panel for Incoming DTA message for Export LC. Option is available to specify the incoming target directories for DTA Export LC messages, along with the required file extension for those message files. Additionally, user could also configure for Printing setup and activate Local authentication hash by providing their key details.

This is the configuration panel for Incoming DTA (DTG) message for Guarantee messages. Option is available to specify the incoming target directories for DTA Guarantee messages, along with the required file extension for those message files. Additionally, user could also configure for Printing setup and activate Local authentication hash by providing their key details.

For details on configuring the Bolero Terminal see Configuring Incoming Messages. Option is available to specify the incoming target directories for Bolero messages, along with the required file extension for those message files. User could specify the bank's OWN RID/BIC for receiving these incoming Bolero messages. Also, the type of print out format can be specified.

This configuration panel allows the user to define the trigger format for the incoming SWIFT Fileact messages. The XML format is wrapped like header to the message. The MT body of such messages is internally routed to and processed by 'Incoming SWIFT' service. Option is also available to specify the incoming target directories for Fileact messages, along with the required file extension for those message files.

From the allNETT configuration panel, user could choose the type of printout format. Option is available for selecting the automatic processing of incoming allNETT messages and also option is available to specify the incoming target directories along with the required file extension for those messages files. The message type/format is an internal proprietary XSD standard.

For more details on this message type, please refer "SmartForm". Option is available to choose the incoming message type format for the incoming SmartForms. Most used format/type is 'PDF'. Also, option is available to specify the incoming target directories along with the required file extension for those messages files. Since PDF could contain, passwords, that could also be stored for easy import of incoming files.

“EasySend” provides a no-code platform to transform any paperwork-based process into responsive digitized process. The platform provides to end-user, custom-tailored web forms to fill which are then converted to PDF (hand signature also supported) and sent to DOKA-NG. The content of the form is then mapped by this transaction ‘Manager of Incoming Messages (SWITSK)’ into the related business transaction and the PDF is attached as evidence.

Option is available to choose the incoming message type format for the incoming message. Most used format/type is 'PDF'. Also, option is available to specify the incoming target directories along with the required file extension for those messages files. Since PDF could contain, passwords, that could also be stored for easy import of incoming files.

For more details on this business module, please refer APF. Option is available to specify the incoming target directories for the incoming messages, along with the required file extension for those message files.