Automatisierte Handelssysteme: Architektur, Protokolle, Arten von Latenzzeiten

Das automatisierte Handelssystem oder Algorithmic Trading steht seit mehr als einem Jahrzehnt im Mittelpunkt der Handelswelt. Ein “Handelssystem”, besser bekannt als “Handelsstrategie”, ist nichts anderes als ein Regelwerk, das auf die gegebenen Eingangsdaten angewendet wird, um Eingangs- und Ausgangssignale (Kauf/Verkauf) zu erzeugen.

Obwohl die Formulierung einer Handelsstrategie als eine leichte Aufgabe erscheint, ist sie es in Wirklichkeit nicht! Die Entwicklung einer erfolgreichen Handelsstrategie erfordert eine umfassende quantitative Forschung, und die Köpfe hinter einer quantitativen Handelsstrategie sind in der Welt des algorithmischen Handels als “Quants” bekannt. Wir können ein “Quant” als einen Fachmann definieren, der bei einer quantitativen Handelsfirma angestellt ist und fortschrittliche mathematische und statistische Modelle mit dem einzigen Ziel anwendet, eine Alpha-Searching-Strategie zu erstellen, d.h. eine profitable Handelsstrategie, die beständig Renditen erzielen kann, die unabhängig von der Richtung des Gesamtmarktes sind.

Der Prozentsatz der Volumina, die dem algorithmischen Handel zugeschrieben werden, hat in den letzten zehn Jahren einen erheblichen Anstieg erfahren. In den USA und anderen entwickelten Märkten machen der Hochfrequenzhandel und der algorithmische Handel schätzungsweise 70% des Aktienmarktanteils aus. In Indien ist der Prozentsatz in Bezug auf den Gesamtumsatz auf rund 50% gestiegen.

Das Wachstum des automatisierten Handels hat in den letzten zehn Jahren zu bedeutenden Veränderungen in der grundlegenden Architektur der automatisierten Handelssysteme geführt und wird dies auch weiterhin tun. Für Unternehmen, insbesondere für solche, die Hochfrequenzhandelssysteme verwenden, ist es zu einer Notwendigkeit geworden, technologische Neuerungen einzuführen, um in der Welt des algorithmischen Handels konkurrenzfähig zu sein, wodurch der Bereich des algorithmischen Handels zu einer Brutstätte für Fortschritte in der Computer- und Netzwerktechnologie wurde.

In diesem Beitrag werden wir die Architektur hinter automatisierten Handelssystemen für unsere Leser entmystifizieren. Wir vergleichen die neue Architektur der automatisierten Handelssysteme mit der traditionellen Handelsarchitektur und verstehen einige der Hauptkomponenten hinter diesen Systemen.

Traditionelle Architektur

Jedes Handelssystem ist vom Konzept her nichts anderes als ein Rechenblock, der mit der Börse auf zwei verschiedenen Strömen interagiert.

Empfängt Marktdaten
Sendet Bestellanforderungen und empfängt Antworten von der Börse.

In seiner Grundform können wir den Austausch von Daten von der Börse und dem Automatisierten Handelssystem wie folgt darstellen:

Die empfangenen Marktdaten informieren das automatisierte Handelssystem in der Regel über das letzte Auftragsbuch. Sie können einige zusätzliche Informationen wie das bisher gehandelte Volumen, den zuletzt gehandelten Preis und die Menge für ein Scrip enthalten. Um jedoch eine Entscheidung über die Daten treffen zu können, muss der Händler möglicherweise alte Werte betrachten oder bestimmte Parameter aus der Historie ableiten. Um dem Rechnung zu tragen, würde ein konventionelles System über eine historische Datenbank zur Speicherung der Marktdaten und über Werkzeuge zur Nutzung dieser Datenbank verfügen. Die Analyse würde auch eine Untersuchung der vergangenen Abschlüsse durch den Händler beinhalten. Daher auch eine weitere Datenbank zur Speicherung der Handelsentscheidungen. Zu guter Letzt eine GUI-Schnittstelle für den Händler, um all diese Informationen auf dem Bildschirm anzuzeigen.

Unter Berücksichtigung aller oben genannten Punkte lässt sich die traditionelle Architektur des gesamten automatisierten Handelssystems nun aufgliedern in

Die Börsen – die Außenwelt
Der Server
– Marktdaten-Empfänger
– Marktdaten speichern
– Vom Benutzer erzeugte Speicheraufträge
Anwendungen
– Eingaben des Benutzers einschließlich der Handelsentscheidungen entgegennehmen
– Schnittstelle zum Anzeigen der Informationen einschließlich der Daten und Aufträge
– Ein Auftragsmanager, der Aufträge an die Börse sendet

