Database di Asset Finanziari per il Trading Algoritmico

In questa lezione del corso relativo alle basi del trading algoritmico con Python , descriviamo come gestire un database di asset finanziari per il trading algoritmico.

Solitamente, nel trading algoritmico l’attenzione è focalizzata sul componente del sistema completo di trading che implementa il modello alpha. Questa è la parte del sistema responsabile della generazione dei segnali di trading, prima che vengano filtrati tramite un sistema di gestione del rischio o di costruzione del portafoglio. Per questo motivo, molti algotrader dedicano una parte significativa del tempo all’ottimizzazione del modello alpha, al fine di ottenere un miglior Shape Ratio durante la fase di backtesting, prima che il sistema venga messo in produzione.

Tuttavia, un modello alpha risulta accurato solo se alimentato con dati di alta qualità. È quindi fondamentale utilizzare input tempestivi e precisi. Altrimenti i risultati saranno poco attendibili nel migliore dei casi, o completamente errati nel peggiore, con il rischio di gravi perdite se il sistema dovesse essere avviato in produzione.

In questa lezione analizziamo le problematiche relative all’acquisizione e alla gestione di dati tempestivi e accurati per il backtesting di una strategia algoritmica e per l’esecuzione automatizzata. L’obiettivo è mostrare come ottenere dati finanziari di qualità, archiviarli correttamente, pulirli in modo efficiente ed esportarli per l’uso nei modelli. Nel settore finanziario, questa tipologia di servizio viene comunemente identificata come database di asset finanziari per il trading algoritmico, o securities master database.

Database di Asset Finanziari per il Trading

Un database di asset finanziari per il trading algoritmico è 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 database di asset finanziari per il trading algoritmico può essere molto più semplice. 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 per un piccolo fondo quantitativo, i set di dati più comunemente utilizzati per azioni, indici, futures (principalmente su materie prime o titoli a reddito fisso) e cambi (forex) includono i prezzi storici di fine giornata (EOD) e i dati intraday. Per semplificare questa trattazione, l’attenzione verrà posta esclusivamente sui dati di fine giornata per il trading algoritmico, riferiti a titoli azionari, ETF e indici azionari. Nelle lezioni successive affronteremo l’integrazione di dati ad alta frequenza, classi di asset aggiuntive e dati derivati, che richiedono una gestione più avanzata.

I dati EOD per i titoli azionari risultano facilmente reperibili. Esistono numerosi servizi online che offrono accesso gratuito tramite API:

• Yahoo Finance
• Google Finance
• QuantQuote (solo dati EOD per S&P500)
• EODData (richiede registrazione)

È semplice scaricare manualmente i dati storici per singoli titoli, ma l’operazione diventa dispendiosa in termini di tempo quando si gestiscono aggiornamenti giornalieri per numerosi asset. Per questo motivo, un componente essenziale del securities master sarà responsabile dell’aggiornamento automatico dei dataset.

Orizzonte temporale

Un’ulteriore considerazione riguarda l’orizzonte temporale: fino a che punto nel passato è necessario risalire? La risposta dipende dalla specifica strategia di trading, ma esistono problematiche comuni a tutti gli approcci. Ad esempio il cambio di regime, spesso associato a nuovi contesti normativi, cambiamenti di volatilità o fasi di mercato particolarmente direzionali. Una strategia momentum di breve periodo potrebbe performare positivamente nei periodi 2000–2003 e 2007–2009, ma perdere denaro tra il 2003–2007.

Una regola generale prevede di acquisire quanti più dati EOD possibili, dato che il costo di archiviazione è ridotto. Non è necessario utilizzare tutti i dati contenuti nel database di asset finanziari, ma è utile disporre di una base storica ampia. Esistono avvertenze in termini di performance, poiché tabelle di grandi dimensioni possono rallentare le query. In genere i vantaggi derivanti da un maggiore numero di osservazioni prevalgono sugli svantaggi.

Gestione dei bias

Come per ogni dataset finanziario, è fondamentale riconoscere la presenza di errori, come massimi o minimi errati o il bias di sopravvivenza, trattato in dettaglio in questa lezione.

La 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 nostro database di asset finanziari, 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.

Quali strumenti usare per memorizzare i dati?

Esistono tre principali modalità per archiviare i dati in un database di asset finanziari per il trading algoritmico. Ognuno possiede diverse caratteristiche per l’accesso ai dati, le prestazioni e le capacità strutturali. Vediamole 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. Sono largamente utilizzati dai giganti del web come Google, Facebook e Twitter. Differiscono sostanzialmente dai sistemi RDBMS in quanto non esiste alcun concetto di schemi di tabelle. I NoSQL prevedono 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 questa lezione! 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 un RDBMS sono:

