1 Zusammenstellung relevanter SWIFT

Transcription

Technische Anbindung BOSS-CUBE
Kreditinstitute
Inhaltsverzeichnis
Nachrichtenformate
1swift.doc
Inhaltsverzeichnis
05.10.1998
Inhaltsverzeichnis
1
Zusammenstellung relevanter S.W.I.F.T.-Konventionen für die
Orderübermittlung
1
1.1
Grundstruktur einer Nachricht
1
1.2
Nachrichten-Kategorien, -Gruppen und -Typen
3
1.2.1
Nachrichten-Kategorien (Category)
4
1.2.2
Nachrichten-Gruppen (Groups)
5
1.2.3
Nachrichten-Typen (Kategorie 5)
6
1.3
Nachrichten-Formate
7
1.4
Symbole für Felder und Unterfelder
8
1.4.1
Beschränkungen in der Länge
8
1.4.2
Art der erlaubten Zeichen
8
1.4.3
Besondere Formate
8
1.4.4
ISO-Codes
9
1.4.5
Wahlfreie Unterfelder
9
1.4.6
Code-Wörter
9
1.4.7
Auftragsnummern
9
1.5
Aufbau einer Nachricht (S.W.I.F.T. II)
1.5.1
Blockstruktur
10
1.5.1.1
Beschreibung: Basic-Header
11
1.5.1.2
Beschreibung: Anwendungs-Header
12
1.5.1.3
Beschreibung: Benutzer-Header
14
1.5.1.4
Textblock
14
1.5.1.5
Nachrichtenende (Trailer)
15
1.5.2
Grundstruktur einer Adresse S.W.I.F.T. II
16
1.5.3
Folgenummern
17
1.5.3.1
Eingabefolgesteuerung (ISN: Input-Sequence-Number)
17
10
Kreditinstitute
Inhaltsverzeichnis
Nachrichtenformate
1swift.doc
Inhaltsverzeichnis
05.10.1998
1.5.3.2
Ausgabefolgesteuerung (OSN: Output-Sequence-Number)
17
2
Anwendung der S.W.I.F.T.-Konventionen innerhalb der
Orderübermittlung
18
2.1
Nachrichtenstruktur und -übermittlung
18
2.2
19
2.3
Nachrichten-Formate
20
2.4
21
2.4.1
Allgemeines
21
2.4.2
Xetra® relevante Änderungen
21
2.5
Aufbau einer Nachricht
2.5.1
Blockstruktur
22
2.5.1.1
22
2.5.1.2
23
2.5.1.3
25
2.5.1.4
Textblock
25
2.5.1.5
25
2.5.2
Anwendung von Adressen
26
2.5.3
Folgenummern
27
2.5.3.1
27
2.5.3.2
27
2.5.4
Feld - Standards
27
2.5.4.1
Einteilung und Bestandteile der Felder
28
2.5.4.2
Feld-Formate und Regeln
28
2.5.4.3
Pflicht- und Kann-Felder
28
2.5.5
Fehler-Identikatoren
29
2.5.5.1
Fehler im Nachrichtenkopf / Formatfehler
29
22
Kreditinstitute
Inhaltsverzeichnis
Nachrichtenformate
1swift.doc
Inhaltsverzeichnis
05.10.1998
2.5.5.2
Fehler in der Nachricht (Mnn)
29
2.5.5.3
Fehler im Text (Tnn)
29
2.5.5.4
Plausibilitäts-Fehler (Cnn)
30
2.5.5.5
Systeminterne Fehlermeldungen / Hinweise
30
2.5.5.5.1
BOSS-CUBE - Fehlermeldungen / Hinweise
30
2.5.5.5.2
Xetra® - Fehlermeldungen / Hinweise
34
2.5.6
Anbindungsarten
35
2.5.6.1
Dezentrale Anbindung
36
2.5.6.2
Zentrale Anbindung
37
2.6
Nachrichtenformate
2.6.1
Nachrichtenformate Kategorie 0
41
2.6.1.1
Anmeldung (MT 000)
42
2.6.1.2
Anmeldungsbestätigung, Passwortänderung und Änderung des Nachrichtenumfangs (MT 001)
43
2.6.1.3
Abmeldung (MT 002)
44
2.6.1.4
Abmeldungsbestätigung (MT 003)
46
2.6.1.5
Retrieval-Anforderung (MT 020)
47
2.6.1.6
Antwort auf Retrieval (MT 021)
49
2.6.2
50
2.6.2.1
Kauforder (MT 500)
50
2.6.2.2
Verkauforder (MT 501)
58
2.6.2.3
Ausführungsbestätigung (MT 519)
66
2.6.2.4
Ereignisse im WP-Geschäft (MT 551)
70
2.6.2.5
Anfrage: Änderung / Streichung (MT 595)
83
2.6.2.6
Antwort (MT 596)
93
2.6.2.7
Nachricht für eigene Anwendung (MT 598)
97
38
Kreditinstitute
Inhaltsverzeichnis
Nachrichtenformate
1swift.doc
Inhaltsverzeichnis
05.10.1998
3
Beispiele zur Anwendung der S.W.I.F.T.-Konventionen innerhalb der
Orderübermittlung
98
3.1
Kauforder (MT 500)
98
3.2
Verkauforder (MT501)
99
3.3
Ausführungsanzeige (MT 519)
100
3.4
Ereignis im Wertpapiergeschäft (MT 551)
101
3.4.1
Kassakursmitteilung
101
3.4.2
Kursaussetzung für VW-Aktien in Frankfurt
101
3.5
Anfrage (MT 595)
3.5.1
Orderänderung
102
3.5.2
Orderstreichung
103
3.6
Antwort (MT 596)
3.6.1
Bestätigung der Orderannahme
104
3.6.2
Ablehnung wegen Datenfehler
105
3.6.3
Bestätigung einer Änderung
107
3.6.4
Bestätigung einer Streichung
108
3.7
3.7.1
Login
109
3.7.2
Bestätigung Login
109
3.7.3
Rückmeldung fehlerhafter Nachrichten durch Kreditinstitut
110
3.7.4
Anforderung historischer Nachrichten, Anfangs-OSN
111
3.7.5
Antwort auf Anforderung
112
102
104
109
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
(S.W.I.F.T.-Konventionen)
1
05.10.1998
Seite 1
Zusammenstellung relevanter S.W.I.F.T.-Konventionen für die Orderübermittlung
In diesem Abschnitt sind die relevanten Konventionen aus den unterschiedlichen S.W.I.F.T.-Handbüchern zusammengefaßt, um ständiges Nachschlagen zu vermeiden. Die für die Realisierung notwendigen Restriktionen sind in
Kapitel 2 beschrieben.
1.1
Grundstruktur einer Nachricht
Nachrichtenkopf
(Header)
Nachrichten-Text
(Message Text)
Nachrichtenende
(Trailer)
Nachrichtenkopf und Nachrichtenende bilden zusammen den "Briefumschlag" (Envelope).
Die einzelnen Felder werden mittels Steuerzeichen voneinander getrennt (Field Separator):
• Nachrichtenanfang (Start of Message)
= SOH
(Hex '01')
• Feldbegrenzung (Field Separator within Text)
= CrLf:
(Hex '0D257A')
• Textende (End of Text)
= CrLf-
(Hex '0D2560')
• Nachrichtenende (End of Message)
= ETX
(Hex '03')
• Neue Zeile (New Line)
= CrLf
(Hex '0D25')
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 2
Die Felder im Nachrichten-Text beginnen jeweils mit einem Etikett (Tag) gefolgt von einem ":"
Doppelpunkt
=
Begrenzung Feldetikett
Neue Zeile =
+ Doppelpunkt
Feldbegrenzung
Jedes Feld beginnt mit einem Doppelpunkt
Bindestrich
=
Textende
Doppelpunkt und Bindestrich dürfen deshalb nicht als erstes Zeichen einer Zeile verwendet werden.
Der Nachrichtenkopf beinhaltet die Bestimmungs- und Sendeadresse, die fortlaufende Nummer, den Nachrichtentyp und die Priorität.
Der Nachrichten-Text besteht aus einer Folge von Feldern, die bestimmten Konventionen unterliegen. Unterfelder (Subfields) werden gekennzeichnet durch Schrägstrich(e) = Slash (/, //).
Entsprechend des Nachrichtentyps kann sich der Text aus einem geschlossenen Block oder aus mehreren Abschnitten (Sections) zusammensetzen. Einige Abschnitte können innerhalb einer Nachricht mehrfach auftreten (Sequence). Dabei darf allerdings die Maximallänge einer S.W.I.F.T.- Nachricht von 2000 Zeichen nicht überschritten
werden.
Das Nachrichtenende kann als Bestandteil der Nachricht fehlen. Alle Finanznachrichten der Kategorie 1, 2, 4, 5,
7 und 8 müssen mit einem Authenticator gesichert werden.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
1.2
05.10.1998
Seite 3
Jede S.W.I.F.T.-Nachricht wird durch den Nachrichtentyp eindeutig spezifiziert. Der Nachrichtentyp besteht aus
drei Ziffern, von denen jede eine andere Bedeutung hat:
Kategorie
MT:
Gruppe
Typ
n n n
Alle S.W.I.F.T.-Nachrichten, die zwischen Benutzern ausgetauscht werden, müssen den Standards für Nachrichtentexte entsprechen, die in den Bänden für die Standards beschrieben sind:
Die S.W.I.F.T.-Standards umfassen sechs Bände:
STANDARDS 1
=
Allgemeine Informationen, wie
− ISO-Code für Bankadressen
− Nachrichtenaufbau
− Definitionen der Felder
STANDARDS 2
=
Zahlungsverkehr, Cash Management und Kundenstatus
− Kategorie 1
− Kategorie 2
− Kategorie 9
STANDARDS 3
=
Außenhandelsfinanzierung
− Kategorie 4
− Kategorie 7
STANDARDS 4
=
Devisen- und Geldhandel
− Kategorie 3
− Kategorie 6
STANDARDS 5
=
Reiseschecks
− Kategorie 8
STANDARDS 6
=
Wertpapierhandel
− Kategorie 5
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
1.2.1
05.10.1998
Seite 4
Nachrichten-Kategorien (Category)
Nr.
Bezeichnung
Benutzerhandbuch
0
System-Nachrichten
Betriebsfunktionen
1
Kundenüberweisungen, Schecks
Standards 2
2
Banküberträge
Standards 2
3
Geld- und Devisenhandel
Standards 4
4
Dokumenten-Inkassi, Kreditbriefe
Standards 3
5
Wertpapiere
Standards 6
6
Konsortialgeschäfte
Standards 4
7
Dokumentenakkreditive, Garantien
Standards 3
8
Reiseschecks
Standards 5
9
Kunden-Status, Nostro-Auszüge
Netting, Auskünfte
Standards 2
n
Allgemeine Gruppe
Allgemeine Informationen
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
1.2.2
05.10.1998
Seite 5
Nachrichten-Gruppen (Groups)
Innerhalb jeder Kategorie sind eine Anzahl von Nachrichtengruppen definiert. Sie werden durch das zweite Zeichen
des Nachrichtentyps bestimmt.
Eine Gruppe, die sog. "Allgemeine Gruppe" (Common Group) erscheint als letzte Gruppe bei allen Kategorien gemeinsam. Sie enthält folgende Nachrichtentypen:
n90
Gebührenanzeige
Advice of Charges, Interest and other Adjustments
n91
Gebührenanforderung
Request for Payment of Charges, Interest and
other Expenses
n92
Stornierungsauftrag
Request for Cancellation
n95
Anfragen
Queries
n96
Antworten
Answers
n98
Nachricht für eigene Anwendungen
n99
Freies Format
Free Format
n = Kategorie
Da die Kategorie in jedem Fall angegeben wird, können Nachrichten der Common Group jeweils in eine entsprechende Gruppe eingeordnet werden. So würde sich der Nachrichtentyp 295 auf die Anfrage zu einem Bankübertrag
beziehen.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
1.2.3
Nachrichten-Typen (Kategorie 5)
Nachrichtentyp
500
Kauforder
501
Verkauforder
510
Kauf-/Verkaufsbestätigung
512
Bestätigung eines Wertpapierhandels
519
Ausführungsanzeige
520
Eingang ohne Zahlung
521
Eingang gegen Zahlung
522
Ausgang ohne Zahlung
523
Ausgang gegen Zahlung
530
Bestätigung eines Eingangs ohne Zahlung
531
Bestätigung eines Eingangs gegen Zahlung
532
Bestätigung eines Ausgangs ohne Zahlung
533
Bestätigung eines Ausgangs gegen Zahlung
539
Avis eines Eingangs / Ausgangs von Wertpapieren
550
Bezugsrechtsankündigung
551
Nachricht über ein Ereignis
552
Angebot auf Zeichnung oder Sonderrecht
553
Anweisung an eine Depotbank
554
Avis über Gelderträge
555
Avis über Erträge in Form von Wertpapieren
556
Tilgungsavis
557
Avis über Erträge aus Wertpapieren
559
Ausgleich von Forderungen einer Zahlstelle
560
Ankündigung einer Versammlung
561
Stimmrechtsermächtigung und Anweisungen
570
Anforderung einer Aufstellung
571
Depotaufstellung
572
Aufstellung von Depotumsätzen
573
Aufstellung von schwebenden Geschäften
574
Aufstellung von offenen Aufträgen
577
Aufstellung von Stückenummern
579
Stückenummern (Folgenachricht)
05.10.1998
Seite 6
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
1.3
05.10.1998
Nachrichten-Formate
Innerhalb der Nachrichtengruppen wurden unterschiedliche Nachrichtentypen festgelegt. Das Format beschreibt die
Regeln für die Zusammensetzung der einzelnen Nachricht.
Seite 7
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
1.4
1.4.1
Beschränkungen in der Länge
nn
nn-nn
nn
nn*nn
1.4.2
Art der erlaubten Zeichen
n
a
c
b
x
1.4.3
maximale Länge
minimale und maximale Länge
feste Länge
maximale Anzahl von Zeilen mal maximale Zeilenlänge
nur Ziffern
nur Buchstaben
nur Buchstaben und Ziffern
nur Leerzeichen
jedes Zeichen aus dem zugelassenen Zeichenvorrat einschließlich Blanks:
A-Z
0-9
Sonderzeichen:
/-?:().,'+
Besondere Formate
6n
nn....n,
Datum in der ISO-Norm (JJMMTT)
Wertzahlen (z.B.: Beträge)
05.10.1998
Seite 8
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
1.4.4
05.10.1998
ISO-Codes
z.B.: Währungs-Code (DEM, EUR, USD)
1.4.5
Wahlfreie Unterfelder
Wahlfreie Unterfelder erscheinen in [...]
1.4.6
Code-Wörter
z.B. BEN, OUR, AMEND
1.4.7
Auftragsnummern
Nicht zugelassen ist ein Schrägstrich "/" als erstes oder letztes Zeichen des Feldes oder zwei aufeinanderfolgende
Schrägstriche "//" innerhalb des Feldes.
Seite 9
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 10
1.5
Aufbau einer Nachricht (S.W.I.F.T. II)
1.5.1
Blockstruktur
Die Transaktionen (Nachrichten) bestehen aus maximal fünf Blöcken:
NACHRICHT
BASIC HEADER
[ANWENDUNGS-HEADER]
[BENUTZER-HEADER]
[TEXT]
[TRAILER]
([]
=
Wahlfrei)
Die Hauptblöcke beginnen mit einem Kennzeichen aus einer Ziffer gefolgt von einem Doppelpunkt:
1
2
3
4
5
=
=
=
=
=
Basic-Header
Anwendungs-Header
Benutzer-Header
Textblock
Trailer-Block
Der einzig zwingend vorgeschriebene Block ist der Basic-Header. Jeder Block einer Nachricht beginnt und endet mit
einer geschweiften Klammer '{' und '}' (HEX 'C0' bzw. HEX 'D0').
Die Blöcke 3, 4 und 5 können Unter-Blöcke enthalten.
Bei S.W.I.F.T. II wird jede Nachricht als fortlaufende Zeichenkette übertragen, ohne Zeilenanfang / Zeilenvorschub
(CrLf) zwischen Blöcken und Unterblöcken (siehe Kapitel 3 Beispiele zur Anwendung der S.W.I.F.T.-Konventionen
innerhalb der Orderübermittlung).
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
1.5.1.1
05.10.1998
Seite 11
Blockkennzeichen
=
1:
Anwendungs-Kennzeichen
=
1a
F
A
L
für Anwendung Finanzbereich
für "Generelle Pflichtanwendung (APC)"
für "Generelle Pflichtanwendung (LTC)"
Kennung Dateneinheit
=
2n
'01' für System- und Benutzernachrichten
LT Adresse
=
4a2a2c1c3c
Sender-LT für Eingabenachrichten
Empfänger-LT für Ausgabenachrichten
Sitzungsnummer
=
4n
Selektiertes Anwendungsprogramm
Folgenummer
=
6n
ISN / OSN
Beispiel:
{1:F01BANKDEFFAXXX2222123456}
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
1.5.1.2
05.10.1998
Seite 12
Blockkennzeichen
=
2:
Kennzeichen für Ein- / Ausgabe
=
1a
I
O
Transaktionstyp
für Eingabe
für Ausgabe
=
3n
Nachrichten-Typ
Bestimmungsadresse
=
4a2a2c1c3c
12-stellige S.W.I.F.T.-Adresse des Empfängers
Priorität
=
1a
S
U
N
für System
für Eilig
für Normal
1n
1
2
3
Warnmeldung bei Nichtzustellung
Meldung bei Zustellung
sowohl 1 als auch 2
Nur bei Eingabe:
Überwachung der Zustellung
Periode für Überfälligkeit
=
=
Beispiel: Anwendungs-Header (Eingabe)
3n
Einheiten von 5 Min
{2:I500BANKDEFFXXXXN2020}
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 13
Nur bei Ausgabe:
Uhrzeit der Eingabe
=
HHMM
Eingabereferenz MIR
=
Eingabedatum (JJMMTT)
Sender-LT
Sitzungsnummer
ISN
Ausgabedatum
=
JJMMTT
Uhrzeit der Ausgabe
=
HHMM
Priorität
=
1a
S
U
N
für System
für Eilig
für Normal
Beispiel: Anwendungs-Header (Ausgabe)
{2:O5961200900510BANKDEFFAXXX22221234569005101201N}
Für bestimmte Nachrichten wird die logische Zusammenfassung einzelner Komponenten aus Basis- und Anwendungsheader wie folgt benötigt:
Eingabereferenz MIR (Block 106)
=
Sender-LT
Sitzungsnummer
ISN
Ausgabereferenz MOR (Block 107)
=
Ausgabedatum (JJMMTT)
Empfänger-LT
Sitzungsnummer
OSN
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
1.5.1.3
Seite 14
Blockkennzeichen
=
3:
Bankpriorität
=
113: 4x
Benutzerreferenz MUR
=
108: 16x
Beispiel:
1.5.1.4
05.10.1998
{3:{113:XXXX}{108:ABCDEFGH90123456}}
Textblock
Der Text einer Benutzernachricht bei S.W.I.F.T. II ist identisch mit dem Text der entsprechenden Nachricht bei
S.W.I.F.T. I, mit Ausnahme eines zusätzlichen Blocktrennzeichens (= 4:).
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
1.5.1.5
05.10.1998
Seite 15
Der Trailer setzt sich aus einer Folge von Trailer-Bestandteilen zusammen. Eine Trailer-Komponente besteht aus
einem dreistelligen Identikator, danach folgt wahlweise eine Information, welche Aussage gibt über die einzelne Ursache.
Verzeichnis wichtiger Trailer-Identikatoren:
AUT
Nachricht mit Authentikator
PDE
Mögliche Doppelnachricht (Possible Duplicate Emission)
(PDE ist der einzige Trailer, der vom Sender angefügt werden kann)
PDM
Mögliche Doppelnachricht
(Wird vom System an jede Nachricht hinzugefügt, welche noch einmal gesendet wird, weil
eine vorherige Zustellung zweifelhaft ist)
TNG
Trailer für Training (ab S.W.I.F.T. II)
Die Trailer können in zwei Kategorien eingeteilt werden:
• Benutzer-Trailer
• System-Trailer
Beispiel:
{5:{AUT:41F2}}
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
1.5.2
05.10.1998
Seite 16
Grundstruktur einer Adresse S.W.I.F.T. II
Bei der Adressierung innerhalb S.W.I.F.T. II wurde eine Struktur festgelegt, die aus fünf aufeinanderfolgenden Unterfeldern besteht, wie die folgende Skizze zeigt:
B
B
B
1
B
C
C
L
2
L
3
E
4
Br
Br
Br
5
Filialcode (branch code)
Adresserweiterung (address extension)
Ortscode (location code)
Ländercode (country code)
Code des Kreditinstitutes (financial institution code)
Zu 4: Die Erweiterung einer Adresse besteht aus einem alphanumerischen Zeichen und wird zur Kennzeichnung
eines bestimmten logischen Terminals benutzt. Wenn der Sender einer Transaktion nicht weiß, an welches
LT die Transaktion zugestellt werden soll, so muß ein X verwendet werden.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
1.5.3
Folgenummern
1.5.3.1
05.10.1998
Seite 17
Jede Nachricht, die S.W.I.F.T. empfängt, muß eine Eingabefolgenummer enthalten, die von der Senderbank zugeteilt wird. S.W.I.F.T. prüft diese Nummer. Jede Nachricht, deren ISN außerhalb der Reihenfolge liegt, wird von
S.W.I.F.T. zurückgewiesen.
Für den Nachrichtenverkehr über das System der Deutsche Börse Systems AG gelten abweichende Regeln (siehe
Kapitel 2.5.3.1).
1.5.3.2
Jede von S.W.I.F.T. übermittelte Nachricht enthält eine Ausgabefolgenummer, die jeweils auf ein Terminal bezogen
ist und die von der Empfängerbank geprüft werden muß. Erhält eine Bank eine Nachricht außerhalb der Nummernfolge, ist die Bank für die Nachforschung der fehlenden Nachrichten und für die weitere Untersuchung des Sachverhaltes verantwortlich.
Für den Nachrichtenverkehr über das System der Deutsche Börse Systems AG gelten abweichende Regeln (siehe
Kapitel 2.5.3.2)
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 18
2
Anwendung der S.W.I.F.T.-Konventionen innerhalb der Orderübermittlung
2.1
Nachrichtenstruktur und -übermittlung
Das Orderübermittlungssystem der Deutsche Börse Systems AG verarbeitet Nachrichten nach den Konventionen
von S.W.I.F.T. II.
Die Banken senden Nachrichten an die Deutsche Börse Systems AG über
• CPU-Verbindung mit Bank-Rechner
Die Datenherkunft und das betroffene Börsensystem werden durch die Nutzung der entsprechenden HeaderAngaben definiert (vgl. 2.5.2):
• Logische Adresserweiterung:
Datenherkunft
(1c)
• Filialcode:
Börsensystem
(3c)
Ordertransaktionen werden nach Prüfung für weitere Bearbeitung in der Eingangs-DB bereitgestellt. Positive und
negative Rückmeldungen werden in Form eines MT n96 in der Ausgangs-DB abgestellt.
Die Eingangs-DB entspricht der Send-Queue und die Ausgangs-DB der Receive-Queue eines CBT von S.W.I.F.T.
Jede DB des Systems verhält sich wie eine Kopie der entsprechenden S.W.I.F.T.- Queue. D.h. von der Orderübermittlung werden keine ACK- oder NAK-Bestätigungen gesendet (gespeichert).
Input- Header
Output- Header
BANK
BÖRSE
Input-Header
Output- Header
S.W.I.F.T.
Output-Header
Input-Header
Um den Banken ein einheitliches Nachrichten-Handling zu gewährleisten, wird seitens der Deutsche Börse Systems
AG zwischen S.W.I.F.T.- und direkter Übertragung (Banken) bezüglich des Austausches der Input- und OutputHeader unterschieden.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.2
Das Orderübermittlungssystem verarbeitet Nachrichten gemäß Abschnitt 2.6 Nachrichtenformate.
05.10.1998
Seite 19
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.3
05.10.1998
Nachrichten-Formate
Das unter Punkt 2.6 Nachrichtenformate aufgezeigte Format beschreibt die Regeln für die Zusammensetzung der
einzelnen Nachrichten für das Orderübermittlungssystem.
Es wurden bei der Definition der Formate die S.W.I.F.T.-Konventionen vollständig eingehalten. Notwendige Änderungen aufgrund bestehender Regeln seitens der Deutsche Börse Systems AG beziehen sich lediglich auf Umwandlung von Kann- in Mußfelder, gekürzte Feldlängen und Einschränkung des Datenformats.
Seite 20
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.4
2.4.1
Allgemeines
05.10.1998
Seite 21
vgl. Abschnitt 1.4 Symbole für Felder und Unterfelder.
2.4.2
Xetra® relevante Änderungen
Sonderzeichen in Textfeldern bzw. im Feld ”Bankinterne Ordernummer” werden bei der Eingabe über eine VALUES
basierte Frontend-Applikation in das Zeichen ”?” konvertiert.
Für die Kennzeichnung der sich durch Xetra® ergebenden Änderungen werden folgende Konventionen benutzt:
1. In der tabellarischen Beschreibung der Nachrichtenformate wurde eine zusätzliche Spalte aufgenommen, in der
die betroffenen Felder durch ein ”X” gekennzeichnet sind. Als betroffen gelten Felder, wenn:
• Feldinhalte für Xetra® eine veränderte Bedeutung haben
• neue Eingabemöglichkeiten für Xetra® generiert wurden
• das Format des Feldes auf Grund von Xetra® angepaßt wurde
• ein Feld für Xetra® erweitert wurde
2. Veränderungen, die sich durch Xetra® ergeben, werden im Teil ”Regeln” bei der jeweiligen Feldbeschreibung im
Detail beschrieben.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.5
Aufbau einer Nachricht
2.5.1
Blockstruktur
05.10.1998
Seite 22
Zwingend vorgeschriebene Blöcke im Orderübermittlungssystem sind der
• Basic-Header
• Anwendungs-Header
• Textblock
2.5.1.1
Blockkennzeichen
=
1:
Anwendungs-Kennzeichen
=
F
Kennung Dateneinheit
=
01
LT Adresse
=
4a2a2c1c3c
Sender-LT für Eingabenachrichten
Empfänger-LT für Ausgabenachrichten
Sitzungsnummer
=
0000
(für das Orderübermittlungssystem nicht relevant)
Folgenummer
=
6n
ISN / OSN
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.5.1.2
05.10.1998
Seite 23
Blockkennzeichen
=
2:
Kennzeichen für
=
1a
I
O
Transaktionstyp
Ein- / Ausgabe
für Eingabe (Bank
für Ausgabe (System
Ù System)
Ù Bank)
=
3n
Nachrichten-Typ
Bestimmungsadresse
=
4a2a2c1c3c
12-stellige S.W.I.F.T.-Adresse des Empfängers
Priorität
=
N
S
für System
U
für Eilig
N
für Normal
Überwachung der Zustellung
=
2
1
Warnmeldung bei Nichtzustellung
2
Meldung bei Zustellung
3
sowohl 1 als auch 2
Periode für Überfälligkeit
=
005
Einheiten von 5 Min
Nur bei Eingabe:
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 24
Nur bei Ausgabe:
Uhrzeit der Eingabe
=
HHMM
Eingabereferenz MIR
=
Sender-LT
Sitzungsnummer
ISN
Ausgabedatum
=
JJMMTT
Uhrzeit der Ausgabe
=
HHMM
Priorität
=
N
S
für System
U
für Eilig
N
für Normal
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.5.1.3
05.10.1998
Seite 25
Angaben im Benutzer-Header werden vom Orderübermittlungssystem ignoriert.
2.5.1.4
Textblock
Siehe Kapitel 2.6 Nachrichtenformate.
2.5.1.5
Das Orderübermittlungssystem überliest sämtliche Trailer-Angaben mit Ausnahme des TNG-Trailers (Training).
Nachrichten mit TNG-Trailer werden von der Deutsche Börse Systems AG geprüft und entsprechend bestätigt
(MT596; DWZ-Ordernummer = 0000000000000), jedoch nicht im System gespeichert. Rückmeldungen zu Trainingsnachrichten werden ebenfalls mit TNG-Trailer, alle anderen jedoch ohne Trailer-Block in die Ausgangs-DB geschrieben.
Trainingsnachrichten müssen von der Bank mit der Orginal-S.W.I.F.T.-Adresse belegt werden und der TNG-Trailer
muß angehängt werden (abweichend zur Übermittlung im S.W.I.F.T.-Netz).
Damit werden Leitungstest und Tests der Formatprüfungsroutinen jederzeit im laufenden System ermöglicht.
Xetra®: Diese Funktion existiert in Xetra® nicht.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.5.2
05.10.1998
Seite 26
Anwendung von Adressen
Die 12-stelligen LT-Adressen für das Börsensystem enthalten in der logischen Adresserweiterung die Art des
Transfers.
Mögliche Werte:
DWZXDEFFAXXX
DWZXDEFFBXXX
=
=
Rechner-Rechner-Verbindung
File-Transfer
DWZX
=
Adress-Code der Deutsche Börse Systems AG
(Die Deutsche Börse Systems AG ist kein S.W.I.F.T.-Teilnehmer)
XXX
=
BOS: BOSS-CUBE
In BOSS-CUBE kann zur Zeit kein Nachrichtenverkehr über das S.W.I.F.T.-Netz stattfinden. Der hier definierte interne Adress-Code bzw. Branch-Code der Deutsche Börse Systems AG kann sich bei Nutzung des S.W.I.F.T.Netzes in späteren Releases ändern (Deutsche Börse Systems AG ist noch kein S.W.I.F.T.-Teilnehmer).
Im Nachrichtentext wird kein Bank Identifier Code benötigt.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.5.3
Folgenummern
2.5.3.1
05.10.1998
Seite 27
Jede Nachricht, die von der Bank versandt wird, muß eine 6-stellige Eingabefolgenummer enthalten, die von der
Bank vergeben wird und pro Tag eindeutig sein muß.
Bei eventuellen Störungen der Verbindung muß die Bank Nachrichten, die seitens der Deutsche Börse Systems AG
nicht quittiert wurden, nochmals mit der gleichen Eingabefolgenummer versenden. Bei der Deutsche Börse Systems
AG wird sichergestellt, daß Nachrichten mit gleicher Eingabefolgenummer nur einmal verarbeitet werden.
2.5.3.2
Jede Nachricht, die von BOSS-CUBE oder Xetra® in die Ausgangs-DB gesendet wurde und an die Bank übertragen
bzw. zur Übertragung bereitgestellt wird, enthält eine Ausgabefolgenummer, die pro Bank fortlaufend und eindeutig
von der Deutsche Börse Systems AG vergeben wird. Diese Ausgabefolgenummer muß von der Bank auf Eindeutigkeit geprüft werden, da nach Störungen ggf. Nachrichten von der Deutsche Börse Systems AG doppelt versandt
werden können (gleiche Ausgabefolgenummer).
Doppelte Nachrichten müssen von der Bank ignoriert werden. Die Nachrichten müssen auf der Bankenseite nicht
zwingend mit fortlaufenden Ausgabefolgenummern ankommen (bei Nutzung mehrerer Empfangs-LTERMs).
Die OSN wird von der Deutsche Börse Systems AG pro Bank in drei verschiedenen Nummernkreisen vergeben (aus DV-technischen Gründen):
• Rückmeldungen zu Orders und Anmeldungen (ab 000001)
• Ereignisse / Ausführungsbestätigungen (ab 300001)
• Schlußnoten aus Geschäftsabwicklung [Boega] (ab 600001): Zur Zeit nicht genutzt für die Orderübermittlung
Zum Tagesende müssen die bei der Bank eingetroffenen Nachrichten pro Nummernkreis in lückenloser Folge vorliegen.
2.5.4
Feld - Standards
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.5.4.1
05.10.1998
Einteilung und Bestandteile der Felder
Die Felder sind in Gruppen eingeteilt, die durch das erste Zeichen des Etiketts gekennzeichnet sind.
2.5.4.2
Feld-Formate und Regeln
Siehe S.W.I.F.T.-Konventionen.
Anmerkung:
2.5.4.3
Übermittelte Kleinbuchstaben werden vom Orderübermittlungssystem in Großbuchstaben umgewandelt.
Pflicht- und Kann-Felder
Das Format jedes Nachrichtentyps unterscheidet eine Anzahl von Feldern fester und variabler Länge, deren Vorhandensein zwingend vorgeschrieben oder freigestellt sein kann.
Ein zwingend vorgeschriebenes Feld muß bei jeder Anwendung vorhanden sein.
Ein nicht zulässiges Feld, oder ein Feld, das in der Formatbeschreibung für einen einzelnen Typ nicht erscheint,
darf niemals vorkommen.
• O = Kann-Feld (Optional)
• M = Pflicht-Feld (Mandatory)
Seite 28
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.5.5
Fehler-Identikatoren
2.5.5.1
Fehler im Nachrichtenkopf / Formatfehler
H01
H02
H15
H20
H25
H30
H50
H99
U00
Z00
2.5.5.2
Fehler in der Nachricht (Mnn)
M60
2.5.5.3
Formatfehler Block 1
Anwendungskennzeichen nicht "F"
falsche Session
falsche Eingabefolgenummer (ISN)
ungültiger Nachrichten-Typ
keine Bestimmungsadresse
Ungültiges Zeichen im Anwendungsheader
ungültiges Zeichen
Fehler im Text (Tnn)
T12
T13
T16
T26
T30
T31
T32
T33
T34
T37
T40
T43
T50
T52
T80
T98
T99
Fehler im Inhalt des Feldes
Zwingend vorgeschriebenes Feld fehlt, Feldfolge unkorrekt
Feldkennzeichen ohne Doppelpunkt; Buchstabe wurde an unerlaubter Stelle gefunden
Feld darf nicht mit "/" beginnen oder mit "/" enden und ebenso darf kein "//" vorkommen
im Feld wurden zu viele Komponenten vorgefunden
Trennzeichen zwischen den Komponenten fehlt oder ist ungültig
Zwingend vorgeschriebene Komponente fehlt
Länge der Komponente zu groß
Länge der Komponente zu klein
Unterfeld 1 in Feld F:35A enthält ungültiges Codewort
Betrag/Zahl fehlt oder erstes Zeichen ist falsch
das Trennzeichen für Dezimalstellen ist kein Komma
Datumsfehler
Ungültiger Währungs-Code
Trailer fehlt
'end of message' falsch
Innerhalb einer Nachricht befindet sich mehr als eine Ende-Sequenz (CrLf-)
05.10.1998
Seite 29
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.5.5.4
Plausibilitäts-Fehler (Cnn)
C03
2.5.5.5
Anzahl der Nachkommastellen größer als für das Feld maximal zugelassen
Systeminterne Fehlermeldungen / Hinweise
Zusätzlich zu den S.W.I.F.T.-Fehler-Identikatoren werden folgende interne Fehlerhinweise verwendet
2.5.5.5.1
BOSS-CUBE - Fehlermeldungen / Hinweise
BC0000F
BC0010F
BC0020F
BC0030F
BC0040F
BC0050F
BC0070F
BC0090F
BC0100F
BC0110F
BC0160F
BC0170F
BC0210F
BC0220F
BC0340F
BC0350F
BC0360F
BC0370F
BC0400F
BC0480F
BC0490F
BC0600F
BC0610F
BC0630F
BC0650F
BC0660F
BC0670F
BC0680F
Keine Berechtigung zu dieser Funktion
Mußfeld fehlt
Fehler bei Abhängigkeitsprüfung
Feld muß gültigen Schlüsselwert enthalten
Feld muß gültiges Datum enthalten
Feld muß WKN oder Kürzel enthalten
Feld muß numerisch sein
Falsche Stellenzahl
Feld enthält unzulässige Zeichen
WKN nicht vorhanden
Feld nicht änderbar
Limit nicht zulässig, da Geschäftsart fehlerhaft
Feldeingabe nicht erlaubt
Funktion z.Z. gesperrt
Börsenplatz ungültig oder nicht zugelassen
Orderaufgeber ungültig
Wegen-Bank ungültig
Empfänger ungültig
Eingeber ungültig
Nominale ist kleiner Kleinste-Handelbare-Einheit
Handelshinweis < EK > und < SK > nicht erlaubt
Maklerbüro ist zur Zeit nicht besetzt
WKN am entspr. Börsenplatz für BOSS-CUBE nicht zugelassen
Die Börse des Kontrahenten hat einen Feiertag
WKN ist kursausgesetzt
Tagesgültige Splitorder nach Kassakurs eingegeben
Tagesgültige Kassaorder nach Kassakurs eingegeben
Tagesgültige Order zum ersten Kurs nach erstem Kurs eingegeben
05.10.1998
Seite 30
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
BC0690F
BC0700F
BC0710F
BC0720F
BC0750F
BC0760F
BC0780F
BC0790F
BC0810F
BC0830F
BC0840F
BC0850F
BC0860F
BC0870F
BC0880F
BC0890F
BC0900F
BC0910F
BC0920F
BC0940F
BC1180F
BC1190F
BC1200F
BC1210F
BC1220F
BC1230F
BC1240F
BC1250F
BC1260F
BC1270F
BC1280F
BC1290F
BC1300F
BC1310F
BC1320F
BC1330F
BC1340F
BC1390F
BC1460F
BC1480F
BC1500F
BC1520F
BC1530F
BC1620F
BC1680F
BC1690F
Tagesgültige Order nach Orderannahmeschluß
Gültigkeit der Order überschreitet Endfälligkeit
Nur tagesgültig zulässig
Kein Handelshinweis erlaubt
Nur Handelshinweis < KS > zulässig
Limit ungültig
Limitzusatz nicht zulässig
Limitzusatz muß zu Geschäftsart passen
Nominale weicht von ausführbarer Nominale ab
WKN-Änderung/Löschung nicht zulässig
Orderänderung wegen Teilausführung nicht zulässig
Keine Berechtigung zur Orderänderung/Löschung
Provision/Spesen nur bei Wegen-Eingabe
Kompensation bei Wegen-Eingabe nicht erlaubt
Kassamarkt gesperrt zur Kursfeststellung
Variabler Markt gesperrt zur Kursfeststellung
Kurswert überschreitet zulässigen Grenzwert
Seriennummer nur bei Verkauf
WKN ist keine gültige Seriennummer
Bankinterne Ordernummer nicht eindeutig
Absender ist kein Orderrouting-Teilnehmer
Nominale ist größer als Ursprungsnominale
Restnominale ist kleiner Kleinste-Handelbare-Einheit
Ursprungsorder: Marktzugehörigkeit darf sich nicht ändern
Ungültiges Paßwort
Paßwort abgelaufen
Ungültiges neues Paßwort
Ungültige User-ID
Ablaufdatum für User-ID überschritten
Freigabe der Berechtigung (durch Security-Beauftragten) fehlt
Ersterfassungs-Paßwort vorhanden; Bitte ändern
Nominale ist fehlerhaft
WKN bzw. ISIN-Nr. ist fehlerhaft
Limitbetrag ist fehlerhaft
Limitzusatz ist fehlerhaft
Bank (LTERM) nicht angemeldet
Bank (LTERM) bereits angemeldet
Nachrichtenumfang nicht zulässig
Empfänger in BOSS-CUBE nicht zugelassen
Restorder: Marktzugehörigkeit darf sich nicht ändern
Keine Order zu bankinterner Ordernummer vorhanden
Order ist bereits ausgeführt
Tagesgültige Order nach SK eingegeben
WKN ist gesperrt (Börsensperre
WKN ist an entsprechender Börse nicht notiert
Geschäftsart ungültig
05.10.1998
Seite 31
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
BC1940F
BC1950F
BC1960F
BC1970F
BC1980F
BC1990F
BC2000F
BC2020F
BC2030F
BC2070F
BC2250F
BC2410F
BC2680F
BC2960F
BC3270F
BC3280F
BC3600F
BC3650F
BC3700F
BC3710F
BC3720F
BC3780F
BC3790F
BC3910F
BC3950F
BC4400F
BC4670F
BC4680F
BC4690F
BC4740F
BC4880F
BC4970F
BC4980F
BC4990F
BC5000F
BC5120F
BC5130F
BC5340F
BC5390F
BC5400F
BC5440F
BC5450F
BC5460F
BC5490F
BC5530F
BC5540F
Datensatz nicht entschlüsselbar
Satz mit ungültigen Messagetype
Änderung/Löschung für Order, die nicht vorhanden ist
Änderung/Löschung für Order, die nicht änderbar ist
Änderung/Löschung für Order, die nicht mehr aktiv ist
Nachricht von Bank wurde nicht über Sende-LTERM d. Bank empfangen
Seriennummer nur bei Verkauf oder Kompensation
Nachricht ist nicht für File-Transfer zugelassen
FT-Änderung mit Nominale ohne DWZ-Ordernummer
Unlimitierte Kompensationen sind nicht möglich
Nominale ist kein Vielfaches des Mindestbetrag Variabler Handel
Nominale für Split entspricht aktueller Nominale
Pfennigbetrag unzulässig
Nominale ist kein Vielfaches der kleinsten handelbaren Einheit
EK- und SK-Orders sind nur tagesgültig möglich
Feld Limitzusatz nicht änderbar
Feld enthält ungültige Sonderzeichen
WKN gelöscht
Falsches Trennzeichen
Feldkomponenten entsprechen nicht der vorgeschriebenen Länge
Fehlende Headerkomponenten
WKN ist für BOSS-CUBE nicht zugelassen
Verarbeitung für Serien-WKN nicht zulässig
Kein Skontroführender Makler zu dieser WKN vorhanden
WKN ist nicht variabel notiert
Limitzusatz SB/SL für Gattung nicht zugelassen
Bei SB/SL-Orders ist HHW EK, SK nicht erlaubt
Sender-LTERM ist identisch mit einem angemeldeten Empfänger-LTERM
Empfänger-LTERM ist identisch mit einem angemeldeten Sender-LTERM
Orderannahmeschluß erreicht; Kursfeststellung für WKN nicht abgeschlossen
Orderänderung w/Verarbeitung Nebenrechte momentan nicht möglich
Tagesgültige Order nach Buchungsschnitt
Tagesgültige Order nach Schlußkurs
Tagesgültige Kassaorder nach Kassakurs
Tagesgültige Order mit HHW 'EK' nach erstem Kurs
Angegebene Stück/Nominale (Ursprung) weicht von aktuellen Wert der Order ab
Änderung des Handelshinweises nicht erlaubt
Gattung nicht mehr notiert
Kein Handelshinweis zulässig
Aufgeber kein ECU-Clearer
Für diese Gattung ist keine Eingabe einer Kassaorder möglich
Gattung wird nur außerbörslich gehandelt
In dieser Gattung wird kein Einheitskurs notiert
Währung entspricht nicht Währung der Notierung
Aufgeber ist kein AKV-Teilnehmer
Funktion ist noch nicht zugelassen
05.10.1998
Seite 32
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
BC5600F
BC5870F
BC6850F
BC9990F
Hinweis:
05.10.1998
Seite 33
Gattung zur Zeit inaktiv
Aufgeber und Wegen-Kontrahent müssen PUEV-Teilnehmer sein
Änderung nicht möglich; SB/SL-Order wird zur Zeit auf billigst/bestens umgesetzt
Systemfehler
Falls ein Feld aus mehreren Unterfeldern besteht, wird in der 6. Stelle des Fehler-KZ die Nummer des ersten fehlerhaften Unterfeldes angegeben.
Bsp.: BC0072F ==> 2. Unterfeld ist nicht numerisch
Xetra: Dieses Verhalten gilt auch für die folgenden Xetra Fehlermeldungen, falls eine Identifizierung des fehlerhaften Unterfeldes möglich ist.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.5.5.5.2
05.10.1998
Seite 34
Xetra® - Fehlermeldungen / Hinweise
Aktion
Umgebung
1. Entschlüsseln S.W.I.F.T.-Satz,
formale Grobprüfung,
Berechtigungsprüfung
(Security, Anmeldung)
2. Prüfen der Daten auf formale und
fachliche Korrektheit
3. Prüfen Nachricht an Xetra®
Fehlercode
Angabe Feldetikett fehlerhaftes Feld in
Nachricht
formaler Fehler
Host
Allgemeiner BOSSTeil
BCnnnnF
ja
Xetra Orderrouting 1. formaler Fehler
2. inhaltlicher Fehler
ja
3. technische Fehler
XKnnnnF
XKnnnnF u.
XAnnnnF
BC9990F
1. formaler Fehler
2. inhaltlicher Fehler
XnnnnnF
XnnnnnF
nein
Xetra®-Backend
Fehlertyp
1. Die detaillierten Fehlermeldungen beim Prüfen der Nachricht an Xetra sind der aktuellsten Version der Dokumentation ”Xetra Release 3 - VALUES API Programming Version” zu entnehmen und werden hier nicht mehr
explizit aufgeführt.
2. Die Fehlermeldungen beim Entschlüsseln des S.W.I.F.T.-Satzes, bei der formalen Grobprüfung, und der Prüfung der Berechtigung (Security, Anmeldung) entsprechen den unter Kapitel 2.5.5.5.1 BOSS-CUBE - Fehlermeldungen / Hinweise beschriebenen Fehlermeldungen.
3. Im folgenden sind die Fehlermeldungen, deren Ursache auf formale und inhaltlichen Fehler im Xetra Orderrouting SNA System zurückzuführen ist, aufgeführt:
XK0010F
XK0020F
XK0100F
XK0110F
XK0210F
XK0300F
XK0310F
XA2000F
XA2010F
XA2020F
Absender ist kein Xetra - Teilnehmer
Xetra Orderrouting nicht möglich (MISS not available)
Orderteillöschung für Xetra nicht möglich
Ordersplit für Xetra nicht möglich
Feldeingabe für Xetra nicht erlaubt
Orderstatus nicht definiert - bitte prüfen
(Order konnte unter Umständen nicht bearbeitet werden)
Evtl. fehlende Broadcasts
(Dieser Fehler wird nicht im Nachrichtentyp MT596, sondern nur im Nachrichtentyp MT551 im Feld
F:72 für das Ereignis XEBAT geliefert. Vgl. 2.6.2.4 Ereignisse im WP-Geschäft (MT 551))
Orderänderungs- / Orderlöschanfrage ist nicht eindeutig
Angegebene Stück/Nominale (Ursprung) weicht von dem aktuellen Wert der Order ab
Stop-Limit Order kann nicht geändert werden
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.5.6
05.10.1998
Seite 35
Anbindungsarten
Für die Kreditinstitute werden zwei Arten der Anbindung an die verschiedenen Börsenplätze angeboten. Folgende
Restriktionen sind zu beachten:
BOSS-CUBE:
An den jeweiligen Börsen dürfen nur Kreditinstitute handeln, die ein KV-Konto am gleichen Platz besitzen (d.h. an der Börse Düsseldorf dürfen nur Kreditinstitute mit KVOrts-KZ = 4 handeln etc.).
Xetra®:
Voraussetzungen für das Handeln am Börsenplatz Xetra sind die Xetra - Mitgliedschaft und die Xetra® - Member-ID. Es erfolgt eine eindeutige Zuordnung der KVKonto-Nr zur Xetra® - Member-ID.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.5.6.1
05.10.1998
Seite 36
Dezentrale Anbindung
Jedes KV-Konto wird als eigenständiges Institut behandelt. Es können von einem Rechenzentrum Nachrichten für
alle Niederlassungen (KV-Konten / Börsenplätze) ausgetauscht werden. Dabei können für alle Niederlassungen inkl.
der Zentrale die gleichen Leitungsverbindungen genutzt werden. Folgende Aktionen müssen jedoch pro Niederlassung/Zentrale (KV-Konto/Börsenplatz) durchgeführt bzw. beachtet werden:
• Generierung von Sets von Logical-Units (LUs; siehe Technische Anbindung Teile 2 bis 5)
• Anmeldungen an BOSS-CUBE und Xetra®:
− für jedes LTERM (Sender/Empfänger) erfolgt eine Anmeldung durch die Bank, gekennzeichnet
durch die KV-Konto-Nr.
− für jedes LTERM erhält das Kreditinstitut eine Anmeldebestätigung
• Abmeldungen an BOSS-CUBE und Xetra®:
− für jedes LTERM (Sender/Empfänger) erfolgt eine Abmeldung durch die Bank, gekennzeichnet
durch die KV-Konto-Nr.
− für jedes LTERM erhält das Kreditinstitut eine Abmeldebestätigung; bei der jeweils letzten Abmeldung (pro KV-Konto-Nr.) erfolgt die Angabe der höchsten vergebenen OSNs pro KV-KontoNr.
• ISN/OSN-Vergabe:
Die ISN/OSN-Vergabe bzw. Prüfung erfolgt sowohl bei der Deutsche Börse Systems AG als auch
bei den angeschlossenen Kreditinstituten pro Niederlassung bzw. Zentrale d.h. pro KV-Konto-Nr.
• Bundesweit gültige Ereignismitteilungen (MT551) werden pro KV-Konto-Nr erstellt. z.B.:
− BOEND
− NOT02
• Belegung des User-Profiles in der Verarbeitungssteuerung pro KV-Konto-Nr.
• S.W.I.F.T.-Adresse der Nachrichtenformate:
jedes KV-Konto muß eine eigene S.W.I.F.T.-Adresse im Header angeben
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.5.6.2
05.10.1998
Seite 37
Zentrale Anbindung
Die Zentrale mit allen Niederlassungen eines Kreditinstituts werden wie ein Institut behandelt. Der Datenaustausch
erfolgt zwingend über ein Rechenzentrum. Folgende Aktionen werden lediglich einmal für die Zentrale durchgeführt
und gelten damit für alle Niederlassungen (Börsenplätze / KV-Konto-Nr.) analog:
• Generierung von einem Set von Logical-Units (LUs; siehe Technische Anbindung Teile 2 bis 5) für die
Zentrale
• Anmeldungen an BOSS-CUBE und Xetra®:
− für jedes LTERM (Sender/Empfänger) erfolgt lediglich für die Zentrale, gekennzeichnet durch die
KV-Konto-Nr. der Zentrale, eine Anmeldung
− für jedes LTERM erhält die Zentrale eine Anmeldebestätigung
• Abmeldungen an BOSS-CUBE und Xetra®:
− für jedes LTERM (Sender/Empfänger) der Zentrale erfolgt gekennzeichnet durch die KV-KontoNr., eine Abmeldung durch die Bank
− für jedes LTERM erhält das Kreditinstitut eine Abmeldebestätigung; bei der letzten Abmeldung
der Zentrale erfolgt die Angabe der höchsten vergebenen OSNs der Zentrale.
• ISN/OSN-Vergabe:
Die ISN/OSN-Vergabe bzw. Prüfung erfolgt für alle Niederlassungen in einem Nummernkreis unter der Zentrale. Somit ist eine Retrieval-Anforderung für alle Sätze einer Niederlassung nicht möglich, da
pro Niederlassung keine ISN/OSN-Vergabe stattfindet.
• Bundesweit gültige Ereignismitteilungen (MT551) werden nur einmal für die Zentrale den Kreditinstituten
übermittelt. z.B.:
− BOEND
− NOT02
• Belegung des User-Profiles in der Verarbeitungssteuerung erfolgt nur einmal für die Zentrale des Kreditinstituts
• S.W.I.F.T.-Adresse der Nachrichtenformate
alle Nachrichten enthalten die S.W.I.F.T.-Adresse der Zentrale im Header. Die Identifizierung
der KV-Konto-Nr. des Instituts (Zentrale bzw. Filiale) erfolgt in den Nachrichtenformaten
MT500/MT501 über Feld F:82D (vgl. Kap. 2.6.2.1 und Kap. 2.6.2.2).
Bemerkung: Für File-Transfer ist sowohl die dezentrale als auch die zentrale Anbindung realisiert.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.6
05.10.1998
Nachrichtenformate
Für sämtliche Nachrichten aus der Kategorie 5 müßte ein Authenticator ermittelt werden. Das Orderübermittlungssystem erstellt keinerlei Trailer-Angaben (außer TNG) und ist auch nicht berechtigt, AuthentikatorBerechnungen durchzuführen.
Erst wenn die Deutsche Börse Systems AG selbst S.W.I.F.T.-Teilnehmer wird, können Authentikatoren mit den
Banken ausgetauscht werden.
Im folgenden werden zur Übersicht alle innerhalb vom Orderrouting (BOSS-CUBE und Xetra®) definierten Nachrichtentypen genannt.
(1)
Von den Banken zum System der Deutsche Börse Systems AG
(1.1)
Programm-Verbindung (LU 6.1 / LU 6.2)
(1.1.1)
(1.1.2)
(1.1.3)
(1.1.4)
(1.1.5)
(1.1.6)
(1.1.7)
(1.1.8)
Anmeldung an das System (MT000)
Passwortänderung (MT001)
Änderung Nachrichtenumfang (MT001)
Abmeldung vom System (MT002)
Anforderung historischer Nachrichten (MT020)
Orderzugänge (MT500/MT501)
Änderungen/Streichungen von Orders (MT595)
Rückmeldung von fehlerhaften Nachrichten (MT021)
Hinweis:
Der Empfangstransaktionscode auf Seiten der Deutsche Börse Systems AG ist für alle Nachrichtentypen:
BC$nnnnA (nnnn = KV-Nummer des Kreditinstituts)
(2)
Von dem System der Deutsche Börse Systems AG zu den Banken:
(2.1)
Programm-Verbindung (LU 6.1 / LU 6.2)
(2.1.1)
(2.1.2)
(2.1.3)
(2.1.4)
(2.1.5)
(2.1.6)
Anmeldungsbestätigung (MT001)
Bestätigung der Passwortänderung (MT001)
Bestätigung der Änderung des Nachrichtenumfangs (MT001)
Abmeldungsbestätigung (MT003)
Bestätigung der Anforderung von historischen Nachrichten (MT021)
Bestätigung bzw. Fehlermeldung bei maschinell übermittelten Orderzugängen, -änderungen und streichungen (MT596)
Seite 38
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
(2.1.7)
(2.1.8)
(2.1.9)
(2.1.10)
(2.1.11)
05.10.1998
Seite 39
Übermittlung/Protokollierung aller Orderzugänge (MT500/MT501), -änderungen und -löschungen
(MT595), die über Terminaleingaben der Bank, von Maklern oder in Xetra® über eine VALUES basierte
Frontend-Applikationen (mit der exklusiven Trader-ID „ORSnnn“; z.B.: „ORS002“, aber nicht „ORS001“,
da diese Trader-ID von Xetra Orderrouting SNA benutzt wird) in das System eingegeben wurden.
Ausführungsbestätigungen (MT519)
Ausführungsbestätigungen auf Gattungsebene für Kassakursfeststellungen (nur 'Bezahlt'-Kurse)
(MT551)
Orderänderungen/-löschungen durch das System
− auf Gattungsebene (MT551)
− auf Einzelorderebene (MT595)
Ereignismitteilungen (MT551)
− Kursaussetzungen und Rücknahme von Kursaussetzungen
− Plus-/Minusankündigungen und Rücknahme von Plus-/Minusankündigungen
− Ankündigung und Rücknahme einer Rationierung
− Ankündigung Bezugsrechtshandel
− Ankündigung und Rücknahme einer Kurstaxe
− Einfügen, Ändern und Löschen eines Kurses
− Allgemeine Information
− Unterbrechung und Freigabe der Börsenversammlung
− Verlängerung der Börsenzeit
− Verlängerung der Geschäftseingabezeit; Eingabeende
− Betriebsstörung wegen technischer Probleme
− Wiederaufnahme des normalen Betriebes nach einer Betriebsstörung
− Handelsunterbrechung in einer Gattung
Hinweis:
• Empfangstransaktionscodes für Banken mit LU6.1-Anbindung und IMS:
− BC01nnnn-BC04nnnn (nnnn = KV-Konto-Nr.)
• Empfangstransaktionscodes für Banken mit LU6.1-Anbindung und CICS:
− BC01-BC04
• Zuordnung von Nachrichten zu Transaktionscodes:
− BC01nnnn bzw. BC01:2.1.1.; 2.1.2.; 2.1.3.; 2.1.4.; 2.1.5.
− BC02nnnn bzw. BC02:2.1.6.; 2.1.7.
− BC03nnnn bzw. BC03:2.1.8.; 2.1.9.
− BC04nnnn bzw. BC04:2.1.10; 2.1.11.
• Nachrichtenaufbau siehe Kapitel Bankenanbindung über LU6.1
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
(2.2)
05.10.1998
Seite 40
File-Transfer
(2.2.1)
Bestandsabgleich (BOSS-CUBE / nicht Xetra®):
Enthält alle noch ausführbaren Orders zu Kontrollzwecken (MT500/MT501) und evtl. dazugehörige Folgesätze (MT596); enthält zusätzlich alle Orders (MT500/MT501), die wegen Einstellung der Notierung in
der Tagesendverarbeitung gestrichen wurden und evtl. dazugehörige Folgesätze (MT596).
Xetra:
Ein Bestandsabgleich kann über die eigene MISS aus den Reports (und den darin enthaltenen Informationen) durchgeführt werden.
(2.2.2)
Historische Nachrichten:
Falls die Leitungsverbindung zwischen Bank und der Deutsche Börse Systems AG bis zum Online-Ende
gestört ist, kann ein FT/Datenträger der am Tage angefallenen Nachrichten telefonisch bei der Deutsche
Börse Systems AG angefordert werden).
Im folgenden werden die einzelnen Nachrichtentypen detailliert beschrieben.
Anmerkung:
(1)
Die Satzaufbauten der einzelnen Nachrichtentypen sind bei Programm-Verbindung und File-Transfer
identisch.
(2)
Bei File-Transfers ist die zu übertragende Datei wie folgt aufzubauen:
− Vorsatz (MT000 bzw. MT598)
− 1. Datensatz
− 2. Datensatz
− ...
− n. Datensatz
− Nachsatz (MT002 bzw. MT598)
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.6.1
05.10.1998
Seite 41
Um die volle Kompatibilität mit S.W.I.F.T. II zu gewährleisten, werden die System-Nachrichten in den MT598 eingebettet.
Da die nachfolgend beschriebenen System-Nachrichten als Textstring dargestellt werden, können die Formate nach
den Bedürfnissen der Deutsche Börse Systems AG individuell angepaßt werden. Dies gilt z.B. für Geschäftsvorfallcode, andere Darstellung der User-ID etc. Dabei darf jedoch die Gesamtlänge von 73x nicht überschritten werden.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.6.1.1
05.10.1998
Seite 42
Anmeldung (MT 000)
Urheber:
Benutzer (Bank) und Systeme (BOSS-CUBE und Xetra®)
Bank:
Das logische Terminal (LTERM) gibt sich gegenüber dem System der Deutsche Börse
Systems AG zu erkennen. Mit der Anmeldung wird der Umfang des Nachrichtenaustauschs für das betreffende LTERM definiert. Dieser Umfang kann durch MT001 modifiziert werden. Erst nach erfolgreicher Anmeldung kann die Bank weitere Nachrichten
an das System senden bzw. Nachrichten vom System erhalten. Ausnahme: Passwortänderung ist ohne vorherige Anmeldung möglich.
System:
Vorsatz bei File-Transfers
Format:
10x/[8x1a]/[5a]/[6n6n]/
Inhalt:
User-ID,
bei Filetransfer = "BOSSnnn":
Anwendungskennung ("BOSS")
GV-Code
− 011
Orderbestandsabgleich
− 016
Historische Nachrichten (ab Anfangs OSN)
10x
Paßwort, (entfällt bei Filetransfer)
KZ Sender/Empfänger (entfällt bei Filetransfer)
S: Bank sendet Nachrichten über entspr. LTERM
E: Bank empfängt Nachrichten über entspr. LTERM
/[8x
1a]
Umfang Nachrichtenaustausch: (entfällt bei Filetransfer; nur bei Anmeldung
durch Bank und KZ Sender/Empfänger = 'E')
1. Stelle:
Bestätigung/Rückmeldung von Orderübermittlung
2. Stelle:
Ausführungsbestätigung
3. Stelle:
Ereignismitteilung
4. Stelle:
Veränderung Orderbestand wegen Nebenrechten
Für Xetra® ist dieses Feld nicht relevant
5. Stelle:
Übermittlung der BOSS-CUBE Terminaleing. / Eingabe
über VALUES basierte Frontend-Applikation
Default:
Benutzerprofile (muß der Deutsche Börse Systems AG vor
Einsatztermin schriftlich mitgeteilt werden).
/[5a]
Das im Benutzerprofile (siehe Anwendungsbeschreibung) nicht definierte Ereignis 'Betriebsstörung' wird den Banken generell mitgeteilt unabhängig von der
Parametrierung.
Y/N
Y/N
Y/N
Y/N
Y/N
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 43
Alle im Benutzerprofile mit 'INFO ...' beginnenden Nachrichten werden hier
unter dem Begriff 'Ereignismitteilung' zusammengefaßt parametriert.
Erstellungsdatum (JJMMTT)
(nur bei File-Transfer; der Bestandsabgleich wird am Ende des Börsentages erstellt und enthält hier generell das Datum des abgelaufenen Börsentages, auch
wenn der Datenträger am Folgetag erstellt wird).
Erstellungsuhrzeit (HHMMSS)
(nur bei File-Transfer)
Zu Anmeldung:
Die Bank muß sich pro LTERM bei dem System der Deutsche Börse Systems AG anmelden.
Es wird pro Bank eine Anmeldung über zwei LTERMs (LUs) von der Deutsche Börse Systems AG empfohlen:
• ein LTERM zum Senden von Nachrichten (max. 4 LTERMS möglich)
• ein LTERM zum Empfangen von Nachrichten (max. 4 LTERMS möglich)
Hinweis:
Die Rückmeldungen auf Anmeldung / Abmeldung / Passwortänderung / Anforderung
historischer Nachrichten (MT0NN) werden jeweils über den LTERM versandt, auf dem
die entsprechende Anfrage erfolgte (also auch über den Sende-LTERM).
Die Anmeldung erfolgt durch Angabe von USER-ID und PASSWORT. Eine Anmeldung über beide LTERMs mit der
gleichen USER-ID ist möglich. Es sollte daher für jede Bank eine USER-ID definiert werden, die die Berechtigung
erhält, über Programm-Programm-Verbindung, Nachrichten zu senden.
Die Einrichtung der USER-ID inkl. Berechtigungen kann durch den Security-Beauftragten der Bank über Terminaleingabe durchgeführt werden.
Bei der Einrichtung einer USER-ID wird ein Ersterfassungs-Paßwort vergeben. Dieses muß vor der ersten Anmeldung mit der USER-ID geändert werden (MT001). Das PAßWORT hat nur für einen gewissen Zeitraum (z.Z. 1
Monat) Gültigkeit. Nach Ablauf dieser Zeitspanne wird eine Anmeldung mit dem Hinweis BC1230F: 'PASSWORT
ABGELAUFEN' abgelehnt. Eine gültige Anmeldung ist erst nach Änderung des Paßworts möglich.
Weitere Informationen sind der Beschreibung des Security-Systems für Online-Anwendungen der Deutsche Börse
Systems AG zu entnehmen.
Treffen Nachrichten von Banken ein, ohne daß eine gültige Anmeldung erfolgt ist, so werden diese Nachrichten abgewiesen und den Kreditinstituten eine entsprechende Rückmeldung gesandt:
(MT596; Feld F:76:/3n5; Fehlermeldung BC1330F).
2.6.1.2
Anmeldungsbestätigung, Passwortänderung und Änderung des Nachrichtenumfangs (MT 001)
Urheber:
/[6n
6n]/
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
Bank:
Systeme:
05.10.1998
Seite 44
(1)
Änderung des Paßworts: In zyklischen Abständen verlangt das System eine Änderung
des Paßworts durch den Benutzer. Eine Änderung des Paßworts ist ohne vorherige
erfolgreiche Anmeldung an das System möglich
(2)
Änderung des Nachrichtenumfangs: Der in der Anmeldung spezifizierte Umfang kann
hierüber modifiziert werden.
(1)
(2)
(3)
Bestätigung/Ablehnung der Anmeldung (MT000)
Bestätigung/Ablehnung der Passwortänderung (MT001)
Bestätigung/Ablehnung der Änderung des Nachrichtenumfangs
Format:
[10x]/[8x][1a]/[8x]/[5a]/3n/[3x7x]
Inhalt:
User-ID,
Altes Paßwort,
KZ Sender/Empfänger (vgl. MT000)
(nur bei GV-Code=102;001;002;005;006)
10x
/[8x]
[1a]
Neues Paßwort,
/[8x]
Umfang Nachrichtenaustausch,(nur bei Empfangs-LTERM möglich; siehe
MT000) Default: aktuellen Status beibehalten
/[5a]
Geschäftsvorfallcode von der Bank an System:
101
Passwortänderung
102
Änderung Nachrichtenumfang
/3n
Geschäftsvorfallcode von System an Bank
001
Anmeldung akzeptiert
002
Anmeldung abgelehnt
003
Passwortänderung akzeptiert
004
Passwortänderung abgelehnt
005
Änderung Nachrichtenumfang akzeptiert
006
Änderung Nachrichtenumfang abgelehnt
007
ungültiger Nachrichtentyp (MT) bzw. Geschäftsvorfallcode
Fehlercode:
Feldetikett, Fehlerhinweis (mögliche Fehlerhinweise vgl. Kap. 2.5.5)
/[3x7x]
Hinweis:
Die hier definierten Nachrichten, die an die Banken gesendet werden, enthalten generell (Ausnahme: GV-Code=007
oder Datenfelder in S.W.I.F.T.-Nachricht nicht identifizierbar) die von der Bank gelieferten Datenfelder (z.B. User-ID,
altes Paßwort, neues Paßwort, Umfang Nachrichtenaustausch) inkl. Geschäftsvorfallcode und ggf. Fehlercode.
2.6.1.3
Abmeldung (MT 002)
Urheber:
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
Bank:
Abmeldung des logischen Terminals
(LTERM) gegenüber dem System.
Systeme:
Nachsatz bei File-Transfers
Format:
10x/[6n]
Inhalt:
User-ID
bei File-Transfer: "BOSS" (Anwendungskennung)
nur bei File-Transfer:
Anzahl übertragener Sätze (inkl. Vor- und Nachsatz)
05.10.1998
Seite 45
10x
/[6n]
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.6.1.4
05.10.1998
Seite 46
Abmeldungsbestätigung (MT 003)
Urheber:
Systeme (BOSS-CUBE und Xetra®)
Systeme:
Bestätigung der Abmeldung (MT002) durch das System oder automatische Abmeldung
durch das System.
Format:
10x/6n/3n/[6n]/[6n]/[3x7x]
Inhalt:
User-ID,
Uhrzeit,
10x
/6n
Geschäftsvorfallcode:
021
Abmeldung akzeptiert
022
Abmeldung abgelehnt
023
automatische Abmeldung; Orderannahme wegen techn. Probleme nicht möglich
/3n
letzte OSN des 2. Nummernkreises
(Ereignisse/Ausführungsbestätigungen)
/[6n]
letzte OSN des 3. Nummernkreises (SNO)
/[6n]
Fehlercode:
Feldetikett, Fehlerhinweis (mögliche Fehlerhinweise vgl. Kap. 2.5.5)
/[3x7x]
Hinweis:
Die letzte von der Deutsche Börse Systems AG vergebene OSN für Orderrückmeldungen / Systemmeldungen
(1.Nummernkreis) ist generell die OSN der Abmeldebestätigung.
Die letzten OSNs des 2. bzw. 3. Nummernkreises sind nur bei der Abmeldungsbestätigung des letzten (falls mehrere LTERMs zulässig) Banken-Empfänger-LTERMs mit GV-Code = 021 oder 023 belegt.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.6.1.5
05.10.1998
Seite 47
Retrieval-Anforderung (MT 020)
Urheber:
Benutzer (Bank).
Funktion (Bank):
Anforderung von am gleichen Tage gesendeten Nachrichten ab einer bestimmten OSN
(Output-Sequence-Number). Es werden, unabhängig von einer erfolgten Anmeldung,
alle der Bank nach dem entsprechenden Benutzerprofil zustehenden Nachrichten auf
einer Ausgangs-Datenbank zur Verfügung gestellt. Die Bank kann über diesen Nachrichtentyp alle aufgelaufenen Nachrichten anfordern (bei verspäteter Anmeldung, Systemausfall der Bank, etc.). Aufgrund dieser Anforderung werden nur Nachrichten gesendet, die bei der Anmeldung im Nachrichtenumfang vorgegeben wurden.
Da die OSN für drei verschiedene Nummernkreise vergeben wird (vgl. Kap. 2.5.3.2),
muß pro Nummernkreis eine Anforderung der historischen Nachrichten erfolgen (d.h.
bei Anforderung ab OSN=17 werden keine Meldungen aus dem bei 300001 beginnenden Nummernkreis übermittelt).
Eine Anforderung der Nachrichten ist bis 18.00 Uhr möglich. Ist eine Bank bis zu diesem Zeitpunkt nicht in der Lage, die Nachrichten zu empfangen, so kann ein Datenträger mit den entsprechenden Informationen angefordert werden (File-Transfer Historische Nachrichten: siehe MT000/GV-Code = 016).
MT 020 Retrieval-Anforderung
O/M
Block
Blockbezeichnung
Format
O
153:
Anfangs-OSN
6n
O
254:
Beginn-MOR / Ende-MOR (siehe 1.5.1.2)
28c28c
Regel:
Die Angabe eines der beschriebenen Blöcke ist Pflicht.
Block 153 (Anfangs-OSN)
Bei der Anforderung historischer Nachrichten über Block 153 (Anfangs-OSN) werden
von der angeforderten OSN beginnend alle vorliegenden Nachrichten übermittelt. Dabei werden alle während der Übertragung der historischen Nachrichten neu entstehenden Nachrichten gesammelt und am Ende der Übertragung in der richtigen Sequenz
übermittelt.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 48
Block 254 (Beginn-MOR / Ende-MOR)
Bei der Anforderung historischer Nachrichten über Block 254 können historische Nachrichten für einen zusammenhängenden Bereich von OSN's angefordert werden (von
OSN, bis OSN).
Aufbau der MOR (siehe 1.5.1.2):
Ausgabedatum
Empfänger-LT
Sitzungs-Nr.
OSN
(JJMMTT)
(lt. Header)
(lt. Header)
(Die Felder Ausgabedatum, Empfänger-LT, Sitzungs-Nr. werden vom Orderübermittlungssystem nicht geprüft).
6n
12c
4n
6n
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.6.1.6
05.10.1998
Seite 49
Antwort auf Retrieval (MT 021)
Urheber:
Bank:
Rückmeldung von fehlerhaften Übertragungen der Deutsche Börse Systems AG.
System:
(1)
Beantwortung der Anforderung von hist. Nachrichten (MT020).
(2)
Beginn-/Endemitteilung der Übermittlung hist. Nachrichten
MT 021 Retrieval-Antwort
O/M
Block
Blockbezeichnung
O
---
Original-Header
O
---
Originaltext
O
421:
Fehlercode / Hinweiscode
ANF - Beginn der Historie-Übertragung
END - Ende der Historie-Übertragung
alle S.W.I.F.T.-Codes
Regel:
Format
3c
Die Anforderung von historischen Nachrichten (MT020) wird wie folgt behandelt:
Bei korrektem Aufbau der Nachricht (MT020) wird dem Kreditinstitut eine Bestätigung
der Anforderung übermittelt (MT021). Falls keine historischen Nachrichten bzgl. der
vorausgegangenen Anforderung (MT020) vorhanden sind, wird lediglich eine Bestätigung der Anforderung übermittelt (MT021 / Block 421:END). Falls historische Nachrichten vorhanden sind, wird zunächst eine Bestätigung (MT021 / Block 421:ANF), danach die angeforderten historischen Nachrichten (MT5xx) übermittelt. Den Abschluß
der Historienübertragung bildet eine entsprechende Ende-Mitteilung (MT021 / Block
421:END). Der gesamte Nachrichtenblock wird über die gleiche LU (LTERM) gesendet, auf der die Anforderung (MT020) bei der Deutsche Börse Systems AG eingetroffen ist.
Block 421:
Bei der Rückmeldung von fehlerhaften Übertragungen durch das Kreditinstitut, können
alle definierten S.W.I.F.T.-Codes verwendet werden.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.6.2
2.6.2.1
Kauforder (MT 500)
Urheber:
Bank:
Übermittlung von Kauforders (Zugänge), Änderungen und Löschungen sind über
MT595 mitzuteilen.
BOSS-CUBE:
Xetra®:
05.10.1998
Seite 50
(1)
Übermittlung/Protokollierung der Kauforders, die über Terminaleingaben von Bank und
Makler in das System eingegeben wurden. Änderungen und Löschungen werden über
MT595 gemeldet.
(2)
Übermittlung aller noch ausführbaren und aller wegen Einstellung der Notierung in der
Tagesendverarbeitung gestrichenen Kauforders zu Kontrollzwecken (Orderbestandsabgleich).
Diese Übermittlung erfolgt nur über File-Transfer.
(1)
Übermittlung aller Kauforders, die über eine VALUES basierte Frontend-Applikation
(Notfall-Prozedere) eingegeben wurden.
Hinweis: Die Anmeldung in der VALUES basierten Frontend-Applikation kann mit der
exklusiven Trader-ID „ORSnnn“ (z.B.: „ORS002“, aber nicht „ORS001“, da diese Trader-ID von Xetra Orderrouting SNA benutzt wird) durchgeführt werden.
(2)
Übermittlung aller Kauforders, die „on behalf“ für den Händler mit der exklusiven Subgroup „ORS“ von der Market Supervision eingegeben wurden.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 51
MT 500 Kauforder
O/M
Etikett
Feldbezeichnung
Format
M
20:
Bankinterne Order-Nr., falls nicht vorhanden:
/NONREF
(bei Bank
Ù System)
DWZnnnnnnnnnnnnn
(bei System Ù Bank)
16x
O
23:
Geschäftsart:
[3n][1a][b1a]
Xetra®
X
− Geschäftsvorfallcode
X
− Kompensation
C = Kompensation
X
− Automatische Lieferfreigabe (wird z.Z. ignoriert)
J = Ja
N = Nein
M
30:
Order gültig bis (JJMMTT)
6n
X
M
35A:
Art des Wertpapiers
Stück oder Nennwert
(Codewörter werden nicht geprüft)
3a10n,3n
X
M
35B:
1. Zeile: Internationale Kenn-Nr.
2. Zeile: Wertpapierkurzbezeichnung (wird nicht geprüft)
ISINb12c
35x
X
Xetra® an Bank:
3. Zeile: Versionsnummer (lastupdatedate)
[18n]
X
1. Zeile:
Währung der Notierung (ISO-Code), Preis/Kurslimit
3a6n,4n
X
2. Zeile:
Börsenplatz
Empfänger der Order (KV-Hauptkto.)
Handelshinweis
Limitzusatz
/3n[4n][b2x][/2a]
X
X
X
X
M
32L:
O
82D:
Orderaufgeber
/4n
O
83C:
KV-Hauptkonto der auftraggebenden Bank (Korrespondenzbank)
/4n
O
87a:
Empfänger der Wertpapiere (wird z.Z. ignoriert)
E, F
O
88a:
Begünstigter der Wertpapiere (wird z.Z. ignoriert)
A, C, D
O
53C:
Abwicklungskonto (wird z.Z. ignoriert)
/10n
X
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 52
MT 500 Kauforder (Fortsetzung 1)
O/M
Etikett
Feldbezeichnung
Format
O
71D:
Einzelheiten zu Gebühren
Spesen
wenn negativ: Konstante /N
[7n,2n[/N]]
Provision
Provisionsbetrag (PD) oder Provisionssatz (PM) oder
Standardprovision (PS)
O
72:
Xetra®
X
[/2a7n,3n[/N]]
1. Zeile: freier Text
[25x]
X
2. Zeile: ID-KZ bei Terminaleingabe über System (nur
bei System an Bank)
[DWZ-USERb10x]
[EIN-ZEITb8n]
3. Zeile: Erstellungszeit der Nachricht (HHMMSSHS) (nur bei
System an Bank)
Regeln:
Feld 20
(Bankinterne Ordernummer):
Datentransfers vom System zum Kreditinstitut: Feld F:20 wird mit der bankinternen Ordernummer belegt; In einem Folgesatz (MT596) wird die DWZ-Ordernummer / Xetra®-Ordernummer in Feld F:20 geliefert, die Referenzierung erfolgt über Feld F:21 (bankinterne Ordernummer). Ist keine bankinterne Ordernummer vorhanden, so wird die DWZ-Ordernummer / Xetra®-Ordernummer in Feld F:20 von MT500
eingestellt (mit Präfix 'DWZ'); In diesem Fall wird kein Folgesatz (MT596) geliefert.
Xetra®: In Xetra® existiert kein Prüfprozedere bezüglich der Eindeutigkeit der bankinternen Ordernummer.
Feld 23
(Geschäftsvorfallcode):
Im folgenden ist aufgeführt, welche Geschäftsvorfallcodes von welchem System (BOSS-CUBE und Xetra®) unterstützt werden:
Code
Bedeutung
BOSS
Xetra®
Bank an System:
121
Order gültig ab Folgetag
Ja
Nein
Orderzugang durch Bankterminal / VALUES basierte Frontend-Applikation
Orderzugang durch Maklerterminal
Bestandsabgleich (ausführbare Kauforders)
Orderzugang während Sperre durch Bankterminal
Orderzugang während Sperre durch Maklerterminal
Ja
Ja
Ja
Ja
Ja
Ja
Nein
Nein
Nein
Nein
System an Bank:
031
032
033
034
035
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
Code
036
037
038
039
040
041
042
043
233
05.10.1998
Seite 53
Bedeutung
BOSS
Xetra®
Ablehnung eines über GV-Code=034 bestätigten Orderzugangs nach Kursfeststellung
Ablehnung eines über GV-Code=035 bestätigten Orderzuganges nach Kursfeststellung
Orderzugang durch Bankterminal gültig ab Folgetag (maschinell)
Orderzugang durch Maklerterminal gültig ab Folgetag (maschinell)
Orderzugang durch Bankterminal gültig ab Folgetag (manuell)
Orderzugang einer Stop-Limit Order
Orderzugang durch Market Supervision „on behalf“
Orderzugang einer „accept surplus“ Order
Bestandsabgleich (wegen Einstellung der Notierung in der
Tagesendverarbeitung gestrichene Kauforders)
Ja
Nein
Ja
Nein
Ja
Nein
Ja
Nein
Ja
Nein
Nein
Nein
Nein
Ja
Ja
Ja
Ja
Nein
Feld 23
(Geschäftsvorfallcode = 041):
Xetra: Bei der Eingabe einer Stop-Limit Order über eine VALUES basierte Frontend-Applikation wird
der GV-Code 041 an die Bank gesendet. Im Feld Preis- / Kurslimit (Feld F:32L) wird das Limit, bei dem
die Order umgesetzt wird, geliefert.
Feld 23
Xetra: Bei der Eingabe einer „accept surplus“ Order über eine VALUES basierte Frontend-Applikation
wird der GV-Code 043 an die Bank gesendet. Das Feld F:32L (Handelshinweis) wird nicht belegt. Die
weitere Verarbeitung dieser Order erfolgt wie bei einer FOK / IOC Order, die über eine VALUES basierte
Frontend-Applikation eingegeben wurde.
Feld 23
Wegen hausinterner Orderannahmeschlüsse bei Banken können Orders zum nächsten Börsentag aufgegeben werden. Diese Orders werden am Eingabetag nicht ausgeführt und bleiben auch von der Nebenrechtsverarbeitung unberücksichtigt. Die positive Bestätigung im MT596 erfolgt mit dem GV-Code
300 (Zugang fehlerfrei durchgeführt).
Feld 23
(Kompensation):
Xetra®: Kompensationsorders werden von Xetra® abgelehnt.
Feld 23
(automatische Lieferfreigabe):
Der Defaultwert aus den Profile-Angaben der Bank kann hier überschrieben werden.
Feld 30
(Order gültig bis):
Xetra® lehnt im Gegensatz zu BOSS-CUBE alle Verfallsdaten später als der aktuelle Handelstag + 1
Jahr ab.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 54
Feld 35B / 2. Zeile (Wertpapierkurzbezeichnung):
Xetra: Falls die Wertpapierkurzbezeichnung bei einer Eingabe über eine VALUES basierte FrontendApplikation nicht ermittelt werden kann, wird als Default-Wert „???“ an den Teilnehmer geliefert.
Feld 35B / 3. Zeile (Versionsnummer lastupdatedate):
Xetra®: Wenn eine Kauforder über eine VALUES basierte Frontend-Applikation erfaßt wird, erhält der
Teilnehmer einen Nachrichtensatz MT500. In diesem Fall transferiert Xetra® die aktuelle Versionsnummer. Diese Versionsnummer sollte für zukünftige Ordermodifikationen verwendet werden. Eine Versionsnummer wird nicht geliefert, wenn die Order entweder sofort vollständig ausgeführt wird, oder
wenn es sich um eine FOK / IOC Order handelt.
Feld 32L / 1. Zeile (Preis-Kurs Limit):
LIMIT = 0 Ù Billigst
nur das Limit, bei dem die Order umgesetzt wird, in diesem Feld mitgeteilt.
Feld 32L / 1. Zeile (Währung der Notierung):
Xetra: Die Währung wird von Xetra nicht geprüft
Feld 32L / 2. Zeile (Börsenplatz):
Börse, an der die Order auszuführen ist (lt. WM- Schlüssel GD621). Möglicher Wertebereich:
100 - Berlin
110 - Bremen
120 - Düsseldorf
130 - Frankfurt
140 - Hamburg
150 - Hannover
160 - München
170 - Stuttgart
194 - Xetra®
Feld 32L / 2. Zeile (Empfänger der Order):
Falls das Feld nicht angegeben ist, so wird die Order dem skontroführenden Makler zugeteilt.
Xetra®: Bei der Eingabe einer Order mit dem Börsenplatz Xetra® werden Orders mit einem Eintrag in
diesem Feld abgelehnt.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 55
Feld 32L / 2. Zeile (Handelshinweis):
Im folgenden sind die einzelnen Ausprägungen des Handelshinweises in BOSS-CUBE und der Trading
Restriction in Xetra aufgeführt. Ferner ist es auch möglich, für Xetra die gleichen Ausprägungen wie
für BOSS-CUBE zu nutzen. Es findet dann eine Transformation der BOSS-CUBE Handelshinweise in
folgende Xetra Trading Restrictions statt (siehe Tabelle):
Schlüssel
BOSS-CUBE
Transformation in Xetra®
KS:
EK:
SK:
Kassa
Eröffnungskurs
Schlußkurs
nicht belegt: gem. Usancen
-> Nur Auktionen
-> Opening Auktion
-> Closing Auktion
nicht belegt: gem. Xetra Marktmodell
Schlüssel
Xetra®
AU:
OA:
CA:
-> Nur Auktionen
-> Opening Auktion
-> Closing Auktion
BOSS-CUBE: Bei Ordererfassung über Terminal wird bei Kassaorders generell "KS" eingestellt.
Xetra®: Xetra® wandelt Orders, bei denen das Feld Handelshinweis (Trading Restrictions) keinen Eintrag
enthält, in Orders ohne diesbezügliche Beschränkungen. Falls im Rahmen des Notfall-Prozederes (Eingabe einer Order über eine VALUES basierte Frontend-Applikationen) eine Kauforder von Xetra an die
Bank geschickt wird, findet immer eine Transformation der Xetra Trading Restrictions in die entsprechenden BOSS-CUBE Handelshinweise statt.
Feld 32L / 2. Zeile (Limitzusatz):
Xetra:Die Eingabemöglichkeiten in diesem Feld werden um die Xetra® Zusätze „fill or kill“ und „immediate or cancel“ ergänzt. Die Eingabe von Stop Limit Orders über den Weg Bank an System wird
nicht unterstützt.
Ausprägung
Bedeutung
BOSS-CUBE
Xetra®
SB:
Stop Buy
Ja
Ja
SL:
Stop Loss
Ja
Ja
FK:
fill or kill
Nein
Ja
IC:
immediate or cancel
Nein
Ja
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 56
Feld 82D (Orderaufgeber):
Falls das Feld nicht belegt ist, wird die KV-Konto-Nr. des Orderaufgebers aus der S.W.I.F.T. - Adresse
ermittelt. Für Banken mit zentraler Anbindung muß das Feld für Orders, die nicht an den Börsenplatz der
Zentrale geroutet werden sollen, mitgeliefert werden.
Empfehlung: das Feld sollte generell gepflegt werden (auch für Banken mit dezentraler Anbindung).
Feld 35A (Art des Wertpapiers):
Im folgenden sind die verschiedenen Ausprägungen der Wertpapierart aufgeführt:
Wertpapierart
SHS
FMT
BON
OPS
RTS
UNT
RTE
WTS
MSC
Bedeutung
Aktien
Festverz. Prozentnotiz
Festverz. Stücknotiz
Optionsscheine
Rechte
Investments
Genußscheine
Bezugsrechte
sonstige
Im Unterfeld 'Art des Wertpapiers' wird generell die Art des Wertpapiers angegeben (durch entspr.
Codewort); eine Währungsangabe erfolgt nicht.
Xetra: Falls die Art des Wertpapiers bei einer Eingabe über eine VALUES basierte FrontendApplikation nicht ermittelt werden kann, wird als Default-Wert „MSC“ an den Teilnehmer geliefert.
Feld 35A (Stück oder Nennwert):
Xetra: Bei der Eingabe einer FOK bzw. IOC Kauforder über eine VALUES basierte Frontend-Applikation (Notfall-Prozedere), die nicht oder nur teilweise ausgeführt wird, wird in diesem Feld die ursprüngliche Nominale geliefert. Der Anteil der Order, der nicht ausgeführt, sondern gelöscht wurde, wird als
Teillöschung im Nachrichtentyp MT595 geliefert. Eine Beschreibung des Ablaufs bei Eingabe einer FOK
/ IOC Order findet sich im Nachrichtentyp MT596.
Feld 83C (KV-Hauptkonto der auftraggebenden Bank):
KV-Hauptkonto der Korrespondenzbank, in deren Auftrag die Order aufgegeben wird.
Xetra®: Diese Funktionalität (und die damit zusammenhängenden Felder Provision und Spesen: Feld
F:71D) existiert in Xetra® nicht. Orders mit Eingaben hierzu werden abgelehnt.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 57
Feld 71D (Einzelheiten zu Gebühren):
Nur bei Aufträgen einer Korrespondenzbank möglich (Feld F:83C muß belegt sein). Die Provision kann
als Provisionsbetrag (in Währung der Notierung (Feld F:32L)), als Provisionssatz (in Promille des Kurswertes) oder als Standardprovision eingegeben werden. Das 2a-Feld kennzeichnet die Art der Provision;
des weiteren sind die unterschiedlichen Definitionen zu beachten:
• Provisionsbetrag (2a7n,2n):
z.B.:
PD100,5
Ù Provision = 100,50 DM
PD,0
Ù keine Provision
• Provisionssatz (2a2n,3n):
z.B.:
PM5,725
Ù Provision = 5,725 Promille des Kurswertes
• Standardprovision (BOEGA)
z.B.:
PS,0
oder
keine Eingabe des Provisionsfeldes
Xetra®: Vgl. Feld F:83C
Feld 72 / 1. Zeile (freier Text):
Xetra®: Von den erlaubten 25 Zeichen werden von Xetra® nur 12 Zeichen unterstützt. Längere Eingaben
werden abgeschnitten und ignoriert.
Feld 72 / 2. Zeile (ID-KZ):
Xetra®: Das ID-KZ enthält die letzten sechs Stellen der Trader-ID (z.B.. „ORS002“)
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.6.2.2
05.10.1998
Seite 58
Verkauforder (MT 501)
Urheber:
Bank:
Übermittlung von Verkauforders (Zugänge), Änderungen und Löschungen sind über
MT595 zu mitzuteilen.
BOSS-CUBE:
Xetra®:
(1)
Übermittlung/Protokollierung der Verkauforders, die über Terminaleingaben von Bank
und Makler in das System eingegeben wurden. Änderungen und Löschungen werden
über MT595 gemeldet.
(2)
Übermittlung aller noch ausführbaren und aller wegen Einstellung der Notierung in der
Tagesendverarbeitung gestrichenen Verkauforders zu Kontrollzwecken (Orderbestandsabgleich).
Diese Übermittlung erfolgt nur über File-Transfer.
(1)
Übermittlung aller Verkauforders, die über VALUES basierte Frontend-Applikationen
(Notfall-Prozedere) eingegeben wurden.
(2)
Übermittlung aller Verkauforders, die „on behalf“ für den Händler mit der exklusiven
Subgroup „ORS“ von der Market Supervision eingegeben wurden.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 59
MT 501 Verkauforder
O/M
Etikett
Feldbezeichnung
Format
M
20:
Bankinterne Order-Nr., falls nicht vorhanden:
/NONREF
(bei Bank
Ù System)
DWZnnnnnnnnnnnnn
(bei System Ù Bank)
16x
O
23:
Geschäftsart:
[3n][1a][/3n]
− Geschäftsvorfallcode
Xetra®
X
X
− Automatische Lieferfreigabe (wird z.Z. ignoriert)
J = Ja
N = Nein
− Referenz-Nr. zum Verdichten von Serien (wird z.Z. ignoriert)
M
30:
Order gültig bis (JJMMTT)
6n
X
M
35A:
Art des Wertpapiers,
Stück od. Nennwert
(Codewörter werden nicht geprüft)
3a10n,3n
X
M
35B:
2. Zeile: Wertpapierkurzbezeichnung (wird nicht geprüft)
ISINb12c
35x
X
Xetra® an Bank:
[18n]
X
1. Zeile:
Währung der Notierung (ISO-Code),
Preis-/Kurslimit
3a6n,4n
X
2. Zeile:
Börsenplatz
Empfänger der Order (KV-Hauptkonto)
Handelshinweis
Limitzusatz
/3n[4n][b2x][/2a]
X
X
X
X
M
32L:
O
35E:
Stücke-Nummern (wird z.Z. ignoriert)
6*50x
O
82D:
Orderaufgeber
/4n
O
83C:
KV-Hauptkonto der auftraggebenden Bank (Korrespondenzbank)
/4n
O
87a:
Lieferant der Wertpapiere (wird z.Z. ignoriert)
E, F
O
53C:
Abwicklungskonto (wird z.Z. ignoriert)
/10n
O
57a:
Kontoführendes Institut (wird ignoriert)
A, B, D
X
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 60
MT 501 Verkauforder (Fortsetzung 1)
O/M
Etikett
Feldbezeichnung
Format
O
58a:
Begünstigter des Geldes (wird ignoriert)
A, D
O
71D:
Einzelheiten zu Gebühren
Spesen
Provision
Provisionsbetrag (PD) oder Provisionssatz (PM) oder
Standardprovision (PS)
O
72:
Xetra®
[7n,2n[/N]]
X
[/2a7n,3n[/N]]
X
1. Zeile: freier Text
[25x]
X
2. Zeile: ID-KZ bei Terminaleingabe über BörsenSystem (nur bei System an Bank)
[DWZ-USERb10x]
[EIN-ZEITb8n]
3. Zeile: Erstellungszeit der Nachricht (HHMMSSHS) (nur bei
System an Bank)
Regeln:
Feld 20
(Bankinterne-Ordernummer):
Datentransfers vom System zum Kreditinstitut: Feld F:20 wird mit der bankinternen Ordernummer belegt; In einem Folgesatz (MT596) wird die DWZ-Ordernummer / Xetra®-Ordernummer in Feld F:20 geliefert, die Referenzierung erfolgt über Feld F:21 (bankinterne Ordernummer). Ist keine bankinterne Ordernummer vorhanden, so wird die DWZ-Ordernummer / Xetra®-Ordernummer in Feld F:20 von MT501
eingestellt (mit Präfix 'DWZ'); In diesem Fall wird kein Folgesatz (MT596) geliefert.
Xetra®: In Xetra® existiert kein Prüfprozedere bezüglich der Eindeutigkeit der bankinternen Ordernummer.
Feld 23
Code
Bedeutung
BOSS
Xetra®
Bank an System:
121
Order gültig ab Folgetag
Ja
Nein
Orderzugang durch Bankterminal / VALUES basierte Frontend-Applikation
Orderzugang durch Maklerterminal
Bestandsabgleich (ausführbare Verkauforders)
Orderzugang während Sperre durch Bankterminal
Ja
Ja
Ja
Ja
Ja
Nein
Nein
Nein
System an Bank:
031
032
033
034
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
Code
035
036
037
038
039
040
041
042
043
233
05.10.1998
Seite 61
Bedeutung
BOSS
Xetra®
Orderzugang während Sperre durch Maklerterminal
Ablehnung eines über GV-Code=034 bestätigten Orderzugangs nach Kursfeststellung
Ablehnung eines über GV-Code=035 bestätigten Orderzuganges nach Kursfeststellung
Orderzugang durch Bankterminal gültig ab Folgetag (maschinell)
Orderzugang durch Maklerterminal gültig ab Folgetag (maschinell)
Orderzugang durch Bankterminal gültig ab Folgetag (manuell)
Orderzugang einer Stop-Limit Order
Orderzugang durch Market Supervision „on behalf“
Orderzugang einer „accept surplus“ Order
Bestandsabgleich (wegen Einstellung der Notierung in der
Tagesendverarbeitung gestrichene Verkauforders)
Ja
Ja
Nein
Nein
Ja
Nein
Ja
Nein
Ja
Nein
Ja
Nein
Nein
Nein
Nein
Ja
Ja
Ja
Ja
Nein
Feld 23
der GV-Code 041 an die Bank gesendet. Im Feld Preis- / Kurslimit (Feld F:32L) wird das Limit, bei dem
die Order umgesetzt wird, geliefert.
Feld 23
Xetra: Bei der Eingabe einer „accept surplus“ Order über eine VALUES basierte Frontend-Applikation
wird der GV-Code 043 an die Bank gesendet. Das Feld F:32L (Handelshinweis) wird nicht belegt. Die
weitere Verarbeitung dieser Order erfolgt wie bei einer FOK / IOC Order, die über eine VALUES basierte
Frontend-Applikation eingegeben wurde.
Feld 23
Wegen hausinterner Orderannahmeschlüsse bei Banken können Orders zum nächsten Börsentag aufgegeben werden. Diese Orders werden am Eingabetag nicht ausgeführt und bleiben auch von der Nebenrechtsverarbeitung unberücksichtigt. Die positive Bestätigung im MT596 erfolgt mit dem GV-Code
300 (Zugang fehlerfrei durchgeführt).
Feld 23
(automatische Lieferfreigabe):
Der Defaultwert aus den Profile-Angaben der Bank kann hier überschrieben werden.
Feld 23
(Referenz-Nr.):
Die Angabe dieses Feldes ist nur bei Serien-WKN möglich; Orders über Serien-WKNs mit gleicher
Stammgattung und gleicher Referenz-Nr. werden dem Makler verdichtet eingestellt.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
Feld 30
05.10.1998
Seite 62
(Order gültig bis):
Xetra® lehnt im Gegensatz zu BOSS-CUBE alle Verfallsdaten später als der aktuelle Handelstag + 1
Jahr ab.
Xetra: Falls die Wertpapierkurzbezeichnung bei einer Eingabe über eine VALUES basierte FrontendApplikation nicht ermittelt werden kann, wird als Default-Wert „???“ an den Teilnehmer geliefert.
Feld 35B / 3. Zeile: (Versionsnummer lastupdatedate):
Xetra®: Wenn eine Verkauforder über eine VALUES basierte Frontend-Applikation erfaßt wird, erhält der
Teilnehmer einen Nachrichtensatz vom Typ MT501. In diesem Fall transferiert Xetra® die aktuelle Versionsnummer. Diese Versionsnummer sollte für zukünftige Ordermodifikationen verwendet werden. Eine
Versionsnummer wird nicht geliefert, wenn die Order entweder sofort vollständig ausgeführt wird, oder
wenn es sich um eine FOK / IOC Order handelt.
Feld 32L / 1. Zeile (Preis-Kurs-Limit):
LIMIT = 0 Ù Bestens
nur das Limit, bei dem die Order umgesetzt wird, in diesem Feld mitgeteilt.
Feld 32L / 1. Zeile (Währung der Notierung):
Xetra: Die Währung wird von Xetra nicht geprüft
Feld 32L / 2. Zeile (Börsenplatz):
Börse, an der die Order auszuführen ist (lt. WM-Schlüssel GD621). Wertebereich:
100 - Berlin
110 - Bremen
120 - Düsseldorf
130 - Frankfurt
140 - Hamburg
150 - Hannover
160 - München
170 - Stuttgart
194 - Xetra®
Feld 32L / 2. Zeile (Empfänger der Order):
Falls das Feld nicht angegeben ist, wird die Order dem skontroführenden Makler zugeteilt.
Xetra®: Bei der Eingabe einer Order mit dem Börsenplatz Xetra® werden Orders mit einem Eintrag in
diesem Feld abgelehnt.
Feld 32L / 2. Zeile (Handelshinweis):
Im folgenden sind die einzelnen Ausprägungen des Handelshinweises in BOSS-CUBE und der Trading
Restriction in Xetra aufgeführt. Ferner ist es auch möglich, für Xetra die gleichen Ausprägungen wie
für BOSS-CUBE zu nutzen. Es findet dann eine Transformation der BOSS-CUBE Handelshinweise in
folgende Xetra Trading Restrictions statt (siehe Tabelle):
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 63
Schlüssel
BOSS-CUBE
Transformation in Xetra®
KS:
EK:
SK:
Kassa
Eröffnungskurs
Schlußkurs
nicht belegt: gem. Usancen
-> Nur Auktionen
-> Opening Auktion
-> Closing Auktion
Schlüssel
Xetra®
AU:
OA:
CA:
-> Nur Auktionen
-> Opening Auktion
-> Closing Auktion
BOSS-CUBE: Bei Ordererfassung über Terminal wird bei Kassaorders generell "KS" eingestellt.
Xetra®: Xetra® wandelt Orders, bei denen das Feld Handelshinweis (Trading Restrictions) keinen Eintrag
enthält, in Orders ohne diesbezügliche Beschränkungen. Falls im Rahmen des Notfall-Prozederes (Eingabe einer Order über eine VALUES basierte Frontend-Applikationen) eine Kauforder von Xetra an die
Bank geschickt wird, findet immer eine Transformation der Xetra Trading Restrictions in die entsprechenden BOSS-CUBE Handelshinweise statt.
Feld 32L / 2. Zeile (Limitzusatz):
Xetra:Die Eingabemöglichkeiten in diesem Feld werden um die Xetra® Zusätze ‘fill or kill’ und ‘immediate or cancel’ ergänzt. Die Eingabe von Stop Limit Orders über den Weg Bank an System wird
nicht unterstützt.
Ausprägung
Bedeutung
BOSS-CUBE
Xetra®
SB:
Stop Buy
Ja
Ja
SL:
Stop Loss
Ja
Ja
FK:
fill or kill
Nein
Ja
IC:
immediate or cancel
Nein
Ja
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 64
Feld 82D (Orderaufgeber):
Falls das Feld nicht belegt ist, wird die KV-Konto-Nr. des Orderaufgebers aus der S.W.I.F.T. - Adresse
ermittelt. Für Banken mit zentraler Anbindung muß das Feld für Orders, die nicht an den Börsenplatz der
Zentrale geroutet werden sollen, mitgeliefert werden. Empfehlung: das Feld sollte generell gepflegt werden (auch für Banken mit dezentraler Anbindung).
Wertpapierart
SHS
FMT
BON
OPS
RTS
UNT
RTE
WTS
MSC
Bedeutung
Aktien
Optionsscheine
Rechte
Investments
Genußscheine
Bezugsrechte
sonstige
Xetra: Falls die Art des Wertpapiers bei einer Eingabe über eine VALUES basierte FrontendApplikation nicht ermittelt werden kann, wird als Default-Wert „MSC“ an den Teilnehmer geliefert.
Feld 35A (Stück oder Nennwert):
Xetra: Bei der Eingabe einer FOK bzw. IOC Verkauforder über eine VALUES basierte FrontendApplikation (im Rahmen des Notfall-Prozedere), die nicht oder nur teilweise ausgeführt wird, wird in diesem Feld die ursprüngliche Nominale geliefert. Der Anteil der Order, der nicht ausgeführt, sondern gelöscht wurde, wird als Teillöschung im Nachrichtentyp MT595 geliefert. Eine Beschreibung des Ablaufs
bei Eingabe einer FOK / IOC Order findet sich im Nachrichtentyp MT596.
Feld 83C (KV-Hauptkonto der auftraggebenden Bank):
KV-Hauptkonto der Korrespondenzbank, in deren Auftrag die Order aufgegeben wird.
Xetra®: Diese Funktionalität (und die damit zusammenhängenden Felder Provision und Spesen: Feld
F:71D) existiert in Xetra® nicht. Order mit Eingaben hierzu werden abgelehnt.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 65
Feld 71D (Einzelheiten zu Gebühren):
Nur bei Aufträgen einer Korrespondenzbank möglich (Feld F:83C muß belegt sein). Die Provision kann
als Provisionsbetrag (in Währung der Notierung (Feld F:32L)), als Provisionssatz (in Promille des Kurswertes) oder als Standardprovision eingegeben werden. Das 2a-Feld kennzeichnet die Art der Provision;
des weiteren sind die unterschiedlichen Definitionen zu beachten:
• Provisionsbetrag (2a7n,2n):
z.B.:
PD100,5
Ù Provision = 100,50 DM
PD,0
Ù keine Provision
• Provisionssatz (2a2n,3n):
z.B.:
PM5,725
Ù Provision = 5,725 Promille des Kurswertes
• Standardprovision (BOEGA)
z.B.:
PS,0
oder
keine Eingabe des Provisionsfeldes
Xetra®: Vgl. Feld F:83C
Feld 72 / 1. Zeile (freier Text):
Xetra®: Von den erlaubten 25 Zeichen werden von Xetra® nur 12 Zeichen unterstützt. Längere Eingaben
werden abgeschnitten und ignoriert.
Feld 72 / 2. Zeile (ID-KZ):
Xetra®: Das ID-KZ enthält die letzten sechs Stellen der Trader-ID (z.B.: „ORS002“)
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.6.2.3
05.10.1998
Seite 66
Ausführungsbestätigung (MT 519)
Urheber:
BOSS-CUBE:
Xetra®:
Systeme BOSS-CUBE und Xetra®
(1)
Nach Feststellung eines Börsenkurses und Ablauf dessen Stornierungsfrist werden
Bestätigungen für alle zu diesem Kurs ausgeführten elektronisch übermittelten Orders
den Benutzern (Banken) gemeldet. In dieser Mitteilung wird generell die ausgeführte
Nominale mitgeliefert. Die Ausführungsbestätigungen sind verbindlich. Eine Stornierung der Ausführungsbestätigungen ist nicht mehr möglich. (Stornierung nur noch über
Stornierung von Geschäften in Börsengeschäftseingabe möglich).
(2)
Bei den Ausführungsbestätigungen für Kassakurse ohne Zusätze ('Bezahlt-Kurse')
kann der Benutzer (Bank) wählen zwischen der hier definierten Mitteilung auf Einzelorderebene und einer globalen Mitteilung auf Gattungsebene (vgl. MT551). Die Festlegung erfolgt im Benutzerprofile.
(3)
Bei Kassakursen mit Zusätzen, die eine Teilausführung von einzelnen Orders notwendig machen, werden generell Ausführungsbestätigungen auf Einzelorderebene mit Angabe der jeweils ausgeführten Nominale erstellt.
(4)
Für alle elektronisch übermittelten Orders (LU6) und alle über Terminal erfaßten Orders werden Ausführungsbestätigungen erstellt.
(1)
Nach Ausführung einer Order wird dem Teilnehmer eine Ausführungsbestätigung
übermittelt.
(2)
Für alle per Orderrouting und über VALUES basierte Frontend-Applikationen (NotfallProzedere) mit der ORS-Trader-ID transferierten Orders wird eine Ausführungsbestätigung erstellt.
(3)
Die Ausführungsbestätigungen werden immer auf Einzelorderebene übermittelt.
(4)
Da in Xetra® eine Order gleichzeitig gegen mehrere Orders mit unterschiedlichen Preisen ausgeführt werden kann, können mehrere Ausführungsbestätigungen pro Ausführung (eine pro Preis) erstellt werden.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 67
MT 519 Ausführungsanzeige
O/M
Etikett
Feldbezeichnung
Format
M
20:
Bezugsauftragsnummer:
DWZ-Ordernummer bzw. Xetra® - Ordernummer
13x
X
M
21:
Bankinterne Ordernummer (aus Feld F:20 der Order) Falls
nicht vorhanden: /NONREF
16x
X
M
23:
Geschäftsart: BOUGHT oder SOLD
16x
M
31P:
Abschlußangaben:
6n3n2a4n8n
[b3x][/1x3n][/1x]
−
−
−
−
−
−
−
−
Ausführungstag (JJMMTT)
Börsenplatz
Handelshinweis
Ausführender Makler
Uhrzeit der Ausführung (HHMMSSHS)
Kurszusatz gem. Schlüsselverzeichnis
Zinstage mit Vorzeichen
Kompensation:
C = Kompensation
Xetra®
X
X
X
X
X
X
M
35A:
Art des Wertpapiers;
Stück od. Nennwert
3a10n,3n
X
M
35B:
2. Zeile: Wertpapierkurzbezeichnung.
ISINb12c
35x
[18n]
X
X
M
33T:
Währung Notierung (ISO-Code);
Ausführungskurs
3a6n,4n
O
72:
ID-KZ des Ordereingebers
[DWZ-USERb10x]
Regeln:
Feld 20
(Bezugsauftragsnummer):
Die DWZ-Ordernummer ist wie folgt aufgebaut:
• Stelle 1-6 (6n): Einstellungsdatum der Order in das BOSS-CUBE - System;
• Stelle 7-13 (7n): 7-stellige laufende Nr.
Xetra®: Die Xetra®-Ordernummer enthält keinen Hinweis auf das Datum oder andere Attribute der Order.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 68
Feld 21
(Bankinterne Ordernummer):
In Xetra® existiert kein Prüfprozedere bezüglich der Eindeutigkeit der BI-Ordernummer.
Feld 23
(Geschäftsart):
BOUGHT aus
SOLD
aus
MT500
MT501
Feld 31P (Börsenplatz):
Börse, an der die Order ausgeführt wurde (lt. WM-Schlüssel GD621). Möglicher Wertebereich:
100 - Berlin
110 - Bremen
120 - Düsseldorf
130 - Frankfurt
140 - Hamburg
150 - Hannover
160 - München
170 - Stuttgart
194 - Xetra®
Feld 31P (Handelshinweis):
KS =
SK =
Kassakurs
Schlußkurs
EK =
VA =
Eröffnungskurs
variabel
Xetra®: In Xetra® gibt es keine Handelshinweise. Da auf Grund der S.W.I.F.T. Konventionen dieses
Feld keine Leerzeichen enthalten darf, wird als Kennzeichnung der Wert ”XT” übergeben.
Feld 31P (Ausführender Makler):
Xetra®: Da dieses Feld ein S.W.I.F.T.-Pflichtfeld ist, wird es mit dem Defaultwert Null zurückgegeben.
Feld 31P (Uhrzeit der Ausführung):
Xetra®: Die Uhrzeit der Ausführung wird in Xetra® nur mit 6 Stellen angegeben (HHMMSS). Die beiden
Stellen, die die 100-stel Sekunden darstellen, werden mit Nullen gefüllt.
Feld 31P (Kurszusatz):
Schlüsselverzeichnis:
blank
Bezahlt
+
Bezahlt; kleine Stücke ohne Umsatz
BB
Bezahlt Brief
BB+
Bezahlt Brief; kleine Stücke ohne Umsatz
BG
Bezahlt Geld
BG+
Bezahlt Geld; kleine Stücke ohne Umsatz
EB
Etwas bezahlt Brief
EB+
Etwas bezahlt Brief; kleine Stücke ohne Umsatz
EG
Etwas bezahlt Geld
EG+
Etwas bezahlt Geld; kleine Stücke ohne Umsatz
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
RB
RB+
RG
RG+
C
05.10.1998
Rationiert/Rep. Brief
Rationiert/Rep. Brief; kleine Stücke ohne Umsatz
Rationiert/Rep. Geld
Rationiert/Rep. Geld; kleine Stücke ohne Umsatz
Kompensationsgeschäft (nur Börse Frankfurt)
Xetra®: In Xetra® gibt es keine Kurszusätze.
Feld 31P (Kompensation):
Xetra®: Kompensationsorders sind in Xetra nicht vorhanden.
Wertpapierart
SHS
FMT
BON
OPS
RTS
UNT
RTE
WTS
MSC
Bedeutung
Aktien
Optionsscheine
Rechte
Investments
Genußscheine
Bezugsrechte
sonstige
Xetra: Falls die Art des Wertpapiers nicht ermittelt werden kann, wird als Default-Wert „MSC“ an den
Teilnehmer geliefert.
Xetra: Falls die Wertpapierkurzbezeichnung bei einer Eingabe über eine VALUES basierte FrontendApplikation nicht ermittelt werden kann, wird als Default-Wert „???“geliefert.
Feld 35B / 3. Zeile (Versionsnummer lastupdatedate):
Xetra®: Xetra® transferiert bei einer Ausführung die aktuelle Versionsnummer (lastupdatedate). Diese
Versionsnummer sollte für zukünftige Ordermodifikationen verwendet werden. Eine Versionsnummer
wird nicht geliefert, wenn die Order entweder sofort vollständig ausgeführt wird, oder wenn es sich um
eine FOK / IOC Order handelt.
Seite 69
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.6.2.4
05.10.1998
Seite 70
Ereignisse im WP-Geschäft (MT 551)
Urheber:
BOSS-CUBE: (1) Mitteilung von folgenden gattungsbezogenen Ereignissen:
• Kassakursmitteilungen/Ausführungsbestätigungen auf Gattungsebene: Für alle Kassakurse ohne
Zusätze können alternativ zu den Ausführungsbestätigungen auf Einzelorderebene diese Kassakursmitteilungen vom Benutzer (Bank) bezogen werden (Festlegung über Benutzerprofile). Bei
Ausführungsbestätigungen auf Kassakursebene wird keine ausgeführte Nominale mitgeliefert.
• Kursaussetzungen
• Rücknahme von Kursaussetzungen
• Plus-/Minusankündigungen
• Rücknahme von Plus-/Minusankündigungen
• Ankündigung einer Rationierung
• Rücknahme einer Rationierung
• Ankündigung Bezugsrechtshandel
• Ankündigung einer Kurstaxe
• Rücknahme einer Kurstaxe
• Einfügen / Ändern / Löschen eines Kurses
• Orderänderungen/-streichungen wegen Nebenrechten durch das System; Mitteilung auf Gattungsebene. Die Verarbeitung der Nebenrechte und der Versand der Ereignismitteilungen erfolgt
in der Regel im Buchungsschnitt für den folgenden Börsentag. Es ist jedoch auch eine Verarbeitung am Folgetag möglich (Anstoß Makler); es werden dann nur Orders bearbeitet, die bis zum
Buchungsschnitt des Vortages vorlagen.
• Die Verarbeitung von Orderstreichungen wegen Einstellung der Notierung nach Tagesendverarbeitung durch das System erfolgt nach dem Online-Ende von BOSS-CUBE. Sie können somit
den Kreditinstituten nicht sofort übermittelt werden. Die Daten (MT551/MT595) werden bereitgestellt und können am nächsten Tag mittels Retrieval angefordert werden.
(2) Mitteilung von sonstigen Ereignissen:
• Verlängerung der Börsengeschäftseingabe bzw. der Nachbearbeitung BOSS-CUBE (Eingabeende)
• Verlängerung der Börsenzeit
• Unterbrechung der Börsenversammlung
• Freigabe der Börsenversammlung
• Technische Störung z.B.: Ausfall von Leitungsverbindung zum HOST der Deutsche Börse Systems AG
• Ausfall BOSS-Anwendungsfunktionen
• Allgemeine Informationen
Xetra®:
(1) Insgesamt werden von Xetra® die folgenden Indikatoren geliefert:
FIXOF, INFO1, HALOF, XEBAT, XMAHA
(2) Die Vergabe einer Ereignisnummer erfolgt analog BOSS-CUBE für den Börsenplatz Xetra®.
Die Mitteilungen werden bei Auftreten bzw. Verarbeitung des Ereignisses den Banken übermittelt.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 71
MT 551 Nachricht über ein Ereignis
O/M
Etikett
Feldbezeichnung
Format
M
20:
Ereignisnummer (TRN)
6n7n
M
35B:
1. Zeile: Wertpapiergattung
2. Zeile: Kurzbezeichnung
3. Zeile: Wertpapier-Kennummer (deutsche)
[ISINb12c]
35x
6n
Xetra®
X
X
sofern gattungsbezogen, sonst
1. Zeile: Indikatorgruppe:
MISC = nicht gattungsbezogen
TECH = Technik, nicht gattungsbezogen
nnnn = KV-HKTO des Maklers
KV-HKTO des Xetra Teilnehmers
M
O
79:
72:
Ereignisschlüssel:
1. Zeile
35x
X
X
5c6n6n[6n6n]
2. Zeile
[/[6n,4n]/[N]/[3n]/[3a]/[4n]/
[2n]/[1x3n]/[ISINb12c]/[4x]/
[6n,4n]/[6n,4n]/[2a]]
3. Zeile
Siehe folgende Tabellen für Details !
[/[6n,4n]/[3x]/[6n,4n]/[3x]]
Freier Informationstext
3*35x
Regeln:
Feld 20
(Ereignisnummer):
Die Ereignisnummer (TRN) ist wie folgt aufgebaut:
• Stelle 1-6 (6n): Entstehungsdatum der Nachricht
• Stelle 7-13 (7n): 7-stellige laufende Nummer
Feld 35B / 2. Zeile und 3. Zeile:
Xetra: Falls die Wertpapierkurzbezeichnung bzw. die deutsche WKN nicht ermittelt werden kann, wird
als Default-Wert „???“ bzw. „999999“ an den Teilnehmer geliefert.
Feld 35B (Indikatorgruppe):
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 72
Die Indikatorgruppen nnnn (KV-HKTO des Maklers oder des Xetra Teilnehmers) können lediglich beim
Indikator (Feld F:79 / 1.Zeile = TREXP oder XEBAT) auftreten.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 73
Feld 79 (Allgemeine Beschreibung):
Zeile
Beschreibung
1.Zeile
Ereignisschlüssel:
Indikator
1.Datum (JJMMTT)
1.Uhrzeit (HHMMSS)
2.Datum (JJMMTT)
2.Uhrzeit (HHMMSS)
2. Zeile Kurs / Limitabschlag
N = Kennzeichen für Limitaufschlag
Börsenplatz
Währung
Art der Plus-/Minus-Ankündigung:
01 = einfach (+/-)
02 = zweifach (++/--)
03 = dreifach (+++/---)
Zinstage mit Vorzeichen
Neue Wertpapiergattung
Art des Nebenrechts
Geldkurs
Briefkurs
Kennzeichen für Schließung der Aufnahme
3. Zeile Kurs alt
Zusatz alt
Kurs neu
Zusatz neu
Xetra®
X
X
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 74
Feld 79 / 1. Zeile:
Im folgenden werden die einzelnen Ereignisschlüssel im Feld F:79 / 1. Zeile in Abhängigkeit vom der
Indikatorgruppe in Feld F:35B beschrieben:
Indikatorgruppe
(Feld F:35B)
Ereignisschlüssel (Feld F:79 / 1. Zeile): Indikator
ISIN
FIXOF
FIXON
PLUSA
PLUSR
MINUA
MINUR
RATIA
RATIR
BZRHD
KUTAX
KUTAX
SPOTR
EKURS
AKURS
LKURS
ORDCH
(Gattungsbezogen)
ORDIN
HALOF
Xetra®
(Fixing stopped) Kursaussetzung
(Fixing restarted) Rücknahme einer Kursaussetzung
(Plusannouncement) Plusankündigung
(Plusann. retracted) Rücknahme einer Plusankündigung
(Minusannouncement) Minusankündigung
(Minusann. retracted) Rücknahme einer Minusankündigung
Ankündigung einer Rationierung
Rücknahme einer Rationierung
Ankündigung Bezugsrechthandel
Ankündigung einer Kurstaxe
Rücknahme einer Kurstaxe
(Spot-Rate) Kassakursmitteilung
Einfügen eines Kurses
Ändern eines Kurses
Löschen eines Kurses
(Orders changed) Orderänderungen/-streichungen auf Gattungsebene wegen Nebenrechten. Orderstreichungen auf Gattungsebene wegen Einstellung der Notierung (Tagesendverarbeitung)
Informationen bzgl. Nebenrechten, die keine Aktionen auf den
Orderbestand bewirken (nur informativ)
Handelsunterbrechung in einer Gattung
X
X
Xetra®: (1)
Die Instrument Suspension von Xetra® wird als FIXOF interpretiert. Beim FIXOF wird sofern vom Teilnehmer vorgegeben - neben dem Ereignis auch für jede gelöschte Order
eine MT595-Nachricht geschickt.
Die Aufhebung der Instrument Suspension erfolgt durch Übergang in einen anderen
Market Status. Eine explizite Nachricht über das Ende der Kursaussetzung wird nicht erstellt.
(2)
HALOF: Entspricht dem Xetra® - Hold. Die Orders werden (im Gegensatz zur Instrument
Suspension) nicht gelöscht. Die Aufhebung des Xetra® - Hold wird nicht mitgeteilt.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
Indikatorgruppe
(Feld F:35B)
MISC
BOEND (BOSS-Ende Buchungsschnitt); Beginn des nächsten Börsentages in BOSS-CUBE. Es werden bis zum Tagesende keine
Ereignismitteilungen (MT551) und Ausführungsbestätigungen
(MT519) mehr erstellt.
BOERE (BOSS-Restart); BOSS-CUBE wieder verfügbar; Orderübertragung heute nicht mehr möglich
ORDRE (BOSS-Restart inkl. Orders) BOSS-CUBE wieder verfügbar; Orderübertragung wieder möglich
INCLO (Input closed) Verlängerung der Eingabezeit BOSS-CUBE / Geschäftseingabe (Eingabeende)
BOINT (Börse interrupt) Unterbrechung der Börsenversammlung; alle
Bearbeitungsfunktionen der Makler sind nicht möglich (inkl.
Kursfestsetzung)
TRINT (Trade interrupt) Unterbrechung der Kursfeststellung; andere
Maklerfunktionen (z.B. Nachbearbeitung) sind erlaubt
BOSTA (Börse started) Wiederaufnahme der Börsenversammlung (nach
BOINT)
TRSTA (Trading started) Wiederaufnahme d. Kursfeststellung (nach
TRINT)
NBSTA (Nachbearbeitung started) Wiederaufnahme der Börsenversammlung nur für Nachbearbeitungsfunktionen; keine Kursfeststellung mehr möglich (nach BOINT)
TREXP (Trading time expanded) Information über eine Verlängerung der
Börsenzeit (global)
INF01
Information (allgemeine Mitteilungen)
05.10.1998
Seite 75
Xetra®
X
XMAHA Market Hold
Xetra®: (1)
(2)
Die ”Xetra® News” werden als Ereigniscode INF01 interpretiert.
Das Ereignis XMAHA wird gesendet, wenn der gesamte Markt angehalten wird, d.h. alle
Instrumente auf Hold gesetzt werden. Es wird allerdings nicht für jedes Instrument zusätzlich eine Hold Meldung (HALOF) gesendet.
X
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 76
Indikatorgruppe
(Feld F:35B)
TECH
NOT01
NOT02
NOT03
Xetra®
Bank kann keine Orders übertragen (z.B. Störung der Leitungsverbindung Bank ⇔ System)
Rechner steht nicht zur Verfügung (z.B. Ausfall HOST-Rechner
der Deutsche Börse Systems AG
Engpaß im System der Deutsche Börse Systems AG (z.B.: Bank
erhält keine Orderbestätigungen)
− Die Nachrichten bzgl. NOT01 bzw. NOT02 werden der Bank nach Störungsende übermittelt. Die Nachrichten bzgl. NOT03 werden der Bank
direkt beim Auftreten der Störung gemeldet. Diese Nachrichten werden
nur an Banken übermittelt, die zum Zeitpunkt der Störung angemeldet
waren.
− Bei Störungsende werden den Banken, die vorher automatisch abgemeldet wurden, Störungsendenachrichten übermittelt (ORDRE bzw.
BOERE). Nach Empfang dieser Störungsendenachrichten kann die
Bank den Datenaustausch mit der Deutsche Börse Systems AG, beginnend mit Anmeldenachrichten, wieder aufnehmen.
− Generell erfolgt nach dem Versenden der Nachrichten der Indikatorgruppe TECH zur Bank eine automatische Abmeldung aller
LTERMs der Bank inkl. Übermittlung der Abmeldebestätigung (MT003 in
MT598 mit GV-CODE=023). Ausnahme: Bei NOT01 werden nur die gestörten LTERMs abgemeldet.
nnnn
TREXP
(Trading time expanded) Information über eine Verlängerung der
Börsenzeit (Teilmarkt)
XEBAT
Ende Xetra Orderrouting auf Teilnehmerebene
Xetra®: XEBAT gilt immer nur für den angegebenen Xetra Teilnehmer. Für diesen Teilnehmer werden nach dem XEBAT keine Orderausführungen oder positiven Orderbestätigungen mehr
übertragen. Für alle zu diesem Zeitpunkt noch nicht beantworteten Nachrichten kann der tatsächliche Status nicht maschinell bestimmt werden. Daher ist eine manuelle Nachbearbeitung
dieser Orders erforderlich.
Die negativen Bestätigungen für diese ausstehenden Nachrichten werden mit einer entsprechenden Fehlermeldung (XK0300F, Feld F:72) nach dem XEBAT übertragen. In Ausnahmefällen wird der XEBAT erst in der Tagesendverarbeitung erstellt und gesendet. Da in diesem
Fall nicht feststeht, ob alle Broadcasts an den jeweiligen Teilnehmer gesendet wurden, wird
diese Nachricht mit einem Text im Feld F:72 belegt: XK0310F EVTL. FEHLENDE
BROADCASTS.
Feld 79 / 2.Zeile (Börsenplatz):
X
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 77
Lt. WM-Schlüssel GD621. Möglicher Wertebereich:
100 - Berlin
110 - Bremen
120 - Düsseldorf
130 - Frankfurt
140 - Hamburg
150 - Hannover
160 - München
170 - Stuttgart
194 - Xetra®
Feld 79 / 3.Zeile (Zusatz alt / Zusatz neu):
Schlüsselverzeichnis:
blank
+
BB
BB+
BG
BG+
EB
EB+
EG
EG+
RB
RB+
RG
RG+
C
B
G
-B
-G
-T
-GT
-BT
Bezahlt
Bezahlt; kleine Stücke ohne Umsatz
Bezahlt Brief
Bezahlt Brief; kleine Stücke ohne Umsatz
Bezahlt Geld
Bezahlt Geld; kleine Stücke ohne Umsatz
Etwas bezahlt Brief
Etwas bezahlt Brief; kleine Stücke ohne Umsatz
Etwas bezahlt Geld
Etwas bezahlt Geld; kleine Stücke ohne Umsatz
Rationiert/Rep. Brief
Rationiert/Rep. Brief; kleine Stücke ohne Umsatz
Rationiert/Rep. Geld
Rationiert/Rep. Geld; kleine Stücke ohne Umsatz
Kompensationsgeschäft (nur Börse Frankfurt)
Brief
Geld
Gestrichen
Gestrichen Brief
Gestrichen Geld
Gestrichen Taxe
Gestrichen Geld / Taxe
Gestrichen Brief / Taxe
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 78
Feld 79 / 1., 2., 3. Zeile (Ereignisschlüssel):
Bei den verschiedenen Indikatoren gilt folgende Feldbelegung:
Indikator Pflichtfelder (M)
Wahlfelder (O)
FIXOF
2.Datum (gültig bis)
2.Uhrzeit (gültig bis) generell, falls 2. Datum
belegt: '235959'
Art des Nebenrechts: die Ergänzung
'-ZG' (gestrichen Ziehung) ist möglich
Börsenplatz
1.Datum (gültig ab)
1.Uhrzeit (gültig ab): aktuelle Uhrzeit falls
gleichtägig wirksam wird; ansonsten:
'000000'
Xetra®
Falls keine Wahlfelder angegeben, gilt die Aussetzung bis zur expliziten Rücknahme. In Xetra® gilt die Aussetzung bis zum Übergang in einen anderen Instrument-Status.
FIXON
Börsenplatz
1.Uhrzeit (gültig ab)
keine
PLUSA
PLUSR
MINUA
MINUR
Börsenplatz
Währung
Art der Plus/Minusankündigung
Geldkurs
Briefkurs
RATIA
RATIR
KUTAX
Börsenplatz
Währung
Geldkurs
Briefkurs
Für die Rücknahme einer Kurstaxe (KUTAX) wird der zurückgenommene Geld- und/oder
Briefkurs nicht belegt.
BZRHD
Börsenplatz
Währung
KZ-Aufnahme:
AG = Aufnahme geschlossen
Geldkurs
Briefkurs
SPOTR
Börsenplatz
1.Uhrzeit (gültig ab) (= Kursfeststellungszeit)
Kurs (= Kassakurs)
Währung
Zinstage
TREXP
(„nnnn“)
Börsenplatz
1. Datum (JJMMTT)
1. Uhrzeit (HHMMSS)
2. Datum (JJMMTT)
2. Uhrzeit (HHMMSS)
X
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 79
Wahlfelder (O)
EKURS
AKURS
LKURS
Börsenplatz
1.Datum (der Kursfeststellung)
1.Uhrzeit (der Kursfeststellung)
2.Datum (der Durchführung)
2.Uhrzeit (der Durchführung)
Kurs alt (bei AKURS / LKURS)
Zusatz alt (bei AKURS / LKURS)
Kurs neu (bei EKURS / AKURS)
Zusatz neu (bei EKURS / AKURS)
ORDCH
1.Datum (gültig ab): Dieses Feld enthält den
Extag des Handelsereignisses
1.Uhrzeit (gültig ab): generell '000000'
Art des Nebenrechts
Börsenplatz
Limitabschlag
N = Kennzeichen für Limitaufschlag
Währung
Neue Wertpapiergattung
(= WKN-Änderung)
Falls keines der Wahlfelder angegeben ist,
wurden die Orders gestrichen
Ù Zu den möglichen Arten von Nebenrechten siehe nachfolgende
Tabelle
ORDIN
1.Datum (gültig ab):Dieses Feld enthält den
Extag des Handelsereignisses
1.Uhrzeit (gültig ab): generell '000000'
Art des Nebenrechts
Xetra®
Börsenplatz
Ù Zu den möglichen Arten von Nebenrechten siehe nachfolgende
Tabelle
HALOF
Börsenplatz
BOEND
ORDRE
BOERE
TRINT
TRSTA
BOINT
BOSTA
NBSTA
INF01
XEBAT
(„nnnn“)
Börsenplatz
TREXP
INCLO
XMAHA
Börsenplatz
1.Uhrzeit (gültig bis)
X
freier Informationstext (Feld F:72)
X
X
keine
X
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 80
Wahlfelder (O)
NOT01
NOT02
NOT03
freier Informationstext (Feld F:72)
Börsenplatz
1.Uhrzeit (gültig bis)
Xetra®
X
X
X
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 81
ORDCH:
ORDCH: Folgende Arten von Nebenrechten sind möglich
Art des NR
Beschreibung
Aktion auf Orderbestand
EREO
ex Redenominierung wegen Euro
Orderlöschung
EXBR
ex Bezugsrecht (ordentliche Kapitalerhöhung)
Orderlöschung
EXBA
ex Berichtigungsaktien (Kapitalerhöhung aus Gesellschaftsmitteln)
Orderlöschung
EXAG
ex Ausschüttung
Limitabschlag bei Genußscheinen
EXDI
ex Dividende (Dividendenausschüttung)
Limitabschlag bei inländischen Aktien
EXDA
ex Dividende (Dividendenausschüttung)
Orderlöschung bei ausländischen
Aktien
EXZS
ex Zinsen
Limitabschlag bei Anleihen
EXAZ
ex Ausgleichszahlung
Limitabschlag bei Aktien
EXBO
ex Bonusrecht
Limitabschlag bei Aktien
HL
Hinweis (auf Besonderheiten wird gesondert hingewiesen)
Orderlöschung
HA
Limitabschlag
EABC
ex verschiedene Rechte
Orderlöschung
EXSP
Teilung (Split) bei ausländischen Aktien
Orderlöschung
WKNA
WKN-Änderung
WKN-Änderung
ENOT
Einstellen der Notierung
Orderlöschung
LHBR
Ende des Bezugsrechtshandels
Orderlöschung von limitierten Orders
SBSL
keine SB-/SL-Orders möglich
Orderlöschung
MSEG
für BOSS-CUBE ungültiges Marktsegment
Orderlöschung
MBKS
Änderung Mindestbetrag Einheitskurs
Orderlöschung
MBVA
Änderung Mindestschluß variabler Handel
Orderlöschung/ -änderung
KSVA
Wechsel von Einheitsnotierung in variablen Handel ohne
Einheitsnotierung
KSKH
Wechsel von Einheitsnotierung in kein Handel
Orderlöschung
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 82
ORDCH: Folgende Arten von Nebenrechten sind möglich (Fortsetzung)
Art des NR
Beschreibung
VAKS
Wechsel von variablen Handel ohne Einheitsnotierung in
Einheitsnotierung
VAKH
Wechsel von variablen Handel ohne Einheitsnotierung in
kein Handel
Orderlöschung
VKKS
Wechsel von variablen Handel mit Einheitsnotierung in
Einheitsnotierung
VKVA
variablen Handel ohne Einheitsnotierung
VKKH
kein Handel
Orderlöschung
ORDIN:
ORDIN: Folgende Arten von Nebenrechten sind möglich
Art des NR
Beschreibung
EXAR
ex Ausschüttung bei Renten
keine; nur informativ
H
keine; nur informativ
Hinweise zu ORDCH und ORDIN:
1. Im Header wird Datum und Zeit der Verarbeitung des Handelsereignisses eingestellt. In der Regel wird dieser
Zeitpunkt im Buchungsschnitt vor dem Extag liegen.
2. In Ausnahmefällen ist die Verarbeitung jedoch auch am Extag vor dem 1. Kurs möglich. Generell werden nur
Orders bearbeitet, deren Eingang bis zum Buchungsschnittende vor dem Extag in BOSS-CUBE vorlagen. Alle
Orders, deren DWZ-Ordernummer in den ersten 6 Stellen identisch mit dem Extag sind (Form: JJMMTT), und
alle Orders, die vom Orderaufgeber mit der Gültigkeit ab dem Folgetag aufgegeben wurden, werden nicht bzgl.
des Handelsereignisses bearbeitet.
3. Dies gilt nicht, falls es sich bei dem Nebenrecht um LHBR handelt. In diesem Fall werden auch die limitierten
Orders mit Gültigkeit ab Folgetag gelöscht.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.6.2.5
05.10.1998
Seite 83
Anfrage: Änderung / Streichung (MT 595)
Urheber:
Bank:
BOSS-CUBE:
Xetra®:
(1)
Übermittlung von Orderänderungen und Orderstreichungen.
(2)
BOSS-CUBE: Für Orders, deren Orderbuch wegen einer laufenden Kursfeststellung
gesperrt ist, erfolgt zunächst die entsprechende Meldung (MT596). Die Änderung der
Order wird im System vorgetragen und nach Entsperren des Orderbuchs automatisch
verarbeitet. Die Bank erhält eine weitere Meldung (MT596), in der die Orderannahme
bzw. Ablehnung (Order bereits ausgeführt; Kassakurs festgestellt bei tagesgültiger Order; etc.) inkl. Uhrzeit der definitiven Annahme / Ablehnung mitgeteilt wird.
(1)
Übermittlung / Protokollierung von Orderänderungen und Orderstreichungen, die über
Terminaleingaben von Bank und Makler in das System eingegeben wurden.
(2)
Mitteilung von Orderänderungen und Orderstreichungen wegen Nebenrechten (auf Orderebene).
(3)
Mitteilung von Teilstreichungen durch Teilausführungen von nicht ganzzahligen Vielfachen des Mindestbetrages variabler Handel.
(4)
Mitteilung von Orderstreichungen wegen Befristung.
(1)
Übermittlung aller Orderänderungen und Orderstreichungen, die über eine VALUES
basierte Frontend-Applikation (Notfall-Prozedere) eingegeben wurden.
(2)
Übermittlung aller Orderänderungen und Orderstreichungen, die „on behalf“ für den
Händler mit der exklusiven Subgroup „ORS“ von der Market Supervision eingegeben
wurden.
(3)
Mitteilung von Orderänderungen und Orderstreichungen wegen Nebenrechten (auf Orderebene). Diese Mitteilungen werden wie Orderänderungen oder Orderstreichungen,
die über eine VALUES basierte Frontend-Applikation eingegeben wurden, interpretiert.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 84
MT 595 Anfrage (Änderung / Streichung)
O/M
Etikett
Feldbezeichnung
Format
M
20:
Bankinterne Order-Nr.
Falls nicht vorhanden: /NONREF
16x
X
M
21:
DWZ-Ordernummer bzw. Xetra® - Ordernummer
13x
X
M
75:
Bank an System:
3n[3a10n,3n]
[/4n][/3n]
Geschäftsvorfallcode:
Art des Wertpapiers,
Stück oder Nennwert (aktueller Wert)
Orderaufgeber
Börsenplatz
Xetra®
X
X
X
System an Bank:
1. Zeile
Geschäftsvorfallcode
Orderaufgeber
ID-KZ bei Terminaleingabe
Börsenplatz
3n[/4n][/DWZUSERb10x][/3n]
2. Zeile
Erstellungszeit der Nachricht (HHMMSSHS)
[EIN-ZEITb8n]
3. Zeile
Art des Nebenrechts
[4x]
X
X
O
77A:
freier Text
35x
M
11:
Nachrichtentyp und
Datum der ursprünglichen Nachricht
3n
6n
O
79:
Bezeichnungen und neue Inhalte der zu ändernden Felder (gleiche Abbildung wie in Ursprungsnachricht, d.h. Feldetikett immer
am Anfang einer neuen Zeile).
Bei Änderung/Löschung von Xetra Orders ist die ISIN ein
Pflichtfeld (Unterfeld F:35B).
35*50x
X
X
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 85
Regeln:
Feld 11
(Nachrichtentyp bzw. Datum der ursprünglichen Nachricht):
Diese Felder werden von der Deutsche Börse Systems AG nicht geprüft. Aus Harmonisierungsgründen
(S.W.I.F.T.) sollten sie jedoch belegt werden:
− Nachrichtentyp:
500 bzw. 501
− Datum der urspr. Nachricht:
Datum der Orderrückmeldung bzw. Tagesdatum.
Feld 21
• Stelle 1-6 (6n): Einstellungsdatum der Order in BOSS-CUBE
Feld 20
(Bankinterne Ordernummer) / Feld 21 (Bezugsauftragsnummer):
Bei Nachrichten von der Bank zum System genügt die Angabe eines der beiden Felder (bei Nutzung
des S.W.I.F.T.-Netz sind jedoch beide Felder erforderlich). Bei Angabe beider Felder müssen diese Felder die gleiche Order innerhalb des Orderbestandes referenzieren. Ansonsten wird die Nachricht abgewiesen.
Feld 75
Code
Bank an System:
111
112
113
System an Bank:
041
042
043
044
045
046
047
048
049
Bedeutung
BOSS
Xetra®
Orderänderung
Ordersplit (siehe unten)
Orderstreichung
Orderteillöschung
Ja
Ja
Ja
Ja
Ja
Nein
Ja
Nein
Rückmeldung Orderänderung über Terminaleingaben durch Bank /
VALUES basierte Frontend-Applikation
Rückmeldung Orderänderung über Terminaleingaben durch Makler
Rückmeldung Orderstreichung über Terminaleingaben durch Bank /
VALUES basierte Frontend-Applikation
Rückmeldung Orderstreichung über Terminaleingaben durch Makler
Order(teil)streichung von Kassaspitzen wegen Teilausführungen und
gleichzeitige Einstellung als Kassaorder
Orderänderung wegen Nebenrechte
Orderstreichung wegen Nebenrechte
Zurückgestellte Änderung via Terminal (wegen Sperre)
Zurückgestellte Löschung via Terminal (wegen Sperre)
Ja
Ja
Ja
Ja
Nein
Ja
Ja
Ja
Nein
Nein
Ja
Ja
Ja
Ja
Nein
Nein
Nein
Nein
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
Code
050
051
052
053
054
055
056
05.10.1998
Seite 86
Bedeutung
BOSS
Xetra®
Orderstreichung wegen Befristung
Umwandlung einer Stop-Order in Billigst / Bestens
Umwandlung einer Stop-Limit in eine Limit Order
Orderänderung durch die Market Supervision „on behalf“
Orderlöschung durch die Market Supervision „on behalf“
Mitteilung des nicht ausgeführten Teils einer FOK/IOC Order
Änderung einer Stop-Limit Order
Ja
Nein
Nein
Nein
Nein
Nein
Nein
Nein
Ja
Ja
Ja
Ja
Ja
Ja
Feld 75
(Geschäftsvorfallcode = 111 Orderänderung und Feld 79):
Die zu ändernden Felder sind innerhalb von Feld F:79 anzugeben. Auch die bankinterne Ordernummer
kann durch Angabe in Feld F:79 geändert werden. In Feld F:20 kann nur die bankinterne Ordernummer
der zu ändernden Order angegeben werden.
Feld 75
(Geschäftsvorfallcode = 112 Ordersplit):
Bei diesem Geschäftsvorfallcode muß zwingend die Nominale als zu änderndes Feld angegeben sein.
Weitere zu ändernde Felder sind möglich.
Folgende Verarbeitung wird bei der Deutsche Börse Systems AG durchgeführt:
Die über Feld F:21 (DWZ-Ordernummer) bzw. Feld F:20 (bankinterne Ordernummer) referenzierte Order
wird um die angegebene Nominale (Feld F:79) reduziert und gleichzeitig wird eine neue Order mit
den Grunddaten der referenzierten Order und den geänderten Feldern aus dieser Nachricht (Feld F:79)
eingestellt. Die Bank erhält zwei Rückmeldungen (MT596): Eine Bestätigung der Änderung der Ursprungsorder (Reduzierung der Nominale) und eine Bestätigung über die Neueinstellung einer Order.
Falls der Vorgang nicht komplett durchgeführt werden kann bzw. wenn das Orderbuch wegen Kursfeststellung gesperrt ist, so erhält die Bank eine Mitteilung.
Die bankinterne Ordernummer für die neu zu generierende Order muß über die zu ändernden Felder
(Feld F:79) mitgeliefert werden. Die bankinterne Ordernummer der Ursprungsorder kann bei Ordersplits
nicht geändert werden. Wird über Feld F:79 keine bankinterne Ordernummer mitgeliefert, so wird wie
folgt verfahren:
• für Banken mit eindeutiger bankinterne Ordernummer (lt. User-Profile):
• der Ordersplit wird abgelehnt
• der Ordersplit wird ebenfalls abgelehnt, falls die über Feld F:79 angegebene bankinterne Ordernummer bereits im Orderbestand von BOSS-CUBE vorhanden ist.
• für Banken mit nicht eindeutiger bankinterner Ordernummer (lt. User-Profile): der Ordersplit wird
durchgeführt; die bankinterne Ordernummer der Ursprungsorder wird in die neu zu generierende
Order übernommen.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 87
Ist die in Feld F:20 bzw. Feld F:21 angegebene Ordernummer nicht vorhanden, so wird eine Nachricht
(MT596) erzeugt mit folgendem Inhalt: Feld F:20 bzw. Feld F:21 enthält den Inhalt der zugrunde liegenden Nachricht (MT595; gedreht 20 <-> 21); im Feld F:79 wird das Feld F:20 bzw. Feld F:21 des MT595
als fehlerhaft ausgewiesen.
Der Geschäftsvorfallcode 112 ist für folgende Situation vorgesehen:
Die Bank sammelt z.B. n Kundenorders, kumuliert diese und sendet eine kumulierte Order. Veranlaßt
ein Kunde einer dieser kumulierten Orders nun eine Änderung z.B. des Limits, so wird über den hier definierten Geschäftsvorfall die Reduzierung der kumulierten Order und Neuaufgabe einer neuen Order in
einem Verarbeitungsschritt (Transaktion) durchgeführt. Würde die Bank eine Änderung durch Ursprungsorder senden und danach einen Zugang für die durch den Kunden geänderte Order, so kann
zwischen beiden Verarbeitungsschritten eine Kursfeststellung des Maklers bearbeitet werden, so daß
u.U. die Änderung ausgeführt wird und der Zugang nicht mehr (vor der Kursfeststellung). Somit könnte
der Fall eintreten, daß ein Kunde eine 'billigst' - Order auf ein Limit ändert, der Kursmakler einen Kurs
feststellt, zu dem beide Zustände der Order ausführbar sind, die Order aber aufgrund der geschilderten
Situation nicht ausgeführt wird.
Feld 75
(Geschäftsvorfallcode = 113 Orderstreichung):
Ohne Belegung von Feld F:79 wird die durch Feld F:20 bzw. Feld F:21 referenzierte Order vollständig
gestrichen. Durch Angabe der zu streichenden Nominale im Feld F:79 (als zu änderndes Feld) wird eine
Teilstreichung der Order durchgeführt.
Xetra: Im Rahmen von Xetra ist eine Teilstreichung der Order nicht möglich. Entsprechende Orders
werden mit einer Fehlermeldung abgelehnt. Falls eine Änderung des Volumens für Xetra Orders gewünscht wird, kann dieses mit dem GV-Code 111 (unter Angabe des neuen Volumens) durchgeführt
werden.
Feld 75
Bei Kassakursen mit bestimmten Kurszusätzen (z.B. bG, bB etc.) sind für auszuführende variable Orders auch Teilausführungen von nicht ganzzahligen Vielfachen des Mindestbetrages variabler Handel
erlaubt. Die verbleibende Restorder erfüllt in diesen Fällen dann nicht mehr die Bedingungen des variablen Handels. Für die entstehende 'Kassaspitze' der Restorder erfolgt eine Streichung bzw. Teilstreichung und eine Neueinstellung als Kassaorder. Diese Aktionen werden über GV-Code = 045 wie folgt
den Banken mitgeteilt:
• Feld F:20: BI-Ordernummer der Ursprungsorder
• Feld F:21: DWZ-Ordernummer der Ursprungsorder
• Feld F:79: die Nominale der zu (teil-)streichenden variablen Order (Kassaspitze) bzw. die Nominale
der einzustellenden Kassaorder sowie die neu vergebene DWZ-Ordernummer der neuen Kassaorder
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
Beispiel:
Ursprungsorder:
05.10.1998
Seite 88
Nominale
DWZ-Ordernummer
BI-Ordernummer
Teilausführung am 15.11.92: Nominale
= 200
= 9211010000001
= 4711
= 80 (MT519/:35A:SHS80,)
⇒ (1)
Es verbleibt von der Ursprungsorder als variable Order:
BI-Ordernummer
= 4711;
DWZ-Ordernummer
= 9211010000001
Nominale
= 100
⇒ (2)
Es erfolgt die Einstellung einer Kassaorder:
Nominale
BI-Ordernummer
neue DWZ-Ordernummer
sonstige Felder
= 20 (Kassaspitze)
= nicht belegt
= 9211150000002
= identisch mit Ursprungsorder.
Die Bank erhält folgende Nachricht:
(MT595):
.
:
:20:4711
:21:9211010000001
:75:045
:11:500
921101
:79:20:DWZ9211150000002
35A:SHS20,
.
:
-}
(Feld F:79 enthält alle Felder der neu eingestellten Kassaorder)
Feld 75
(Geschäftsvorfallcode = 046 / 047):
Informationen auf Orderebene werden generiert, wenn die Bank in ihrem Benutzerprofil folgende
Einträge hat:
• Orderbestandsänderung wegen Nebenrecht:
1 (=CPU)
• Information auf Orderebene:
J
Xetra: Für Xetra werden diese GV-Codes nicht geliefert.
Feld 75
(Geschäftsvorfallcode = 048 / 049):
Kann eine zurückgestellte Änderung/Löschung, die über Terminal eingestellt wurde, wegen zwischenzeitlicher Kursauszeichnung nicht durchgeführt werden, so wird kein MT595, sondern ein MT596 mit
Geschäftsvorfallcode 315/325 und mit Fehlercode BC1520F (=Order bereits ausgeführt) geliefert. Bei
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 89
erfolgreicher Durchführung der zurückgestellten Änderung / Löschung wird ein MT595 mit GV-Code 41
bzw. 43 geliefert.
Bei zurückgestellter Änderung der bankinternen Ordernummer enthält Feld F:20 schon die neue bankinterne Ordernummer.
Feld 75
Zu bestimmten Terminen (z.B. 30.06./31.12.) werden die im System befindlichen aktiven Orders zum
Ende dieses Handelstages durch das System gestrichen. Ausnahmen sind Bezugsrechtsorders und Orders mit Einstellung 'Gültig-ab-Folgetag' durch das Kreditinstitut.
Die Verarbeitung der Orderstreichungen wegen Befristung erfolgt nach dem Online-Ende von BOSSCUBE. Die Daten (MT595) können somit nicht direkt den Kreditinstituten übermittelt werden. Sie werden
bereitgestellt und können am nächsten Tag mittels Retrieval angefordert werden.
Feld 75
Xetra: Bei der Umwandlung einer Stop-Market Order in Billigst / Bestens wird in Xetra das Attribut
”lastupdatedate” aktualisiert. Diese Änderung wird der Bank über den GV-Code 051 mitgeteilt.
Feld 75
Xetra: Bei der Umwandlung einer Stop-Limit Order in eine Limit Order wird der Bank das umgesetzte
Limit mitgeteilt.
Feld 75
Xetra: Bei der Eingabe einer FOK / IOC Order sowohl über die SNA-Schnittstelle, als auch bei Eingabe über eine VALUES basierte Frontend-Applikation, kann es zu einer Nichtausführung bzw. zu
Teilausführungen kommen. Der nicht ausgeführte Teil der Order wird in einem solchen Fall im Feld
F:79:35A (Stück oder Nennwert) unter Angabe des GV-Codes 055 der Bank mitgeteilt. Falls es zu
Teilausführungen kommt (nur für IOC Orders relevant) werden Ausführungsbestätigungen (Nachrichtentyp MT519) an die Bank gesendet. Eine Beschreibung des Ablaufs bei Eingabe einer FOK / IOC Order findet sich unter 2.6.2.6 Antwort (MT 596).
Feld 75
Xetra: Dieser GV-Code wird bei den folgenden zwei Aktionen an die Bank gesendet:
1.
2.
Änderung einer Stop-Market Order in eine Stop-Limit Order über eine VALUES basierte FrontendApplikation.
Änderung einer Stop-Limit Order über eine VALUES basierte Frontend-Applikation (z.B.: Änderung
des Stop-Limits).
Eine Ordermodifikation einer Stop-Limit Order über die Xetra Order Routing SNA Schnittstelle ist nicht
möglich und wird deshalb abgelehnt (Fehlercode: XA2020F). Die Löschung einer Stop-Limit Order hingegen ist möglich.
Feld 75
(Börsenplatz):
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 90
(lt. WM- Schlüssel GD621). Möglicher Wertebereich:
100 – Berlin
110 – Bremen
120 – Düsseldorf
130 – Frankfurt
140 – Hamburg
150 - Hannover
160 - München
170 - Stuttgart
194 - Xetra®
Xetra®: Bei der Lieferung der Nachricht von der Bank zum System ist bei Xetra® Orders der Börsenplatz
(194) ein Pflichtfeld. Im umgekehrten Fall (System an Bank) wird der Börsenplatz nur bei Xetra® Orders
zurückgeliefert.
Feld 75
(Stück oder Nennwert):
Bei den GV-Codes = 111, 112 und 113 kann als Ergänzung dieses Feld (aktueller Wert, der dem Teilnehmer bekannt ist) mit angegeben werden. Die Orderänderung, der Ordersplit bzw. die Orderstreichung wird abgelehnt, falls die aktuell gültige Stückzahl / Nominale der Order in BOSS-Cube / Xetra
(nur bei der Orderänderung) ungleich diesem Feld ist. Als Fehlercodes erhält man:
BOSS-CUBE:
BC5120F
Xetra®:
XA2010F
Wird dieses Feld nicht angegeben, werden die entsprechenden Aktionen ohne Prüfung der Stückzahl /
Nominale generell durchgeführt.
Ergänzung: Falls eine Änderung der aktuell gültigen Stückzahl / Nominale gewünscht wird, so kann dieses durch Angabe des Feldes F:79:35A erreicht werden.
Xetra: Für Xetra wird das Feld aktuell gültige Stückazhl / Nominale nur bei einer Änderung (GV-Code
111) geprüft. Das Feld sollte bei Orderänderungen unbedingt gefüllt sein. Falls bei einer Orderstreichung (GV-Code 113) dieses Feld gefüllt ist, wird die Orderstreichung mit dem Fehlercode XK0210F
abgelehnt.
Feld 75
(Orderaufgeber):
Falls bei Banken mit zentraler Anbindung die KV-Konto-Nr. des Orderaufgebers von der KV-Konto-Nr.
der Zentrale abweicht und die DWZ-Ordernummer / Xetra®-Ordernummer (Feld F:21) nicht belegt wird,
muß dieses Feld bei Nachrichten von der Bank zum System mitgeliefert werden. Bei Nachrichten von
dem System zur Bank ist das Feld generell belegt.
Empfehlung: Das Feld sollte von Banken generell gepflegt werden (auch für Banken mit dezentraler Anbindung).
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
Feld 75
05.10.1998
Seite 91
(ID-KZ bei Terminaleingabe / Values basierte Frontend-Applikation):
Das Feld wird nur bei GV-Codes = 041, 042, 043, 044, 048, 049, 051, 052, 053, 054, 055 und 056 belegt.
Xetra®: Das ID-KZ enthält die letzten sechs Stellen der Trader-ID (z.B.: „ORS002“)
Feld 75
(Einstellungszeit der Nachricht):
Die Einstellungszeit enthält die Uhrzeit des Eingangs in das System.
Feld 75
(Art des Nebenrechts):
Bei Orderänderung/-löschung wegen Nebenrechten (GV-Code 046/047) wird die Art des Nebenrechts
mitgeliefert (siehe auch MT551). Bei Orderlöschung wegen Kursaussetzung wird "AUSS", bei Orderlöschung wegen Auslosung wird "-ZG" als Schlüsselwert geliefert.
Feld 77A (freier Text):
Nur belegbar bei Nachrichten von Banken zum System. Bei Bedarf können hier Änderungen / Löschungen referenziert werden; der hier angegebene Text wird unverändert vom System in die Rückmeldung
(MT596) eingestellt.
Xetra®: Das Feld F:77A wird von Xetra® nicht unterstützt.
Feld 79
(Bezeichnungen und neue Inhalte):
Xetra: Die Eingabe der ISIN ist in Xetra® sowohl für Orderänderungen, als auch Orderlöschungen eine
Pflichteingabe.
Ergänzung: Da die ISIN in der 1. Zeile des Feldes ”F:79:35B” angegeben werden muß, ist gemäß
S.W.I.F.T. Konventionen auch die zweite Zeile (Wertpapierkurzbezeichnung) zu füllen, da es sich bei
dieser Zeile um keine optionale Angabe handelt. Ferner sollte in der 3. Zeile des Feldes ”F:79:35B” das
Attribut ”lastupdatedate” mit angegeben werden.
Bei Änderungen der Order über eine VALUES basierte Frontend-Applikation wird unter Umständen eine
neue Xetra-Ordernummer vergeben. Diese neue Xetra-Ordernummer wird im Feld F:79:20 mitgeteilt
(DWZnnnnnnnnnnnnn). Ausnahme von dieser Regel ist die Orderänderung wegen Nebenrechten, bei
der keine neue Xetra-Ordernummer vergeben wird.
Darstellung der Feldinhalte F:20 (bankinterne Ordernummer), F:21 (Xetra-Ordernummer) und F:79:20
bei der Änderung einer Order über eine VALUES basierte Frontend-Applikation:
Änderung
Keine Änderung der bankin-
F:20(BI-Order-Nr.)
Aktuell gültige bankinterne Or-
ternen oder der Xetra-Order- dernummer
F:21 (Xetra-Order-Nr.)