Beispiele solcher Handelsbörsen sind hier zu finden:

Aktienbroker Vergleich
Forexbroker Vergleich
Bestbitcoinexchange

Grenzen der traditionellen Architektur

Es stellte sich jedoch heraus, dass die traditionelle Architektur den Bedürfnissen und Anforderungen des automatisierten Handels mit DMA nicht gerecht werden konnte. Die Latenzzeit zwischen dem Ursprung des Ereignisses und der Auftragserzeugung überschritt die Dimension menschlicher Kontrolle und drang in den Bereich von Millisekunden und Mikrosekunden vor. Das Auftragsmanagement muss auch robuster sein und viel mehr Aufträge pro Sekunde verarbeiten können. Da der Zeitrahmen im Vergleich zur menschlichen Reaktionszeit winzig ist, muss das Risikomanagement auch Aufträge in Echtzeit und vollständig automatisiert abwickeln.

Selbst wenn zum Beispiel die Reaktionszeit für einen Auftrag 1 Millisekunde beträgt (was im Vergleich zu den Latenzen, die wir heute sehen, eine Menge ist), ist das System immer noch in der Lage, 1000 Handelsentscheidungen in einer einzigen Sekunde zu treffen. Jede dieser 1000 Handelsentscheidungen muss also innerhalb derselben Sekunde das Risikomanagement durchlaufen, um die Börse zu erreichen. Man könnte sagen, dass dies bei automatisierten Handelssystemen nur ein Problem der Komplexität ist.

Ein weiterer Punkt, der sich herausgestellt hat, ist, dass, da die Architektur nun eine automatisierte Logik beinhaltet, 100 Händler durch ein einziges automatisiertes Handelssystem ersetzt werden können. Dadurch wird das Problem noch größer. So erzeugt jede der logischen Einheiten 1000 Aufträge, und 100 solcher Einheiten bedeuten 100.000 Aufträge pro Sekunde. Das bedeutet, dass der Entscheidungs- und Order-Sendeteil viel schneller sein muss als der Marktdatenempfänger, um die Datenrate zu erreichen.

Die neue Systemarchitektur des automatisierten Handelssystems

Um die Einschränkungen der traditionellen Systemarchitektur zu überwinden, wurde die Engine, die die Logik der Entscheidungsfindung ausführt, auch bekannt als “Complex Event Processing”-Engine oder CEP, von innerhalb der Anwendung auf den Server verlagert. Die Anwendungsschicht ist nun etwas mehr als eine Benutzerschnittstelle zur Anzeige und Bereitstellung von Parametern für die CEP.

Das Problem der Skalierung in einem automatisierten Handelssystem führt ebenfalls zu einer interessanten Situation. Nehmen wir an, es werden 100 verschiedene Logiken über ein einziges Marktdatenereignis ausgeführt (wie im früheren Beispiel diskutiert). Es könnte jedoch gemeinsame Stücke komplexer Berechnungen geben, die für die meisten der 100 Logikeinheiten ausgeführt werden müssen, sagen wir, die Berechnung der Griechen für Optionen. Wenn jede Logik unabhängig funktionieren würde, würde jede Einheit dieselbe griechische Berechnung durchführen, was unnötig Prozessorressourcen verbrauchen würde. Um die Redundanz der Berechnung zu optimieren, werden komplexe redundante Berechnungen in der Regel in eine separate Berechnungsmaschine ausgegliedert, die die Griechen als Input für die CEP im automatisierten Handelssystem bereitstellt.

Obwohl es sich bei der Anwendungsschicht in erster Linie um eine Sichtweise handelt, können einige der Risikoprüfungen (die wegen des Skalenproblems inzwischen zu ressourcenhungrigen Operationen geworden sind) auf die Anwendungsschicht verlagert werden, insbesondere solche, die mit der Zurechnungsfähigkeit von Benutzereingaben wie Fettfingerfehler zu tun haben.

Der Rest der Risikoprüfungen in einem automatisierten Handelssystem wird nun von einem separaten Risikomanagementsystem (RMS) innerhalb des Order Managers (OM) durchgeführt, kurz bevor eine Order freigegeben wird. Das Problem der Größenordnung bedeutet auch, dass es dort, wo früher 100 verschiedene Händler ihr Risiko verwalteten, jetzt nur noch ein RMS-System gibt, um das Risiko über alle logischen Einheiten/Strategien hinweg zu verwalten. Einige Risikoprüfungen können jedoch für bestimmte Strategien spezifisch sein, und einige müssen möglicherweise für alle Strategien durchgeführt werden. Daher umfasst das RMS selbst ein RMS auf Strategieebene (SLRMS) und ein globales RMS (GRMS). Es könnte auch eine Benutzeroberfläche zur Ansicht des SLRMS und GRMS umfassen.

