Swift for Corporates uses the secure and reliable SWIFT network to send and receive transaction messages to and from corporate parties. This is achieved by wrapping special Score messages in Tag :77E: of the Standard SWIFT MT 798. The Score message formats are defined in the “Swift for Corporates Standards MT Messages Implementation Guide” as provided by SWIFT.

As the Score Messages are standard SWIFT MT 798, the SWIFT Messages details apply also for Score Messages.

Here are additional development guidelines covered, that only apply to Score Messages.

Each Score message consist at least of a so called index message and optional additional main messages. For example the application to issue an Import Letter of Credit consists of the index message MT 798 with sub message type 770 (MT798<770>), the main application MT798<700> and up to a maximum of 7 additional MT798<701>.

Score messages are handled like any other incoming SWIFT messages. The mapping definition as defined in SWH/SWM for Source SWIFT are applied. The message type for the definition is the index message but the definition must also include tags from follow up messages.

Score messages created in a business transaction are technically created in one file. This means all needed tags from the index and main messages are printed in one document rule (document rule specifier “O”) and stored in one file in the filesystem. When a Score message is viewed as Pretty Print or is finally send via service SWT in MGRTSK, the tags are distributed to the relevant index and main messages as per definition in the scomap.ini

The scomap.ini contains information how Score messages that are generated by the business transaction are transformed into the sequence of real Score message (i.e. properly formed MT 798). By default all tags in a score message file will occur in the main message. If tags are needed to be available in the index message, this is handled via scomap.ini definition. The scomap.ini logic allows to move, copy and rename tags as per the following logic.

Score messages are created in business transactions as one message containing all relevant tags with the exception of tags “:20:”, “:12:”, “:77E:”, and “:27A:” (value of “outer” tag “:20:” can be set in the header by using pseudo-tag “:20S:”)

Section “IndexMT-” + <MT of index message> contains tags how this MT is mapped. The existence of an MT= in this section determines that this message is handled as Score message

MT=<MT of the first message following index message (i.e. “main” message, e.g. 700 or 760)

MT=<MT of index message> means that this is a SCORE message with index message only. For these messages second (and following messages are deleted so all tags must be moved to index message). For every tag that should occur in the index message one entry in this section is required. The move and copy operation will add the relevant tag to the end of the index message unless the tag name specifier is used.

<tag>=M # “M”ove for tags that should occur in the index message but not remain in the main message (e.g. 13E)

<tag>=C # “C”opy for tags that are required in both, index message and main message (e.g. 21A)

“:tagname” following “C” or “M” indicates that tag has to be inserted after this tag e.g. in [IndexMT-776] 52A=C:13E

A comma separated list of optional preceding tags e.g. for tag :72Z: in MT 733 allows to specify the tag after which the new moved / copied tag has to be inserted. The tag specified must exist already in the index message stream.

Example:

26E=C:23X,72Z,13E → copies 26E to index behind optional 23X. If not available behind 72Z and so on. The last tag in the list should be a mandatory tag.

“:tagname:newtagname” following “C” or “M” indicates that tag has to be inserted after tagname and that tagid is replaced by newtagname.

Example:

23=C:21P:20 → copies content of tag :23: behind tag :21P: and renames tag in the index message to Tag :20: