<\/p>\n
\u00a0<\/strong>Die Geschichte des B\u00f6rsenhandels hat sich seit seinen Anf\u00e4ngen dramatisch ver\u00e4ndert. Die ersten Wertpapierb\u00f6rsen entstanden vor etwa vierhundert Jahren. Damals wurden die Gesch\u00e4fte m\u00fcndlich abgeschlossen, die Handelsregeln steckten noch in den Kinderschuhen. Doch die Welt stand nicht still und die B\u00f6rsen nutzten alle technischen M\u00f6glichkeiten, die damals zur Verf\u00fcgung standen, um sich auf den neuesten Stand zu bringen.<\/p>\n So wurden Mitte des 19. Jahrhunderts Handelsanmeldungen in gro\u00dfer Entfernung von der B\u00f6rse \u00fcber Telegraphenleitungen \u00fcbermittelt. Dann wurde diese Technik durch das Telefon ersetzt. Schlie\u00dflich kam der Moment, als die ersten Handelsanfragen von H\u00e4ndlern \u00fcber das Internet geliefert wurden.<\/p>\n Fairerweise muss man sagen, dass der Handel \u00fcber das Telefon bei einigen Brokern auch heute noch beliebt ist. Bei einem bestimmten Teil davon ist es die einzige garantierte M\u00f6glichkeit, eine Transaktion zu machen. Auch von den Anf\u00e4ngen der ersten B\u00f6rsen bis zum Beginn des 21. Jahrhunderts wurden die Gesch\u00e4fte m\u00fcndlich direkt bei den B\u00f6rsen abgewickelt. Solche Handelsparkette wurden „Stock Pits“ genannt und stellten ein Spektakel dar, das uns aus Hollywood-Filmen zu \u00e4hnlichen Themen bekannt ist.<\/p>\n \u00a0<\/strong>Eines der \u00e4ltesten digitalen Handelsprotokolle ist das FIX-Protokoll. Es steht f\u00fcr „Financial Information Protocol“ oder „Financial eXchange protocol“ und beide Definitionen sind gel\u00e4ufig. Die Spezifikation des FIX-Protokolls wurden 1992 erstellt, um Informationen \u00fcber den Aktienhandel zwischen Fidelity Investments und Salomon Brothers bereitzustellen. Broker und Investmentfonds wollten die Abwicklung des B\u00f6rsenhandels beschleunigen. Das Ergebnis ist ein offener Standard f\u00fcr die elektronische \u00dcbermittlung von Informationen, den keine gro\u00dfe Organisation kontrolliert. Heute ist FIX zum Industriestandard geworden und wird von Finanzm\u00e4rkten in verschiedenen L\u00e4ndern zur Verbindung ihrer Produkte verwendet.<\/p>\n Urspr\u00fcnglich wurde dieses Kommunikationsprotokoll nur zwischen den beiden oben genannten B\u00f6rsen genutzt, hie\u00df SBX (Salomon Brothers Exchange) und wurde nur f\u00fcr den Aktienhandel genutzt. Sp\u00e4ter in der Geschichte erkannten die Leiter dieser Unternehmen die Bedeutung ihrer Erfindung und boten an, sich an der Entwicklung von Goldman Sachs und Putman zu beteiligen. Das Protokoll hat inzwischen seinen heutigen Namen erhalten.<\/p>\n Urspr\u00fcnglich unterst\u00fctzte das Protokoll nur 17 Nachrichtentypen und 103 Tags. Die Idee war so erfolgreich, dass bis 1995 mehr als 70% aller US-Maklerunternehmen das Protokoll nutzten. Das war auf Kosteneinsparungen, geringere Kosten und weniger Handelsfehler zur\u00fcckzuf\u00fchren. Schlie\u00dflich hat der menschliche Faktor einen sehr gro\u00dfen Einfluss auf den Handel per Telefon. Im Laufe der Zeit wurde das Protokoll erheblich erweitert. Unterst\u00fctzung f\u00fcr den Handel mit Derivaten, Anleihen und W\u00e4hrungen wurden hinzugef\u00fcgt. Die aktuelle FIX-Spezifikation beschreibt 168 Nachrichten und 7.868 Tags und deckt alle Wertpapierkategorien ab. 1998 wurde die Entwicklung des FIX-Protokolls und der Spezifikationen, sowie die Entwicklung damit verbundener Technologien dem Konsortium FIX Protocol Ltd. \u00fcbertragen. Das Konsortium wurde sp\u00e4ter in FIX Trading Community umbenannt. Mehr als 270 f\u00fchrende Finanzinstitute sind inzwischen Mitglieder der Organisation.<\/p>\n \u00a0<\/strong>Das FIX-Protokoll l\u00e4uft \u00fcber TCP. Derzeit ist das FIX-Protokoll auf zwei Ebenen definiert: Auf der Sitzungs- oder Steuerungsebene (Sitzungsaufbau, Daten\u00fcbermittlung) und auf der Anwendungsebene (Beschreibung des Dateninhalts). Die Steuerungsebene ist f\u00fcr die grundlegenden Parameter der FIX-Sitzung zust\u00e4ndig: \u00d6ffnen und Schlie\u00dfen der Verbindung, Wiederherstellung verlorener Nachrichten. Die Anwendungsebene steuert das Senden und Empfangen von Daten: Anfragen, Ausf\u00fchrungen, Ablehnungen, Marktdaten und Anfragen nach Statusinformationen. Das Protokoll selbst ist ein Textprotokoll und das hei\u00dft, es verwendet Zeichen aus der ASCII-Tabelle. Es gibt zwei Darstellungsformen: Die traditionelle Form Tag=Wert (Tag=Wert oder Schl\u00fcssel=Wert) und die XML-Darstellung (FIXML). Die neueste Version ist derzeit 5.0, am h\u00e4ufigsten werden jedoch die Versionen 4.2 und 4.4 verwendet. Verschiedene Broker und B\u00f6rsen k\u00f6nnen verschiedene Versionen des Protokolls verwenden, manchmal auch mehrere gleichzeitig.<\/p>\n Syntax Tag=Wert<\/p>\n Die Meldung ist \u00e4hnlich wie die folgende:<\/p>\n 8=FIX.4.2 | 9=178 | 35=D | 34=1234567 | 49=TESTER | 56=PHLX | 52=20071123-05:30:00,000 | 11=ATOMNOCCC9990900 | 54=1 | 167=FUT | 55=MSFT | 38=15 | 40=2 | 44=15 | 59=0 | 10=128 |<\/p>\n Das ist eine Textfolge, die aus mehreren Teilen besteht, welche durch einen vertikalen Balken getrennt sind. Diese Teile werden als Felder bezeichnet. Jeder der Teile besteht wiederum aus einem Schl\u00fcssel-Wert-Paar, das durch ein Gleichheitszeichen getrennt ist. Rechts vom Zeichen steht der Schl\u00fcssel, links der Wert. In der FIX-Spezifikation werden die Schl\u00fcssel als Tags bezeichnet.\u00a0 Ein Tag ist immer eine positive ganze Zahl, die im Wesentlichen ein Zeiger auf einen Feldnamen ist. Alle Feldnamen und ihre m\u00f6glichen Werte sind in der Dokumentation f\u00fcr eine bestimmte B\u00f6rse beschrieben. Die meisten dieser Felder sind Standardfelder und k\u00f6nnen in der Liste jeder B\u00f6rse gefunden werden. Es gibt auch benutzerdefinierte Felder, die nur innerhalb einer bestimmten B\u00f6rse definiert werden und eine Bedeutung haben. Wenn die Beschreibung der Standardfelder in der allgemeinen FIX-Protokollspezifikation zu finden ist, m\u00fcssen die benutzerdefinierten Felder in der FIX-Protokollspezifikation f\u00fcr die B\u00f6rse beschrieben werden. Es gibt auch erforderliche, optionale und bedingt erforderliche Felder (erforderlich in Abh\u00e4ngigkeit vom Vorhandensein einiger anderer Felder in der Nachricht). Das Symbol SoH (Start of Header) wird als Trennzeichen zwischen den Feldern verwendet. Es ist eigentlich nicht sichtbar, daher wird es in diesem Beispiel durch einen vertikalen Balken ersetzt. In der UNICODE-Kodierung hat dieses Zeichen den Code „\\u0001“.<\/p>\n W\u00e4hrend die Nachricht in Felder unterteilt ist, definieren diese wiederum 3 weitere Komponenten:<\/p>\n – Header (Nachrichtenkopf)<\/p>\n – Body (Nachrichtentext)<\/p>\n – Nachricht Trainer (Pr\u00fcfsumme)<\/p>\n In FIX1.1\/FIX5.0 enth\u00e4lt der Header 5 Pflichtfelder und ein optionales Feld: 8 (BeginString), 9 (BodyLength), 35 (MsgType), 49 (SenderCompID), 56 (DestComppID) und 1128 (ApplVerID – falls vorhanden, muss es an 6.Position sein) Es gibt zwei Hauptgruppen von Nachrichten – Administrativ und Anwendung. Admin-Nachrichten behandeln die Grundlagen einer FIX-Sitzung. Sie erm\u00f6glichen es Ihnen, eine Sitzung zu starten und zu beenden, sowie verpasste Nachrichten wiederherzustellen. Die Anwendungsnachrichten beziehen sich auf das Senden und Empfangen von handelsbezogenen Informationen, wie z. B. die Anfrage f\u00fcr einen Optionsschein oder Informationen \u00fcber den aktuellen Status und die anschlie\u00dfende Ausf\u00fchrung der Option.<\/p>\n Wir werden diese Nachricht analysieren:<\/p>\n Wenn Sie diese Nachricht allgemein beschreiben, handelt es sich um eine Aktion zum Kauf von Microsoft-Aktienfutures in der Anzahl von 15 Kontrakten zum limitierten Preis von 15, mit G\u00fcltigkeit zum Ende des Werktages.<\/p>\n Um FIX flexibler zu gestalten, enth\u00e4lt das Protokoll sogenannte benutzerdefinierte Felder – User Defined Fields. Sie werden f\u00fcr den Datentransfer zwischen kooperierenden Finanzorganisationen verwendet. Die Tag-Nummern von 5000 bis 9999 waren f\u00fcr benutzerdefinierte Felder reserviert, die auf der offiziellen Website des Standards reserviert werden konnten. Diese Zahlen wurden sp\u00e4ter verwendet, so dass ein neues Intervall von 20.000 bis 39.999 vergeben wurde.<\/p>\n Die Arbeit an der Syntax begann 1998 und die erste Version wurde 1999 ver\u00f6ffentlicht. Es ist semantisch dasselbe, wie Nachrichten, die mit Tags kodiert sind, nutzt aber die XML-Parsing-Technologie. Die neue Anwendung f\u00fcr den Vorgang im Format FIXML lautet wie folgt:<\/p>\n <FIXML><\/p>\n <Order ClOrdID=“123456″ Side=“2″ TransactTm=“2001-09-11T09:30:47-05:00″ OrderTyp=“2″ Px=“93.25″<\/p>\n Acct=“26522154″><\/p>\n <Instrmt Sym=“IBM“ ID=“459200101″ IDSrc=“1″\/><\/p>\n <OrdQty Qty Qty=“1000″\/><\/p>\n <\/Order><\/p>\n <\/FIXML><\/p>\n Im XML-Format wird ein bestimmter Codeblock in ein so genanntes Tag (ein anderes Tag, nicht das vom Protokoll selbst verwendete) eingebettet. Zum Beispiel gibt es ein <FIXML> Tag ganz oben. Jeder Tag unterbricht einen bestimmten Teil des Codes oder der Nachricht und schlie\u00dft ihn mit demselben Tag ab, aber am linken Rand ist noch ein Schr\u00e4gstrich. Der genannte Tag schlie\u00dft den Block also wie folgt ab: <\/FIXML>.<\/p>\n Innerhalb dieses Tags wird noch der folgende Tag angezeigt:<\/p>\n <Order ClOrdID=“123456″ Side=“2″ TransactTm=“2001-09-11T09:30:47-05:00″ OrderTyp=“2″ Px=“93.25″<\/p>\n Acct=“26522154″>.<\/p>\n Hier sehen wir den Tag-Namen – Order, und innerhalb der geschweiften Klammern gibt es zus\u00e4tzliche Informationen (die gleichen Felder, Schl\u00fcssel=Wert Paar wie die Syntax Tag=Value).<\/p>\n In diesem Fall:<\/p>\n ClOrdID=“123456″ – Auftragsnummer im Handelssystem des Brokers<\/p>\n Side=“2″ – Verkaufsauftrag<\/p>\n TransactTm=“2001-09-11T09:30:47-05:00″ Datum und Uhrzeit der Transaktion<\/p>\n OrdTyp=“2″ – Art der Anfrage – Limit Order<\/p>\n Px=“93.25″ – Der Preis eines Verm\u00f6genswerts zum Kauf oder Verkauf<\/p>\n Acct=“26522154″ – Nummer des Benutzerkontos<\/p>\n Wie das vorherige XML-Tag wird auch dieses XML-Tag mit einem Schr\u00e4gstrich geschlossen – <\/Order><\/p>\n Der Inhalt zwischen dem \u00f6ffnenden und dem schlie\u00dfenden XML-Tag wird als Tag-Body bezeichnet. Der Order-Tag ist also der Hauptteil des FIXML-Tags. Innerhalb des Order-Tags als Body gibt es zwei weitere Tags: Instrmt und OrdQty.<\/p>\n N\u00e4chster Tag:<\/p>\n <Instrmt Sym=“IBM“ ID=“459200101″ IDSrc=“1″\/><\/p>\n Hier k\u00f6nnen wir sehen, dass sie sich gleichzeitig \u00f6ffnet und schlie\u00dft, am Ende gibt es einen Schr\u00e4gstrich. Das ist der Fall, wenn der Tag keinen Inhalt hat und es keinen Sinn macht, einen separaten Framing-Tag zu erstellen. Dieser Tag enth\u00e4lt Informationen \u00fcber den Ticker des Tools, seine Kennung usw.<\/p>\n Im Tag <OrdQty Qty=“1000″\/> k\u00f6nnen wir Informationen \u00fcber das Volumen der Transaktion sehen, es ist auch der abschlie\u00dfende Tag ohne Body.<\/p>\n FIXML wird in der Regel f\u00fcr Back-Office- und Clearing-Anwendungen genutzt, nicht f\u00fcr den Handel.<\/p>\n \u00a0<\/strong>Die bisherigen Beispiele haben die Anwendungsschicht beschrieben. Die Spezifikation definiert spezielle Feldtypen, die f\u00fcr die Session-Ebene zwischen dem Client und der Vermittlungsstelle zust\u00e4ndig sind:<\/p>\n – 35=4 – Sequenz-Reset oder Zur\u00fccksetzen der Sendesequenz der Nachricht. Diese Nachricht kann zwei Formen haben.<\/p>\n – 123=“Y“ – Es gibt einen Tag GapFillFlag mit dem angegebenen Wert. Gibt an, dass administrative Nachrichten ignoriert werden sollen, wenn sie erneut gesendet werden.<\/p>\n – wird verwendet, um den Z\u00e4hler MsgSeqNum auf Null zu setzen<\/p>\n Bei der Verarbeitung gro\u00dfer Mengen von FIX-Daten kam es zu erheblichen Verz\u00f6gerungen, die es den H\u00e4ndlern unm\u00f6glich machten, effektive Handelsstrategien zu entwickeln. Schon bald nach dem Erkennen dieses Problems wurden die ersten Schritte zur Behebung unternommen. Ziel des FAST-Protokolls war es, die \u00dcbermittlung gro\u00dfer Datenmengen zu erm\u00f6glichen, ohne dass es zu Verz\u00f6gerungen beim Empfangen der Informationen kommt. FAST (FIX Adapted for STreaming, \u00fcbersetzt: FIX, angepasst f\u00fcr Streaming) ist ein von der FIX Protocol Ltd. entwickelter Technologiestandard, der speziell f\u00fcr die Optimierung der Netzwerkdarstellung entwickelt wurde. Es ist im Wesentlichen ein Bin\u00e4rformat des FIX-Protokolls und erm\u00f6glicht die \u00dcbertragung gro\u00dfer Mengen an Informationen \u00fcber Transaktionen und das Marktumfeld in kompakter Form. Das erm\u00f6glicht den Einsatz in Handelssystemen mit Hochgeschwindigkeit, die geringe \u00dcbertragungsverz\u00f6gerungen erfordern. Fast wurde am California Institute of Technology in Pasadena entwickelt. Derzeit ist die neueste Version von FAST die 1.2. Die h\u00e4ufigste Anwendung ist der direkte Anschluss an die B\u00f6rsen mit einer Umgehung des Handelssystems der Broker. Das FAST-Protokoll ist das standardisierte Protokoll f\u00fcr die Verteilung von Marktinformationen und auch das beliebteste der Welt. Fr\u00fcher basierte der gesamte Internetverkehr auf dem Transmission Control Protocol (TCP), das in den siebziger Jahren entwickelt wurde. TCP ist eine Socket-Verbindung, die eine Best\u00e4tigung der Paket\u00fcbermittlung erfordert. Es unterteilt gro\u00dfe Dateien und Nachrichten in Pakete mit 1500 Byte, die jeweils die Quell- und Zieladresse des Pakets enthalten.\u00a0 Der Absender wartet auf die Best\u00e4tigung, dass das gesendete Paket erfolgreich zugestellt wurde und sendet erst dann das n\u00e4chste Paket. Wenn die Zustellung fehlschl\u00e4gt oder das Zustellsignal nicht innerhalb der angegebenen Zeitspanne eintrifft, wird das Paket erneut gesendet, allerdings mit einer geringeren Geschwindigkeit. Das kann so lange weitergehen, wie Sie wollen, wobei die Geschwindigkeit exponentiell abnimmt, bis das Signal kommt, dass die Zustellung erfolgreich war. Es wird deutlich, dass selbst geringf\u00fcgige Leitungsprobleme die Datenrate stark beeintr\u00e4chtigen k\u00f6nnen, da jede fehlgeschlagene \u00dcbertragung einen Verlust von wertvollen Millisekunden bedeutet. Deshalb hat FAST hier Abhilfe geschaffen: Das System \u00fcberwacht st\u00e4ndig die Pakete und empfangenen Nachrichten auf erfolgreiche Zustellung, um Probleme der Leitung sofort zu erkennen und den n\u00e4chsten Sendevorgang auf eine stabile, wenn auch leicht reduzierte Rate einzustellen. Mit diesem Ansatz entf\u00e4llt in den meisten F\u00e4llen die Notwendigkeit, Pakete erneut zu senden, da man keine Zeit braucht, um eine langsame Leistung zu ermitteln. Bei einigen B\u00f6rsen wird die Verbindungsschnittstelle durch zwei Arten von Verbindungen realisiert: UDP und TCP. Es macht keinen Sinn, alle Daten \u00fcber den UDP-Socket zu senden, da eine solche Verbindung keine Best\u00e4tigung der Zustellung erfordert und die Pakete einfach verschwinden, ohne dass eine der beiden Parteien davon erf\u00e4hrt. Daher wird der gr\u00f6\u00dfte Teil der Daten \u00fcber den UDP-Socket \u00fcbertragen und nur die nicht zugestellten Datens\u00e4tze werden \u00fcber TCP \u00fcbertragen. Auf schnellen M\u00e4rkten ist eine mit der Neu\u00fcbertragung verbundene Verz\u00f6gerung oft unerw\u00fcnscht und f\u00fchrt zu verpassten Chancen oder schlechten Gesch\u00e4ften.<\/p>\n Wie wir bereits wissen, besteht das FIX-Protokoll aus einer Folge von Feldern, die wiederum aus Paaren mit Schl\u00fcssel=Wert bestehen. Abgesehen von der Tatsache, dass das Zeichenfolgenformat im Prinzip redundant ist, werden Sie merken, dass jede Nachricht doppelte Elemente enth\u00e4lt, z. B. Feldnamen und „=“. FAST vermeidet Redundanz durch Verwendung einer Vorlage, welche die gesamte Nachrichtenstruktur beschreibt. Diese Methode wird als implizites Tagging bezeichnet. Da die FIX-Tags in den \u00fcbertragenen Daten nur „impliziert“ sind, \u00e4ndert sich die Syntax von Tag = Wert wie folgt:<\/p>\n – Eine Vorlage beschreibt eine strukturierte Menge von Feldern mit ihren Operatoren;<\/p>\n – Die Feldreihenfolge in der Nachricht stimmt mit der Tag-Reihenfolge in der Vorlage \u00fcberein;<\/p>\n – In der Nachricht werden nur Daten\u00e4nderungen gesendet.<\/p>\n Jeder Tag-Wert hat eine feste L\u00e4nge in Bytes. Wenn man die L\u00e4nge eines bestimmten Feldes und die Reihenfolge der Felder in einer Nachricht kennt, ist es nicht schwierig, die Werte dieser Felder in einer Nachricht zu identifizieren. Mit Hilfe von Vorlagen k\u00f6nnen daher nur die eigentlichen Daten direkt \u00fcbertragen werden, ohne dass redundante Zeichen \u00fcbertragen werden m\u00fcssen. Diese Kodierung wird als einfache Bin\u00e4rkodierung (SBE) bezeichnet. So haben Nachrichtenkodierung und -dekodierung eine viel geringere Latenzzeit als Zeichenprotokolle, weil es nicht notwendig ist, Daten in ein Format zu \u00fcbersetzen, das die Computer nutzen k\u00f6nnen. Da sich die entsprechenden Felder an einer festen Position in der Nachricht befinden, ist es viel einfacher, auf den gew\u00fcnschten Wert zuzugreifen. Man muss nur den Offset relativ zum Anfang der Nachricht und die L\u00e4nge des Wertes kennen. Anders als das Tag und FIXML ist eine SBE-Nachricht nicht selbstbeschreibend. Nur Daten mit einer minimalen Kopfzeile werden \u00fcber das Netz gesendet, um die Vorlage zu identifizieren, welche die Nachricht steuert. Metadaten (Vorlagen), die die Nachrichtenstruktur beschreiben, werden au\u00dferhalb des Hauptkommunikationskanals ausgetauscht. Nach Empfang der n\u00f6tigen Vorlagen wei\u00df der Handelsserver, in welchem Format er die Daten im Rahmen dieser verbundenen Sitzung an den Kunden senden muss. Vor der Daten\u00fcbertragung m\u00fcssen die Systeme also irgendwie miteinander vereinbaren, wie sie in Zukunft miteinander kommunizieren. Das Nachrichtenschema wird in der Regel im XML-Format \u00fcbermittelt. Es kann eine beliebige Anzahl von Nachrichtenvorlagen enthalten. Die Vorlage beschreibt die Felder, aus denen die Nachricht besteht. Dar\u00fcber hinaus bietet das Schema eine Liste einfacher und komplexer Datentypen, die in einer beliebigen Anzahl von Feldern wiederverwendet werden k\u00f6nnen.<\/p>\n Offene Implementierungen f\u00fcr verschiedene Sprachen f\u00fcr das FIX-Protokoll<\/p>\n Java – QuickFIX\/J – http:\/\/www.quickfixj.org\/<\/p>\n .NET\/C# – QuickFIX\/N – http:\/\/quickfixn.org\/<\/p>\n Kostenloser Online-Parser f\u00fcr FIX-Nachrichten – FIX Parser – https:\/\/fix.aprics.net\/<\/p>\n Offene Sprachimplementierungen f\u00fcr FAST<\/p>\n F\u00fcr C – Referenzimplementierung von FPL – www.fixprotocol.org\/fastdownload<\/p>\n F\u00fcr C# – Referenzimplementierung von FPL – www.fixprotocol.org\/fastdownload<\/p>\n Java \u043b \u0434 code – OpenFAST – www.openfast.org<\/p>\n www.sourceforge.net\/projects\/openfastdotnet\/ \u0414 \u044f<\/p>\n \u0414\u043b\u044f C++ – QuickFAST – www.quickfast.org<\/p>\n \u0414\u043b\u044f Golang – goFAST – www.github.com\/co11ter\/goFAST<\/p>\n Andere Kodierungen des FIX-Protokolls<\/p>\n Die FIX-Gemeinschaft hat auch Standard-Mappings zwischen dem FIX-Protokoll und anderen Daten-Serialisierungsprotokollen wie z. B.:<\/p>\nGeschichte zum FIX-Protokoll<\/strong><\/h3>\n
Wie das FIX-Protokoll funktioniert<\/strong><\/h2>\n
\n
FIXML-Syntax<\/strong><\/h3>\n
FIX Session-Ebene<\/strong><\/h3>\n
\n
Implementierung von FAST als Erweiterung der FIX-API<\/strong><\/h3>\n
So funktioniert FAST<\/strong><\/h3>\n