Lassen Sie uns nun die Server-Komponenten im Detail verstehen.

Markt-Adapter

Exchange oder jeder Marktdatenanbieter sendet Daten in seinem eigenen Format. Ihr algorithmisches Handelssystem kann diese Sprache verstehen oder auch nicht. Exchange stellt Ihnen eine API oder eine Anwendungsprogrammschnittstelle zur Verfügung, mit der Sie Ihren eigenen Adapter programmieren und erstellen können, der das Format der Daten in das Format konvertieren kann, das Ihr System versteht.
Komplexe Ereignisverarbeitungs-Engine

Dieser Teil ist das Gehirn Ihrer Strategie. Sobald Sie über die Daten verfügen, müssen Sie gemäß Ihrer Strategie damit arbeiten. Dazu gehören verschiedene statistische Berechnungen, Vergleiche mit historischen Daten und die Entscheidungsfindung für die Auftragsgenerierung. Die Art des Auftrags, die Auftragsmenge wird in diesem Block vorbereitet.

Was Sie ein Handelssystem nennen, ist in Wirklichkeit ein CEP-System.

Ein komplexes Ereignis ist nichts anderes als eine Reihe von eingehenden Ereignissen. Dazu gehören Aktientrends, Marktbewegungen, Nachrichten usw. Komplexe Ereignisverarbeitung ist die Durchführung von Rechenoperationen bei komplexen Ereignissen in kurzer Zeit. In einem automatisierten Handelssystem können die Operationen die Erkennung komplexer Muster, den Aufbau von Korrelationen und Beziehungen wie Kausalität und Timing zwischen eingehenden Ereignissen umfassen.

CEP-Systeme verarbeiten Ereignisse in Echtzeit, d.h. je schneller die Verarbeitung von Ereignissen, desto besser ist ein CEP-System. Wenn z.B. ein automatisiertes Handelssystem darauf ausgelegt ist, eine Gewinnmöglichkeit für die nächste 1 Sekunde zu erkennen, aber die vom CEP-System benötigte Zeit diese Schwelle überschreitet, dann kann das Handelssystem keine Gewinne erzielen.

Das CEP-System besteht aus vier Teilen:

CEP-Engine
CEP-Regeln
CEP WS
CEP-Ergebnis-Schnittstelle

Hier 2 interessante Ressourcen zu CEP:

https://www.sciencedirect.com/topics/computer-science/complex-event-processing
https://flink.apache.org/news/2016/04/06/cep-monitoring.html

Die beiden Hauptkomponenten jedes CEP-Systems sind die CEP-Maschine und die CEP-Regeln. Die CEP-Engine verarbeitet eingehende Ereignisse auf der Grundlage der CEP-Regeln. Diese Regeln und die Ereignisse, die als Input in die CEP-Engine eingehen, werden durch das angewandte Handelssystem (Handelsstrategie) bestimmt.

Für ein Quant konzentriert sich der Großteil seiner Arbeit auf diesen CEP-Systemblock. Ein Quant wird die meiste Zeit damit verbringen, Handelsstrategien zu formulieren; er wird unter anderem rigoroses Backtesting, Optimierung und Positionsgrößenbestimmung durchführen. Dies geschieht, um die Durchführbarkeit der Handelsstrategie in realen Märkten sicherzustellen. Keine einzelne Strategie kann ewige Gewinne garantieren. Daher ist es erforderlich, dass Quants regelmäßig neue Strategien entwickeln, um sich auf den Märkten einen Vorsprung zu sichern.

Es gibt eine Reihe von beliebten automatisierten Handelssystemen, die auf den aktuellen Märkten weit verbreitet sind. Diese reichen von Momentum-Strategien, statistischer Arbitrage, Market Making usw. Lesen Sie unseren sehr aufschlussreichen Blog über Algorithmische Handelsstrategien, Paradigmen und Modellierungsideen, um mehr über diese Handelssysteme zu erfahren.

Order-Routing-System

Der Auftrag wird in der für die Börse verständlichen Sprache verschlüsselt, wobei die von der Börse zur Verfügung gestellten APIs verwendet werden. Es gibt zwei Arten von APIs, die von der Börse bereitgestellt werden: native API und FIX API. Native APIs sind diejenigen, die spezifisch für eine bestimmte Börse sind. Das FIX (Financial Information Exchange)-Protokoll ist eine Reihe von Regeln, die von verschiedenen Börsen verwendet werden, um den Datenfluss auf den Wertpapiermärkten einfacher und effektiver zu gestalten. Wir werden im nächsten Abschnitt weiter über FIX sprechen.

