-
Gebiet der Erfindung
-
Die vorliegende Erfindung bezieht sich allgemein auf Verbesserungen in automatischen Handelssystemen für Markthandelsaktivitäten und insbesondere, jedoch nicht ausschließlich, auf eine Kommunikationsschnittstelle für ein automatisches Handelssystem.
-
Hintergrund der Erfindung
-
Automatische Handelssysteme (Automated Trading Systems – ATSs) sind bereits bekannt, welche das Echtzeit-Matching von Käufern und Verkäufern in einem Markt erleichtern, wo ein oder mehrere börsennotierte Instrumente (z. B. Aktien, Wertpapiere usw.) gehandelt werden.
-
Bei den aktuellen ATSs kommt ein elektronisches Kommunikationsnetzwerk (Electronic Communication Network – ECN) zum Einsatz. Das ECN implementiert ein Central Limited Order Book (CLOB), welches eine Standard-Doppelauktion zwischen Verkäufern, die ein Finanzinstrument zu einem bestimmten Preis verkaufen wollen, und Käufern, die ein oder mehrere Finanzinstrumente zu einem bestimmten Preis kaufen wollen, umfasst.
-
Auf den wichtigsten Handelsmärkten, wie beispielsweise Nasdaq, ASX und anderen, sind leistungsstarke Computersysteme erforderlich, um die zahlreichen Handelsaktivitäten zu implementieren, die während der Handelszeit durchgeführt werden.
-
Dabei ist die Geschwindigkeit der Computersysteme von großer Bedeutung. Es gibt zwei wichtige Faktoren bei der Durchführung einer Handelsaktivität, das sind Preis-Priorität und Zeit-Priorität. Preis-Priorität bedeutet, dass beim Handel die Person die Priorität erhält, die zum besten Preis verkaufen will oder die zum besten Preis kaufen will. Zeit-Priorität bedeutet, dass in dem Fall, dass es zwei oder mehr Verkäufer bzw. zwei oder mehr Käufer mit demselben Preis gibt, der Handel mit dem ersten der Käufer oder Verkäufer durchgeführt wird, dessen Auftrag das CLOB zuerst erreicht und zuerst ausgeführt wird. Deshalb ist die Verarbeitungsgeschwindigkeit des ECN von entscheidender Bedeutung.
-
Kunden des ECN erteilen elektronisch Aufträge zum Kaufen oder Verkaufen einer bestimmten Menge eines börsennotierten Instruments, unter Angabe bestimmter Bedingungen wie z. B. eines maximalen/minimalen Preises. Diese Aufträge werden in einer Warteschlange platziert. Zunächst wird der Kunde darüber benachrichtigt, dass sein Auftrag bestätigt wurde.
-
Werden ein Käufer und ein Verkäufer gefunden, die miteinander gematcht werden können, weil deren Preisbedingungen übereinstimmen, erfolgt eine Handelsaktivität. Käufer und Verkäufer werden beide benachrichtigt, dass ihre Aufträge erfolgreich ausgeführt wurden.
-
Eine anonymisiere Zusammenfassung der Auftragspreise und Handelsaktivitäten („Marktdaten”) wird auch an andere interessierte Kunden verbreitet.
-
Zu den Kennziffern der ECN-Leistung zählen Latenz und Durchsatz. Die Latenz charakterisiert die Reaktionszeit der Börse. Diese kann in vielen unterschiedlichen Kontexten gemessen werden: von der Erteilung eines Auftrags bis zum Empfang einer Anfangsbestätigung, von der Erteilung eines Auftrags bis zum Empfang einer Ausführungsbenachrichtigung oder von der Erteilung eines Auftrags bis zu dessen Verbreitung in den Marktdaten. Der Durchsatz bezeichnet die maximale Anzahl von Aufträgen oder Handelsaktivitäten, die vom ECN pro Sekunde unterstützt werden können.
-
Viele Kunden von ECNs wünschen sich eine niedrige Latenz und einen hohen Durchsatz, so dass sie häufig und vertrauensvoll handeln können, weniger Unsicherheit in Bezug auf den Status ihrer Aufträge erleben und in der Lage sind, schnell auf sich ändernde Bedingungen zu reagieren.
-
Die aktuellen ECNs werden als Software auf Architekturen mit Allzweck-Prozessoren implementiert, und typischerweise auch mit Allzweck-Betriebssystemen. Das vereinfacht zwar die Implementierung, führt aber dazu, dass diese Lösungen hohe Latenzen aufweisen – bestenfalls in der Größenordnung von Hunderten von Mikrosekunden und typischerweise in der Größenordnung von Millisekunden. Wird ein Allzweck-Betriebssystem genutzt, wächst damit auch die Wahrscheinlichkeit, dass ein feindlicher Angreifer den Computer beeinträchtigt, auf dem die ECN-Software ausgeführt wird; aus diesem Grund wird oft ein zusätzliches Firewall-System zwischen den Kunden und dem ECN-System eingefügt, was die Latenz weiter erhöht.
-
Zusammenfassung der Erfindung
-
Gemäß einem ersten Aspekt stellt die vorliegende Erfindung eine Kommunikationsschnittstelle für ein automatisches Handelssystem bereit, wobei die Kommunikationsschnittstelle für die Kommunikation von Nachrichten zu und von einem externen Netzwerk ausgelegt ist, wobei die Kommunikationsschnittstelle zum externen Netzwerk weisende dedizierte Hardware umfasst, die dazu ausgelegt ist, Nachrichten direkt vom externen Netzwerk zu empfangen, und eine in dezidierter Hardware implementierte Parsing-Engine umfasst, die dazu ausgelegt ist, die Nachrichten zu verarbeiten, die zur Übertragung an eine Matching-Engine im automatischen Handelssystem vorgesehen sind.
-
In einer Ausführungsform handelt es sich bei der dedizierten Hardware um einen PLD (Programmable Logic Device – programmierbarer Logikbaustein), der für die Verarbeitung der Finanztransaktionsnachrichten programmiert ist. In einer Ausführungsform wird die dedizierte Hardware durch einen PGA (Programmable Gate Array – programmierbare Logikanordnung) implementiert, wobei es sich in einer Ausführungsform um einen FPGA (Field Programmable Gate Array – frei programmierbare Logikanordnung) handelt.
-
In einer Ausführungsform kann durch den Einsatz dedizierter Hardware vorteilhafterweise die Verarbeitung eingehender und abgehender Nachrichten mit Hardware-Geschwindigkeiten erfolgen, was die Gesamtgeschwindigkeit des automatischen Handelssystems erhöht, wobei es sich in einer Implementierung um ein elektronisches Kommunikationsnetzwerk (Electronic Communications Network – ECN) handelt.
-
In einer Ausführungsform wird durch die dedizierte Hardware eine Parsing- und Validierungs-Engine implementiert, die dazu ausgelegt ist, eingehende Nachrichten (z. B. Aufträge von Brokern) in ein Anforderungsformat zu konvertieren, das in einer Ausführungsform einfacher ist und für die Matching-Engine geeignet ist.
-
In einer Ausführungsform ist die dedizierte Hardware dazu ausgelegt, eine Benachrichtigungs-Engine zu implementieren, die dem Empfang von Transaktionsinformationen von der Matching-Engine und dem Zusammenstellen entsprechender Nachrichten dient, welche in das Netzwerk ausgesendet werden sollen.
-
In einer Ausführungsform ist die dedizierte Hardware dazu ausgelegt, eine Sicherheitsfunktion zu implementieren, und sie ist dazu ausgelegt zu überprüfen, ob die eingehenden Nachrichten authentisch sind. In einer Ausführungsform ist die Sicherheitsfunktion durch die Implementierung einer Prüfsummen-Überprüfung der eingehenden Nachrichten implementiert, welche börsenspezifische Protokolle verwenden.
-
Die Verwendung dedizierter Hardware-Prozesse ermöglicht vorteilhafterweise einen sehr hohen Datendurchsatz bei geringer Latenz. Außerdem kann die Schnittstellenanbindung von Hardware wie PLDs an Netzwerke relativ einfach bewerkstelligt werden. Durch die Platzierung des PLD als der dem Kunden zugewandter Bestandteil eines ECN kann eine Kundenkommunikation mit hoher Bandbreite und geringer Latenz realisiert werden. Außerdem ist in einer Ausführungsform, da ein PLD (Anmerkung des Übersetzers: Es muss hier im Originaltext wohl statt „APLD” „a PLD” heißen, da die Abkürzung APLD sonst nirgendwo vorkommt) eine sehr minimale und verifizierbare Netzwerkimplementierung aufweist, die Angriffsfläche für potenzielle Angreifer minimal, was die Funktion einer Firewall subsumiert.
-
In einer Ausführungsform wird für Redundanz gesorgt, indem eine weitere Kommunikationsschnittstelle und eine weitere Matching-Engine bereitgestellt werden, wobei die weitere Kommunikationsschnittstelle und die Kommunikationsschnittstelle miteinander verbunden sind. In einer Ausführungsform sind die weitere Kommunikationsschnittstelle und die Kommunikationsschnittstelle über eine serielle Verbindung miteinander verbunden. In einer Ausführungsform wird noch eine weitere Kommunikationsschnittstelle und eine Matching-Engine bereitgestellt, um für weitere Redundanz zu sorgen. Die weitere Kommunikationsschnittstelle ist mit den anderen Kommunikationsschnittstellen verbunden, in einer Ausführungsform durch eine serielle Verbindung.
-
In einer Ausführungsform kann auch eine Matching-Engine durch dedizierte Hardware implementiert sein. In einer Ausführungsform kann die Matching-Engine durch einen PLD implementiert werden, und in einer Ausführungsform durch einen FPGA.
-
Gemäß einem zweiten Aspekt stellt die vorliegende Erfindung ein Verfahren zur Abwicklung der Kommunikation zwischen einem automatischen Handelssystem und einem externen Netzwerk bereit, welches die folgenden Schritte umfasst:
- – das direkte Empfangen von Nachrichten von dem externen Netzwerk mit Hardware- oder Beinahe-Hardware-Geschwindigkeiten und das Verarbeiten der Nachrichten, was den Schritt der Syntaxanalyse (Parsing) der Nachrichten mit Hardware- oder Beinahe-Hardware-Geschwindigkeiten einschließt, die zur Übertragung an eine Matching-Engine im automatischen Handelssystem vorgesehen sind.
-
In einer Ausführungsform erfolgt die Verarbeitung durch eine dedizierte Hardware-Anordnung, die durch einen PLD (Programmable Logic Device – programmierbarer Logikbaustein) implementiert sein kann.
-
Gemäß einem dritten Aspekt stellt die vorliegende Erfindung eine Matching-Engine für ein automatisches Handelssystem bereit, wobei die Matching-Engine dedizierte Hardware umfasst, die dazu ausgelegt ist, einen Standard-Doppelauktionsprozess zum Handel von Instrumenten auszuführen.
-
In einer Ausführungsform handelt es sich bei der dedizierten Hardware um einen PLD (Programmable Logic Device – programmierbarer Logikbaustein). In einer Ausführungsform handelt es sich bei der dedizierten Hardware um einen FPGA (Field Programmable Gate Array – frei programmierbare Logikanordnung).
-
Gemäß einem vierten Aspekt stellt die vorliegende Erfindung eine Sicherheitsanordnung für ein automatisches Handelssystem bereit, wobei die Sicherheitsanordnung eine Kommunikationsschnittstelle umfasst, die dazu ausgelegt ist, von einem externen Netzwerk an das automatische Handelssystem gerichtete Nachrichten zu empfangen, und die dedizierte Hardware enthält, welche dazu ausgelegt ist, die eingehenden Nachrichten zu verifizieren.
-
In einer Ausführungsform erfolgt die Verifizierung durch eine Prüfsummen-Überprüfung.
-
In einer Ausführungsform handelt es sich bei der dedizierten Hardware um einen PLD (Programmable Logic Device – programmierbarer Logikbaustein). In einer Ausführungsform handelt es sich bei dem programmierbaren Logikbaustein um einen FPGA (Field Programmable Gate Array – frei programmierbare Logikanordnung.
-
Kurze Beschreibung der Zeichnungen
-
Die Merkmale und Vorzüge der vorliegenden Erfindung werden aus der nachfolgenden Beschreibung von erfindungsgemäßen Ausführungsformen deutlich, die lediglich anhand von Beispielen erfolgt, und unter Bezug auf die beiliegenden Zeichnungen, die folgende Bedeutung haben:
-
1 ist ein allgemeines Blockdiagramm eines automatischen Handelssystems, das eine Vorrichtung gemäß einer Ausführungsform der vorliegenden Erfindung umfasst;
-
2 ist ein detaillierteres Blockdiagramm des Systems aus 1;
-
3 ist ein Blockdiagramm einer Vorrichtung gemäß einer weiteren Ausführungsform der Erfindung.
-
Detaillierte Beschreibung der Ausführungsformen
-
Bezug nehmend auf 1 wird dort eine mit der Bezugsziffer 1 gekennzeichnete Kommunikationsschnittstelle für ein automatisches Handelssystem dargestellt. Die Kommunikationsschnittstelle 1 ist durch dedizierte Hardware implementiert, wobei es sich – in diesem Beispiel – um einen FPGA 1 (Field Programmable Gate Array – frei programmierbare Logikanordnung) handelt, die dafür programmiert ist, eine Schnittstelle zwischen einem externen Netzwerk 2 und einer Matching-Engine 3 zu bilden, die in diesem Beispiel durch Software auf Allzweck-Prozessoren (z. B. einem Allzweck-Server- und Computerprogramm zur Implementierung einer Standard-Doppelauktion für Markthandelsaktivitäten) implementiert ist.
-
Gemeinsam bilden die Kommunikations- und Messaging-Schnittstelle 1, welche durch den FPGA implementiert ist, und die Matching-Engine, die durch das Allzweck-System und die darauf ausgeführte Software implementiert ist, ein elektronisches Kommunikationsnetzwerk (Electronic Communications Network – ECN), welches ein automatisches Handelssystem (Automated Trading System – ATS) implementiert.
-
Die Funktion der Kommunikations- und Messaging-Schnittstelle 1 besteht darin, Nachrichten vom Netzwerk 2 zu empfangen, diese zu verarbeiten und an die Matching-Engine 3 zu übergeben. Außerdem besteht ihre Funktion darin, Nachrichten von der Matching-Engine 3 zu empfangen, diese zu verarbeiten und zurück an das Netzwerk 2 zu übergeben.
-
Die Kunden des ECN, z. B. Broker, Händler und dergleichen, erteilen Aufträge zum Kaufen oder Verkaufen einer bestimmten Menge eines börsennotierten Instruments, z. B. einer Aktie oder eines Wertpapiers. Die Erteilung dieser Aufträge erfolgt in Form der ORDER-Nachrichten 4. Die ORDER-Nachricht hat üblicherweise ein bekanntes Format entsprechend der jeweiligen Handelsbörse. Ein typisches Format für eine ORDER-Nachricht 4 wird später detailliert beschrieben.
-
Als Reaktion auf den Empfang einer ORDER-Nachricht 4, stellt ein ECN üblicherweise eine Quittierung (Acknowledgement), die ACK-Nachricht 5, bereit, mit der quittiert wird, dass das ECN die ORDER-Nachricht 4 empfangen hat. Außerdem wird durch das ECN eine CONFIRM-Nachricht 6 als Bestätigung bereitgestellt, wenn der Auftrag verarbeitet und an die Matching-Engine übergeben wurde, um in den Standard-Doppelauktionsprozess einbezogen zu werden.
-
Wenn eine Handelsaktivität erfolgte, d. h. wenn die Matching-Engine einen Match zwischen einem Kauf und einem Verkauf hergestellt und deshalb eine Handelsaktivität durchgeführt hat, wird eine EXECUTE-Nachricht 7 zurück an das externe Netzwerk 2 geleitet, sodass der Kunde über die Handelsaktivität unterrichtet wird. Wenn eine Handelsaktivität erfolgt ist werden sowohl der Käufer als auch der Verkäufer durch eine EXECUTE-Nachricht 7 darüber informiert, dass ihre Aufträge erfolgreich ausgeführt wurden.
-
Die Reaktionszeit des ECN ist ein wichtiges Leistungskriterium. Diese schließt die Reaktionszeit für das Bereitstellen einer ACK-Nachricht 5 und auch die Reaktionszeit für das Bereitstellen einer CONFIRM-Nachricht 6 ein. Ein Kriterium kann auch die Zeit von der Erteilung eines Auftrags bis zum Empfang einer EXECUTE-Nachricht 7 sein.
-
Wie bereits erwähnt wurde, werden aktuelle ECNs auf Allzweck-Prozessoren unter Verwendung typischer Software ausgeführt. Diese aktuellen Lösungen weisen hohe Latenzen auf, die bestenfalls in der Größenordnung von Hunderten von Mikrosekunden und typischerweise in der Größenordnung von Millisekunden liegen. Und in einem Bereich, indem Zeit entscheidend ist (wo buchstäblich gilt „Zeit ist Geld”), müssen derartige Latenzen verbessert werden.
-
In dieser Ausführungsform ist der FPGA 1 entweder direkt oder über einen oder mehrere Sende-Empfangs-Einrichtungen auf der physikalischen Schicht mit dem Netzwerk 2 (z. B. dem Ethernet) verbunden. In dieser Ausführungsform werden High-End-PLDs, wie beispielsweise Virtex 5 FPGAs von Xilinx eingesetzt, um einen sehr hohen Datendurchsatz bei geringer Latenz zu erzielen. Die Anmelderin hat festgestellt, dass durch die Platzierung des PLD als der dem Kunden zugewandter Bestandteil eines ECN eine Kundenkommunikation mit hoher Bandbreite und geringer Latenz realisiert werden kann.
-
Neben der Kommunikation und dem Matching führt die Ausführungsform aus 1 auch die anderen Funktionen eines ECN durch, beispielsweise die Speicherung der verarbeiteten Informationen und die Erstellung von Marktdaten aus den verarbeiteten Handelsaktivitäten.
-
2 zeigt das ECN aus 1 mit weiteren Details.
-
Der FPGA 1 umfasst eine Parsing- und Validierungs-Engine 10 sowie eine Benachrichtigungs-Engine 11, die über die Schnittstelle 12 der physikalischen Schicht mit dem Netzwerk verbunden ist. Die Kunden (z. B. Broker usw.) senden über das Netzwerk 2 Nachrichten an das ECN-System. Es gibt je nach Operation unterschiedliche Nachrichtentypen, beispielsweise zum Erteilen eines neuen Auftrags und zum Ändern eines zuvor erteilten Auftrags.
-
Die Parsing- und Validierungs-Engine 10 konvertiert diese Nachrichten in ein einfacheres Anforderungsformat. Bei diesem Prozess verifiziert sie auch, dass die Nachricht von einem autorisierten Kunden stammt und legitime Daten enthält, wozu beispielsweise eine Prüfsummen-Überprüfung durchgeführt wird. Der Auftrag wird dann an eine Matching-Engine 12 für das angeforderte Instrument gesendet. In dieser Ausführungsform befindet sich die Matching-Engine auf einem Allzweck-Prozessor und ist durch typische Software implementiert.
-
Die Matching-Engine aktualisiert ihre Notierungswarteschlangen entsprechend der Anforderung.
-
Die Matching-Engine 13 kommuniziert ein Set daraus resultierender Transaktionen an die Benachrichtigungs-Engine 11 (durch FPGA implementiert) und auch an eine Speicher-Engine 14 (die ebenfalls auf einem Allzweck-Prozessor unter Verwendung typischer Software implementiert ist).
-
Die Benachrichtigungs-Engine 11 sendet Benachrichtigungsnachrichten (z. B. die EXECUTE-Nachricht 7) an den anfordernden Kunden und an alle anderen Kunden, mit denen der Auftrag möglicherweise gematcht wurde. Sie verbreitet auch die Marktdaten an andere Kunden.
-
Die Speicher-Engine 14 stellt sicher, dass alle Transaktionen auf Festplatten oder anderen stabilen Speichermedien sicher gespeichert werden.
-
Die Verwendung eines FPGA zur Implementierung der Parsing- und Validierungs-Engine 10 und der Benachrichtigungs-Engine 11 führt im ECN zu einer viel geringeren Latenz und kann bei den Nachrichten CONFIRM 6 und ACK 5 zu sehr kurzen Zeitperioden (in der Größenordnung von wenigen Mikrosekunden oder noch weniger) führen, und sie verbessert auch die Ausführungen, da der Auftrag schneller zur Matching-Engine gelangt als bei herkömmlichen Systemen. Und auch die EXECUTE-Nachrichten 7 werden schneller zurückgeschickt.
-
Bei dieser Ausführungsform sind die Parsing- und Validierungs-Engine 10 sowie die Benachrichtigungs-Engine 11 durch FPGA implementiert. Das heißt, dass die Kommunikations- und Messaging-Schnittstelle 1 durch FPGA implementiert ist.
-
In einer anderen Ausführungsform kann auch die Matching-Engine 13 durch einen FPGA (oder eine andere programmierbare oder Logik-Einrichtung oder durch dedizierte Hardware) implementiert sein, was die Geschwindigkeit weiter erhöht. In einer anderen Ausführungsform kann auch die Speicher-Engine durch dedizierte Hardware implementiert sein, z. B. durch PLDs, FPGAs oder dergleichen. Im Allgemeinen kann der Funktionsumfang des ECN unterschiedlich auf das PLD und den Allzweck-Prozessor aufgeteilt sein, was vom gewünschten Kompromiss zwischen Leistung und Einfachheit der Implementierung abhängt.
-
Die folgende Beschreibung ist eine etwas detailliertere Beschreibung der Verarbeitung durch den FPGA 1 unter Verwendung von Beispielnachrichten.
-
Parsing-/Validierungs-E-Mail
-
Die Parsing-/Validierungs-Engine 10 im FPGA 1 ist so ausgelegt, dass sie synchron zum Netzwerkempfang arbeitet. Für ein Gigabit Ethernet Netzwerk ist eine FPGA-Taktrate von 125 MHz wünschenswert, was in jedem Taktzyklus den Empfang und die Verarbeitung von 8 Bit (ein Byte) an Daten ermöglicht.
-
Es gibt zwei Typen von ECN-Nachrichten, die in diesem Beispiel durch den FPGA
1 verarbeitet werden: eine Nachricht bei neuen Aufträgen und eine Nachricht zum Ändern/Stornieren bestehender Auftrage. Die ECN-Nachrichten sind in standardmäßige Internet-Protokoll-Paketen (UDP/IP) eingekapselt. Eine Nachricht bei einem neuen Auftrag sieht beispielsweise folgendermaßen aus:
| Ethernet-Protocol-Header: | 112 Bit/14 Byte |
| IP-Protocol-Header: | 160 Bit/20 Byte (Minimum) |
| UDP-Protocol-Header: | 64 Bit/8 Byte |
| --- | |
| Sitzungs-ID: | 16 Bit/2 Byte |
| Sequenznummer: | 16 Bit/2 Byte |
| Instrument-Code: | 32 Bit/4Byte |
| Nachrichtentyp: | 8 Bit/1 Byte (0 = NEUER AUFTRAG) |
| Transaktionstyp: | 8 Bit/1 Byte (0 = kaufen, 1 = verkaufen) |
| (Reserviert für künftige Nutzung): | 16 Bit/2 Byte |
| Menge: | 16 Bit/2 Byte |
| Preis: | 16 Bit/2 Byte |
| Kundenreferenz: | 32 Bit/4 Byte |
-
Zuerst werden die Ethernet-, IP- und UDP-Protocol-Header übersprungen, was ziemlich einfach ist, obwohl der IP-Header eine variable Länge haben kann. Dann werden die ECN-Protokollfelder empfangen.
-
Das erste Feld – die Sitzungs-ID – ist ein nicht-transparentes Token, das die Sitzung zwischen einem Kunden und der Börse repräsentiert. Unter Verwendung dieses ersten Felds können Daten, die mit dem Kunden im Zusammenhang stehen, in einem im FPGA gespeicherten Kundeninformations-Array nachgeschlagen werden. Wenn das Feld „Sequenznummer” empfangen wird, verifiziert der FPGA, dass die Sequenznummer mit der für den Kunden erwarteten Sequenznummer übereinstimmt. Wenn diese Überprüfung erfolglos ist, wird der Rest der Nachricht ignoriert, und es wird sofort eine Benachrichtigungsnachricht an den Kunden zurückgesendet. Andernfalls wird die erwartete Sequenznummer in Vorbereitung auf die nächste Nachricht um 1 erhöht, und die Verarbeitung geht weiter. Die Sitzungs-ID wird in einen kompakteren „Kunden-Index” umgewandelt, der den Kunden identifiziert, und diese beiden Felder werden ansonsten verworfen.
-
Die folgenden vier Byte geben den Instrument-Code an, auf den sich die Nachricht bezieht. Dabei kann es sich um einen Aktiencode wie z. B. „MSFT” handeln oder um eine andere Kennung. Der FPGA ermittelt unter Verwendung effizienter Nachschlagetabellen (Look-Up Tables – LUTs), ob der Instrument-Code gültig ist. Wenn das der Fall ist wandelt er ihn in eine kompaktere Form um, nämlich in einen Instrument-Index. Eine solche Form macht die spätere Verarbeitung viel effizienter, aber diese Nummer ist möglicherweise nur für kurze Zeit gültig, wogegen es für Kunden wünschenswert ist, einen Standard-Instrument-Code zu verwenden.
-
Die anderen Felder in der Nachricht teilen den Transaktionstyp (kaufen oder verkaufen), den Preis, die Menge und die Kundenreferenz mit (ein vom Kunden geliefertes Feld, das in jeder Korrespondenz zu einem Auftrag an den Kunden gesendet wird). Beim Empfang von jedem der restlichten Felder wird eine interne Darstellung erzeugt, was nach dem Schema unten erfolgt. Viele der Eingabefelder können wörtlich durchgelassen werden. Die Felder werden jedoch einer Validierung unterzogen, um sicherzustellen, dass sie sinnvolle Werte enthalten; dass beispielsweise der Transaktionstyp entweder „kaufen” oder „verkaufen” ist. Damit wird die Validierung minimiert, die später in der Matching-Engine durchgeführt werden muss. Einige Felder, wie beispielsweise das Reserviert-Feld, befinden sich nur für künftige Erweiterungszwecke im Protokoll und können aus dem internen Formular ausgelassen werden.
-
Sobald alle Felder empfangen wurden, wird eine interne Sequenznummer angehängt. Der resultierende interne 16-Byte-Datensatz wird in einen Ringpuffer in einem Speicherbereich geschrieben, der gemeinsam mit der Matching-Engine verwendet wird.
| Kunden-Index: | 1 Byte |
| Instrument-Index: | 1 Byte |
| Nachrichtentyp: | 1 Byte (0 = NEUER AUFTRAG) |
| Transaktionstyp: | 1 Byte (0 = kaufen, 1 = verkaufen) |
| Menge: | 2 Byte |
| Preis: | 2 Byte |
| Kundenreferenz: | 4 Byte |
| (Nicht verwendet): | 2 Byte |
| Interne Sequenznummer: | 2 Byte |
-
Dieselbe Bearbeitung erfolgt auch für die Ändern-/Stornieren-Meldung:
| Ethernet-Protocol-Header: | 112 Bit/14 Byte |
| IP-Protocol-Header: | 160 Bit/20 Byte |
| UDP-Protocol-Header: | 64 Bit/8 Byte |
| --- | |
| Sitzungs-ID: | 16 Bit/2 Byte |
| Sequenznummer: | 16 Bit/2 Byte |
| Instrument: | 32 Bit/4 Byte |
| Nachrichtentyp: | 8 Bit/1 Byte (1 = AUFTRG ÄNDERN/STORNIEREN) |
| (Reserviert für künftige Nutzung): | 8 Bit/1 Byte |
| Neue Menge: | 16 Bit/2 Byte |
| Auftragsreferenz: | 32 Bit/4 Byte |
| Kundenreferenz: | 32 Bit/4 Byte |
-
Diese Nachricht enthält gleiche Felder wie die Nachricht für neue Aufträge und in wird in gleicher Weise verarbeitet. Anstelle von Transaktionstyp und Preis wird jetzt eine Auftragsreferenz verwendet, um den Bezug zum bereits erteilten Auftrag herzustellen. Diese wird wörtlich in den internen 16-Byte-Datensatz übernommen, der in diesem Fall folgendermaßen aussieht:
| Kunden-Index: | 1 Byte |
| Instrument-Index: | 1 Byte |
| Nachrichtentyp: | 1 Byte (1 = AUFTRG ÄNDERN/STORNIEREN) |
| (Nicht verwendet): | 1 Byte |
| Auftragsreferenz: | 4 Byte |
| Kundenreferenz: | 4 Byte |
| Neue Menge: | 2 Byte |
| Interne Sequenznummer: | 2 Byte |
-
Matching-Engine
-
Die Matching-Engine greift auf die 16-Byte-Datensätze zu, die durch die Parsing-/Validierungs-Engine erzeugt wurden. Für jeden Datensatz, den sie liest, führt sie die erforderlichen Aktualisierungen an ihren internen Warteschlangen durch, und erzeugt 16-Byte-Datensätze in einem Ausgangs-Ringpuffer (der Benachrichtigungswarteschlange). Das Benachrichtigungsformat wird weiter unten beschrieben.
-
Wenn der Nachrichtentyp AUFTRAG ÄNDERN/STORNIEREN ist, verwendet die Matching-Engine die Auftragsreferenz zur Suche nach einem vorhandenen Auftrag und aktualisiert dessen Menge anhand des Felds „Neue Menge”. Wird der Auftrag nicht gefunden, gehört er zu einem anderen Kunden oder ist die Angabe in „Neue Menge” größer als die bisherige Menge, wird eine ÄNDERN-ABGELEHNT-Benachrichtigung in der Warteschlange platziert. Andernfalls wird eine ÄNDERN-AKZEPTIERT-Benachrichtigung in der Warteschlange platziert.
-
Wenn der Nachrichtentyp NEUER AUFTRAG ist, überprüft die Matching-Engine, ob der neue Auftrag mit einem in der Warteschlange befindlichen Auftrag auf der Gegenseite gematcht werden kann (z. B. überprüft sie für einen Kaufauftrag, ob in den Warteschlangen Verkäufer für das Instrument vorhanden sind). Wenn das der Fall ist, werden AUFTRAG-AUSGEFÜHRT-Benachrichtigungen für beide Seiten in die Warteschlange aufgenommen. Wenn sich der Preis bei weitem vom aktuellen Marktpries unterscheidet, führt das zu einer AUFTRAG-ABGELEHNT-Benachrichtigung.
-
Andernfalls wird der Auftrag zur Warteschlange hinzugefügt und eine AUFTRAG-AKZEPTIERT-Benachrichtigung erzeugt.
-
Die Benachrichtigungen folgen einem einfachen Datensatzformat, das dem Eingabeformat der Matching-Engine gleicht.
| Kunden-Index: | 1 Byte |
| Instrument-Index: | 1 Byte |
| Benachrichtigungstyp: | 1 Byte (0 = AUFTRAG-ABGELEHNT, 1 = AUFTRAG-AKZEPTIERT, 2 = AUFTRAG-AUSGEFÜHRT, 3 = ÄNDERN-ABGELEHNT, 4 = ÄNDERN-AKZEPTIERT) |
| Transaktionstyp: | 1 Byte |
| Menge: | 2 Byte |
| Preis: | 2 Byte |
| Kundenreferenz: | 4 Byte |
| Auftragsreferenz: | 4 Byte |
-
Benachrichtigungs-Engine
-
Eine Benachrichtigungs-Engine im FPGA liest die Datensätze aus der Benachrichtigungswarteschlange und sendet die Nachrichten an die Kunden. Der Kunden-Index wird verwendet, um die Indizierung in einen Kundeninformations-Index durchzuführen, der die Ethernet-Adresse, die IP-Adresse und die UDP-Portnummer zur Kontaktierung des Kunden enthält sowie die nächste abgehende Sequenznummer. Der interne Instrument-Index wird wieder dem 4-Byte-Instrument-Code zugeordnet, der von den Kunden verwendet wird. Die andere Felder werden wörtlich übernommen.
-
Die abgehenden Nachrichten werden durch die FPGA-Logik erzeugt, die synchron zur Netzwerkübertragung ausgeführt wird, wobei jedes Ausgangs-Byte je nach Bedarf erzeugt wird, anstatt eine vorkonstruierte Nachricht im Speicher halten zu müssen. Die Felder aus dem Benachrichtigungsdatensatz werden an den entsprechenden Stellen in die abgehende Nachricht eingesetzt. Eine abgehende Nachricht sieht beispielsweise folgendermaßen aus:
| Ethernet-Protocol-Header: | 112 Bit/14 Byte |
| IP-Protocol-Header: | 160 Bit/20 Byte |
| UDP-Protocol-Header: | 64 Bit/8 Byte |
| --- | |
| Sequenznummer: | 16 Bit/2 Byte |
| Benachrichtigungstyp: | 8 Bit/1 Byte |
| Transaktionstyp: | 8 Bit/1 Byte |
| Instrument-Code: | 32 Bit/4 Byte |
| Menge: | 16 Bit/2 Byte |
| Preis: | 16 Bit/2 Byte |
| Kundenreferenz: | 32 Bit/4 Byte |
| Auftragsreferenz: | 32 Bit/4 Byte |
-
Es lässt sich leicht nachvollziehen, dass es sich bei den Nachrichten in der obigen Beschreibung lediglich um Beispiele handelt, und auch Nachrichten mit anderen Formaten oder andere Nachrichten können durch Anordnungen gemäß anderen Ausführungsformen der vorliegenden Erfindung verarbeitet werden.
-
In einer Ausführungsform kann ein System wie bei der oben beschriebenen Ausführungsform mehrfach reproduziert sein, um Redundanz zu erzielen. Es lässt sich leicht nachvollziehen, dass Redundanz in einem solchen System wichtig sein kann, um sicherzustellen, dass die Markthandelsaktivitäten fortgesetzt werden können (im Falle des Ausfalls eines Teils oder des gesamten Systems) und dass dabei die Handelsdatensätze bewahrt werden.
-
3 zeigt ein Blockdiagramm eines Systems gemäß einer weiteren Ausführungsform der vorliegenden Erfindung. Das System umfasst in diesem Beispiel drei Systemeinheiten 30, 31 und 32. Jede der Systemeinheiten umfasst eine Kommunikations- und Messaging-Schnittstelle 1 und eine Matching-Engine sowie über Vorrichtungen zur Durchführung der anderen ECN-Funktionen 3. Mit anderen Worten: Die Systemeinheiten 30, 31 und 32 sind drei Reproduktionen des Systems aus 1.
-
In dieser Ausführungsform sind die FPGAs 1 von jeder Systemeinheit 30, 31 und 32 über die Verbindungen 33 und 34 seriell miteinander verbunden. Damit wird sichergestellt, dass es für alle Nachrichten, die in die Systeme kommen oder von diesen abgehen, Sicherungssysteme gibt. Fällt beispielsweise System 30 aus, dann verfügen die Systeme 31 und 32 über sämtliche verfügbaren Informationen, um die Verarbeitung der Markthandelsdaten fortzusetzen.
-
Ausführungsformen, wie sie oben beschrieben wurden, können zum Handel mit jedem Instrument verwendet werden, einschließlich, jedoch ohne Beschränkung auf Aktien, Wertpapiere, Optionen, Termingeschäfte, Anleihen, andere Derivate, CFDs, Commodities, Halbleiterchips und anderes.
-
In den obigen Ausführungsformen erfolgt die Implementierung der Kommunikationsschnittstelle durch einen FPGA. Sie kann jedoch auch durch jeden programmierbaren Logikbaustein implementiert werden, und kann in der Tat durch jede dedizierte Hardware implementiert werden. Beispielsweise kann ein angepasster Chip verwendet werden, um den Funktionsumfang der Kommunikationsschnittstelle zu implementieren. In gleicher Weise können, wo andere Teile des ECN durch dedizierte Hardware implementiert werden (z. B. die Matching-Engine und/oder die Speicher-Engine), diese auch durch jeden Typ von dedizierter Hardware implementiert werden, beispielsweise durch angepasste Schaltkreise, durch jede Art von PLDs und durch FPGAS.
-
In den nachfolgenden Patentansprüchen und in der oben erfolgten Beschreibung der Erfindung wird, sofern vom Kontext nicht anders durch ausdrückliche Formulierungen oder notwendige Implikationen verlangt, das Wort „umfassen” oder Varianten davon wie „umfasst” oder „umfassend” in einem einbeziehenden Sinne gebraucht, d. h. um das Vorhandensein des angegebenen Merkmals festzulegen, jedoch nicht, um das Vorhandensein oder die Hinzufügung weiterer Merkmale in den verschiedenen Ausführungsformen der Erfindung auszuschließen.
-
Für Fachleute auf dem Gebiet der Technik wird es leicht nachvollziehbar sein, dass zahlreiche Variationen und/oder Änderungen an der in den konkreten Ausführungsformen gezeigten Erfindung vorgenommen werden können, ohne dabei vom Gedanken und Umfang der Erfindung abzuweichen, die umfassend beschrieben wurden. Die vorliegenden Ausführungsformen sollten deshalb in jeder Hinsicht als beispielhaft und nicht als einschränkend angesehen werden.