• La semplicità di installazione.
• L’indipendenza dalla piattaforma.
• La facilità di interrogazione.
• La semplicità di integrazione con i principali software di backtest.
• La capacità ad alte prestazioni su grandi set di dati.

I loro svantaggi sono spesso dovuti:

• Alla complessità di effettuare personalizzazioni.
• 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.

Nelle prossime lezioni relative all’implementazione di database di asset finanziari per il trading utilizzeremo MySQL o PostgreSQL. Questi database sono 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.

Da esperienze dirette nella realizzazione di database di asset finanziari per il trading, possiamo affermare che ci sono problemi significativi riguardo alla memorizzazione dei ticker canonici. Diversi fornitori utilizzano metodi diversi per risolvere i ticker e quindi è necessario combinare più fonti per avere una precisione dei dati soddisfacente.

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 FTSE MIB).

Come si valuta l’accuratezza dei dati?

I dati storici forniti da società terze sono soggetti a molte forme di errore:

• Azioni societarie – Errata gestione delle scissioni azionarie e degli aggiustamenti per dividendi. È fondamentale verificare che le formule siano state implementate correttamente per garantire la qualità dei dati storici per il trading algoritmico.
• Spike – Picchi di prezzo che superano di gran lunga i livelli storici di volatilità. È essenziale prestare attenzione a questi picchi al momento della loro comparsa. Possono essere causati anche dalla mancata considerazione delle divisioni azionarie. Gli script di spike-filter servono per informare i trader su tali anomalie.
• Aggregazione OHLC – I dati OHLC gratuiti, come quelli di Yahoo o Google, possono soffrire di una “cattiva aggregazione di ticker”, dove scambi su piccole borse avvengono a prezzi molto diversi rispetto al mercato principale, causando massimi/minimi distorti. Questo non è tecnicamente un errore, ma un’anomalia da monitorare.
• Dati mancanti – I dati possono mancare a causa di assenza di scambi (comune su timeframe al minuto o secondo per azioni small-cap e illiquide), chiusura dei mercati o errori di sistema. I dati mancanti possono essere riempiti, interpolati o ignorati, in base alle logiche del sistema di trading.

Gestire gli errori

Molti di questi errori richiedono un giudizio umano per decidere come gestirli. È possibile automatizzare la notifica degli errori, ma correggerli automaticamente è molto più complesso. Ad esempio, è necessario scegliere una soglia per rilevare i picchi: quante deviazioni standard e su quale intervallo temporale? Una soglia troppo alta potrebbe ignorare anomalie reali, mentre una troppo bassa genererebbe falsi positivi, specialmente durante eventi di mercato straordinari. Questi aspetti devono essere valutati attentamente dal trader algoritmico.

Occorre inoltre stabilire come e quando correggere gli errori rilevati. È necessario decidere se intervenire immediatamente e se avviare una procedura di controllo. Questo può richiedere l’integrazione di una tabella aggiuntiva nel database.

Si introduce così il tema del back-filling, un problema critico per la gestione di un database di asset finanziari per il trading. Riguarda la correzione retroattiva dei dati errati. Se il fornitore corregge un dato storico che era stato utilizzato per ottimizzare una strategia, bisogna valutare se la strategia sia ancora valida.

Questo rischio può essere mitigato studiando attentamente le metriche di performance, in particolare la variazione delle caratteristiche di vincita/perdita per ogni operazione. Le strategie dovrebbero essere progettate in modo tale che un singolo dato errato non comprometta in modo significativo i risultati complessivi.

Come sono automatizzati questi processi?

Il vantaggio di scrivere il software per la gestione di database di asset finanziari per il trading permette di automatizzare il processo tramite gli strumenti forniti dal sistema operativo. Ad esempio possiamo automatizzare eseguire il download, l’archiviazione e la pulizia dei dati. Nei sistemi basati su UNIX (come Mac OSX o Linux), si può fare uso di crontab. Crontab è 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 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

Nelle prossime lezioni descriviamo i dettagli tecnici per l’implementazione di un database di asset finanziari per il trading algoritmico. In particolare, installeremo MySQL, lo configureremo per i dati sui prezzi, otterremo i dati EOD da Yahoo / Google finance ed li esploreremo tramite la libreria di analisi dati pandas