Im Falle einer offenen Wirtschaft kann man Aufträge über das automatisierte Handelssystem an Börsen oder Nichtbörsen senden, und ORP sollte in der Lage sein, Aufträge an verschiedene Bestimmungsorte zu bearbeiten.

An dieser Stelle möchten wir darauf hinweisen, dass das Auftragssignal entweder manuell durch eine Person oder automatisiert ausgeführt werden kann. Der letztere Teil ist das, was wir als “automatisiertes Handelssystem” bezeichnen. Das Auftragsverwaltungsmodul besteht aus verschiedenen Ausführungsstrategien, die die Kauf-/Verkaufsaufträge auf der Grundlage einer vordefinierten Logik ausführen. Zu den beliebten Ausführungsstrategien gehören VWAP, TWAP usw. Es gibt verschiedene Prozesse wie Order-Routing, Order-Codierung, Übertragung usw., die Teil dieses Moduls sind. Lesen Sie unseren Blog über Order Management System (OMS), um mehr über diese Prozesse zu erfahren.

Risikomanagement in automatisierten Handelssystemen

Da automatisierte Handelssysteme ohne jegliches menschliches Zutun funktionieren, ist es sinnvoll, gründliche Risikoprüfungen durchzuführen, um sicherzustellen, dass die Handelssysteme wie geplant funktionieren. Das Fehlen von Risikoprüfungen oder fehlerhaftes Risikomanagement kann für ein quantitatives Unternehmen zu enormen uneinbringlichen Verlusten führen. Daher bildet ein Risikomanagementsystem (RMS) eine sehr kritische Komponente jedes automatisierten Handelssystems.

Es gibt 2 Stellen, an denen das Risikomanagement in automatisierten Handelssystemen gehandhabt wird:

Innerhalb der Anwendung – Wir müssen sicherstellen, dass diese falschen Parameter nicht vom Händler eingestellt werden. Es sollte einem Händler nicht erlauben, grob falsche Werte oder Fettfingerfehler einzustellen.

Bevor ein Auftrag im OMS generiert wird – Bevor der Auftrag aus dem System herausfließt, müssen wir sicherstellen, dass er ein Risikomanagementsystem durchläuft. Hier findet die kritischste Überprüfung des Risikomanagements statt. In unserem Blog zum Thema “Wechselnde Trends im Handelsrisikomanagement” erfahren Sie mehr über Risikomanagement-Aspekte und die Risikohandhabung in einem automatisierten Handelssystem.

Um mehr über den Ordermanager zu erfahren, lesen Sie unseren Beitrag über “Order Management System in einem automatisierten Handelssystem”.

Um mehr über Risikomanagement zu erfahren, können Sie unseren Beitrag über “Changing Trends in Trading Risk Management in Automated Trading Systems” lesen.

Die Entstehung von Protokollen für automatisierte Handelssysteme

Wie wir bereits beim Tutorial zum automatisierten Handelssystem gesehen haben, ergab sich, da die neue Architektur in der Lage war, auf viele Strategien pro Server zu skalieren, die Notwendigkeit, sich von einem einzigen Server aus mit mehreren Zielen zu verbinden. Daher stellte der Order Manager mehrere Adapter bereit, um Aufträge an mehrere Ziele zu senden und Daten von mehreren Börsen zu empfangen.

Jeder Adapter fungiert als Dolmetscher zwischen dem Protokoll, das vom Austausch verstanden wird, und dem Kommunikationsprotokoll innerhalb des Systems. Mehrere Austausche würden also mehrere Adapter erfordern.

Um jedoch dem automatisierten Handelssystem eine neue Börse hinzuzufügen, muss ein neuer Adapter entworfen und in die Architektur eingesteckt werden, da jede Börse ihrem Protokoll folgt, das für die von der Börse bereitgestellten Funktionen optimiert ist. Um diesen Ärger mit dem Hinzufügen von Adaptern zu vermeiden, wurden Standardprotokolle entwickelt. Das bekannteste unter ihnen ist das FIX-Protokoll. Dadurch wird es nicht nur handhabbar, Verbindungen zu verschiedenen Zielen im laufenden Betrieb herzustellen, sondern auch die Markteinführungszeit drastisch verkürzt, wenn es um die Verbindung mit einem neuen Ziel geht.

