Solitamente, nel trading algoritmico i riflettori sono puntati sul componente del completo sistema di trading che implementa il modello alpha. Questa è la parte del sistema che genera i segnali di trading, prima della filtrazione tramite un sistema di gestione dei rischi o di costruzione del portafoglio. Di conseguenza, gli algotrader spendono una parte significativa del loro tempo alla ricerca di ottimizzazioni del modello alpha, in modo da generare un maggiore Shape Ratio durante la fase di backtesting prima di mettere in produzione il proprio sistema.
Tuttavia, un modello alpha è accurato solo quando viene alimentato da dati di ottima qualità. Per questo motivo è fondamentale utilizzare dati accurati e tempestivi come input per il modello alpha, altrimenti i risultati saranno scarsi nel migliore dei casi o addirittura completamente errati nel peggiore dei casi, con conseguenti ingenti perdite se il sistema verrà messo in produzione.
In questo articolo desidero discutere questioni relative all’acquisizione e alla fornitura di dati tempestivi e accurati per il backtesting di una strategia algoritmica e, in definitiva, per il motore di esecuzione di trading. In particolare voglio evidenziare come ottenere dati finanziari, come conservarli, come pulirli e come esportarli. Nel settore finanziario questo tipo di servizio dati è noto come securities master database.
Cos'è una Securities Master Database?
Un Securities Master è un database che memorizza i dati fondamentali, i prezzi e le transazioni per una varietà di strumenti finanziari in tutte le classi di attività. Fornisce l’accesso a queste informazioni in modo coerente per essere utilizzato da molti processi, come la gestione dei rischi, la compensazione / liquidazione e il trading proprietario.
Ecco alcuni degli strumenti che potrebbero comporre un securities master database:
- Azioni
- Opzioni azionarie
- Indici
- Foreign Exchange
- Tassi di interesse
- Futures
- Commodities
- Obbligazioni – Governo e società
- Derivati – Caps, Floors, Swaps
La basi dati di Securities Master sono gestite da un team di sviluppatori e da specialisti di dati che garantiscono un elevato livello di disponibilità dei dati all’interno di un’azienda o istituzione.
Mentre questo è necessario nelle grandi aziende, a livello di un trader retail o in un piccolo fondo, un securities master può essere molto più semplice. Infatti, mentre i securities master dei grandi fondi fanno uso di costosi database aziendali e sistemi di analisi, a livello retail è possibile utilizzare software open source per fornire lo stesso livello di funzionalità, presupponendo che un sistema ben ottimizzato.
Quale database scegliere?
Per il trader algoritmico al dettaglio o il piccolo fondo quantitativo, i set di dati più comuni per azioni, indici, futures (principalmente materie prime o reddito fisso) e cambi (forex) sono i prezzi storici di fine giornata (EOD) e i dati intraday . Al fine di semplificare questa discussione ci concentreremo esclusivamente sui dati di fine giornata (EOD) per titoli azionari, ETF e indici azionari. Gli articoli successivi discuteranno di aggiungere dati ad alta frequenza, classi di assets aggiuntivi e dati derivati, che hanno requisiti più avanzati.
I dati EOD per le azioni sono facili da ottenere. Esistono numerosi servizi che forniscono l’accesso gratuito tramite API disponibili sul Web:
- Yahoo Finance
- Google Finance
- QuantQuote (solo i dati EOD di S&P500)
- EODData (registrazione obbligatoria)
È semplice scaricare manualmente i dati storici per singoli titoli, ma diventa molto dispendioso in termini di tempo se si devono scaricare giornalmente molti titoli. Pertanto un componente importante del nostro securities master si occuperà di aggiornare automaticamente il set di dati.
Un altro problema è il periodo di riferimento. Fino a che punto in passato abbiamo bisogno di andare con i nostri dati? Questo dipenderà dai requisiti della tua strategia di trading, ma ci sono alcuni problemi che riguardano tutte le strategie. Il più comune è il cambio di regime, che è spesso caratterizzato da un nuovo contesto normativo, periodi di volatilità superiore / inferiore o mercati con lunghe fasi di trend. Ad esempio, una strategia trend-following/momentum per movimenti corti nel lungo termine potrebbe performare molto bene tra il 2000-2003 e il 2007-2009. Tuttavia avrebbe avuto un periodo difficile dal 2003 al 2007 o dal 2009 ad oggi.
La mia regola generale consiste nell’ottenere quanti più dati possibili, specialmente per i dati EOD, che sono economici da archiviare (necessitano di poco spazio sul disco fisso). Solo perché i dati esistono nel tuo securities master, non significa che debbano essere utilizzati. Ci sono avvertenze circa le prestazioni, in quanto tabelle di database più grandi significano tempi di interrogazione più lunghi (vedi sotto), ma i benefici di avere più punti di campionamento generalmente superano qualsiasi problema di prestazione.
Come per tutti i dati finanziari, è imperativo essere consapevoli degli errori, come i prezzi massimi/minimi non corretti o il bias di sopravvivenza, di cui ho discusso a lungo in questo articolo.
Quali strumenti usare per memorizzare i dati?
Esistono tre principali modalità per archiviare i dati finanziari. Ognumo possiede diverse caratteristiche per l’accesso ai dati, le prestazioni e le capacità strutturali. Vediamo singolarmente.
Flat-File
Il modo più semplice per memorizzare i dati finanziari, che è anche il principale “formato” in cui si ricevono i dati da qualsiasi fornitore, è un file flat. I file flat utilizzano spesso il formato CSV (Comma-separated values), che memorizza una matrice bidimensionale di dati come una serie di righe, con i dati della colonna separati da un delimitatore (spesso una virgola, ma può essere anche uno spazio bianco, come ad esempio uno spazio o tab). Per i dati sui prezzi EOD, ogni riga rappresenta un giorno di negoziazione tramite il paradigma OHLC (vale a dire i prezzi di aperta , massimo, minimo, e di chiusura).
Il vantaggio dei file flat è la loro semplicità e la capacità di essere efficientemente compressi per l’archiviazione o il download. Gli svantaggi principali risiedono nella mancanza di capacità di interrogazione e le scarse prestazioni per l’iterazione su set di dati di grandi dimensioni. SQLite ed Excel attenuano alcuni di questi problemi fornendo alcune funzionalità base di interrogazione.
Documentale / NoSQL
I database documentali/NoSQL, sebbene non siano un nuovo concetto, negli ultimi anni hanno acquisito una notevole importanza grazie a loro utilizzo da parte dei giganti del web come Google, Facebook e Twitter. Differiscono sostanzialmente dai sistemi RDBMS in quanto non esiste alcun concetto di schemi di tabelle. Invece, ci sono collezioni e documenti, che sono le analogie più vicine, rispettivamente, alle tabelle e ai record. Esiste un’ampia tassonomia di archivi documentali, la cui discussione è ben al di fuori di questo articolo! Tuttavia, alcuni delle soluzioni più popolari sono MongoDB, Cassandra e CouchDB.
I database documentali, nelle applicazioni finanziarie, sono adatti principalmente ai dati fondamentali o ai metadati. I dati fondamentali per le attività finanziarie sono disponibili in molte forme, come azioni aziendali, dichiarazioni di guadagni, archivi SEC ecc. Pertanto, la natura senza schema dei DB NoSQL è particolarmente adatta. Tuttavia, i DB NoSQL non sono ben progettati per le serie temporali come i dati sui prezzi ad alta risoluzione e quindi non li prenderemo in considerazione per tale scopo.
Relational Database Management Systems
Un Relational Database Management Systems utilizza il modello relazionale per archiviare i dati. Questi database sono particolarmente adatti ai dati finanziari perché diversi “oggetti” (come exchanges, sorgenti dati, prezzi) possono essere separati in tabelle con specifiche relazioni tra di loro.
Un RDBMS fa uso del Structured Query Language (SQL) per eseguire complesse query sui dati finanziari. Esempi di RDBMS includono Oracle, MySQL, SQLServer e PostgreSQL.
I principali vantaggi di unRDBMS sono la semplicità di installazione, l’indipendenza dalla piattaforma, la facilità di interrogazione, la semplicità di integrazione con i principali software di backtest e la capacità ad alte prestazioni su grandi set di dati. I loro svantaggi sono spesso dovuti alla complessità ddi effettuare personalizzazioni e alle difficoltà nel raggiungere tali prestazioni senza una conoscenza di base del modo in cui i dati RDBMS sono archiviati. Inoltre, possiedono schemi semirigidi e quindi i dati devono essere modificati per adattarsi a tali schemi. Questo è diverso dagli archivi dati NoSQL, dove non esiste uno schema.
Per tutti i futuri articoli di implementazione dei prezzi storici su DataTrading, utilizzeremo MySQL o PostgreSQL, che sono entrambi gratuiti, open source, multipiattaforma, estremamente robusti e le prestazioni sono ben documentate, che li rendono una scelta ottimale per il lavoro degli algotrader.
Come sono strutturati i dati storici?
Nel campo dell’informatica, esiste moltissimo lavoro teorico e di ricerca accademica relativo al design ottimale per gli archivi di dati. Tuttavia, non entreremo troppo nei dettagli in quanto è facile perdersi nei dettagli! In questo paragrafo voglio introdurre un modello comune per la costruzione di un securities master azionario, che è possibile modificare a seconda delle specifiche delle proprie applicazioni.
Il primo compito consiste nel definire le nostre entità, che corrispondono ad elementi dei dati finanziari mappati con le tabelle del database. Per una banca dati di titoli azionari si prevedono le seguenti entità:
- Exchange – Qual è l’ultima fonte originale dei dati?
- Fornitore: da dove viene ottenuto un particolare dataset?
- Strumento / Ticker – Il ticker / simbolo per l’equity o l’indice, insieme alle informazioni aziendali, della società o del fondo sottostante.
- Prezzo – il prezzo effettivo per un determinato titolo in un determinato giorno.
- Azioni Aziendali: l’elenco di tutte le suddivisioni di azioni o gli aggiustamenti dei dividendi (ciò potrebbe portare a una o più tabelle), necessarie per adeguare i dati del prezzo.
- Festività nazionali – Per evitare di classificare erroneamente le vacanze come errori per dati mancanti, può essere utile memorizzare festività nazionali e i riferimenti incrociati.
Ci sono problemi significativi riguardo alla memorizzazione dei ticker canonici. Posso affermare questo grazie ad esperienze dirette. Diversi fornitori utilizzano metodi diversi per risolvere i ticker e quindi è necessario combinare più fonti per avere una precisione dei dati soddisfaciante. Inoltre, le società falliscono, sono esposte all’attività di fusione e acquisizione (ad esempio acquisiscono e cambiano nomi / simboli) e possono avere più classi di azioni quotate in borsa. Molti di voi non dovranno preoccuparsi di ciò perché il vostro universo di ticker sarà limitato ai componenti dei grandi indici(come S&P500 o FTSE350).
Come si valuta l'accuratezza dei dati?
I dati storici dei forniti da società terze sono soggetti a molte forme di errore:
- Azioni societarie – Errata gestione delle scissioni azionari e gli aggiustamenti dei dividendi. Bisogna essere assolutamente sicuri che le formule siano state implementate correttamente.
- Spike: i picchi di prezzo che superano di gran lunga determinati livelli storici di volatilità. Bisogna stare molto attenti a questi picchi quando si verificano. I picchi possono anche essere causati dal non prendere in considerazione le divisioni azionarie, quando si verificano. Gli script di spike-filter vengono utilizzati per informare i trader di tali situazioni.
- Aggregazione OHLC – I dati OHLC gratuiti, come quelli di Yahoo / Google, sono particolarmente soggetti a situazioni di “cattiva aggregazione di ticker” in cui le piccole borse trattano piccoli scambi ben al di sopra dei prezzi di scambio “principali” per un singolo giorno, portando così a massimi / minimi eccessivi una volta aggregati questi dati. Questo non è un vero e proprio ‘errore’ in quanto tale, ma al più un problema di cui stare attenti.
- Dati mancanti: i dati mancanti possono essere causati dalla mancanza di scambi in un particolare periodo di tempo (comune nei dati con timeframe al minuti o secondi in azioni small-cap ed illiquidi), dalle giornate di chiusura dei mercati o semplicemente da un errore nel sistema dell’exchange. I dati mancanti possono essere riempiti (cioè riempiti con il valore precedente), interpolati (linearmente o in altro modo) o ignorati, a seconda del sistema di trading.
Molti di questi errori si basano sul giudizio manuale per decidere come procedere. È possibile automatizzare la notifica di tali errori, ma è molto più difficile automatizzare la loro soluzione. Ad esempio, si deve scegliere la soglia per essere informati sui picchi: quante deviazioni standard usare e su quale periodo di ritorno? Un livello troppo alto di stdev salterà alcuni picchi, mentre un livello troppo basso produce molti falsi positivi (come molti annunci di notizie insolite). Tutti questi problemi richiedono un giudizio da parte dell’algotrader.
È anche necessario decidere come correggere gli errori. Gli errori devono essere corretti non appena sono individuati e, in caso affermativo, deve essere eseguita una procedura di controllo? Ciò richiederà una tabella aggiuntiva nel DB. Questo ci porta al tema del back-filling, che è un problema particolarmente insidioso per il backtesting. Riguarda la correzione automatica dei dati errati a monte. Ad esempio se il fornitore di dati inizia a corregge un errore storico, ma la nostra strategia di trading in produzione è stata ottimizzata (backtested)in base alla ricerca dei precedenti dati non validi, è necessario prendere decisioni in merito all’efficacia della strategia. Questo problema può essere un po’ attenuato grazie ad uno studio approfondito delle metriche sul rendimento della strategia (in particolare la variazione delle caratteristiche di vincita / perdita per ogni trade). Le strategie dovrebbero essere scelte o progettate in modo tale che un singolo dato non possa distorcere le prestazioni della strategia.
Come sono automatizzati questi processi?
Il vantaggio di scrivere il software per eseguire il download, l’archiviazione e la pulizia dei dati consiste che tali software possono essere automatizzati tramite gli strumenti forniti dal sistema operativo. Nei sistemi basati su UNIX (come Mac OSX o Linux), si può fare uso di crontab, che è un processo in esecuzione continua che consente di eseguire script specifici in periodi definiti dall’utente o periodi regolari. Esiste un processo equivalente su MS Windows noto come Utilità di pianificazione.
Un processo di produzione, ad esempio, potrebbe automatizzare il download di tutti i prezzi di fine giornata del S&P500 non appena vengono pubblicati tramite da fornitore di dati. Avvierà quindi automaticamente gli algoritmi per la verifica dei dati mancanti e gli script per il filtraggio degli spike, avvisando il trader via e-mail, SMS o qualche altra forma di notifica. A questo punto, qualsiasi strumento di backtesting avrà automaticamente accesso ai dati recenti, senza che il trader debba alzare un dito! A seconda che il tuo sistema di trading si trovi su un desktop o su un server remoto, puoi scegliere di avere un processo semi-automatico o completamente automatico per queste attività.
Come vengono forniti i dati al software di backtesting?
Una volta che i dati vengono aggiornati automaticamente e risiedono nell’RDBMS, è necessario acquisirlo ed includerlo nel software di backtesting. Questo processo dipenderà in larga misura dal modo in cui il database è installato e dal fatto che il tuo sistema di trading sia locale (cioè su un computer desktop) o remoto (come con un server co-localizzato).
Una delle considerazioni più importanti è quella di ridurre al minimo l’input / output (I / O) eccessivo in quanto può essere estremamente costoso sia in termini di tempo che di denaro, presupponendo connessioni remote in cui la larghezza di banda è costosa. Il modo migliore per affrontare questo problema è trasferire i dati attraverso una connessione di rete solo quando ne hai bisogno (tramite query selettiva) o esportando e comprimendo i dati.
Molti RDBMS supportano la tecnologia di replicazione, che consente di clonare un database su un altro sistema remoto, solitamente con un certo grado di latenza. A seconda della configurazione e della quantità di dati, questo processo può impiegare alcuni secondi o minuti. Un semplice approccio consiste nel replicare un database remoto su un desktop locale. Tuttavia, tieni presente che si possono presentare problemi di sincronizzazione e richiedono molto tempo per essere risolti!
Di seguito descrivo alcuni casi di esempio, ma ci sono molti modi per affrontare questo problema e saranno altamente dipendenti dalla tua specifica configurazione:
MySQL
Se si utilizza MySQL, è possibile utilizzare un linguaggio di scripting open source come Python (tramite la libreria MySQLdb o l’ORM di SQLAlchemy) per connettersi al database ed eseguire query su di esso.
Le più recenti librerie di analisi dei dati, come Pandas , consentono l’accesso diretto a MySQL (si consulti questo thread per un esempio).
È inoltre possibile utilizzare il linguaggio / ambiente preferiti (C ++, C #, Matlab) e un collegamento ODBC per connettersi ad un’istanza MySQL.
MS SQLServer
SQLServer è progettato per essere facilmente connesso ai linguaggi MS .NET, come C # e Visual Basic tramite l’ORM LINQ. È anche possibile connettersi a SQLServer con Python, tramite pyODBC.
Esistono chiaramente molte altre combinazioni di database e ambiente di backtesting. Tuttavia, tratterò la discussione di questi setup in successivi articoli!
Conclusioni
Nei prossimi articoli introdurrò i dettagli tecnici per l’implementazione di securities master.i. In particolare, installeremo MySQL, lo configureremo per i dati sui prezzi e otterremo i dati EOD da Yahoo / Google finance ed li esploreremo tramite la libreria di analisi dati pandas.