F:79:20
Aktuell gültige Xetra -Ordernum-
mer zur Referenzierung
dernummer
nummer
Nur Änderung der bankinter-
Aktuell gültige Xetra-Order-
nen Ordernummer
dernummer
nummer zur Referenzierung
dernummer
Nur Änderung der Xetra Or- Aktuell gültige bankinterne Or-
Alte Xetra-Ordernummer zur
Neue Xetra-Ordernummer
dernummer
Referenzierung beim Teilnehmer
(DWZnnnnnnnnnnnnn).
dernummer
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 92
Änderung
F:20(BI-Order-Nr.)
F:21 (Xetra-Order-Nr.)
F:79:20
Änderung der bankinternen
Alte Xetra-Ordernummer zur
Neue Xetra-Ordernummer
und der
dernummer
Referenzierung beim Teilnehmer
(DWZnnnnnnnnnnnnn).
Xetra-Ordernummer
Feld 79
(Unterfeld 32L / Handelshinweis):
Xetra: Für den Inhalt des Attributes Handelshinweis im Feld F:79:32L gilt bei der Vornahme von Änderungen folgendes:
1. Bank an System: Um eine Order von Auction Only, Opening Auction oder Closing Auction auf Continuous Trading zu ändern, muß der Schlüsselwert „CT“ (Continuous Trading) eingegeben werden.
2. System an Bank: Bei der Mitteilung einer Orderänderung (z.B. bei Eingabe über eine VALUES basierte Frontend-Applikation) von System an Bank wird im Attribut Handelshinweis des Feldes
F:79:32L der Schlüsselwert „CT“ (Continuous Trading) für die entsprechenden Orders mitgeteilt.
Ergänzung: Der Schlüsselwert „CT“ für das Attribut Handelshinweis ist für alle anderen Nachrichtentypen (z.B.: MT500, MT501, MT519) nicht zulässig.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.6.2.6
05.10.1998
Seite 93
Antwort (MT 596)
Urheber:
BOSS-CUBE:
Xetra®:
(1)
Rückmeldungen (Bestätigungen und Fehlermeldungen) von Ordereinstellungen, Orderänderungen und Orderlöschungen für maschinell übermittelte Aufträge.
Für Orders, deren Orderbuch wegen einer laufenden Kursfeststellung gesperrt ist, erfolgt zunächst eine entsprechende Meldung. Die Änderung der Order wird im System
vorgetragen und nach Entsperren des Orderbuchs automatisch verarbeitet. Die Bank
erhält eine weitere Meldung (MT596), in der die Orderannahme bzw. Ablehnung (Order
bereits ausgeführt; Kassakurs festgestellt bei tagesgültiger Order; etc.) inkl. Uhrzeit der
definitiven Annahme/Ablehnung mitgeteilt wird (vgl. Anlage).
(2)
Bei Übermittlung von Orders, die über Terminaleingaben in das System gelangten und
bei Übermittlung des gesamten Orderbestandes zu Kontrollzwecken wird in Ergänzung
zu MT500/MT501 eine Nachricht dieser Art gesandt, um die DWZ-Ordernummer der
Bank mitzuteilen (nur falls bankinterne Ordernummer vorhanden). Die Verknüpfung zu
MT500/MT501 erfolgt über Feld F:20 (bankinterne Ordernummer).
(1)
Für Orders, die über die Order-Management-Systeme der Kreditinstitute eingestellt,
geändert oder gelöscht werden und via Orderroutingsystem zu Xetra® weitergeleitet
worden sind, werden Rückmeldungen (Bestätigungen und Fehlermeldungen) erstellt.
Hierfür wird der Nachrichtentyp MT596 verwendet.
Orders, die während der Preisermittlungsphase oder Marktausgleichsphase eingestellt
werden, werden von Xetra mit dem GV-Code 3n5 und einer qualifizierten Xetra
Fehlermeldung zurückgewiesen.
(2)
Bei Übermittlung von Orders, die über Eingaben in VALUES basierten FrontendApplikationen in das System gelangten, wird in Ergänzung zu MT500 / MT501 eine
Nachricht dieser Art gesandt, um die Xetra®-Ordernummer der Bank mitzuteilen (nur
falls bankinterne Ordernummer vorhanden). Die Verknüpfung zu MT500/MT501 erfolgt
über Feld F:20 (bankinterne Ordernummer).
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 94
MT 596 Antwort (Rückmeldung)
O/M
Etikett
Feldbezeichnung
Format
Xetra®
M
20:
DWZ-Ordernummer bzw. Xetra® - Ordernummer (alt)
13x
X
M
21:
Bezugsauftragsnummer (Bankinterne Order-Nr.)
Falls nicht vorhanden: /NONREF
16x
X
M
76:
1. Zeile:
/3n[/13x]
Codenummer
Xetra® - Ordernummer (neu)
2. Zeile:
Erstellungszeit der Nachricht (HHMMSSHS)
Versionsnummer (lastupdatedate)
X
X
[EIN-ZEITb8n]
[18n]
X
O
77A:
freier Text (wird übernommen aus MT595/Feld F:77A)
35x
X
M
11:
Nachrichtentyp und
Datum der ursprünglichen Nachricht
3n
6n
X
O
79:
Fehlercode: Feldetikett,
Fehlerhinweis
(mögliche Fehlerhinweise vgl. Kap. 2.5.5)
3*3x[7x]
X
Regel:
Feld 20
• Stelle 1-6 (6n): Einstellungsdatum der Order in das BOSS-CUBE - System
Xetra® vergibt bei Limitänderung, Verlängerung der Gültigkeit und Erhöhung der Nominale, eine neue
Ordernummer. In diesem Fall gibt Xetra® die alte Ordernummer in Feld F:20 und die neue Ordernummer
in Feld F:76 zurück.
Bei einer Orderänderung/-löschung (MT595), die nur über die bankinterne Ordernummer (Feld F:20) referenziert wurde, und die abgelehnt wird, enthält das Feld F:20 im MT596 den Wert "0000000000000".
Feld 21
Bezugsauftragsnummer (Bankinterne Order-Nr.):
Xetra®: Bei einer Änderung der bankinternen Ordernummer wird im Gegensatz zu BOSS-CUBE in diesem Feld die neue und nicht die alte bankinterne Ordernummer geliefert.
Feld 76
(Codenummer):
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 95
Im folgenden ist aufgeführt, welche Codenummern von welchem System (BOSS-CUBE und Xetra®)
unterstützt werden.
Codenummer
/000
/3n0
/3n1
/3n2
/3n3
/3n4
/3n5
/3n6
/307
n=
Bedeutung
BOSS
Xetra®
Folgesatz zu MT500/MT501(bei Datentransfer System -->
Bank)
Anforderung fehlerfrei durchgeführt
Konvertierungsfehler (Order wurde nicht übergeben)
Anforderung zurückgestellt, später neuer Versuch durch
BOSS-CUBE
Order nicht gefunden
Order bereits vorhanden
Dateninhalte führten zu Fehler
Anforderung nicht durchgeführt; Funktionen für BOSS-CUBE
- Systemanschluß sind z.Z. gesperrt
Zugang fehlerfrei durchgeführt, gültig ab Folgetag
0 Ù Zugang
1 Ù Änderung
2 Ù Streichung
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Nein
Ja
Ja
Ja
Ja
Ja
Nein
Ja
Nein
Ja
Ja
Ja
Ja
Nein
Ja
Ja
Ja
Abfolge der erzeugten Nachrichtentypen (System an Bank) bei einer Eingabe einer FOK / IOC Order
über die SNA-Schnittstelle oder eine VALUES basierte Frontend-Applikation:
Order
Ergebnis
SNA-Schnittstelle
FOK:
1. Ausführung
MT596 (GV-Code 300)
2. Ablehnung
MT596 (GV-Code 300)
1. Ausführung
MT596 (GV-Code 300)
2. Ablehnung
MT596 (GV-Code 300)
3. Teilausführung
MT596 (GV-Code 300)
IOC:
Frontend-Applikation
MT500 / MT501 und evtl. der Folgesatz MT596
Eine bis n Ausführungsbestätigungen (MT519)
Orderlöschungsmitteilung MT595 (GV-Code 055)
Orderteillöschungsmitteilung MT595 (GV-Code 055) über den gelöschten Teil
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 96
Abfolge der erzeugten Nachrichtentypen (System an Bank) bei der Änderung einer Order in eine FOK /
IOC Order über die SNA-Schnittstelle oder eine VALUES basierte Frontend-Applikation. Das Verfahren
ist analog zu dem der Ordereingabe:
Order
Ergebnis
SNA-Schnittstelle
FOK:
1. Ausführung
MT596 (GV-Code 310)
MT595
2. Ablehnung
MT596 (GV-Code 310)
MT595
1. Ausführung
MT596 (GV-Code 310)
MT595
2. Ablehnung
MT596 (GV-Code 310)
MT595
3. Teilausführung
MT596 (GV-Code 310)
MT595
Orderteillöschungsmitteilung MT595 (GV-Code 055) über den gelöschten Teil
IOC:
Feld 76
Frontend-Applikation
(Xetra®-Ordernummer neu):
Xetra® vergibt bei einer Limitänderung, Verlängerung der Gültigkeit oder Erhöhung der Nominale eine
neue Ordernummer. In diesem Fall transferiert Xetra® die alte und die neue Ordernummer.
Feld 76 / 2. Zeile (Versionsnummer lastupdatedate):
Xetra®: Xetra® transferiert bei einer erfolgreichen Ordereingabe oder -modifikation die aktuelle Versionsnummer (lastupdatedate). Diese Versionsnummer sollte für zukünftige Ordermodifikationen verwendet werden. Eine Versionsnummer wird nicht geliefert, wenn die Order entweder sofort vollständig
ausgeführt wird, oder wenn es sich um eine FOK / IOC Order handelt.
Feld 77A (freier Text):
Xetra®: Das Feld F:77A wird von Xetra® nicht unterstützt.
Feld 11
(Nachrichtentyp):
Das Feld F:11 ‘Nachrichtentyp’ enthält als Inhalt den Nachrichtentyp, der sozusagen der Initiator der
Eingabebestätigung war.
Feld 79 / Fehlercode (Feldetikett):
Xetra®: Die Angabe des Feldetiketts wird von Xetra® nicht unterstützt. Anstelle dessen werden Leerzeichen geliefert.
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
2.6.2.7
05.10.1998
Seite 97
Urheber:
Funktion:
Dieser Nachrichtentyp wird als Umschlag für die bereits definierten Nachrichtentypen
MT000, MT001, MT002, MT003, MT020 und MT021 benutzt (Kap. 2.6.1 ff).
MT 598 Nachricht für eigene Anwendung
O/M
Etikett
Feldbezeichnung
Format
M
20:
Auftragsnummer (TRN)
6n7n
M
12:
Nachrichtentyp der in dieser Nachricht übermittelt wird
3n
M
77E:
Nachricht gemäß besonderer Beschreibung ohne Header und
Trailer
73x
[n*78x]
Regeln:
Feld 20:
Bei File-Transfer gilt folgendes Format: 6n3n
Bei Übertragungen vom System zur Bank wird die Auftragsnummer jeweils in Vor- (Feld F:12 = 000) und
Nachsatz (Feld F:12 = 002) eingestellt. Die Nummern in beiden Sätzen sind pro Stapel identisch.
Bei Programm/Programm-Verbindung gilt generell:
Bei allen Rückmeldungen / Bestätigungen, wird im Feld F:20 die TRN aus der zugrundeliegenden Nachricht des Kreditinstituts eingestellt. Beim Nachrichtenaustausch über das S.W.I.F.T.-Netz (Backup, Folgerelease) kann diese Verfahrensweise nicht beibehalten werden; hierbei wird die TRN neu vergeben.
Die Auftragsnummer (TRN) ist wie folgt aufgebaut:
• Stelle 1-6 (6n): Entstehungsdatum der Nachricht
• Stelle 7-13 (7n): 7-stellige laufende Nr. (wird nicht geprüft)
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
3
05.10.1998
Seite 98
Beispiele zur Anwendung der S.W.I.F.T.-Konventionen innerhalb der
Orderübermittlung
Die Beispiele sind unter Berücksichtigung der Restriktionen der Systeme erstellt wurden (Beispiele zur Kategorie 5).
Xetra: Xetra spezifische Änderungen in den Beispielen sind ”fett” gekennzeichnet.
3.1
Kauforder (MT 500)
BEISPIEL 1A: (S.W.I.F.T. II): Kauf festverzinslicher Papiere zur Kasse
{1:F01DRESDEFFAXXX0000000004}
{2:I500DWZXDEFFABOSN2005}
{4:
:20:ABCDEFGH
:30:900530
:35A:FMT10000,
:35B:ISIN DE0002681491
HESS.LDSBK.IS.E.242
:32L:DEM99,5
/130 KS
-}
(kein CrLf)
(kein CrLf)
BEISPIEL 1B: (S.W.I.F.T. II): Format für eine Xetra® - Kauforder
{4:
:20:ABCDEFGH2
:30:980530
:35A:FMT10000,
:35B:ISIN DE0002030751
BAY.HYP.BK.AG PF.R.46 SVG
:32L:DEM99,5
/194
-}
(kein CrLf)
(kein CrLf)
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
3.2
05.10.1998
Seite 99
Verkauforder (MT501)
BEISPIEL 2A: (S.W.I.F.T. II): Verkauf von Aktien im variablen Handel
{4:
:20:ABCDABCD
:30:900829
:35A:SHS100,
:35B:ISIN DE0007664005
VOLKSWAGEN
:32L:DEM0,
/120
:82D:/4037
-}
(kein CrLf)
(kein CrLf)
BEISPIEL 2B: (S.W.I.F.T. II): Format für eine Xetra® - Verkauforder
{4:
:20:ABCDABCD2
:30:980829
:35A:SHS100,
:35B:ISIN DE0007664005
VOLKSWAGEN
:32L:DEM0,
/194
:82D:/7002
-}
(kein CrLf)
(kein CrLf)
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
3.3
Ausführungsanzeige (MT 519)
BEISPIEL 3A: (S.W.I.F.T. II): Ausführungsanzeige für festverzinsliche Papiere
Bezug auf: Beispiel 1A
(kein CrLf)
{2:O5191125900515DWZXDEFFABOS00000000019005151125N} (kein CrLf)
{4:
:20:9005150004711
(DWZ-Order-Nr. gem. MT596 zu MT500)
:21:ABCDEFGH
(Bankinterne Order-Nr.)
:23:BOUGHT
:31P:900515130KS780112020768/+105
:35A:FMT10000,
:35B:ISIN DE0002681491
HESS.LDSBK.IS.E.242
:33T:DEM99,45
-}
BEISPIEL 3B: (S.W.I.F.T. II): Format für eine Xetra® - Ausführungsanzeige
Bezug auf: Beispiel 1B
(kein CrLf)
{2:O5191125980515DWZXDEFFABOS00000000019805151125N} (kein CrLf)
{4:
:20:0000000000001
(Xetra®-Order-Nr. gem. MT596 zu MT500)
:21:ABCDEFGH2
(Bankinterne Order-Nr.)
:23:BOUGHT
:31P:980515194XT000012020700/+105
:35A:FMT10000,
:35B:ISIN DE0002030751
BAY.HYP.BK.AG PF.R.46 SVG
123456789012345678
(Versionsnummer / lastupdatedate)
:33T:DEM99,45
-}
05.10.1998
Seite 100
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
3.4
Ereignis im Wertpapiergeschäft (MT 551)
3.4.1
Kassakursmitteilung
05.10.1998
Seite 101
BEISPIEL 4: (S.W.I.F.T. II)
{2:O5511336900830DWZXDEFFABOS00000000219008301336N}
{4:
:20:9008301234567
:35B:ISIN DE0007664005
VOLKSWAGEN
766400
:79:SPOTR900830133550
/504,//130/DEM/7885///////
-}
3.4.2
(kein CrLf)
(kein CrLf)
Kursaussetzung für VW-Aktien in Frankfurt
{2:O5511155900830DWZXDEFFABOS00000000039008301155N}
{4:
:20:9008302345678
:35B:ISIN DE0007664005
VOLKSWAGEN
766400
:79:FIXOF900830120050
///130/////////
-}
(kein CrLf)
(kein CrLf)
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
3.5
Anfrage (MT 595)
3.5.1
Orderänderung
05.10.1998
Seite 102
BEISPIEL 6A: (S.W.I.F.T. II) (Bezug auf: Beispiel 2A)
Limitänderung
{4:
:20:ABCDABCD
:75:111/4037
:11:501
900515
:79:32L:DEM600,
/120
-}
(kein CrLf)
(kein CrLf)
Die Änderung wird mit MT596 bestätigt.
BEISPIEL 6B: (S.W.I.F.T. II): Format für eine Xetra® - Orderänderung (Bezug auf: Beispiel 2B)
Limitänderung
{4:
:20:ABCDABCD2
:21:0000000000002
:75:111/7002/194
:11:501
980515
:79:35B:ISIN DE0007665005
VOLKSWAGEN
123456789012345678
32L:DEM600,
/194
-}
Die Änderung wird mit MT596 bestätigt.
(kein CrLf)
(kein CrLf)
(Xetra® - Ordernummer)
(Versionsnummer ”lastupdatedate”)
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
3.5.2
05.10.1998
Seite 103
Orderstreichung
BEISPIEL 7A: (S.W.I.F.T. II) (Bezug auf: Beispiel 1A)
{4:
:20:ABCDEFGH
:21:9005150004711
:75:113/4037
:11:500
900515
-}
(kein CrLf)
(kein CrLf)
(Bankinterne Ordernummer)
(DWZ-Order-Nr. gem. MT596 zu MT500)
BEISPIEL 7B: (S.W.I.F.T. II): Format für eine Xetra® - Orderstreichung (Bezug auf: Beispiel 1B)
{4:
:20:ABCDEFGH2
:21:0000000000001
:75:113/7002/194
:11:500
980515
:79:35B:ISIN DE0007665005
VOLKSWAGEN
-}
(kein CrLf)
(kein CrLf)
(Bankinterne Ordernummer)
(Xetra®-Order-Nr. gem. MT596 zu MT500)
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
3.6
Antwort (MT 596)
3.6.1
Bestätigung der Orderannahme
05.10.1998
Seite 104
BEISPIEL 8A: (S.W.I.F.T. II) (Bezug: Beispiel 1A)
Rückmeldung (Positiv):
{2:O5961125900515DWZXDEFFABOS00000000049005151125N}
{4:
:20:9005150004711
:21:ABCDEFGH
:76:/300
EIN-ZEIT 11244001
:11:500
900515
-}
(kein CrLf)
(kein CrLf)
BEISPIEL 8B: (S.W.I.F.T. II): Format für Xetra® (Bezug: Beispiel 1B)
{2:O5961125980515DWZXDEFFABOS00000000049805151125N}
{4:
:20:0000000000001
:21:ABCDEFGH2
:76:/300/0000000000003
EIN-ZEIT 11244001123456789012345678
:11:500
980515
-}
(kein CrLf)
(kein CrLf)
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
3.6.2
05.10.1998
Seite 105
Ablehnung wegen Datenfehler
BEISPIEL 9A: (S.W.I.F.T. II)
Fehlerhafte Nachricht:
{4:
:20:ABABABAB
:30:990710
:35A:FMT10000
:35B:ISIN DE0002681491
HESS.LDSBK.IS.E.242
:32L:DEM99,5
/120
:82D:/4037
-}
(kein CrLf)
(kein CrLf)
Rückmeldung (Datenfehler):
{2:O5961125900515DWZXDEFFABOS00000000069005151125N}
{4:
:20:0000000000000
:21:ABABABAB
:76:/305
EIN-ZEIT 11250110
:11:500
900515
:79:30 BC0700F
-}
(kein CrLf)
(kein CrLf)
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
05.10.1998
Seite 106
BEISPIEL 9B: (S.W.I.F.T. II): Format für Xetra®
Fehlerhafte Nachricht:
{4:
:20:ABABABAB
:30:980710
:35A:FMT10000
:35B:ISIN DE0002681491
HESS.LDSBK.IS.E.242
:32L:DEM99,5
/194
:82D:/4037
-}
(kein CrLf)
(kein CrLf)
Rückmeldung (Datenfehler):
{2:O5961125980515DWZXDEFFABOS00000000069805151125N}
{4:
:20:0000000000000
:21:ABABABAB
:76:/305
EIN-ZEIT 11250110
:11:500
980515
:79: XnnnnnF
-}
(kein CrLf)
(kein CrLf)
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
3.6.3
05.10.1998
Seite 107
Bestätigung einer Änderung
{1:F01DRESDEFFAXXX0000000007
{2:O5961125900829DWZXDEFFABOS00000000079005151125N}
{4:
:20:9008290004712
:21:ABCDABCD
:76:/310
EIN-ZEIT 11255830
:11:595
900515
-}
(kein CrLf)
(kein CrLf)
BEISPIEL 10B: (S.W.I.F.T. II): Format für Xetra® (Bezug: Beispiel 6B)
{2:O5961125980829DWZXDEFFABOS00000000079805151125N}
{4:
:20:0000000000002
:21:ABCDABCD2
:76:/310/0000000000004
EIN-ZEIT 11255830123456789012345678
:11:595
980515
-}
(kein CrLf)
(kein CrLf)
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
3.6.4
05.10.1998
Seite 108
Bestätigung einer Streichung
Rückmeldung (Negativ):
{2:O5961125900515DWZXDEFFABOS00000000089005151125N}
{4:
:20:9005150004711
:21:ABCDEFGH
:76:/323
EIN-ZEIT 11250110
:11:595
900515
-}
(kein CrLf)
(kein CrLf)
BEISPIEL 11B: (S.W.I.F.T. II): Format für eine Xetra® - Order (Bezug: Beispiel 7B)
Rückmeldung (Negativ):
{2:O5961125980515DWZXDEFFABOS00000000089805151125N}
{4:
:20:0000000000001
:21:ABCDEFGH2
:76:/323
EIN-ZEIT 11250110
:11:595
980515
-}
(kein CrLf)
(kein CrLf)
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
3.7
3.7.1
Login
05.10.1998
Seite 109
{4:
:20:9005150000001
:12:000
:77E:USER567890/PASSWORTS///
-}
3.7.2
(kein CrLf)
(kein CrLf)
Bestätigung Login
{2:O5981006900830DWZXDEFFABOS00000000099005151006N}
{4:
:20:9005150000001
:12:001
:77E:USER567890/PASSWORTS///001/
-}
(kein CrLf)
(kein CrLf)
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
3.7.3
Rückmeldung fehlerhafter Nachrichten durch Kreditinstitut
(kein CrLf)
(kein CrLf)
{4:
:20:9005150000001
:12:021
77E:1:F01DRESDEFFAXXX0000000009
← Beginn Ursprungsnachricht
2:O5981006900830DWZXDEFFABOS00000000099005151006N
4:
:20:9005150000001
:12:001
:77E:USER567890/PASSWORTS///001/
← Ende Ursprungsnachricht
:421:021
-}
05.10.1998
Seite 110
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
3.7.4
05.10.1998
Seite 111
Anforderung historischer Nachrichten, Anfangs-OSN
{4:
:20:9005150000002
:12:020
:77E:153:000017
-}
(kein CrLf)
(kein CrLf)
Kreditinstitute
Nachrichtenformate
1swift.doc
Nachrichtenformate
3.7.5
05.10.1998
Seite 112
Antwort auf Anforderung
{2:O5981006900830DWZXDEFFABOS0000000010900515006N}
{4:
:20:9005150000002
:12:021
2:I598DWZXDEFFABOSN2005
4:
:20:9005150000002
:12:020
:77E:153:000017
:421:ANF
-}
(kein CrLf)
(kein CrLf)
:
: (historische Nachrichten; diese Nachrichten werden mit ursprünglicher OSN gesendet)
:
{2:O5981006900830DWZXDEFFABOS0000000011900515006N}
{4:
:20:9005150000002
:12:021
2:I598DWZXDEFFABOSN2005
4:
:20:9005150000002
:12:020
:77E:153:000017
:421:END
-}
(kein CrLf)
(kein CrLf)

1 Zusammenstellung relevanter SWIFT

Transcription

Similar documents

Bedienungsanleitung VR-ProfiBroker - GLS-Bank

Financial Institutes

preis - HypoVereinsbank

SWIFT-Befüllungsregeln für HOAM.AT-Kontoinhaber (PDF

internationales mitarbeiteraktienprogramm

Online-Banking - Deutsche Bank

Unterschied Visti-ID Transit ID v1.1

Settlement Services Fachlicher Leitfaden

2015 consumer tire catalog - Multi

highway all-season suv/lt - Multi

Handbuch UnionFondsOnline

Affiliate Marketing eBook

Glossar - Daytradeaustria.com

eurex rundschreiben 276/13

Xetra BEST-Marktmodell