Das Vorhandensein von Standardprotokollen macht es dem automatisierten Handelssystem leicht, auch Drittanbieter für Analysen oder Marktdaten-Feeds zu integrieren. Infolgedessen wird der Markt sehr effizient, da die Integration mit einer neuen Destination/einem neuen Anbieter keine Beschränkungen mehr mit sich bringt.

Darüber hinaus wird die Simulation sehr einfach, da der Empfang von Daten vom realen Markt und das Senden von Aufträgen an einen Simulator nur eine Frage der Verwendung des FIX-Protokolls zur Verbindung mit einem Simulator ist. Der Simulator selbst kann intern gebaut oder von einem Drittanbieter beschafft werden. Auf ähnliche Weise aufgezeichnete Daten können wiedergegeben werden, wobei die Adapter unabhängig davon sind, ob die Daten vom Live-Markt oder von einem aufgezeichneten Datensatz empfangen werden.

Das Aufkommen von Architekturen mit niedriger Latenz

Mit den Bausteinen eines automatisierten Handelssystems sind die Strategien nun in der Lage, riesige Datenmengen in Echtzeit zu verarbeiten und schnelle Handelsentscheidungen zu treffen. Heute, mit dem Aufkommen von Standardkommunikationsprotokollen wie FIX, ist die technologische Einstiegshürde für die Einrichtung eines algorithmischen Handelsdesks oder eines automatisierten Handelssystems niedriger geworden, und folglich ist die Welt des algorithmischen Handels wettbewerbsfähiger geworden. Als die Server mehr Speicher und höhere Taktfrequenzen erhielten, verlagerte sich der Schwerpunkt auf die Verringerung der Latenzzeit für die Entscheidungsfindung. Im Laufe der Zeit ist die Verringerung der Latenz aus vielen Gründen zu einer Notwendigkeit geworden:

Die Strategie ist nur in einer Umgebung mit geringer Latenz sinnvoll.
Der Stärkste überlebt – Konkurrenten nehmen Sie aus, wenn Sie nicht schnell genug sind

Das Problem ist jedoch, dass Latenz eigentlich ein übergreifender Begriff ist, der mehrere verschiedene Verzögerungen umfasst. Obwohl er sehr leicht verständlich ist, lässt er sich nur schwer quantifizieren. Daher wird es immer wichtiger, wie das Problem der Reduzierung der Latenz angegangen wird.

Wenn wir uns den grundlegenden Lebenszyklus in einem automatisierten Handelssystem ansehen,

Ein Marktdatenpaket wird von der Börse veröffentlicht
Das Paket wird über die Leitung übertragen.
Das Paket kommt bei einem Router auf der Serverseite an.
Der Router leitet das Paket über das Netzwerk auf der Serverseite weiter.
Das Paket kommt am Ethernet-Port des Servers an.
Je nachdem, ob es sich um UDP/TCP handelt, findet eine Verarbeitung statt, und das von seinen Headern und Trailern befreite Paket findet seinen Weg in den Speicher des Adapters.
Der Adapter parst dann das Paket und konvertiert es in ein internes Format der algorithmischen Handelsplattform.
Dieses Paket durchläuft nun die verschiedenen Module des Systems – CEP, Tick Store usw.
Das CEP analysiert und sendet eine Bestellanfrage
Die Bestellanforderung durchläuft als Marktdatenpaket wieder den umgekehrten Zyklus.

In einem automatisierten Handelssystem gewährleistet eine hohe Latenzzeit bei jedem dieser Schritte eine hohe Latenzzeit für den gesamten Zyklus. Daher beginnt die Latenzoptimierung normalerweise mit dem ersten Schritt in diesem Zyklus, der in unserer Kontrolle liegt, d.h. “das Paket läuft über die Leitung”. Am einfachsten wäre es hier, die Entfernung zum Zielort so weit wie möglich zu verkürzen.

Colocations sind Einrichtungen, die von Börsen bereitgestellt werden, um den Handelsserver in unmittelbarer Nähe der Börse zu hosten. Das folgende Diagramm veranschaulicht die Gewinne, die durch eine Verkürzung der Entfernung erzielt werden können.

In einem automatisierten Handelssystem ist für jede Art von Hochfrequenzstrategie mit einem einzigen Zielort die Kolokation zu einem defacto-Muss geworden. Strategien, die mehrere Zielorte umfassen, bedürfen jedoch einer sorgfältigen Planung. Faktoren wie die Zeit, die die Destination benötigt, um auf Bestellanfragen zu antworten, und ihr Vergleich mit der Ping-Zeit zwischen den beiden Destinationen müssen berücksichtigt werden, bevor eine solche Entscheidung getroffen wird. Die Entscheidung kann auch von der Art der Strategie abhängen.

