SWIFT-Nachrichten, die im Rahmen eines Geschäftsvorfalls erstellt werden, bestehen aus zwei Teilen.

Der erste Teil der Nachricht (logischer Header) enthält die folgenden Pseudo-SWIFT-Tags:

Der zweite Teil der Nachricht bis zum abschließenden “-” umfasst die eigentliche SWIFT-Nachricht (Nachrichtentext) im Standard-SWIFT-Format. Die SWIFT-Nachricht wird zunächst als .TXT-Datei erstellt.

Bereits während des Geschäftsvorfalls wird geprüft, ob die maximal zulässige Nachrichtenlänge überschritten wurde. Da der Header zu diesem Zeitpunkt noch nicht vollständig ist, kann es in Einzelfällen vorkommen, dass das Problem erst durch den SWIFT-Dienst SRVSWT erkannt wird. Um dies zu verhindern, enthält das Modul DOCIMM die Variable SWTHEADIF, die die Anzahl der Zeichen angibt, die als “Sicherheitszuschlag” hinzugefügt werden sollen. Im Produkt ist dieser Wert auf '60' gesetzt, was der Anzahl der Zeichen entspricht, die sich normalerweise aus der Differenz zwischen der Länge des Pseudo-SWIFT-Tags und der des später hinzugefügten Headers ergibt.

Der Dienst SRVSWT (in der Regel aus der Transaktion MGRTSK heraus aufgerufen) erzeugt aus den .TXT-Dateien neue Dateien, die SWIFT-Nachrichten in dem für das SWIFT-Terminalsystem erforderlichen Format enthalten (je nach verwendetem SWIFT-Terminal können sowohl die Nachrichtenstruktur als auch die Dateierweiterung leicht abweichen). SRVSWT ersetzt den Dokumentenkopf bis einschließlich des EOH-Tags durch einen SWIFT Basic Header Block und einen Application Header Block und platziert die eigentliche Nachricht (den Nachrichtenkörper) in einem SWIFT-Textblock (“{4: ” ). Die resultierende Nachricht wird in einer Datei mit der für das jeweilige SWIFT-Terminal erforderlichen Dateierweiterung gespeichert.

Überschreitet eine SWIFT-Nachricht die maximal zulässige Länge einer SWIFT-Nachricht (festgelegt in der INIT-Regel von SRVSWT), so teilt SRVSWT die Nachricht in eine Folge von Nachrichten auf (z. B. MT700 und MT701, gemäß den SWIFT-Regeln). Diese Nachrichtenfolge wird in einer einzigen Nachrichtendatei gespeichert. Wenn eine Nachricht auf diese Weise aufgeteilt wurde, werden zusätzliche SMH-Zeilen erzeugt (eine für jede Nachricht). Diese Zeilen enthalten die INR der ursprünglichen Nachricht im Feld GRPINR und die Sequenznummer (erste Ziffer von Tag 27) im Feld GRPSEQ. MSGPOS und MSGLEN spiegeln die sequenzielle Position der einzelnen Nachrichten innerhalb der generierten Datei wider. Die Tatsache, dass die Nachricht aufgeteilt wurde (d. h. dass die während der Transaktion erstellte Nachricht in die später tatsächlich gesendeten Nachrichten aufgeteilt wurde), wird in der SMH-Zeile der Ursprungsnachricht angezeigt, indem GRPINR auf seine eigene INR und GRPSEQ auf Null gesetzt wird. Die Anzeigefunktionen (SMHP.FRM) verwenden diese Informationen, um einem Benutzer die Möglichkeit zu geben, alle Versionen anzuzeigen: die ursprüngliche Nachricht und ihre PrettyPrint-Formatierung oder die einzelnen Nachrichten und ihre PrettyPrint-Darstellung.

Wenn eine Nachricht die maximale Länge in Tag 79 überschreitet, erzeugt DOKA automatisch:*.

• in TAG 79 der Nachricht den Text 'für Details siehe separater MT799' und
• eine oder mehrere MT 799-Nachrichten mit den vollständigen Texten.
  

Zu diesem Zweck enthält TRNDOC das zusätzliche Feld TAG79TXT999.

Die individuelle Aufbereitung und Versendung von Nachrichten an ein Kommunikationssystem kann in “SRVSWT.SendMessageCus” realisiert werden