- Fallstudie eines persönlichen Projekts: ein in Go gebauter Retail-Trading-Bot, der mehr als 5.500 Aktien an NYSE und NASDAQ in Echtzeit überwacht und automatisiert handelt
- Anfangs machte er schnell Verluste, entwickelte sich aber über Jahre des Ausprobierens und Lernens bis auf Break-even-Niveau und erzielt inzwischen gelegentlich Gewinne
- Besteht aus drei Kernkomponenten: Datenanbieter, Go-Anwendung und Broker; verarbeitet zur Markteröffnung und zum Marktschluss mehr als 60.000 Events pro Sekunde im Speicher
- Zentrale Erkenntnisse aus der Praxis: Systemtests über Zufallskäufe, eigene Candlestick-Erzeugung auf Basis von Tick-Bars, Umstellung auf In-Memory-Verarbeitung und mehr
- Zeigt die praktische Komplexität und die Möglichkeiten beim Aufbau einer persönlichen Trading-Plattform an der Schnittstelle von Finanzen, Programmierung und Datenanalyse
Projekthintergrund und Motivation
- Ausgangspunkt war eine Trendfolge-Idee: rund 500 kurzfristige Trades im gesamten Aktienmarkt automatisch ausführen und verwalten und aus jedem Trade kleine Gewinne mitnehmen
- Die Automatisierung begann wegen der Grenzen des manuellen Tradings
- Das Risiko, das gesamte Kapital in eine einzelne Aktie zu investieren, war extrem hoch; gleichzeitig liegen Dutzende kurzfristige Wetten parallel zu überwachen außerhalb menschlicher Fähigkeiten
- Schneller Ein- und Ausstieg war nur bei hochliquiden Aktien möglich, und für eine schnelle Ausführung mussten kleine Mengen gekauft werden
- Auch das Positionsmanagement war eine große Herausforderung: Bei mehr als 25 parallelen Wetten den richtigen Zeitpunkt für Ein- und Ausstieg zu treffen, ist sehr komplex
- Mit wachsendem Kapital muss auch die Zahl der Wetten steigen — ein Skalierbarkeitsproblem
- Es bestand die Notwendigkeit, Handelskosten wie Spread, Gebühren, Slippage, API-Gebühren und Steuern schnell zu berechnen, um die Sinnhaftigkeit eines Trades zu beurteilen
Lösungsarchitektur
- Über mehrere Jahre wurde ein automatisiertes Tool entwickelt, das mehr als 5.500 Aktien an NYSE und NASDAQ in Echtzeit überwacht und schnelle Trading-Entscheidungen trifft
- Läuft auf einem leistungsstarken Gaming-System unter Linux: 16 Kerne, 128 GB RAM, 8 TB NVMe-Speicher, 1-Gbps-Internet
-
Drei Kernkomponenten
- Data Provider (Massive.com): Deckt historische und Echtzeitdaten des gesamten Markts ab und bietet eine entwicklerfreundliche, intuitive API samt Dokumentation. Einfaches Preismodell mit Zugriff auf alle Marktdaten ohne künstliche Einschränkungen
- Go-Anwendung: Die zentrale Engine, die Datenfeeds sammelt und interpretiert, berechnete Trading-Entscheidungen trifft und Kauf- bzw. Verkaufsorders an die Broker-API sendet
- Broker (Interactive Brokers): Stellt eine einfache API bereit und übernimmt die Orderausführung
-
Warum Go gewählt wurde
- Die Hedgefonds-Branche setzt zwar auf C++ und Python, doch nach jahrelanger Nutzung von Go zeigte sich dessen hervorragende Eignung für Datenstream-Verarbeitung und API-Integration
Hauptfunktionen der Go-Anwendung
-
Data Ingestion Loop
- Sammelt über Massive.com kontinuierlich Echtzeitdaten von mehr als 5.500 Aktien
- Anfangs wurde versucht, die Daten in einer Datenbank zu speichern; da diese zur Markteröffnung und zum Marktschluss mehr als 60.000 Events pro Sekunde nicht bewältigen konnte, wurde vollständig auf In-Memory-Verarbeitung umgestellt
-
Build Our View Of The Stock Market
- Baut aus den gesammelten Daten eine Echtzeit-In-Memory-Ansicht des gesamten Markts auf, einschließlich Preis, Spread und Handelsaktivität
- Ermöglicht, Chancen vor den großen Nachrichtenmedien zu erkennen und zu handeln
- Zugriff auf Handelsaktivitäten im Pre-Market, regulären Handel und After-Hours-Handel
-
BUY Signal Loop
- Sendet bei erkannten Chancen Kauforder-Anfragen an die Broker-API
- Führt keine einfachen Trigger aus, sondern berechnet vorab unter anderem spreadbasierte Gewinnschätzungen, die benötigte Aktienzahl sowie Gebühren und Steuern
- Enthält Logik für Situationen wie Kursbewegungen, Teilausführungen und Orderstornierungen
-
Position Tracking System
- Ein Loop zur kontinuierlichen Überwachung gehaltener Positionen, der Positionstabelle und aktuelle Preise in Echtzeit vergleicht, um Gewinn und Verlust zu verfolgen
- Über die GUI lassen sich der Auslöser eines Trades, der aktuelle Status und der Verkaufszeitpunkt prüfen
- Spielt eine zentrale Rolle bei der Verfeinerung der BUY- und SELL-Logik
-
SELL Signal Loop
- Führt bei Erkennung guter Gewinne oder übermäßiger Verluste Verkaufsorders über die Broker-API aus
- Enthält komplexe Logik wie Preis-Updates schnell bewegter Aktien und Verarbeitung von Teilausführungen
Webinterface und Screenshots
- Über ein eingebautes Webinterface lassen sich alle Datenstrukturen durchsuchen, Daten visualisieren sowie Trade-Auslöser und aktueller Status prüfen
- Ansicht einer Gesamtmarktübersicht mit Preisen, Spreads usw. von mehr als 5.500 Tickersymbolen
- Einzelne Symbolseiten, etwa für Tesla TSLA, zeigen Tick-Bars und zugehörige Informationen
- Interface mit Gewinn-/Verlustquote und aktuell offenen Positionen; in einer Beispielsitzung wurden rund -900 US-Dollar Verlust verzeichnet
- Ansicht mit Metadaten und Charts von Echtzeit-Trades, bei der Kaufpunkte als orangefarbene Linie markiert sind
- Konsolenlog-Ansicht, die Echtzeit-Events wie Kauf- und Verkaufsorders protokolliert
Strategieentwicklung und Backtesting
- Go-Anwendung, Strategie und Backtesting werden als drei getrennte Kernelemente betrachtet
- Die meisten Diskussionen konzentrieren sich zwar auf Strategien wie Mean Reversion, Trendfolge oder lineare Regression sowie auf Backtesting, doch die praktische Umsetzung und Logistik von Strategien im Echtzeit-Intraday-Trading werden häufig übersehen
- Mit den umfangreichen historischen Trade- und Quote-Daten von Massive.com wurden Strategien in Python exploriert und Backtests durchgeführt — der Grund für den 8-TB-NVMe-Speicher
- Backtesting wird zwar mit „Vorwärtsfahren mit Blick in den Rückspiegel“ verglichen, ist aber ein wertvolles Validierungswerkzeug als Entscheidungsgrundlage für Spread, Steuern, Gebühren sowie Ein- und Ausstiegspunkte
- Erkenntnisse aus Strategieentwicklung und Backtesting werden in die Logik des BUY Signal Loop überführt
Codebeispiele
- Enthält High-Level-Pseudocode und echte Go-Codebeispiele; die tatsächliche App umfasst rund 7.000 Zeilen
- Zentrale Datenstrukturen: TrackedSymbols (globale Symbol-Map, Flag für aktiven Handel, globaler Lock), Symbol (Rohdaten zu Trades und Quotes, Aggregate, Position usw.), TradeEvent, QuoteEvent, Aggregate, Position
- Struktur des Main-Loops
- Erfasst Trade- und Quote-Daten über eine WebSocket-Verbindung und parst Events
- Speichert sie in der Symbol-Map und führt Trade- und Quote-Daten zu Aggregates zusammen
- Leitet Signale über Go-Channels an die Kauf- und Verkaufslogik weiter
- Stellt über einen HTTP-Server Funktionen zum Abruf aller Symbole, Positionen und benutzerdefinierter Watchlists bereit
Zentrale Erkenntnisse (Lessons Learned)
-
Abstraktionen verstehen
- NYSE und NASDAQ sind kein einzelnes System, sondern ein großes verteiltes System aus mehr als 19 Börsen
- Candlestick-Daten sind eine massive Abstraktion, die aus Rohdaten einzelner Trades bzw. Ticks erzeugt wird; ein tiefes Verständnis davon ist unerlässlich
- Je nach Handelsphase — Pre-Market, regulärer Handel, After-Hours — gelten unterschiedliche Regeln
-
Ordermanagement
- Erfolgreiches Trading beruht nicht nur auf dem Senden einfacher Kauf- und Verkaufsorders, sondern auf vorab berechnetem Position Sizing, der Fähigkeit zu schnellem Handel, parallelem Management von mehr als 25 Positionen, Berechnung von Steuern und Gebühren, Slippage-Management und Überwachung des Orderstatus
-
Edge Cases
- Es gibt zahlreiche Edge Cases rund um Orderausführung, Tracking, Änderung, Stornierung, Teilausführungen und Handelsaussetzungen; werden sie übersehen, entstehen finanzielle Verluste
- Tests mit Paper Trading bzw. Simulation statt echtem Kapital sind unerlässlich
- In einem Fall wurde eine Aktie, die im Pre-Market um 40 % gestiegen war, am Hoch gekauft und stürzte anschließend ab; wegen fehlgeschlagener Anpassung der Verkaufsorder entstand innerhalb weniger Minuten ein Verlust von 40 %. Im Pre-Market und After-Hours-Handel gelten andere Regeln als im regulären Markt, sodass extreme Bewegungen sehr schnell auftreten können
-
Zufallskäufe nutzen
- Wichtiger als das Entdecken einer geheimen Strategie ist das Testen der Kernfunktionen des Systems
- Führt man eine Woche lang täglich 1.000 Käufe zufälliger Aktien aus, lassen sich Kauf- und Verkaufslogik, Management von Teilausführungen, Stornierungslogik und Positions-Tracking-System effektiv validieren
- Die Integration von Zufallskäufen als Testprozess in ein Paper-Trading-Konto ist eine effiziente Methode, mehrere Systemaspekte gleichzeitig zu überprüfen
-
Tick-Bars vs. Time-Bars
- Vom Broker bereitgestellte Candlestick-Bars decken feste Zeitfenster ab, etwa 30 Sekunden; bei abrupten Marktbewegungen können im selben Zeitraum jedoch 100 und mehrere Tausend Trades nebeneinander auftreten
- Auf Basis roher Tick- und Quote-Daten wurden eigene Bars nach Anzahl der Trades gebaut; sie liefern in hochaktiven Phasen wie Markteröffnung und -schluss deutlich höhere Auflösung und ermöglichen zusätzliche Custom-Metriken wie Spreads
-
Umstellung auf In-Memory
- Der anfängliche Datenbankansatz konnte die massiven Aktivitätsspitzen zur Markteröffnung und zum Marktschluss nicht bewältigen
- Die Umstellung auf einen vollständig In-Memory-basierten Ansatz mit großen Maps und Mutex-Locks löste das Skalierbarkeitsproblem
- Die Struktur mit allen Daten wird zur Speicherung als komprimierte gob-Datei gedumpt und kann beim Neustart erneut geladen werden. Sie wächst im Tagesverlauf auf mehr als 40 GB; um gob-Dumps dieser Größe zu unterstützen, war ein Patch des Go-Builds nötig
- Nach der Erfahrung, durch einen Stromausfall im Live-Betrieb den gesamten Zustandsdatensatz zu verlieren, wurde eine unterbrechungsfreie Stromversorgung (USV) unverzichtbar
-
Komplexität und Einsamkeit
- Das Projekt erwies sich als weit anspruchsvoller und zeitaufwendiger als erwartet und entwickelte sich von einem kleinen Hobby zu einer ernsthaften Obsession
- Am Ende zählt nur, den Kontostand zu erhöhen; das kann einsam sein und geht mit einer extremen emotionalen Achterbahnfahrt einher
-
Go und Python kombinieren
- Das Trading-System ist in Go geschrieben, während für die Datenerkundung ein hybrider Ansatz mit Pythons breitem Ökosystem an Data-Science-Bibliotheken genutzt wird
-
Nutzung eines privaten PCs
- Moderne Desktop-PCs sind bei ausreichender Optimierung leistungsstark genug, um den gesamten Aktienmarkt in Echtzeit zu überwachen
-
ChatGPT nutzen
- Statt wie früher bei unbekannten Problemen nur auf Suche und Lektüre zu setzen, wurde auf einen Ansatz umgestellt, bei dem Probleme ChatGPT erklärt, Lösungswege erfragt und sogar Codegenerierung angefordert werden; subjektiv führte das zu einer dreifachen Produktivitätssteigerung
Erfahrungen mit Marktereignissen
- Verschiedene Marktanomalien wie Meme-Stock-Ereignisse, große IPO-Events, Marktbooms und -crashs sowie Fed-Nachrichten und Zinserhöhungen konnten mit dem eigenen System erkannt und vor den Nachrichten nachvollzogen werden
- Eine Erfahrung wie ein Platz in der ersten Reihe, während sich Marktereignisse direkt vor den eigenen Augen entfalten
1 Kommentare
Hacker-News-Kommentare
Ich habe eine Zeit lang im HFT gearbeitet, und ich fand das ganze Feld wirklich faszinierend; schön zu hören, dass der Autor des Originals offenbar ähnlich viel Spaß daran hatte.
Dass die Plattform selbst in Diskussionen oft untergeht, liegt daran, dass Trading ein Bereich ist, in dem Hochtechnologie, Komplexität, starke Regulierung und extremer Wettbewerb aufeinandertreffen.
Ein Order-Entry-System, ein Risikomanagementsystem und ein System zur Positionsverfolgung zu bauen, ist an sich schon eine große Leistung, aber aus Sicht einer Trading-Firma ist das fast schon nur der Eintrittspreis.
Deshalb reden die Leute über Strategien: Die Basisplattform ist vorhanden, jetzt geht es darum, herauszufinden, wie man damit Geld verdient.
Außerdem spielen die Marktteilnehmer nicht einmal dasselbe Spiel. Im HFT konkurrierten wir um Alphas von wenigen Sekunden, indem wir auf FPGAs Nanosekunden herauspressten und im Funknetz von New Jersey Mikrosekunden einsparten; eine Bank dagegen interessiert sich mehr für Wahlen und Geopolitik als für das Wetter in Carteret. Wenn es regnet, funktioniert an dem Tag das Mikrowellennetz nicht.
Dazwischen gibt es unzählige Strategien, die auf Alphas von einigen Stunden bis zu einigen Wochen zielen, sodass es schwierig ist, in öffentlichen Foren überhaupt dieselbe Sprache zu sprechen. Trotzdem ist es eine spannende Welt, die ich manchmal vermisse.
Strategie hingegen ist ein Bereich, in dem Entdeckung nötig ist. Es gibt ein paar bekannte Strategien, die immer noch profitabel sind, aber die haben sich im Großen und Ganzen die größten Firmen gesichert; der Rest ist ein Suchprozess. Manche Strategien werfen nur in sehr kurzen Marktphasen Gewinn ab.
Ich vermisse es auch manchmal, aber es ist inzwischen so stark konsolidiert, dass es größtenteils eine Welt großer Firmen geworden ist.
Der Großteil dieses Wissens scheint innerhalb der einzelnen Firmen siloartig abgeschottet zu sein und wird nach außen nicht diskutiert.
HFT spielt ein völlig anderes Spiel. Ich habe mich in Börsenarchitekturen und die tatsächliche Verkabelung eingelesen: Während ich Daten über SIP bekomme, ist HFT direkt mit der Börse verbunden [1].
Ich handle im Sekundentakt, HFT dagegen, wie gesagt, im Mikrosekundentakt – das ist nicht vergleichbar. In gewisser Weise ist es sogar gut, dass ich nicht direkt mit ihnen konkurriere. Oder vielleicht konkurriere ich doch, kann aber trotzdem noch ein bisschen Geld verdienen.
[1] https://www.researchgate.net/figure/Latencies-in-the-Electro...
Im Grunde frage ich mich, ob es einfach darum geht, Mid-Frequency-Trading schneller zu machen, oder ob es konkrete Vorteile gibt, etwa Priorität in der Order-Warteschlange zu bekommen.
Wenn es Fragen zu diesem Projekt gibt, kann ich sie beantworten. Es begann als Nebenprojekt und wurde dann zu einer kompletten Obsession.
Am System selbst ist nicht viel Geheimnisvolles; der Kern liegt darin, eine solide Plattform zu haben, in die man Strategien einstecken kann.
Vielleicht veröffentliche ich es irgendwann als Open Source, aber dafür müsste ich zuerst all die Hacks aufräumen, die ich eingebaut habe.
Tech Trader wird als vollautonomes Trading-System beschrieben, das seit über zehn Jahren im Live-Trading läuft, ohne menschliches Eingreifen oder Updates.
Der Unterschied zu traditionellen algorithmischen Systemen sei, dass es nicht quantitativ, statistisch-arbitragebasiert oder hochfrequent arbeite, sondern so „schaue“, wie ein Mensch auf Aktien schaut, dabei aber die kalte Disziplin und grenzenlose Aufmerksamkeit einer Maschine nutze.
Seit dem Start im Dezember 2012 handele es vollautomatisch mit echtem Kapital; gebaut worden sei es angeblich von einem einzelnen autodidaktischen Entwickler, der den Gaming-Nickname pftq verwendet.
Mich würde interessieren, ob du deinen Ansatz teilen kannst, wie man verschiedene Strategien einsteckt. Ein pluginartiges Strategiesystem kann sich über mehrere Ebenen erstrecken und wird schnell knifflig.
Mich interessiert auch, ob du beim Backtesting sämtliche Orderbuch- und Tick-Daten speicherst und wieder abspielst oder nur historische aggregierte Daten verwendest.
Nach dem Artikel dachte ich darüber nach, eine WebSocket-Konfiguration mit Polygon aufzusetzen, sah dann aber, dass das erste Paket mit WebSocket-Funktion 29 Dollar kostet und das Advanced-Paket mit Echtzeitdaten 200 Dollar pro Monat.
Echtzeitdaten mit unbegrenzten API-Aufrufen klingen ziemlich gut, aber meine Strategie kommt bei normalen Kapitalgrößen auf eine Trefferquote von höchstens etwa 78 %, sodass 200 Dollar im Monat schwer zu rechtfertigen wären.
Ich würde gern wissen, welches Paket du nutzt und welche Vor- und Nachteile es hat. Falls du lieber per E-Mail antworten möchtest: Sie steht in meinem Profil.
Ich weiß nicht, ob IB den Preisfeed in Echtzeit sendet. Die TWS-Oberfläche aktualisiert sich ständig, also scheint sie die Daten in Echtzeit zu liefern; mich würde interessieren, ob auch das Orderbuch per API verfügbar ist.
Mir ist klar, dass dieser Artikel im polygon.io-Blog erschienen ist, aber ich frage mich, ob die Architektur auch nur mit der IB/TWS API funktionieren könnte.
Eines der am häufigsten missverstandenen Konzepte im algorithmischen Trading ist, dass Geschwindigkeit in den meisten Systemen nicht der entscheidende Faktor ist.
Ein Modell wie mein System https://grizzlybulls.com/models/vix-ta-macro-mp-extreme hat den Markt im Live-Handel über mehr als drei Jahre deutlich geschlagen, handelt aber im Schnitt nur etwa einmal alle 18 Handelstage und erzeugt Signale nur in der Nähe stündlicher Wendepunkte.
Die letzten 18 Monate waren wegen der großen strukturellen Veränderung durch hohe Inflation und schnell steigende Zinsen schwächer als die Anfangsphase, aber seit dem Start der Website im Januar 2022 erzielte es +14,11 % Rendite, während der SPX bei -7,83 % lag.
Das gelang ohne Leverage, und der maximale Drawdown im selben Zeitraum war mit -16,48 % ebenfalls niedriger als die -27,57 % des SPX.
Die Darstellung ist so aufgebaut, dass es aussieht, als hätte das Modell den Markt tatsächlich deutlich geschlagen. Wenn du wirklich eine unerschlossene Goldgrube hast, wäre das großartig, aber persönlich fällt es mir wegen einiger Warnsignale schwer, das zu glauben.
Wenn man sich für algorithmisches Trading interessiert, lohnt sich ein Blick auf Collective2. Dort bieten Engineers Kauf- und Verkaufssignale gegen eine Abo-Gebühr an.
Es fühlt sich ein bisschen wie die Minor League des algorithmischen Tradings an und ist ziemlich interessant.
Da das System Gewinne und Verluste verfolgt, ist es schwer, Performance-Berichte zu fälschen, und wenn man Collective2 Zugriff auf ein Interactive-Brokers-Konto erlaubt, kann es die Handelssignale auch ausführen.
Den Dienst gibt es seit mindestens zehn Jahren, daher kann man auch langfristige Performance sehen, aber die meisten Systeme halten nicht so lange durch.
https://collective2.com/leader-board
Auch die aktuellen Spitzenreiter sind kaum lange dabei, meist nur etwa ein bis zwei Jahre. Das zeigt, dass das Alpha bei den meisten Systemen ziemlich schnell verschwindet.
Auch die Ertragskurven sind unruhig, und einige wenige Trades machen den Großteil der Gewinne aus.
Bei der Entwicklung automatisierter Trading-Systeme sind die wichtigen Achsen Datenfeeds und Erfassung, Feature-Erzeugung, Signalerzeugung, tatsächlicher Handel sowie Order-Management und die gesamte Orchestrierung.
Rohdaten werden selten direkt für Entscheidungen verwendet, und gute Feature-Erzeugung ist oft ein Hauptfaktor für Erfolg. Gleitende Durchschnitte sind ein Beispiel, aber heutzutage kommt man damit allein kaum noch weit.
Der Artikel zeigt die technischen Aspekte der Datenverarbeitung und des Order-Managements sowie die gesamte Pipeline, aber ich hätte mir mehr Details zur Skalierung der Lösung und zur asynchronen Implementierung gewünscht.
Gerade weil Go verwendet wird, gibt es dafür passende Channel-Strukturen, daher hätte mich das besonders interessiert.
Ich verstehe, dass das nicht der Fokus des Artikels ist, aber allgemeine Informationen zur Trading-Logik, dazu, wie man neue Strategien einsteckt, und wie man bestehende Strategien parametrisiert, wären ebenfalls hilfreich gewesen.
Die Links am Ende waren interessant, und da ich einen intelligenten Trading-Bot auf Basis von Machine Learning und Feature Engineering entwickle (https://github.com/asavinov/intelligent-trading-bot), können solche Artikel wichtig sein.
Die Struktur ist schlicht: goroutines und channels kommunizieren miteinander, und alles wird mit einem großen Mutex gesperrt.
Wenn neue Daten hereinkommen, werden die benötigten Aggregatwerte erstellt, also tickbasierte Candlesticks, und diese Daten triggern die BUY-Logikschleife. Wenn etwas erkannt wird, wird eine Order über die IB API ausgelöst.
Es ist sehr einfach und nichts Komplexes. Ich habe zeitweise mehr als 100 Positionen gleichzeitig verfolgt, und es lief einfach gut, daher habe ich an komplexer asynchroner Logik nicht viel herumgeschraubt.
Die Parameter sind tatsächlich direkt in der BUY-Schleife hardcodiert. Das mag seltsam klingen, aber in einem kleinen Setup ändern sie sich nicht so häufig.
Ich lasse ein paar Trades laufen, passe Werte an, starte neu und teste wieder. In einer Enterprise-Umgebung gäbe es vielleicht eine formale Sprache oder Hot Loading, aber in meinem Fall funktioniert Hardcoding völlig ausreichend.
Go selbst – oder irgendeine andere Sprache – bringt keinen großen Vorteil. Den Vorteil bringt der Trading-Algorithmus, und der ist immer schwer zu finden.
Ich habe monatelang die optimalen Parameter gesucht, aber am Ende funktionierten sie nur auf historischen Daten; in der Praxis war es völlig anders.
Wenn Algorithmus und Strategie perfekt sind, kann selbst Visual Basic besser sein als Go, Rust oder jede andere Sprache. Die Sprache ist nur ein Werkzeug.
Dass Go verwendet wurde, ist gut, aber der Titel kann etwas irreführend sein. Leute könnten es als eine Art Vorteil auffassen, was es nicht ist.
Und für HFT halte ich Sprachen mit Garbage Collector nicht für eine gute Wahl.
Solche Logik, also eine Strategie, manuell zu entwickeln, ist natürlich schwierig; deshalb habe ich einen intelligenten Trading-Bot gebaut, der Handelsstrategien aus historischen Daten ableitet.
https://github.com/asavinov/intelligent-trading-bot
Derzeit funktioniert er mit Kryptowährungen, lässt sich aber auch auf andere Märkte anwenden.
https://t.me/intelligent_trading_signals
Dass etwas nur auf historischen Daten gut funktioniert und sich in der Realität anders verhält, ist eine typische Situation. Entscheidend ist, Strategien zu entwickeln, die auch auf künftigen, ungesehenen Daten funktionieren.
Auch der Backtesting-Algorithmus muss so gestaltet sein, dass keine zukünftigen Daten in die Vergangenheit durchsickern.
In der Branche werden C++ und Python häufig genutzt, daher kann die Verwendung von Go eher ein Nachteil sein, aber es war eben die Sprache, die ich beherrsche.
Es war nicht meine Absicht, einen falschen Eindruck zu erwecken. Go eignet sich ziemlich gut dafür, Daten entgegenzunehmen, zu verarbeiten und entfernte APIs aufzurufen, und funktioniert in der Praxis gut.
Wenn man darauf allerdings eine Jobsuche aufbauen will, wird es vermutlich nicht besonders helfen.
Es gibt Firmen, die Java verwenden und beim Start den gesamten benötigten Speicher vorab allokieren. Jane Street ist außerdem dafür bekannt, OCaml zu nutzen.
Damit ist die Performance ziemlich gut, und man muss sich keine Sorgen um Speicherfehler machen.
Wenn man eine Weile mit historischen Daten experimentiert hat, nimmt der Nutzen dieser Daten ab.
Ich baue Bots in TypeScript, weil ich die Sprache kenne, und in Python, weil es viele Tools gibt.
Es ist extrem überwältigend und eine einsame Arbeit. Andere Projekte habe ich immer im Team gemacht; selbst wenn das Team sehr klein und die Arbeit autonom war, gab es gelegentlich Meetings und Stand-ups.
Daran arbeite ich jetzt seit sechs Monaten allein, und ich habe überlegt, einen Freund dazuzuholen, nur um nicht allein zu sein.
Da es ein Nebenprojekt ist, komme ich vielleicht nicht besonders weit, aber ich bin jederzeit offen für einen Austausch.
Der einzige Weg, der mir einfällt, ist, an Daten zu kommen, die sie nicht haben.
Ich halte diesen Beitrag für völlig belanglos und klickheischend. Zusammengefasst: „Für Marktdaten kann man polygon.io nutzen, aber Algorithmic Trading ist ohnehin schwierig, daher gibt es noch nicht viel zu teilen.“
Persönlich wollte ich die High-Level-Struktur beim Aufbau eines eigenen Systems teilen. Als ich in dieses Rabbit Hole geraten bin, hätte ich mir gewünscht, es hätte so einen Beitrag gegeben.
Wenn du mir sagst, was zusätzlich enthalten sein sollte, damit er besser wird, nehme ich das gern auf.
Es ist gut, Leute zu finden, die den reinen Feedback-Loop aus Code, Strategie und Geld schätzen, den Trading bietet.
Ich habe Timing und Korrelationen zwischen Aktien und Indizes als Alpha-Quelle untersucht und damit gewisse Erfolge erzielt.
Jetzt versuche ich, diesen Prozess zu automatisieren, und ich genieße die Arbeit daran wirklich.
Ich versuche nicht, als Market Maker aufzutreten, und ich will auch nicht ständig zwischen Titeln hin- und herspringen. Ich konzentriere mich darauf, ein präzises Modell zu verfeinern, mit dem sich einige wenige Aktien sehr gut monetarisieren lassen.
Zu den nützlichen Werkzeugen gehören TradingView und Pinescript-Indikatoren/-Strategien, Excel-Modelle mit exportierten Daten fürs Backtesting, Python und Go für Machine Learning im Backend sowie ChatGPT, um neue Code-Iterationen zu beschleunigen.
Bei Interesse würde ich mich gern unter trading @ dianazink.com austauschen.
Guter Beitrag; die konkreten Erklärungen und besonders die Screenshots haben mir gefallen.
Ich verstehe, dass du die Strategie nicht im Detail offenlegst, aber ich frage mich, ob du sagen kannst, ob die Trades vollständig auf technischer Analyse basieren oder ob du externe Daten bzw. alternative Datenfeeds nutzt.
Anders gesagt: Ist es ein weitgehend geschlossenes System mit Polygon als Input und der IB API als Output, oder umfasst es eine breitere Architektur mit eigenen Datenfeeds wie News-Websites, Twitter oder Reddit?
Falls Letzteres zutrifft, würde mich auch interessieren, wie du das beim historischen Backtesting ausbalancierst, wenn einige Datenquellen in der Vergangenheit nur teilweise abgedeckt sind.
In letzter Zeit schaue ich mir an, wie man mit Lookup-Tabellen vorab berechneter historischer Werte Anomalien erkennen kann, etwa: „Ist diese Aktivität bei dieser Aktie normal?“
Das heutige BXRX ist ein gutes Beispiel [1].
Ich schaue mir außerdem die Handelsaktivität bei Optionen an und versuche herauszufinden, ob sie als Signal nutzbar ist.
[1] https://www.google.com/search?q=BXRX