Die Netzwerklatenz ist normalerweise der erste Schritt zur Verringerung der Gesamtlatenz eines automatisierten Handelssystems. Es gibt jedoch viele andere Stellen, an denen die Architektur optimiert werden kann.

Ausbreitungs-Latenz

In einem automatisierten Handelssystem bezeichnet die Ausbreitungslatenz die Zeit, die benötigt wird, um die Bits über die Leitung zu senden, natürlich begrenzt durch die Lichtgeschwindigkeit.

Es wurden mehrere Optimierungen eingeführt, um die Ausbreitungslatenz zu verringern, abgesehen von der Verringerung der physischen Distanz. Zum Beispiel beträgt die geschätzte Hin- und Rücklaufzeit für ein gewöhnliches Kabel zwischen Chicago und New York 13,1 Millisekunden. Spread Networks kündigte im Oktober 2012 Latenzverbesserungen an, die die geschätzte Hin- und Rücklaufzeit auf 12,98 Millisekunden brachten. Die Mikrowellenkommunikation wurde auch von Firmen wie Tradeworx übernommen, wodurch die geschätzte Hin- und Rücklaufzeit auf 8,5 Millisekunden erhöht wurde. Beachten Sie, dass das theoretische Minimum etwa 7,5 Millisekunden beträgt. Kontinuierliche Innovationen verschieben die Grenzen der Wissenschaft und erreichen schnell die theoretische Grenze der Lichtgeschwindigkeit. Jüngste Entwicklungen in der Laserkommunikation, die früher in der Verteidigungstechnik eingesetzt wurden, haben die ohnehin schon dünner werdende Latenz um Nanosekunden über kurze Distanzen weiter verringert.

Latenz der Netzwerkverarbeitung

Unter Netzwerkverarbeitungs-Latenz versteht man die durch Router, Switches usw. eingeführte Latenz.

Die nächste Optimierungsebene in der Architektur eines automatisierten Handelssystems wäre die Anzahl der Hops, die ein Paket benötigt, um von Punkt A nach Punkt B zu gelangen. Ein Hop ist definiert als ein Teil des Pfades zwischen Quelle und Ziel, während dessen ein Paket nicht durch ein physikalisches Gerät wie einen Router oder Switch läuft. Beispielsweise könnte ein Paket die gleiche Strecke über zwei verschiedene Wege zurücklegen. Es kann jedoch zwei Sprünge auf dem ersten Pfad im Vergleich zu 3 Sprüngen auf dem zweiten Pfad haben. Unter der Annahme, dass die Ausbreitungsverzögerung gleich ist, führen die Router und Switches jeweils ihre eigene Latenzzeit ein, und in der Regel gilt als Faustregel: Je mehr Hops, desto mehr Latenz kommt hinzu.

Die Latenz der Netzwerkverarbeitung kann auch durch so genannte Microbursts beeinflusst werden. Microbursts sind definiert als ein plötzlicher Anstieg der Datenübertragungsrate, der sich nicht unbedingt auf die durchschnittliche Datenübertragungsrate auswirkt. Da automatisierte Handelssysteme regelbasiert sind, reagieren alle derartigen Systeme auf das gleiche Ereignis auf die gleiche Weise. Infolgedessen können viele teilnehmende Systeme Aufträge senden, die zu einem plötzlichen Datentransferwirbel zwischen den Teilnehmern und dem Ziel führen, der einen Microburst auslöst. Das folgende Diagramm zeigt, was ein Microburst ist.

Die erste Abbildung zeigt eine 1-Sekunden-Ansicht der Datenübertragungsrate. Wir können sehen, dass die durchschnittliche Rate weit unter der verfügbaren Bandbreite von 1 Gbps liegt. Wenn wir jedoch tiefer eintauchen und uns das zweite Bild (die 5-Millisekunden-Ansicht) ansehen, sehen wir, dass die Übertragungsrate mehrmals pro Sekunde über die verfügbare Bandbreite gestiegen ist. Infolgedessen können die Paketpuffer auf dem Netzwerkstapel sowohl in den Netzwerk-Endpunkten als auch in Routern und Switches überlaufen. Um dies zu vermeiden, wird einem automatisierten Handelssystem in der Regel eine Bandbreite zugewiesen, die viel höher ist als die beobachtete Durchschnittsrate.

Serialisierungs-Latenzzeit

Die Serialisierungs-Latenzzeit für ein automatisiertes Handelssystem bezeichnet die Zeit, die benötigt wird, um die Bits auf und von der Leitung zu ziehen.

