Fino ad oggi su DataTrading abbiamo considerato due principali motori di backtesting quantitativo e di trading live. Il primo è derivato dalla serie Backtesting Event-Drive. Il secondo è un motore di trading live e backtesting sul Forex, DTForex, che si collega all’API del broker OANDA.
In questo articolo introduciamo una versione più “aggiornata” della serie di backtesting guidata dagli eventi e/o del “DTForex” che funzioni su altre classi di asset. La funzionalità principale che vogliamo introdurre è il collegamento con Interactive Brokers. E’ quindi arrivato il momento di aggiornare l’infrastruttura di trading che utilizziamo.
Per questi motivi abbiamo deciso di scrivere una nuova serie di articoli su come progettare e costruire un’infrastruttura end-to-end che implementi un portafoglio completo e un sistema di gestione degli ordini, compreso un ambiente di backtesting/ricerca, la possibilità di deploy su server remoti ed esecuzione algoritmica. Inoltre il sistema dovrà essere multi-asset, ma è generalmente preferibile iniziare con un singola asset class per ridurre al minimo l’eccessiva capacità di configurazione.
Inizieremo con le azioni / ETF statunitensi scambiati con Interactive Brokers, con frequenza giornaliera, poiché questa è spesso la richiesta più popolare.
In particolare, il risultato di questa serie di articoli sarà la mia nuova infrastruttura di trading personale, e del progetto DataTrading, quindi avrò molto interesse personale nell’assicurarmi che sia robusta, affidabile e altamente efficiente! Documenterò il processo in modo “end-to-end” in modo che sia possibile replicare completamente i risultati.
In questo modo qualsiasi articolo futuro di questo sito che discuta le prestazioni di una strategia di trading sarà basato su questa libreria, consentendo a chiunque di replicare completamente i risultati purché si utilizzi:
- a) gli stessi identici dati storici elaborati
- b) un insieme identico di seed casuali a qualsiasi modello stocastico utilizzato all’interno del codice.
Ovviamente vedremo come assicurarci che questi due criteri siano soddisfatti!
Anche in questo caso, come in precedenza, renderò disponibile il software su GitHub con una licenza open source in stile MIT open source, insieme a tutti gli script e ai file di configurazione. In questo modo sarà possibile progettare il vostro sistema usando il mio come modello, o di iniziare a sviluppare strategie sapendo che avrete una solida libreria che farà il “lavoro sporco” per voi.
Considerazioni sul Design del Sistema
L’obiettivo finale di questo progetto è costruire un portafoglio e un sistema di gestione degli ordini completamente open source, ma di livello professionale, pronto per la produzione, con livelli di gestione del rischio tra le posizioni, i portafogli e l’infrastruttura nel suo insieme.
Sarà automatizzato end-to-end, il che significa che è necessario un intervento umano minimo affinché il sistema possa operare una volta impostato “live”. È impossibile eliminare completamente l’intervento umano, soprattutto quando si tratta di input di qualità dei dati (ad esempio in caso di tick errati), ma è certamente possibile prevedere che il sistema funzioni in modo automatizzato per la maggior parte del tempo.
Considerazioni sul Trading Algoritmico
Il sistema rispecchierà l’infrastruttura che potrebbe essere trovata in un software commerciale o nei sistemi utilizzati da piccolo fondo quantistico o dal team quantistico di un trading desk. Sarà altamente modulare e liberamente configurabile. I componenti principali sono l’archivio dati (l’anagrafica dei titoli), il generatore di segnali, sistema di gestione portafoglio / ordini, il livello di rischio e l’interfaccia verso i broker.
Come descritto negli articoli precedenti, questi componenti tendono a sovrapporsi ed essere accorpati, ma di seguito è riportato un elenco di componenti di “livello istituzionale” attorno ai quali desideriamo costruire il sistema:
- Integrazione con il fornitore di dati : il primo componente fondamentale prevede l’interazione con uno o più fornitori di dati, solitamente tramite una qualche forma di API. Il sistema supporterà inizialmente l’acquisizione dei dati tramite Quandl , DTN IQFeed e Interactive Brokers.
- Importazione e pulizia dei dati: tra l’archiviazione e il download dei dati è necessario un livello di filtraggio / pulizia che memorizzerà i dati solo se superano determinati controlli. Contrassegnerà i dati “cattivi” e attiva notifiche se i dati non sono disponibili.
- Memorizzazione dei dati sui prezzi : è necessario creare un database principale dei prezzi intraday, archiviando i simboli e i valori dei prezzi ottenuti da un broker o un fornitore di dati.
- Memorizzazione dei dati di trading – Tutti gli ordini, le operazioni e gli stati del portafoglio devono essere archiviati nel tempo. A questo scopo si prevede di usare una forma di serializzazione / persistenza degli oggetti, come la libreria pickle di Python .
- Archiviazione dei dati di configurazione : è necessario memorizzare in un database le informazioni di configurazione dipendenti dal tempo con un riferimento storico, in formato tabulare o, ancora una volta, in formato pickle.
- Ambiente di ricerca / backtesting – il sistema deve prevede un ambiente di ricerca / backtesting collegato al database dei prezzi e utilizzerà una logica avanzata per simulare il flusso di esecuzione degli ordini a mercato e quindi generare backtest realistici.
- Generazione dei segnali – Abbiamo già descritto gli approcci principali al machine learning, all’analisi di serie temporali e alle statistiche bayesiane. Possiamo implementare queste tecniche per generare i segnali e produrre raccomandazioni di trading per il gestore del portafoglio.
- Portfolio / Order Management – Il “cuore” del sistema è il portfolio e il sistema di gestione degli ordini (OMS) che riceve i segnali del generatore e li utilizza come “raccomandazioni” per la costruzione degli ordini. L’OMS comunica direttamente con la componente di gestione del rischio per determinare come devono essere costruiti questi ordini.
- Gestione del rischio – Il gestore del rischio fornisce un meccanismo di “veto” o di modifica per l’OMS, in modo da considerare/includere i specifici pesi settoriali, i vincoli di leva finanziaria, la disponibilità di margine del broker e i limiti di volume medio giornaliero. Il livello di rischio prevede anche la gestione della “copertura ombrello”, fornendo al portafoglio la capacità di copertura a livello di mercato o di settore.
- Interfaccia al broker: l’interfaccia consiste nel codice di connessione verso le API di un broker (in questo caso Interactive Brokers) e nell’implementazione di più tipi di ordine come market, limit, stop, ecc.
- Esecuzione algoritmica : implementa e utilizza algoritmi di esecuzione automatizzata al fine di mitigare gli effetti dell’impatto sul mercato.
- Performance e P&L – L’analisi delle performance è fondamentalmente per rispondere alla domanda “Quanto ho guadagnato?”. In realtà non è una domanda così semplice a cui rispondere! Descriveremo in modo approfondito come contabilizzare correttamente il PnL in un sistema di trading professionale.
Considerazioni sullo Sviluppo del Software
L’obbiettivo di questo sistema, a differenza della maggior parte dei sistemi di algotrading “retails”, è prestare la massima attenzione ad aspetti di solito trascurati, come l’alta disponibilità, la ridondanza, il monitoraggio, la rendicontazione, la contabilità, la qualità dei dati e la gestione del rischio all’interno del sistema. In questo modo si può creare un sistema che prevede un significativo grado di affidabilità nel processo di automazione, consentendo (eventualmente) di concentrarci sull’ottimizzazione della generazione del segnale e della gestione del portafoglio.
I seguenti concetti, la maggior parte dei quali sono presi dal settore dell’ingegneria del software professionale, forniranno la base del progetto:
- Pianificazione automatizzata delle attività: si prevede un robusto software di pianificazione automatizzata delle attività, come la gestione dei cron jobs, al fine di garantire l’esecuzione di attività periodiche e schedulabili.
- Alta disponibilità : il sistema prevede un grado significativo di alta disponibilità grazie alla ridondanza, utilizzando più istanze dei database e server delle applicazioni.
- Backup e ripristino : si prevede l’esecuzione di backup di tutti i nostri dati utilizzando robusti sistemi cloud (come Amazon RDS), che consentiranno il ripristino diretto in caso di errore nei database.
- Monitoraggio – il sistema deve essere continuamente monitorato, comprese le metriche “normali” di utilizzo della CPU, utilizzo della RAM, capacità del disco rigido e I / O di rete, permettendoci di monitorare la “salute” del nostro sistema di trading nel tempo.
- Registrazione : per quanto possibile, il sistema deve registrare il più possibile in un sistema di logging al fine di consentire l’individuazione rapida di guasti e permettere direttamente il debug.
- Reporting – il sistema prevede di calcolare in real-time le performance, confrontala con i benchmark desiderati e valutare dinamicamente il rischio.
- Sistemi di controllo della versione : il codice sorgente, gli script e i file di configurazione devono essere gestiti tramite un controllo della versione, ovvero GitHub , evitando di copiare e incollare le nuove versioni del codice localmente e in remoto
- Sviluppo Test-Driven: come per DTForex , si prevede un approccio di sviluppo completamente basato sui test (TDD), scrivendo i test unitari per il codice
- Distribuzione continua – Al fine di ridurre al minimo l’introduzione di bug che potrebbero eliminare rapidamente i profitti, si prevede di implementare i concetti di integrazione continua e distribuzione continua per il deploy sul server. Nei prossimi articoli si descriveranno maggiori dettagli su questo tema.
- Distribuzione remota: si prevede di utilizzare una distribuzione completamente basata su cloud / server remoto in modo tale che l’infrastruttura di trading non abbia una dipendenza locale.
Prossimi Passi
Il primo passo è descrivere lo stack del software e gli strumenti da utilizzare per costruire il sistema di trading. Questo include l’hosting provider, il controllo della versione e i sistemi di distribuzione continua, gli strumenti di monitoraggio e i meccanismi di archiviazione dei dati (inclusi backup e ripristino), nonché la fondamentale scelta del broker e le prestazione dell’interfaccia API che mette a disposizione.
Nel prossimo articolo descriviamo tutti i fornitori che sono all’altezza delle prestazione previste dal sistema, oltre a una ragionevole stima dei costi. Inoltre descriviamo in modo dettagliato le effettive implementazioni di questa infrastruttura.
