Wie das FIX-Protokoll funktioniert Montag, der 7. März 2022 – Posted in: Forex trading

Einführung

Die Geschichte des Börsenhandels hat sich seit seinen Anfängen dramatisch verändert. Die ersten Wertpapierbörsen entstanden vor etwa vierhundert Jahren. Damals wurden die Geschäfte mündlich abgeschlossen, die Handelsregeln steckten noch in den Kinderschuhen. Doch die Welt stand nicht still und die Börsen nutzten alle technischen Möglichkeiten, die damals zur Verfügung standen, um sich auf den neuesten Stand zu bringen.

So wurden Mitte des 19. Jahrhunderts Handelsanmeldungen in großer Entfernung von der Börse über Telegraphenleitungen übermittelt. Dann wurde diese Technik durch das Telefon ersetzt. Schließlich kam der Moment, als die ersten Handelsanfragen von Händlern über das Internet geliefert wurden.

Fairerweise muss man sagen, dass der Handel über das Telefon bei einigen Brokern auch heute noch beliebt ist. Bei einem bestimmten Teil davon ist es die einzige garantierte Möglichkeit, eine Transaktion zu machen. Auch von den Anfängen der ersten Börsen bis zum Beginn des 21. Jahrhunderts wurden die Geschäfte mündlich direkt bei den Börsen abgewickelt. Solche Handelsparkette wurden „Stock Pits“ genannt und stellten ein Spektakel dar, das uns aus Hollywood-Filmen zu ähnlichen Themen bekannt ist.

Geschichte zum FIX-Protokoll

Eines der ältesten digitalen Handelsprotokolle ist das FIX-Protokoll. Es steht für „Financial Information Protocol“ oder „Financial eXchange protocol“ und beide Definitionen sind geläufig. Die Spezifikation des FIX-Protokolls wurden 1992 erstellt, um Informationen über den Aktienhandel zwischen Fidelity Investments und Salomon Brothers bereitzustellen. Broker und Investmentfonds wollten die Abwicklung des Börsenhandels beschleunigen. Das Ergebnis ist ein offener Standard für die elektronische Übermittlung von Informationen, den keine große Organisation kontrolliert. Heute ist FIX zum Industriestandard geworden und wird von Finanzmärkten in verschiedenen Ländern zur Verbindung ihrer Produkte verwendet.

Ursprünglich wurde dieses Kommunikationsprotokoll nur zwischen den beiden oben genannten Börsen genutzt, hieß SBX (Salomon Brothers Exchange) und wurde nur für den Aktienhandel genutzt. Später 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.

Ursprünglich unterstützte 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ückzuführen. Schließlich hat der menschliche Faktor einen sehr großen Einfluss auf den Handel per Telefon. Im Laufe der Zeit wurde das Protokoll erheblich erweitert. Unterstützung für den Handel mit Derivaten, Anleihen und Währungen wurden hinzugefügt. 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. übertragen. Das Konsortium wurde später in FIX Trading Community umbenannt. Mehr als 270 führende Finanzinstitute sind inzwischen Mitglieder der Organisation.

Wie das FIX-Protokoll funktioniert

Das FIX-Protokoll läuft über TCP. Derzeit ist das FIX-Protokoll auf zwei Ebenen definiert: Auf der Sitzungs- oder Steuerungsebene (Sitzungsaufbau, Datenübermittlung) und auf der Anwendungsebene (Beschreibung des Dateninhalts). Die Steuerungsebene ist für die grundlegenden Parameter der FIX-Sitzung zuständig: Öffnen und Schließen der Verbindung, Wiederherstellung verlorener Nachrichten. Die Anwendungsebene steuert das Senden und Empfangen von Daten: Anfragen, Ausführungen, Ablehnungen, Marktdaten und Anfragen nach Statusinformationen. Das Protokoll selbst ist ein Textprotokoll und das heißt, es verwendet Zeichen aus der ASCII-Tabelle. Es gibt zwei Darstellungsformen: Die traditionelle Form Tag=Wert (Tag=Wert oder Schlüssel=Wert) und die XML-Darstellung (FIXML). Die neueste Version ist derzeit 5.0, am häufigsten werden jedoch die Versionen 4.2 und 4.4 verwendet. Verschiedene Broker und Börsen können verschiedene Versionen des Protokolls verwenden, manchmal auch mehrere gleichzeitig.

Syntax Tag=Wert