Eine Paketgröße von 1500 Bytes, die auf einer T1-Leitung (1.544.000 bps) übertragen wird, würde eine Serialisierungsverzögerung von etwa 8 Millisekunden erzeugen. Das gleiche 1500-Byte-Paket mit einem 56K-Modem (57344 bps) würde jedoch 200 Millisekunden dauern. Eine 1G-Ethernet-Leitung würde diese Latenzzeit auf etwa 11 Mikrosekunden reduzieren.

Unterbrechungs-Latenzzeit

Unter Unterbrechungslatenz in einem automatisierten Handelssystem versteht man eine Latenz, die durch Unterbrechungen beim Empfang der Pakete auf einem Server entsteht.

Die Unterbrechungslatenz ist definiert als die Zeit, die zwischen der Erzeugung einer Unterbrechung und der Wartung der Unterbrechungsquelle verstrichen ist. Wann wird ein Interrupt generiert? Unterbrechungen sind Signale an den Prozessor, die von Hardware oder Software ausgesendet werden und anzeigen, dass ein Ereignis sofortige Aufmerksamkeit erfordert. Der Prozessor wiederum antwortet, indem er seine aktuelle Aktivität unterbricht, seinen Zustand speichert und die Unterbrechung bearbeitet. Immer wenn ein Paket auf der Netzwerkkarte empfangen wird, wird ein Interrupt gesendet, um die Bits zu verarbeiten, die in den Empfangspuffer der Netzwerkkarte geladen wurden. Die Zeit, die benötigt wird, um auf diese Unterbrechung zu antworten, wirkt sich nicht nur auf die Verarbeitung der neu ankommenden Nutzlast aus, sondern auch auf die Latenzzeit der bestehenden Prozesse auf dem Prozessor.

Solarflare führte 2011 “OpenOnload” ein, das eine als Kernel-Bypass bekannte Technik implementiert, bei der die Verarbeitung des Pakets nicht dem Betriebssystemkern, sondern dem Userspace selbst überlassen wird. Das gesamte Paket wird von der NIC direkt in den Userspace eingeblendet und dort verarbeitet. Dadurch werden Unterbrechungen vollständig vermieden.

Dadurch wird die Geschwindigkeit der Verarbeitung jedes einzelnen Pakets beschleunigt. Das folgende Diagramm zeigt deutlich die Vorteile der Kernel-Umgehung.

Latenzzeit der Anwendung

Die Antragslatenz für ein automatisiertes Handelssystem bezeichnet die Zeit, die die Bearbeitung des Antrags in Anspruch nimmt.

Diese hängt von den verschiedenen Paketen, der der Anwendungslogik zugeordneten Verarbeitung, der Komplexität der Berechnung, der Effizienz der Programmierung usw. ab. Eine Erhöhung der Anzahl der Prozessoren im System würde im Allgemeinen die Antragslatenz verringern. Dasselbe gilt für die Erhöhung der Taktfrequenz. Viele automatisierte Handelssysteme machen sich den Vorteil zunutze, Prozessorkerne für wesentliche Elemente der Anwendung wie z.B. die Strategielogik zu dedizieren.

Ähnlich verhält es sich, wenn die Programmierung der Strategie in einem automatisierten Handelssystem unter Berücksichtigung der Cache-Größen und der Lokalität des Speicherzugriffs erfolgt ist, dann würde es viele Speicher-Cache-Treffer geben, was zu einer weiteren Reduzierung der Latenz führt. Um dies zu erleichtern, verwenden viele Systeme sehr niedrige Programmiersprachen, um den Code auf die spezifische Architektur der Prozessoren zu optimieren. Einige Firmen sind sogar so weit gegangen, komplexe Berechnungen mit Hilfe von Fully Programmable Gate Arrays (FPGA) auf Hardware zu brennen. Mit zunehmender Komplexität steigen auch die Kosten, und das folgende Diagramm veranschaulicht dies treffend.

Stufen der Raffinesse

Die Welt des hochfrequenten algorithmischen Handels ist in eine Ära intensiven Wettbewerbs eingetreten. Da jeder Teilnehmer neue Methoden anwendet, um den Wettbewerb zu verdrängen, hat sich die Technologie sprunghaft weiterentwickelt. Moderne Algorithmic Trading-Architekturen sind im Vergleich zu ihren Pendants im Frühstadium recht komplex. Dementsprechend ist der Aufbau fortschrittlicher automatisierter Handelssysteme sowohl zeit- als auch kostenintensiver.

Der Aufbau eines gesamten automatisierten Handelssystems kann den Rahmen eines einzelnen Einzelhändlers sprengen. Denn Händler, die die algorithmische Art und Weise des Handels erkunden wollen, können sich für automatisierte Handelssysteme entscheiden, die auf den Märkten auf Abonnementbasis erhältlich sind. Ein Händler kann diese automatisierten Systeme abonnieren und die algorithmischen Handelsstrategien verwenden, die den Benutzern auf diesen Systemen zur Verfügung gestellt werden. Wir haben einige der beliebten automatisierten Handelssysteme in unserem Blog “Top Algo Trading Platforms in India” hervorgehoben. Händler, die sich mit Programmierung auskennen, können ihre Strategien in Programmierplattformen wie Python und R formulieren und rückwärts testen.

Erstellen Sie Ihre eigenen automatisierten Handelssysteme

Anfänger-Händler können lernen, ihre eigenen algorithmischen Handelsstrategien zu entwickeln und auf den Märkten gewinnbringend zu handeln. Die folgenden Schritte können als grobe Richtlinie für den Aufbau einer algorithmischen Handelsstrategie dienen:

Idee oder Strategie-Hypothese – lassen Sie sich eine Handelsidee einfallen, von der Sie glauben, dass sie auf lebendigen Märkten profitabel wäre. Die Idee kann auf Ihren Marktbeobachtungen beruhen oder aus Handelsbüchern, Forschungspapieren, Handelsblogs, Handelsforen oder jeder anderen Quelle entlehnt werden.
Besorgen Sie sich die erforderlichen Daten – Um Ihre Idee zu testen, würden Sie historische Daten benötigen. Sie können diese Daten von Websites wie Google Finance, Yahoo Finance oder von einem bezahlten Datenanbieter beziehen
Schreiben von Strategien – Sobald Sie die Daten haben, können Sie mit der Codierung Ihrer Strategie beginnen, für die Sie Werkzeuge wie Excel, Python oder R-Programmierung verwenden können.
Backtesting Ihrer Strategie – Sobald Sie Ihre Strategie kodiert haben, müssen Sie testen, ob Ihre Handelsidee mit den historischen Daten gute Erträge abwirft. Backtesting würde die Optimierung der Inputs, das Setzen von Gewinnzielen und Stop-Loss, die Positionsgrößenbestimmung usw. beinhalten.
Handel Ihrer Strategie auf Papier – Nach dem Backtesting-Schritt müssen Sie Ihre Strategie zuerst auf Papier handeln. Dies würde bedeuten, Ihre Strategie auf einem Simulator zu testen, der die Marktbedingungen simuliert. Es gibt Broker, die die algorithmische Handelsplattform für den Papierhandel Ihrer Strategie bereitstellen.
Live-Übertragung Ihrer Strategie – Wenn die Strategie nach dem Papierhandel profitabel ist, können Sie Ihre Strategie live übertragen. Sie können ein Konto bei einem geeigneten Broker eröffnen, der die algorithmische Handelsplattform zur Verfügung stellt.

Die Zahl der Börsen, die den algorithmischen Handel sowohl für professionelle als auch für private Händler ermöglichen, wächst von Jahr zu Jahr, und immer mehr Händler wenden sich dem algorithmischen Handel zu.

Schlussfolgerung

Dies war ein detaillierter Beitrag über die Architektur eines automatisierten Handelssystems, der sicherlich ein sehr aufschlussreiches Wissen über die beteiligten Komponenten und auch über die verschiedenen Herausforderungen vermittelt hat, die die Architekturentwickler bewältigen/überwinden müssen, um ein robustes automatisiertes Handelssystem aufzubauen.

Haftungsausschluss: Alle in diesem Artikel enthaltenen Daten und Informationen dienen ausschließlich Informationszwecken. Wir machen keine Zusicherungen hinsichtlich der Genauigkeit, Vollständigkeit, Aktualität, Eignung oder Gültigkeit der Informationen in diesem Artikel und sind nicht haftbar für Fehler, Auslassungen oder Verzögerungen bei diesen Informationen oder für Verluste, Verletzungen oder Schäden, die sich aus der Anzeige oder Verwendung dieser Informationen ergeben. Alle Informationen werden in der vorliegenden Form zur Verfügung gestellt.

Ähnliche Artikel zu "Automatisierte Handelssysteme: Architektur, Protokolle, Arten von Latenzzeiten":

Wenn Du noch Fragen zum Thema Automatisierte Handelssysteme: Architektur, Protokolle, Arten von Latenzzeiten hast, dann schreib einfach einen Kommentar - oder schau dir meine Buchtipps an:

Comments are closed.