Die Meldung ist ähnlich wie die folgende:

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 |

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üssel-Wert-Paar, das durch ein Gleichheitszeichen getrennt ist. Rechts vom Zeichen steht der Schlüssel, links der Wert. In der FIX-Spezifikation werden die Schlüssel als Tags bezeichnet. Ein Tag ist immer eine positive ganze Zahl, die im Wesentlichen ein Zeiger auf einen Feldnamen ist. Alle Feldnamen und ihre möglichen Werte sind in der Dokumentation für eine bestimmte Börse beschrieben. Die meisten dieser Felder sind Standardfelder und können in der Liste jeder Börse gefunden werden. Es gibt auch benutzerdefinierte Felder, die nur innerhalb einer bestimmten Börse definiert werden und eine Bedeutung haben. Wenn die Beschreibung der Standardfelder in der allgemeinen FIX-Protokollspezifikation zu finden ist, müssen die benutzerdefinierten Felder in der FIX-Protokollspezifikation für die Börse beschrieben werden. Es gibt auch erforderliche, optionale und bedingt erforderliche Felder (erforderlich in Abhängigkeit 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“.

Während die Nachricht in Felder unterteilt ist, definieren diese wiederum 3 weitere Komponenten:

– Header (Nachrichtenkopf)

– Body (Nachrichtentext)

– Nachricht Trainer (Prüfsumme)

In FIX1.1/FIX5.0 enthält 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öglichen 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ür einen Optionsschein oder Informationen über den aktuellen Status und die anschließende Ausführung der Option.

Wir werden diese Nachricht analysieren:

8=FIX.4.2 – BeginString. Das ist die verwendete Protokollversion. Weist das Händlerprogramm an, welche Regeln es anwenden soll, um die Felder dieser Nachricht zu analysieren.
9=178 – BodyLength. Die Länge des Nachrichtentextes beträgt 178 Bytes, einschließlich Header. Berechnet als die Anzahl der Zeichen von Tag 35 (einschließlich) bis Tag 10 (ausschließlich). Der SoH-Splitter wird ebenfalls berücksichtigt.
35=D – MsgType. Art der Nachricht. In diesem Fall bedeutet D, dass eine Handelsanfrage gestellt wird. Ein Feld mit 35=V bedeutet zum Beispiel, dass Marktdaten über das Instrument eingeholt werden.
34=1234567 – MsgSeqNum. Nachrichtennummer. Wenn MsgSeqNum Nachrichten in der gesendeten Reihenfolge nicht um 1 abweichen, gibt der Server einen Fehler zurück und verarbeitet die Nachricht nicht.
49=TESTER – SenderCompID. Absender-ID. Ausgestellt von der Börse. Dabei kann es sich um einen Benutzernamen oder den Namen eines Brokers handeln, wenn die Nachricht von einem Broker gesendet wird.
56=PHLX – TargetCompID. Empfänger-ID zum Senden. Ebenfalls von der Börse ausgestellt.
52=20071123-05:30:00.000 – SendingTime. Datum und Uhrzeit, zu der die Nachricht gesendet wurde.
11=ATOMNOCCC9990900 – ClOrdID. Anfragenummer im Handelssystem des Brokers.
54=1 – Side. Aktion zum Erwerb von Vermögenswerten
167=FUT – SecurityType. Der Vermögenswert ist ein Future
55=MSFT – Symbol. Microsoft-Aktionen. Die Ticker können von Börse zu Börse variieren.
38=15 – OrderQty. Das Handelsvolumen beträgt 15 Lots oder Kontrakte.
40=2 – OrdType. Kauf zu einem begrenzten Preis, Limited Order.
44=15 – Price. Einkaufspreis – 15
59=0 – TimeInForce. Die Frist für die Anfrage endet am Ende des Werktages.
10=128 – CheckSum. Prüfsumme der Nachricht. Immer das letzte Feld in der Nachricht. Sie wird nach einer speziellen Formel berechnet und in der Protokollspezifikation beschrieben. Sie wird durch Summierung der ASCII-Werte aller Zeichen in der Nachricht mit Ausnahme der Zeichen des Prüfsummenfelds berechnet. Der Wert wird dann durch 256 geteilt und der Rest des Felds genommen. Die Prüfsumme muss immer drei Zeichen lang sein. Wenn also der Modulus 22 ist, wird der Zahl eine Null – „022“ – vorangestellt.

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ültigkeit zum Ende des Werktages.

Um FIX flexibler zu gestalten, enthält das Protokoll sogenannte benutzerdefinierte Felder – User Defined Fields. Sie werden für den Datentransfer zwischen kooperierenden Finanzorganisationen verwendet. Die Tag-Nummern von 5000 bis 9999 waren für benutzerdefinierte Felder reserviert, die auf der offiziellen Website des Standards reserviert werden konnten. Diese Zahlen wurden später verwendet, so dass ein neues Intervall von 20.000 bis 39.999 vergeben wurde.

FIXML-Syntax

Die Arbeit an der Syntax begann 1998 und die erste Version wurde 1999 veröffentlicht. Es ist semantisch dasselbe, wie Nachrichten, die mit Tags kodiert sind, nutzt aber die XML-Parsing-Technologie. Die neue Anwendung für den Vorgang im Format FIXML lautet wie folgt:

<FIXML>

<Order ClOrdID=“123456″ Side=“2″ TransactTm=“2001-09-11T09:30:47-05:00″ OrderTyp=“2″ Px=“93.25″

Acct=“26522154″>

</Order>

</FIXML>

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ßt ihn mit demselben Tag ab, aber am linken Rand ist noch ein Schrägstrich. Der genannte Tag schließt den Block also wie folgt ab: </FIXML>.

Innerhalb dieses Tags wird noch der folgende Tag angezeigt:

<Order ClOrdID=“123456″ Side=“2″ TransactTm=“2001-09-11T09:30:47-05:00″ OrderTyp=“2″ Px=“93.25″

Acct=“26522154″>.

Hier sehen wir den Tag-Namen – Order, und innerhalb der geschweiften Klammern gibt es zusätzliche Informationen (die gleichen Felder, Schlüssel=Wert Paar wie die Syntax Tag=Value).

In diesem Fall:

ClOrdID=“123456″ – Auftragsnummer im Handelssystem des Brokers

Side=“2″ – Verkaufsauftrag

TransactTm=“2001-09-11T09:30:47-05:00″ Datum und Uhrzeit der Transaktion

OrdTyp=“2″ – Art der Anfrage – Limit Order

Px=“93.25″ – Der Preis eines Vermögenswerts zum Kauf oder Verkauf

Acct=“26522154″ – Nummer des Benutzerkontos

Wie das vorherige XML-Tag wird auch dieses XML-Tag mit einem Schrägstrich geschlossen – </Order>

Der Inhalt zwischen dem öffnenden und dem schließenden 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.

Nächster Tag:

Hier können wir sehen, dass sie sich gleichzeitig öffnet und schließt, am Ende gibt es einen Schrägstrich. Das ist der Fall, wenn der Tag keinen Inhalt hat und es keinen Sinn macht, einen separaten Framing-Tag zu erstellen. Dieser Tag enthält Informationen über den Ticker des Tools, seine Kennung usw.

Im Tag <OrdQty Qty=“1000″/> können wir Informationen über das Volumen der Transaktion sehen, es ist auch der abschließende Tag ohne Body.

FIXML wird in der Regel für Back-Office- und Clearing-Anwendungen genutzt, nicht für den Handel.

FIX Session-Ebene

Die bisherigen Beispiele haben die Anwendungsschicht beschrieben. Die Spezifikation definiert spezielle Feldtypen, die für die Session-Ebene zwischen dem Client und der Vermittlungsstelle zuständig sind:

35=A – Logon. Dient der Authentifizierung des Benutzers gegenüber dem Vermittlungssystem bei einer Verbindung. Diese Nachricht wird zuerst gesendet und signalisiert den Beginn der Datensitzung. Bei erfolgreicher Übermittlung erhalten Sie eine Antwort. Wenn die Verbindung fehlschlägt, wird ein Fehler zurückgegeben.
35=5 – Logout. Diese Nachricht wird verwendet, um die Autorisierung beim Server aufzuheben und die Handelssitzung mit der Börse zu schließen.
35=0 – Heartbeat. Herzfrequenz oder Puls. Diese Nachricht wird von beiden Seiten der Verbindung an die jeweils andere gesendet und zeigt an, dass beide Seiten bereit sind, Nachrichten zu empfangen und zu senden. Die Heartbeat-Frequenz wird in der ersten Logon-Nachricht festgelegt.
35=1 – Test Request. Diese Nachricht ist eine Testnachricht und wird gesendet, wenn die Gegenpartei innerhalb eines bestimmten Zeitraums keine Heartbeat-Nachricht gesendet hat. Die Sitzung wird beendet, wenn diese Nachricht unbeantwortet bleibt.
35=2 – Resend Request. Diese Nachricht ist eine Aufforderung, die Nachricht erneut zu senden, falls Informationen fehlen.
35=3 – Reject, or reject. Wird von der Gegenpartei gesendet, wenn die vorherige Nachricht fehlerhaft ist oder nicht ausgeführt werden kann.

– 35=4 – Sequenz-Reset oder Zurücksetzen der Sendesequenz der Nachricht. Diese Nachricht kann zwei Formen haben.

– 123=“Y“ – Es gibt einen Tag GapFillFlag mit dem angegebenen Wert. Gibt an, dass administrative Nachrichten ignoriert werden sollen, wenn sie erneut gesendet werden.

– wird verwendet, um den Zähler MsgSeqNum auf Null zu setzen

Implementierung von FAST als Erweiterung der FIX-API

Bei der Verarbeitung großer Mengen von FIX-Daten kam es zu erheblichen Verzögerungen, die es den Händlern unmöglich 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 Übermittlung großer Datenmengen zu ermöglichen, ohne dass es zu Verzögerungen beim Empfangen der Informationen kommt. FAST (FIX Adapted for STreaming, übersetzt: FIX, angepasst für Streaming) ist ein von der FIX Protocol Ltd. entwickelter Technologiestandard, der speziell für die Optimierung der Netzwerkdarstellung entwickelt wurde. Es ist im Wesentlichen ein Binärformat des FIX-Protokolls und ermöglicht die Übertragung großer Mengen an Informationen über Transaktionen und das Marktumfeld in kompakter Form. Das ermöglicht den Einsatz in Handelssystemen mit Hochgeschwindigkeit, die geringe Übertragungsverzögerungen erfordern. Fast wurde am California Institute of Technology in Pasadena entwickelt. Derzeit ist die neueste Version von FAST die 1.2. Die häufigste Anwendung ist der direkte Anschluss an die Börsen mit einer Umgehung des Handelssystems der Broker. Das FAST-Protokoll ist das standardisierte Protokoll für die Verteilung von Marktinformationen und auch das beliebteste der Welt. Früher 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ätigung der Paketübermittlung erfordert. Es unterteilt große Dateien und Nachrichten in Pakete mit 1500 Byte, die jeweils die Quell- und Zieladresse des Pakets enthalten. Der Absender wartet auf die Bestätigung, dass das gesendete Paket erfolgreich zugestellt wurde und sendet erst dann das nächste Paket. Wenn die Zustellung fehlschlägt 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ügige Leitungsprobleme die Datenrate stark beeinträchtigen können, da jede fehlgeschlagene Übertragung einen Verlust von wertvollen Millisekunden bedeutet. Deshalb hat FAST hier Abhilfe geschaffen: Das System überwacht ständig die Pakete und empfangenen Nachrichten auf erfolgreiche Zustellung, um Probleme der Leitung sofort zu erkennen und den nächsten Sendevorgang auf eine stabile, wenn auch leicht reduzierte Rate einzustellen. Mit diesem Ansatz entfällt in den meisten Fällen die Notwendigkeit, Pakete erneut zu senden, da man keine Zeit braucht, um eine langsame Leistung zu ermitteln. Bei einigen Börsen wird die Verbindungsschnittstelle durch zwei Arten von Verbindungen realisiert: UDP und TCP. Es macht keinen Sinn, alle Daten über den UDP-Socket zu senden, da eine solche Verbindung keine Bestätigung der Zustellung erfordert und die Pakete einfach verschwinden, ohne dass eine der beiden Parteien davon erfährt. Daher wird der größte Teil der Daten über den UDP-Socket übertragen und nur die nicht zugestellten Datensätze werden über TCP übertragen. Auf schnellen Märkten ist eine mit der Neuübertragung verbundene Verzögerung oft unerwünscht und führt zu verpassten Chancen oder schlechten Geschäften.

So funktioniert FAST

Wie wir bereits wissen, besteht das FIX-Protokoll aus einer Folge von Feldern, die wiederum aus Paaren mit Schlüssel=Wert bestehen. Abgesehen von der Tatsache, dass das Zeichenfolgenformat im Prinzip redundant ist, werden Sie merken, dass jede Nachricht doppelte Elemente enthält, 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 übertragenen Daten nur „impliziert“ sind, ändert sich die Syntax von Tag = Wert wie folgt:

– Eine Vorlage beschreibt eine strukturierte Menge von Feldern mit ihren Operatoren;

– Die Feldreihenfolge in der Nachricht stimmt mit der Tag-Reihenfolge in der Vorlage überein;

– In der Nachricht werden nur Datenänderungen gesendet.

Jeder Tag-Wert hat eine feste Länge in Bytes. Wenn man die Länge 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önnen daher nur die eigentlichen Daten direkt übertragen werden, ohne dass redundante Zeichen übertragen werden müssen. Diese Kodierung wird als einfache Binärkodierung (SBE) bezeichnet. So haben Nachrichtenkodierung und -dekodierung eine viel geringere Latenzzeit als Zeichenprotokolle, weil es nicht notwendig ist, Daten in ein Format zu übersetzen, das die Computer nutzen können. Da sich die entsprechenden Felder an einer festen Position in der Nachricht befinden, ist es viel einfacher, auf den gewünschten Wert zuzugreifen. Man muss nur den Offset relativ zum Anfang der Nachricht und die Länge des Wertes kennen. Anders als das Tag und FIXML ist eine SBE-Nachricht nicht selbstbeschreibend. Nur Daten mit einer minimalen Kopfzeile werden über das Netz gesendet, um die Vorlage zu identifizieren, welche die Nachricht steuert. Metadaten (Vorlagen), die die Nachrichtenstruktur beschreiben, werden außerhalb des Hauptkommunikationskanals ausgetauscht. Nach Empfang der nötigen Vorlagen weiß der Handelsserver, in welchem Format er die Daten im Rahmen dieser verbundenen Sitzung an den Kunden senden muss. Vor der Datenübertragung müssen die Systeme also irgendwie miteinander vereinbaren, wie sie in Zukunft miteinander kommunizieren. Das Nachrichtenschema wird in der Regel im XML-Format übermittelt. Es kann eine beliebige Anzahl von Nachrichtenvorlagen enthalten. Die Vorlage beschreibt die Felder, aus denen die Nachricht besteht. Darüber hinaus bietet das Schema eine Liste einfacher und komplexer Datentypen, die in einer beliebigen Anzahl von Feldern wiederverwendet werden können.

Offene Implementierungen für verschiedene Sprachen für das FIX-Protokoll

Java – QuickFIX/J – http://www.quickfixj.org/

.NET/C# – QuickFIX/N – http://quickfixn.org/

Kostenloser Online-Parser für FIX-Nachrichten – FIX Parser – https://fix.aprics.net/

Offene Sprachimplementierungen für FAST

Für C – Referenzimplementierung von FPL – www.fixprotocol.org/fastdownload

Für C# – Referenzimplementierung von FPL – www.fixprotocol.org/fastdownload

Java л д code – OpenFAST – www.openfast.org

www.sourceforge.net/projects/openfastdotnet/ Д я

Для C++ – QuickFAST – www.quickfast.org

Для Golang – goFAST – www.github.com/co11ter/goFAST

Andere Kodierungen des FIX-Protokolls

Die FIX-Gemeinschaft hat auch Standard-Mappings zwischen dem FIX-Protokoll und anderen Daten-Serialisierungsprotokollen wie z. B.:

JSON

– Google (Protokollpuffer)

|ASN.1

Anwendungsbereiche des FIX/FAST-Protokolls

In der Regel wird eine Abkürzung aus genau zwei Wörtern gebildet. Das ermöglicht, verschiedene Finanzinformationen von den Börsen zu erhalten: Tabellen der Finanzinstrumente (Preise, Volumen usw.), Notierungen, alle Transaktionen, Indizes sowie Informationen über alle nicht persönlichen Anwendungen. Die erhaltenen Daten können je nach Börse unterschiedlich sein. Das primäre FIX/FAST ist:

– Private Trader für den Handel

– Programmierer, die Produkte auf der Grundlage dieser Technologie entwickeln. Wie zum Beispiel – FIX API Handelsplattformen, Verbindungen zu verschiedenen Börsen, Handelssystemen, Datenerfassungssystemen und Statistiken.

– Austausch von Informationen zwischen den Börsen

– Beschaffung der aktuellsten Daten für verschiedene Informationsstellen

Am häufigsten werden sie von Hochfrequenzhändlern genutzt, um sich über den direkten Marktzugang (DMA) einen Vorteil gegenüber anderen Marktteilnehmern zu verschaffen. Dieses Protokoll kann von Börsen, Banken und Devisenbrokern in das Handelssystem integriert werden. Kryptowährungsbörsen verwenden nach allgemein bekannten Daten nicht diese Technologie. In der Vergangenheit haben diese Börsen meist WebSocket-Verbindungen zum Abrufen von Marktinformationen und Verbindungen per HTTP-Rest-API zur Durchführung von Handelsgeschäften genutzt, um direkte Verbindungen zu den Handelsservern der Händler herzustellen. Wenn die WebSocket-Technologie in der Geschwindigkeit noch mit einer TCP-Verbindung vergleichbar ist, dann hinkt die HTTP-Rest-API stark hinterher.