Scegliere una Piattaforma per il Backtesting e l’Esecuzione Automatica

In questo articolo si approfondisce il concetto di esecuzione automatica. In generale, questo è il processo che consente a una strategia di trading, tramite una piattaforma di trading elettronica, di generare segnali di esecuzione di un trade senza alcun intervento umano. La maggior parte dei sistemi discussi su DataTrading sono stati progettati per essere implementati come strategie con esecuzione automatizzata. L’articolo descrive i pacchetti software e linguaggi di programmazione che forniscono sia funzionalità di backtesting che di esecuzione automatizzata.

La prima considerazione è come testare una strategia. La mia opinione personale è che lo sviluppo personalizzato di un ambiente di backtesting all’interno di un linguaggio di programmazione di prima classe offre la massima flessibilità. Viceversa, con una piattaforma di backtesting sviluppata da un fornitore software si devono introdurre dei vincoli sulla modalità di esecuzione dei backtest. Nonostante ciò, la scelta dei linguaggi di programmazione disponibili è ampia e diversificata, e spesso può essere disorientante. Non è sempre noto, prima di inziare lo sviluppo, quale linguaggio possa essere il più adatto.

Quando si codifica una strategia con regole sistematiche, il trader quantitativo deve essere sicuro che i suoi risultati futuri rifletteranno le performance passate. Esistono generalmente due tipologie di sistemi per il backtesting che sono utilizzate per testare le strategie. In generale, tali sistemi sono classificati in backtesting di ricerca e backtesting event-driven (basato sugli eventi). In questo articolo consideriamo sistemi backtesters personalizzati per entrambe queste tipologie e per ognuno si evidenziano vantaggi e svantaggi.

Sistemi di Ricerca

La forma più semplice di un sistema di backtesting, il sistema di ricerca, è solitamente il primo ad essere utilizzato. Il sistema di ricerca viene utilizzato per verificare rapidamente se una strategia può avere buone prestazioni. Tali strumenti fanno spesso ipotesi non realistiche per i costi di transazione, i probabili prezzi di esecuzione, i vincoli di shorting, la gestione dei rischi e una miriade di altre questioni che sono state delineate negli articoli precedenti. I comuni strumenti per effettuare la ricerca comprendono MATLAB, R, Python ed Excel.

La fase di ricerca è utile perché i pacchetti software forniscono una capacità di trasporto vettoriale significativa, che porta ad una buona velocità di esecuzione e un’immediata implementazione (meno linee di codice). In questo modo è possibile testare più strategie, combinazioni e varianti in modo rapido e iterativo.

Sebbene tali strumenti siano spesso utilizzati sia per il backtesting che per l’esecuzione, tali ambienti di ricerca non sono generalmente adatti per strategie che si avvicinano al trading intraday a frequenze elevate (sotto il minuto). Tale limitazione è causata dalla mancanza, all’interno di questi ambienti, delle librerie necessarie per connettersi ai server dei fornitori di dati in tempo reale o della difficoltà ad interfacciarsi con le API dei broker in modo pulito. Nonostante queste carenze esecutive, gli ambienti di ricerca sono fortemente utilizzati all’interno dell’ambiente quantitativo professionale. Sono il “primo test” per tutte le idee di strategie prima di promuoverle ad un controllo più rigoroso all’interno di un ambiente di backtesting realistico.

Backtesting Event-Driven

Una volta che una strategia è stata ritenuta idonea nella fase di ricerca, deve essere testata in modo più realistico. Tale realismo tenta di simulare fedelmente la maggioranza (se non tutte) delle criticità descritte negli articoli precedenti. Lo scenario ideale è la possibilità di utilizzare lo stesso codice di generazione dei trade per il backtesting storico e l’esecuzione live. Questo può essere ottenuto utilizzando un backtester basato su eventi.

I sistemi basati su eventi sono ampiamente utilizzati nell’ingegneria del software, comunemente per la gestione dell’input GUI (graphicalical user interface) all’interno di sistemi operativi basati su interfacce grafiche. Questi sono ideali anche per il trading algoritmico. Tali sistemi sono spesso scritti in linguaggi ad alte prestazioni come C ++, C # e Java.

Si consideri uno scenario dove una strategia di trading automatizzata è collegata a un feed di mercato in tempo reale e ad un broker (questi due possono essere la stessa entità). In questo caso nuove informazioni sul mercato sono inviate costantemente verso il sistema, attivando e generando un nuovo segnale di trading e quindi un evento di esecuzione. Tale sistema è quindi in un ciclo continuo, rimanendo in attesa di ricevere eventi e gestirli in modo appropriato.

È possibile generare sotto componenti come un gestore di dati storici e un simulatore del broker, che possono imitare le loro controparti reali. Questo consente di effettuare il backtesting delle strategie in modo estremamente verosimile all’esecuzione live.

Lo svantaggio di tali sistemi è che sono molto più complicati da progettare e da implementare rispetto ad un sistema di ricerca. Quindi il “time to market” è più lungo. Sono più inclini a bug e richiedono una buona conoscenza di programmazione e, in una certa misura, della metodologia di sviluppo del software.

Latenza

In termini ingegneristici, la latenza è definita come l’intervallo di tempo tra una simulazione e una risposta. Nel trading quantitativo si riferisce generalmente al ritardo temporale tra la generazione di un segnale di esecuzione e la ricezione delle informazioni dell’eseguito da parte del broker che esegue l’esecuzione.

Raramente questo tipo di latenza è un problema nelle strategie intraday a bassa frequenza, dato che il movimento dei prezzi previsto durante il periodo di latenza non influirà in alcun modo sulla strategia. Lo stesso non vale per le strategie a frequenza più alta dove la latenza diventa estremamente importante. L’obiettivo finale di HFT è ridurre il più possibile la latenza al fine di ridurre lo slippage.

La riduzione della latenza comporta la riduzione al minimo della “distanza” tra il sistema di trading algoritmico e l’exchange definitivo su cui viene eseguito un ordine. Ciò può comportare la riduzione della distanza geografica tra i sistemi, riducendo così i tempi di trasmissione lungo i cablaggi di rete. Può anche implicare la riduzione dell’elaborazione effettuata nell’hardware di rete o la scelta di una intermediazione con un’infrastruttura più sofisticata. Molti broker competono sulla latenza per attirare i clienti.

La diminuzione della latenza diventa esponenzialmente più costosa in funzione della “distanza in Internet”, che è definita come la distanza di rete tra due server. Quindi per un trader ad alta frequenza deve essere raggiunto un compromesso tra i costi per ridurre la latenza e il guadagno derivato dalla riduzione dello slippage. Questi problemi saranno discussi in uno dei prossimi paragrafi.

Linguaggio di Programmazione

Alcune aspetti relativi alla scelta del linguaggio sono già stati descritti in precedenza. Ora si vogliono considerare i vantaggi e gli svantaggi dei singoli linguaggi di programmazione. Ho diviso i linguaggi in due categorie, i linguaggi alte prestazioni / difficoltà di sviluppo, e quelli a basse prestazioni / facili da sviluppare. Questi sono termini soggettivi e alcuni possono non condividere tale classificazione, a seconda del proprio background tecnico.

Uno degli aspetti più importanti della programmazione di un ambiente di backtesting personalizzato è la familiarità del programmatore abbia con gli strumenti utilizzati. Per coloro che sono nuovi nel mondo della programmazione, ciò che segue descrive le principali tecnologie utilizzate nel trading algoritmico.

C++, C# e Java

C++, C# e Java sono tutti esempi di linguaggi di programmazione orientati agli oggetti di uso generale. Ciò significa che possono essere utilizzati senza un corrispondente ambiente di sviluppo integrato (IDE), sono tutti multipiattaforma, hanno una vasta gamma di librerie per quasi tutte le attività immaginabili e consentono una rapida velocità di esecuzione se correttamente utilizzati.

Se si desidera la massima velocità di esecuzione, è probabile che C++ (o C) sia la scelta migliore. Offre la massima flessibilità per la gestione della memoria e l’ottimizzazione della velocità di esecuzione. Questa flessibilità ha un prezzo. C++ è difficile da imparare bene e può spesso portare all’introduzione di bug. Lo sviluppo può richiedere molto più tempo rispetto alle altre lingue. Nonostante queste carenze è molto usato nel settore finanziario.

C# e Java sono simili poiché entrambi richiedono che tutti i componenti siano oggetti con l’eccezione di tipi di dati primitivi come float e integer. Differiscono dal C++ perchè eseguendo una garbage collection automatica. La garbage collection aggiunge un carico aggiuntivo alle prestazioni ma permette uno sviluppo più rapido. Questi linguaggi rappresentano sia una buona scelta per lo sviluppo di un backtester in quanto hanno funzionalità GUI native, librerie di analisi numerica e velocità di esecuzione veloce.

Personalmente, utilizzo C++ per creare backtest event-driven che richiedono una velocità di esecuzione estremamente elevata, come per i sistemi HFT. Questo solo se ritengo che un sistema event-driven sviluppato con Python possa avere delle prestazioni negative, poiché Python è la mia prima scelta per un sistemi basati sugli eventi.

MATLAB, R e Python

MATLAB è un IDE commerciale per il calcolo numerico. Ha ottenuto ampia diffusione nei settori accademici, ingegneristici e finanziari. Ha molte librerie numeriche per il calcolo scientifico. Vanta una velocità di esecuzione rapida partendo dal presupposto che qualsiasi algoritmo in fase di sviluppo possa essere soggetto a vettorizzazione o parallelizzazione. Nonostante questi vantaggi il costo della sua lincenza lo rende poco attraente per i trader retail con un budget limitato. MATLAB viene talvolta utilizzato per l’esecuzione diretta verso un broker come Interactive Brokers.

R è un ambiente di scripting statistico dedicato. È gratuito, open source, multipiattaforma e contiene una vasta gamma di pacchetti statistici liberamente disponibili per eseguire analisi estremamente avanzate. R è molto usato nelle statistiche accademiche e nel settore quantitativo degli hedge fund. Nonostante sia possibile collegare R ad un broker non è adatto per tali funzionalità, quindi essere considerato come uno strumento di ricerca. Anche la velocità di esecuzione è carente, a meno che le operazioni non siano vettorializzate.

In questa sezione ho incluso anche Python, che si pone a metà tra MATLAB, R e i suddetti linguaggi di uso generale. È gratuito, open source e multipiattaforma. È un linguaggio interpretato in contrasto ai linguaggi compilati (come C++ e Java), il che lo rende nativamente più lento del C ++. Tuttavia, contiene una libreria per svolgere praticamente qualsiasi compito immaginabile, dal calcolo scientifico fino alla progettazione di server Web di basso livello. In particolare, contiene NumPy, SciPy, panda, matplotlib e scikit-learn, che forniscono un robusto ambiente di ricerca numerica che, quando vettorializzato, è paragonabile alla velocità di esecuzione di un linguaggio compilato.

Python possiede anche le librerie per la connessione al broker. Questo lo rende un “one-stop shop” per la creazione di un backtesting basato sugli eventi e un ambiente di esecuzione live senza dover utilizzare altri linguaggi più complessi. La velocità di esecuzione è più che sufficiente per i trader intraday che operano su timeframe ad un minuto o superiore. Python è molto semplice da imparare rispetto ai linguaggi di livello inferiore come il C ++. Per questi motivi facciamo ampio uso di Python all’interno degli articoli di Data Trading.

Ambienti di Sviluppo Integrati

Il termine IDE ha più significati all’interno del trading algoritmico. Gli sviluppatori di software lo utilizzano per indicare una GUI che consente la programmazione con controllo della sintassi, la navigazione dei file del progetto, il debug e le funzionalità per esecuzione del codice. Gli operatori algoritmici lo usano per indicare un ambiente di backtesting / trading completamente integrato con il download di dati storici, la creazione di grafici, la valutazione delle statistiche e l’esecuzione live. Per i nostri scopi, utilizzo il termine per indicare qualsiasi ambiente di backtest / trading, spesso integrato con una GUI, che non è considerato un linguaggio di programmazione generico.

Excel

Nonostante alcuni trader quantistici considerano Excel poco appropriato per il trading, l’ho trovato estremamente utile per il “controllo dell’integrità” dei risultati. Il fatto che tutti i dati siano direttamente disponibili in bella vista rende semplice implementare semplici strategie di segnale / filtro. Intermediari come Interactive Brokers mettono a disposizione un plug-in DDE che consente ad Excel di ricevere dati di mercato in tempo reale ed eseguire ordini di trading. Nonostante la facilità d’uso, Excel è estremamente lento per la gestione dei dati e il calcolo numerico. Personalmente uso excel solo per verificare eventuali bug durante lo sviluppo di nuove strategie. In particolare, è estremamente utile per verificare se una strategia è soggetta a bias look-ahead. Questo è facile da rilevare in Excel a causa della natura del foglio elettronico del software. Se sei a disagio con i linguaggi di programmazione e stai portando avanti una strategia di interday, Excel potrebbe essere una buona scelta.

Software Proprietari / Commerciali

Il mercato dei dei software di backtesting, di visualizzazione grafica dei dati storici e di “analisi tecnica” è estremamente competitivo. Le caratteristiche offerte da tali software includono la creazione di grafici dei prezzi in tempo reale, una vasta gamma di indicatori tecnici, linguaggi di backtesting personalizzati ed esecuzione automatizzata.

Alcuni fornitori offrono una soluzione all-in-one, come TradeStation. TradeStation è un broker online e produttore di un software di trading (anche noto come TradeStation) che fornisce l’esecuzione elettronica degli ordini su più classi di attività. Attualmente non sono a conoscenza di un’API diretta per l’esecuzione automatica. Invece gli ordini devono essere inseriti attraverso il software della GUI. Ciò è in contrasto con Interactive Brokers, che ha una interfaccia di trading più snella (Trader WorkStation), ma offre sia le API proprietarie in tempo reale per il mercato / l’esecuzione degli ordini sia un’interfaccia FIX.

Un’altra piattaforma estremamente popolare è MetaTrader, che viene utilizzata nel trading sul forex per la creazione di “Expert Advisors”. Si tratta di script personalizzati scritti in un linguaggio proprietario che possono essere utilizzati per il trading automatico. Non ho avuto molta esperienza con TradeStation o MetaTrader, quindi non passerò troppo tempo a discutere delle loro caratteristiche.

Tali strumenti sono utili se non ci si sente a proprio agio con la programmazzione e non si desidera considerare troppi fattori e dettagli. Tuttavia, con tali sistemi si sacrifica molta flessibilità e spesso si è vincolati a un’unico broker.

Strumenti Open-Source e Web-Based

I due più popolari web-based sistemi di backtesting sono Quantopian e QuantConnect. Il primo fa uso di Python (e ZipLine, vedi sotto) mentre il secondo utilizza C#. Entrambi forniscono una vasta gamma di dati storici. Quantopian attualmente non supporta più il live trading, mentre QuantConnect supporta il live trading con alcuni dei maggiori broker internazionali (tra cui Interactive Brokers).

Algo-Trader è una società con sede in Svizzera che offre un sistema proprietario sia una licenza open-source che una licenza commerciale. Dalle informazioni disponibili sempra che sia un prodotto robusto e hanno molti clienti istituzionali. Il sistema consente il backtesting completo dello storico e l’elaborazione di eventi complessi e si collega con Interactive Brokers. L’edizione Enterprise offre sostanzialmente più funzionalità ad alte prestazioni.

Marketcetera fornisce un sistema di backtesting che può collegarsi a molti altri linguaggi, come Python e R, al fine di sfruttare il codice che potresti aver già scritto. Lo ‘Strategy Studio’ fornisce la possibilità di scrivere il codice di backtesting e algoritmi di esecuzione ottimizzati e successivamente la transizione da un backtest storico a un paper trading o al trading dal vivo.

ZipLine è la libreria Python che alimenta il servizio Quantopian menzionato sopra. È un ambiente backtest completamente event-driven ed attualmente supporta titoli azionari statunitensi. Non ho fatto ampio uso di ZipLine, ma conosco altri che ritengono che sia un buon strumento. Ci sono ancora molte aree da migliorare, ma il team lavora costantemente al progetto e viene mantenuto molto attivamente.

Ci sono anche alcuni progetti ospitati su Github / Google Code che potresti voler esaminare. Non ho passato molto tempo a studiarli. Tali progetti includono OpenQuant, TradeLink e PyAlgoTrade.

Software di Backtesting Istituzionali

I sistemi di backtesting di livello istituzionale come Deltix e QuantHouse non sono spesso utilizzati dai trader algoritmici retail. Le licenze software sono generalmente ben al di sopra del budget per l’infrastruttura. Detto questo, tali software sono ampiamente utilizzati da fondi d’investimento, società di trading proprietarie, uffici di consulenza finaziaria e simili.

I vantaggi di tali sistemi sono chiari. Forniscono una soluzione all-in-one per la raccolta dei dati, lo sviluppo della strategia, il backtesting storico e l’esecuzione dal vivo su singoli strumenti o portafogli, fino ad altissime frequenze. Tali piattaforme hanno avuto numerosi test e un sacco di “usi sul campo”, sono quindi considerati molto robusti.

I sistemi sono event-driven e gli ambienti di backtesting possono spesso simulare gli trading reale con un alto grado di precisione. I sistemi supportano inoltre algoritmi di esecuzione ottimizzati, che tentano di minimizzare i costi di transazione. Ciò è particolarmente utile per gli operatori con una ampia base di capitale.

Devo ammettere che non ho avuto molta esperienza di Deltix o QuantHouse. Detto questo, il budget da solo li mette fuori dalla portata della maggior parte dei trader al dettaglio, quindi non mi dilungherò su questi sistemi.

Collocazione

Dopo aver descritto lo stato dell’arte del software per il trading algoritmico, rivolgiamo ora la nostra attenzione verso l’implementazione dell’hardware che eseguirà le nostre strategie. Un trader retail esegue probabilmente la sua strategia da casa durante le ore di apertura del mercato. Ciò comporterà l’accensione del PC, la connessione al broker, l’aggiornamento del software e l’esecuzione automatica dell’algoritmo durante il giorno. Viceversa, un fondo quant professionale con asset significativi in ​​gestione (AUM) disporrà di un’infrastruttura server dedicata in exchange centralizzato, al fine di ridurre il più possibile la latenza nell’esecuzione delle strategie HFT.

Home Desktop

L’approccio più semplice consiste semplicemente nel realizzare una strategia algoritmica con un computer desktop domestico connesso al broker tramite una connessione a banda larga (o simile). Mentre questo approccio è semplice per iniziare, soffre di molti inconvenienti. La macchina desktop è soggetta a mancanza di alimentazione, a meno che non sia supportata da un UPS. Inoltre, una connessione Internet domestica è anche in balia dell’ISP. La perdita di potenza o l’interruzione della connettività Internet potrebbero verificarsi in un momento cruciale nel trading, lasciando il trader algoritmico con posizioni aperte che non possono essere chiuse. Questo problema si verifica anche con riavvii obbligatori del sistema operativo (questo in realtà mi è successo anche in un ambiente professionale!) e il malfunzionamento dei componenti hardware. Per i motivi sopra esposti, sono molto restio a raccomandare un approccio “casalingo” al trading algoritmico. Se decidi di seguire questo approccio, assicurati di disporre sia di un computer di backup sia di una connessione Internet di backup, che puoi utilizzare per chiudere le posizioni in una situazione di inattività.

VPS

Il livello successivo consiste nell’utilizzare un server virtuale privato (VPS). Un VPS è un server remoto, spesso commercializzato come servizio “cloud”. Sono molto più economici di un corrispondente server dedicato, dal momento che un VPS è in realtà una partizione di un server molto più grande. Possiedono un ambiente di sistema operativo virtuale isolato disponibile esclusivamente per ogni singolo utente. Il carico della CPU è condiviso tra più VPS e una parte dei sistemi RAM viene allocata al VPS. Tutto ciò viene realizzato attraverso un processo noto come virtualizzazione.

I principali provider VPS includono Amazon EC2 e Rackspace Cloud. Entrambi forniscono sistemi entry-level con poca RAM e utilizzo base della CPU fino a soluzioni business con server multi core e RAM ad altissime prestazioni. Per la maggior parte dei trader algoritmici retail, i sistemi entry level sono sufficienti per le strategie infragiornaliere o interday a bassa frequenza e per i database di dati storici più piccoli.

I vantaggi di un sistema  VPS sono la disponibilità 24 ore su 24, capacità di monitoraggio più robuste, semplici “plug-in” per servizi aggiuntivi, come archiviazione di file, la gestione dei database e un’architettura flessibile. Uno svantaggio principale è il costo. Con la crescita del sistema, l’hardware dedicato diventa più economico per unità di prestazioni. Questo approccio si presuppone una collocazione lontana da un exchange.

Rispetto ad un sistema desktop domestico, scegliere un VPS non sempre la latenza usufruisce di miglioramenti. La posizione geografica del tuo desktop casalingo potrebbe essere più vicina a un particolare exchange finanziario rispetto ai data center del provider cloud. Ciò viene mitigato scegliendo un’azienda che fornisce servizi VPS specificamente concepiti per il trading algoritmico che si trovano vicino agli exchange. Questi probabilmente costano più di un provider VPS generico come Amazon o Rackspace.

Internamente all'Exchange

Per ottenere la minore latenza possibile è necessario prevedere l’uso di server dedicati direttamente nel data center di scambio. Questa è un’opzione proibitivamente costosa per quasi tutti i trader algoritmici, a meno che non siano molto ben capitalizzati. È quasi esclusivo dominio dei  fondi quantitativi professionali. Come ho detto sopra un’opzione più realistica è quella di acquistare un sistema VPS da un fornitore che si trova vicino ad un exchange.

Come si può vedere, ci sono molte opzioni per il backtesting, l’esecuzione automatizzata e l’hosting di una strategia. Determinare la soluzione più idonea dipende dal budget, dalla capacità di programmazione, dal grado di personalizzazione richiesto, dalla disponibilità degli asset e se il trading è effettuato su base retail o professionale.

Testing Statistico della Mean Reversion – Parte II

Nel precedente articolo abbiamo introdotto il test statistico della mean-reverting. Abbiamo esaminato un paio di tecniche che ci hanno aiutato a determinare se una serie temporale fosse o meno mean reverting. In particolare abbiamo esaminato il test Dickey-Fuller e l’esponente di Hurst. In questo articolo considereremo un altro metodo, ovvero il test Cointegrated Dickey Fuller (CADF).

Innanzitutto, si deve notare che è molto difficile ,in realtà, trovare un asset direttamente negoziabile direttamente che abbia un comportamento mean revering. Ad esempio, le azioni si comportano generalmente come un moto browniano geometrico e quindi rendono relativamente inutili le strategie mean-reverting. Tuttavia, non c’è nulla che ci impedisca di creare un portafoglio di serie di prezzi stazionario. Quindi possiamo applicare strategie di trading a medio termine al portafoglio.

La forma più semplice di strategie di trading di mean-backing è il classico “pairs trade”, che di solito implica una coppia long-short di azioni indipendente dal moneta fiat. Questa tecnica si basa sulla teoria che due società dello stesso settore sono probabilmente esposte a simili fattori di mercato, che influenzano le loro attività. Occasionalmente i loro relativi prezzi azionari divergono a causa di determinati eventi, ma nel lungo periodo tengono a tornare verso la media.

Consideriamo due titoli del settore energetico Approach Resources Inc (AREX) e Whiting Petroleum Corp (WLL). Entrambi sono esposti alle stesse condizioni di mercato e quindi sono collegate in modo stazionario. Si può studiare le relazioni tra questa coppia di titoli usando le librerie Pandas e Matplotlib. Il primo grafico (Figura 1) mostra i rispettivi storici dei prezzi dal 1 ° gennaio 2012 al 1 ° gennaio 2013.

Fig 1 - Grafico dei prezzi di AREX e WLL
Se creiamo il grafico di dispersione dei loro prezzi, si osserva una relazione sostanzialmente lineare (vedi Figura 2) per questo periodo.
Fig 2 - Grafico della dispersione dei prezzi di AREX e WILL

Il pairs trading si basa su un modello lineare per identificare la relazione tra i prezzi di due azioni:

\(\begin{eqnarray}
y(t) = \beta x(t) + \epsilon(t)
\end{eqnarray}\)

Dove y(t) è il prezzo del titolo AREX e x(t) è il prezzo del titolo WLL, entrambi per il giorno t.

Se tracciamo i residui ε(t) = y(t) – βx(t) (per un particolare valore di β che determineremo in seguito) si crea una nuova serie temporale che, a prima vista, sembra relativamente stazionaria. Il grafico è mostrato in Figura 3:

Fig 3 - Grafico dei Residui della Regressione Lineare tra AREX e WLL

Test di Dickey-Fuller Aumetato e Cointegrato

Al fine di confermare statisticamente se questa serie è di tipo mean-reverting, si può utilizzare uno dei metodi descritti nell’articolo precedente, vale a dire il test Dickey-Fuller aumentato o l’esponente di Hurst. Tuttavia, nessuno di questi due test può determinare β, il rapporto di coperta (Hedge Ratio) necessario per formare la combinazione lineare, quindi possono solo verificare se, per un particolare β, la combinazione lineare è stazionaria.

È qui che entra in gioco il test Cointegrated Dickey-Fuller (CADF). Questo metodo determina il rapporto di correlazione ottimale eseguendo una regressione lineare rispetto alle due serie temporali e quindi verifica la stazionarietà di una combinazione lineare.

Implementazione in Python

La verifica della relazione di cointegrazione tra AREX e WLL per il periodo dal 1 ° gennaio 2012 al 1 ° gennaio 2013 può essere effettuata facilmente sfruttando le librerie di Python. Come fonte di dati per questo esempio è sufficiente utilizzare Yahoo Finance, mentre per eseguire il test ADF, come sopra, si utilizza la libreria Statsmodels. Il primo passo è creare un nuovo file, cadf.py, e importare le librerie necessarie. Il codice utilizza NumPy, Matplotlib, Pandas e Statsmodels. Per poter etichettare correttamente gli assi e scaricare i dati da Yahoo Finance tramite panda, importiamo il modulo matplotlib.dates e il modulo pandas.io.data. Usiamo anche la funzione dei minimi quadrati ordinari (OLS) presente in pandas:
#!/usr/bin/python
# -*- coding: utf-8 -*-

# cadf.py

import datetime
import numpy as np
import matplotlib.pyplot as plt
import matplotlib.dates as mdates
import pandas as pd
import pandas.io.data as web
import pprint
import statsmodels.tsa.stattools as ts

from pandas.stats.api import ols

La prima funzione, plot_price_series, accetta un DataFrame panda come input, e due colonne identificate con stringhe “ts1” e “ts2”. Queste saranno le nostre coppie di azioni. Semplicemente la funzione traccia le due serie di prezzi sullo stesso grafico. Questo ci consente di verificare visivamente se esiste una probabile cointegrazione.

Usiamo il modulo dates di Matplotlib per ottenere i mesi dagli oggetti datetime. Quindi creiamo una figura e un insieme di assi su cui applicare l’etichettatura. Infine, stampiamo in output il grafico:

# cadf.py

def plot_price_series(df, ts1, ts2):
    months = mdates.MonthLocator()  # every month
    fig, ax = plt.subplots()
    ax.plot(df.index, df[ts1], label=ts1)
    ax.plot(df.index, df[ts2], label=ts2)
    ax.xaxis.set_major_locator(months)
    ax.xaxis.set_major_formatter(mdates.DateFormatter('%b %Y'))
    ax.set_xlim(datetime.datetime(2012, 1, 1), datetime.datetime(2013, 1, 1))
    ax.grid(True)
    fig.autofmt_xdate()

    plt.xlabel('Month/Year')
    plt.ylabel('Price ($)')
    plt.title('%s and %s Daily Prices' % (ts1, ts2))
    plt.legend()
    plt.show()

 

La seconda funzione, plot_scatter_series, traccia il grafico di dispersione dei due prezzi. Questo ci consente di verificare visivamente se esiste una relazione lineare tra le due serie e quindi se può essere un buon candidato per la procedura OLS e il successivo test ADF:

# cadf.py

def plot_scatter_series(df, ts1, ts2):
    plt.xlabel('%s Price ($)' % ts1)
    plt.ylabel('%s Price ($)' % ts2)
    plt.title('%s and %s Price Scatterplot' % (ts1, ts2))
    plt.scatter(df[ts1], df[ts2])
    plt.show()

 

La terza funzione, plot_residuals, è progettata per tracciare i valori residui del modello lineare adattato delle due serie di prezzi. Questa funzione richiede che il DataFrame abbia una colonna “res”, che rappresenta i prezzi residui:

# cadf.py

def plot_residuals(df):
    months = mdates.MonthLocator()  # every month
    fig, ax = plt.subplots()
    ax.plot(df.index, df["res"], label="Residuals")
    ax.xaxis.set_major_locator(months)
    ax.xaxis.set_major_formatter(mdates.DateFormatter('%b %Y'))
    ax.set_xlim(datetime.datetime(2012, 1, 1), datetime.datetime(2013, 1, 1))
    ax.grid(True)
    fig.autofmt_xdate()

    plt.xlabel('Month/Year')
    plt.ylabel('Price ($)')
    plt.title('Residual Plot')
    plt.legend()

    plt.plot(df["res"])
    plt.show()

 

Infine, la procedura è racchiusa in una funzione __main__. Il primo compito è scaricare i dati OHLCV per AREX e WLL da Yahoo Finance. Quindi creiamo un DataFrame separato, df, utilizzando lo stesso indice del frame AREX per archiviare entrambi i valori di prezzo di chiusura corretti. Quindi tracciamo la serie di prezzi e il grafico di dispersione.

Dopo che i grafici sono completi, i residui vengono calcolati chiamando la funzione pandas ols sulle serie WLL e AREX. Questo ci consente di calcolare il rapporto β. Il rapporto di copertura viene quindi utilizzato per creare una colonna “res” tramite il calcolo della combinazione lineare di WLL e AREX.

Infine, i residui vengono tracciati e il test ADF viene eseguito sui residui calcolati. Quindi stampiamo i risultati del test ADF:

# cadf.py

if __name__ == "__main__":
    start = datetime.datetime(2012, 1, 1)
    end = datetime.datetime(2013, 1, 1)

    arex = web.DataReader("AREX", "yahoo", start, end)
    wll = web.DataReader("WLL", "yahoo", start, end)

    df = pd.DataFrame(index=arex.index)
    df["AREX"] = arex["Adj Close"]
    df["WLL"] = wll["Adj Close"]

    # Plot the two time series
    plot_price_series(df, "AREX", "WLL")

    # Display a scatter plot of the two time series
    plot_scatter_series(df, "AREX", "WLL")

    # Calculate optimal hedge ratio "beta"
    res = ols(y=df['WLL'], x=df["AREX"])
    beta_hr = res.beta.x

    # Calculate the residuals of the linear combination
    df["res"] = df["WLL"] - beta_hr*df["AREX"]

    # Plot the residuals
    plot_residuals(df)

    # Calculate and output the CADF test on the residuals
    cadf = ts.adfuller(df["res"])
    pprint.pprint(cadf)

 

L’output del codice (ad esclusione dei grafici Matplotlib) è il seguente:

(-2.9607012342275936,
 0.038730981052330332,
 0,
 249,
 {'1%': -3.4568881317725864,
  '10%': -2.5729936189738876,
  '5%': -2.8732185133016057},
 601.96849256295991)

Si può vedere che il test statistico di -2.96 è inferiore al valore critico del 5% di -2.87, il che significa che possiamo rifiutare l’ipotesi che non ci sia una relazione di cointegrazione al livello del 5%. Quindi possiamo concludere, con un ragionevole grado di certezza, che AREX e WLL possiedono una relazione di cointegrazione, almeno nel il campione temporale considerato.

Perchè fare il test statistico?

Fondamentalmente, per quanto riguarda il trading algoritmico, i test statistici descritti sopra sono utili per analizzare i profitti che generano quando sono applicati a strategie di trading. Quindi, ha sicuramente senso valutare semplicemente le prestazioni a livello di strategia, al contrario del livello di serie prezzo / tempo? Perché prendersi il disturbo di calcolare tutte le metriche di cui sopra quando possiamo semplicemente utilizzare l’analisi a livello di trade, le metriche di rischio/rendimento e le valutazioni del drawdown?

In primo luogo, qualsiasi strategia di trading implementata basata su una misura statistica delle serie temporali avrà un campione molto più ampio su cui lavorare, dato che quando si calcolano questi test statistici, stiamo facendo uso delle informazioni contenute in ogni candela OHLCV, invece che di ogni trade. Ci saranno molti meno trade round-trip rispetto alle barre e quindi la rilevanza statistica di qualsiasi metrica del livello di trading sarà molto più piccola.

In secondo luogo, qualsiasi strategia che implementiamo dipenderà da alcuni parametri, come i periodi di osservazione per il calcolo dell medie o le misure z-score per entrare / uscire da una operazione, in un contesto di mean-reverting. Quindi le metriche del livello di strategia sono più appropriate per questi parametri, mentre i test statistici sono validi per il campione di serie temporali sottostante.

In pratica, vogliamo calcolare entrambe le serie di statistiche. Python, tramite le librerie pandas e statsmodels, rende questo estremamente semplice. Lo sforzo aggiuntivo è in realtà piuttosto minimo!

Testing Statistico della Mean Reversion

Finora su DataTrading abbiamo parlato dell’identificazione di strategie di trading algoritmico, il backtesting, i securities master database dei titoli e come creare un ambiente di sviluppo software. È giunto il momento di rivolgere la nostra attenzione alla creazione di strategie di trading e di come implementarle.

Uno dei concetti chiave nella cassetta degli attrezzi del trader quantitativo è quello della mean reversion. Questo concetto si riferisce ad una serie temporale che mostra una tendenza a ritornare verso valore medio. Matematicamente, una tale serie temporale (continua) viene definita processo Ornstein-Uhlenbeck. Questo è in contrasto con random walk (moto Browniano), dove non si prevede “memoria” dei valori pregressi in ogni specifica istanza di tempo. La proprietà mean-reverting di una serie temporale può essere sfruttata al fine di produrre strategie di trading redditizie.

In questo articolo verranno illustrati i test statistici necessari per identificare la mean reversion. In particolare, studieremo il concetto di stazionarietà e come testarla.

Testing per la Mean Reversion

Una serie temporale continua di mean-reverting può essere rappresentata da un’equazione differenziale stocastica di Ornstein-Uhlenbeck:
\(\begin{eqnarray}
d x_t = \theta (\mu – x_t) dt + \sigma dW_t
\end{eqnarray}\)

Dove θ è la velocità del processo di reversion, μ è il prezzo medio di lungo periodo verso cui avviene la reversione, σ è la varianza del processo e Wt è un processo Wiener o moto browniano.

L’equazione afferma che la “tendenza” delle serie di prezzi nel prossimo periodo di tempo è proporzionale alla differenza tra il prezzo medio e il prezzo corrente, con l’aggiunta del rumore gaussiano.

Questa proprietà è dimostata del test Augmented Dickey-Fuller, che descriveremo di seguito.

Il Test Dickey-Fuller Aumentato (ADF)

Matematicamente, l’ADF si basa sulla verifica della presenza di un trend o radici unitarie a root unit in un campione di serie temporali autoregressive. Sfrutta il fatto che se una serie di prezzi possiede una mean revertion, allora il livello di prezzo successivo sarà proporzionale al livello di prezzo corrente. 

Queste serie storiche sono rappresentate matimaticamente da un modello di regressione lineare di ordine p:

\(\begin{eqnarray}
\Delta y_t = \alpha + \beta t + \gamma y_{t-1} + \delta_1 \Delta y_{t-1} + \cdots + \delta_{p-1} \Delta y_{t-p+1} + \epsilon_t
\end{eqnarray}\)

Dove α è una costante, β rappresenta il coefficiente di andamento temporale e Δyt = y (t) -y (t-1).

Il test ADF prevede che  il processo autogressivo di ordine p=1 abbia una media nulla, cioè γ = 0, che si traduce con α = β = 0 e quindi identifica il processo come casuale e non mean-reverting.

Se si può eliminare l’ipotesi che γ = 0, allora il movimento della serie di prezzi è proporzionale al prezzo corrente e quindi è improbabile che sia casuale.

Quindi, come viene eseguito il test ADF? Il primo compito è calcolare la statistica di prova \(DF_{\tau}\), che è data dalla costante di proporzionalità del campione \(\hat{\gamma}\) divisa per l’errore standard della costante di proporzionalità del campione:

\(\begin{eqnarray} DF_{\tau} = \frac{\hat{\gamma}}{SE(\hat{\gamma})} \end{eqnarray}\)

Dickey e Fuller hanno calcolato la distribuzione di questa statistica di test, che ci consente di scartare l’ipotesi per qualsiasi specifico valore percentuale scelto. La statistica del test è un numero negativo e quindi, per essere significativo, il numero deve essere più negativo di questi valori, cioè inferiore ai valori critici.

In sostanza, per i trader è che qualsiasi deriva a lungo termine in termini di  prezzo è molto probabile rispetto a qualsiasi fluttuazione a breve termine e quindi il modello approssima a zero la deriva (β = 0).

Poiché stiamo considerando un modello di regressione di ordine p, è necessario definire p con uno specifico valore. Di solito è sufficiente, per le strategie di trading, impostare p = 1 per consentirci scartare l’ipotesi nulla.

Per calcolare il test Dickey-Fuller aumentato possiamo utilizzare le librerie pandas e statsmodels. La prima ci fornisce un metodo diretto per ottenere i dati Open-High-Low-Close-Volume (OHLCV) da Yahoo Finance, mentre il secondo implementa il test ADF in una funzione facile da richiamare.

Effettueremo il test ADF su i dati storici delle azioni di Google, dal 1 ° gennaio 2000 al 1 ° gennaio 2013.

Serie dei prezzi Google dal 01/01/2000 to 01/01/2013
Di seguito il codice Python per eseguire il test:
# Import the Time Series library
import statsmodels.tsa.stattools as ts

# Import Datetime and the Pandas DataReader
from datetime import datetime
from pandas.io.data import DataReader

# Download the Google OHLCV data from 1/1/2000 to 1/1/2013
goog = DataReader("GOOG", "yahoo", datetime(2000,1,1), datetime(2013,1,1))

# Output the results of the Augmented Dickey-Fuller test for Google
# with a lag order value of 1
ts.adfuller(goog['Adj Close'], 1)
Ecco il risultato del test di Dickey-Fuller Aumentato per le azioni Google nel periodo considerato. Il primo valore è il valore della statistica test, il secondo valore è il p-value. Il quarto è il numero di punti nel campione. Il quinto valore, il dizionario, contiene i valori critici della statistica del test rispettivamente ai valori 1, 5 e 10%.
(-2.1900105430326064,
 0.20989101040060731,
 0,
 2106,
 {'1%': -3.4334588739173006,
  '10%': -2.5675011176676956,
  '5%': -2.8629133710702983},
 15436.871010333041)
Poiché il valore della statistica test è maggiore di uno qualsiasi dei valori critici, sui livelli 1, 5 o 10 percento, non possiamo respingere l’ipotesi nulla di γ = 0 e quindi è improbabile che abbiamo trovato una serie temporale mean reverting. Un metodo alternativo per identificare una serie temporale mean reverting sfrutta il concetto di stazionarietà, di cui parleremo ora.

Testing per la Stazionarità

Una serie temporale (o processo stocastico) è definita fortemente stazionaria se la sua distribuzione di probabilità congiunta non cambia se viene traslata nel tempo o nello spazio. In particolare, e di fondamentale importanza per i trader, la media e la varianza del processo non cambiano nel tempo o nello spazio e nessuno di essi stia seguendo un trend. Una caratteristica fondamentale delle serie di prezzi stazionarie è che i prezzi all’interno della serie si allontanano dal loro valore iniziale più lentamente rispetto al moto browniano geometrico. Misurando il tasso di questo comportamento possiamo identificare la natura delle serie temporali. Descriveremo ora un parametro, ovvero l’Esponente di Hurst, che ci aiuta a caratterizzare la stazionarietà di una serie temporale.

Esponente Hurst

L’Espondente di Hurst Exponent rappresenta un valore scalare che può essere d’aiuto ad identificare (entro i limiti della stima statistica) se una serie è mean reverting, random walking o trending. L’idea alla base del calcolo dell’esponente consiste nell’usare la varianza dei logaritmi di una serie di prezzi per valutare il tipo di comportamento della struttura. Per un intervallo di tempo arbitrario τ, la varianza è data da:
\(\begin{eqnarray} {\rm Var}(\tau) = \langle |\log(t+\tau)-\log(t)|^2 \rangle \end{eqnarray}\)
Dal momento che si sta confrontando il tasso di diffusione con quello di un moto browniano geometrico, si può dire che τ è abbastanza grande e quindi la varianza è proporzionale a τ, come nel caso di un GBM:
\(\begin{eqnarray} \langle |\log(t+\tau)-\log(t)|^2 \rangle \sim \tau \end{eqnarray} \)
L’idea chiave è che se esistono alcune autocorrelazioni (ad esempio un qualsiasi movimento sequenziale del prezzo con una correlazione diversa da zero), la relazione di cui sopra non è valida. Ciò nonostate, può essere modificato per includere il valore esponenziale “2H”, da cui calcolare il valore H dell’Esponente di Hurst:
\(\begin{eqnarray} \langle |\log(t+\tau)-\log(t)|^2 \rangle \sim \tau^{2H} \end{eqnarray} \)

Una serie temporale può quindi essere caratterizzata nel seguente modo:

  • H <0,5 – Le serie temporali sono mean reverting;
  • H = 0.5 – Le serie temporali sono in un moto browniano geometric;
  • H> 0,5 – Le serie temporali sono in trend

Oltre alla caratterizzazione delle serie temporali, l’esponente di Hurst descrive anche il grado in cui una serie si comporta nel modo categorizzato. Ad esempio, un valore di H vicino allo 0 vuol dire che una serie ha un’elevata mean-reverting, mentre per H vicino a 1 la serie è fortemente in trend.

Per calcolare l’esponente di Hurst per la serie di prezzi di Google, gli stessi ustati come esempio per l’ADF, possiamo usare il seguente codice Python:

from numpy import cumsum, log, polyfit, sqrt, std, subtract
from numpy.random import randn

def hurst(ts):
	"""Returns the Hurst Exponent of the time series vector ts"""
	# Create the range of lag values
	lags = range(2, 100)

	# Calculate the array of the variances of the lagged differences
	tau = [sqrt(std(subtract(ts[lag:], ts[:-lag]))) for lag in lags]

	# Use a linear fit to estimate the Hurst Exponent
	poly = polyfit(log(lags), log(tau), 1)

	# Return the Hurst exponent from the polyfit output
	return poly[0]*2.0

# Create a Gometric Brownian Motion, Mean-Reverting and Trending Series
gbm = log(cumsum(randn(100000))+1000)
mr = log(randn(100000)+1000)
tr = log(cumsum(randn(100000)+1)+1000)

# Output the Hurst Exponent for each of the above series
# and the price of Google (the Adjusted Close price) for 
# the ADF test given above in the article
print "Hurst(GBM):   %s" % hurst(gbm)
print "Hurst(MR):    %s" % hurst(mr)
print "Hurst(TR):    %s" % hurst(tr)

# Assuming you have run the above code to obtain 'goog'!
print "Hurst(GOOG):  %s" % hurst(goog['Adj Close'])
Mandando in esecuzione il code Python si ottiene il seguente output:
Hurst(GBM):   0.500606209426
Hurst(MR):    0.000313348900533
Hurst(TR):    0.947502376783
Hurst(GOOG):  0.50788012261

Da questa output si nota come il movimento browniano geometrico possiede un esponente di Hurst, H, che è quasi esattamente 0,5. La serie di mean reverting ha H quasi uguale a zero, mentre la serie in trend ha H vicino a 1.

È interessante notare che Google ha anche H quasi uguale a 0,5 che indica che è estremamente simile ad una random walk geometrica (almeno nel periodo considerato).

Ora che abbiamo un metodo per caratterizzare la natura di una serie temporale di prezzi, dobbiamo discutere quanto il valore H sia statisticamente significativo. Dobbiamo essere in grado di determinare se sia possiamo rifiutare l’ipotesi nulla che H = 0.5 in modo da valutare un comportamento mean reverting o di trend.

Negli articoli successivi descriveremo come calcolare che H è statisticamente significativa. Inoltre, prenderemo in considerazione il concetto di cointegrazione, che ci consentirà di creare le nostre serie temporali di mean-reverting da più serie di prezzi differenti. Infine, uniremo insieme queste tecniche statistiche al fine di formare una strategia di trading mean reverting di base.

Il Backtesting di una Strategia di Trading Algoritmico – Parte II

Nel primo articolo sul backtesting di una strategia sono stati introdotti i bias statistici e comportamentali che influenzano le prestazioni del backtest. Inoltre sono stati descritti i principali linguaggi di programmazione usati per il backtesting, tra cui Excel, MATLAB, Python, R e C ++. In questo articolo si vuole descrivere come incorporare i costi di transazione ed alcune vincoli che devono essere introdotti quando si crea un motore di backtest, come i tipi di ordine e la frequenza dei dati.

Costi di Transazione

Uno degli errori più diffusi dei principianti quando si implementano modelli di trading è di trascurare (o grossolanamente sottostimare) gli effetti dei costi di transazione su una strategia. Inoltre spesso si presume che i costi di transazione comprendano solo le commissioni dei broker, esistono in realtà molti altri modi in cui i costi possono essere accumulati in un modello di trading. I tre principali tipi di costi che devono essere considerati includono:

Commissioni

La forma più diretta di costi di transazione causati dall’esecuzione di una strategia di trading algoritmico sono le commissioni. Tutte le strategie richiedono una qualche forma di accesso a un mercato, direttamente o attraverso un intermediario  (“il broker”). Questi servizi comportano un costo incrementale con ogni operazione, nota come commissione.

Generalmente i broker forniscono molti servizi, quindi le commissioni di intermediazione sono spesso piccole per un trade base. Inoltre i broker addebitano altri tipi di commissioni, che tengono conto dei costi sostenuti per gestire e liquidare le posizioni. Oltre a questo ci sono le imposte dei governi regionali o nazionali. Ad esempio, è prevista l’imposta di bollo per le transazioni in titoli azionari. Poiché le commissioni, le tasse e le imposte sono generalmente fisse, è relativamente semplice da implementare queste logiche in un motore di backtest (vedi il codice sotto).

Slippage/Latency

Lo slippage è la differenza di prezzo raggiunta tra il momento in cui un sistema di trading decide di effettuare una operazione e il momento in cui una operazione viene effettivamente eseguita nel mercato. Lo slippage è una componente considerevole dei costi di transazione e può fare la differenza tra una strategia molto redditizia e una che fa perdere denaro. Lo slippage è funzione della volatilità delle attività sottostanti, della latenza tra il sistema di trading e l’exchange e del tipo di strategia in corso.

Uno strumento con maggiore volatilità ha più probabilità che si verifichi dei movimenti  e quindi i prezzi tra il segnale ed l’esecuzione possono essere diversi. La latenza è definita come la differenza di tempo tra la generazione del segnale e il punto di esecuzione. Le strategie di frequenza più elevata sono più sensibili ai problemi di latenza e anche solo migliorare le performance di pochi millisecondi può fare la differenza in termini di redditività. Anche il tipo di strategia è importante. Le strategie di momentum sono più influenzate dallo slippage  perché stanno cercando di acquistare strumenti che si stanno già muovendo nella direzione prevista. Mentre per le strategie di mean-reverting risento poco dello slippage, poiché queste strategie stanno operando in direzione opposta al mercato.

Market Impact/Liquidity

L’impatto sul mercato è il costo sostenuto dai trader a causa delle dinamiche  domanda / offerta dell’exchange (e del strumento) con il quale si sta operando. Un ordine importante su un asset relativamente illiquido potrebbe sostanzialmente spostare il mercato poichè l’exchange avrà bisogno di accedere a una grande percentuale della quantità disponibile per quel specifico asset. Per contrastare questo, le grandi operazioni sono suddivise in “blocchi” più piccoli e vengono negoziate periodicamente, appena entra nuova liquidità nel mercato. Al contrario, per gli strumenti altamente liquidi come il contratto futures E-Mini sull’indice di S&P500, è improbabile che le operazioni a basso volume provochi l’esecuzione di un solo blocco di questi grandi ordini.

Inoltre le attività illiquide sono caratterizzate da uno spread più ampio, che è la differenza tra gli attuali prezzi bid e ask presenti nell’order-book. Questo spread è un costo di transazione aggiuntivo, presente per ogni trade. Lo spread è una componente molto importante del costo totale della transazione.

Modelli di Costi di Transazione

Al fine di modellare con successo i costi di cui sopra all’interno di un sistema di backtesting, sono stati introdotti modelli di transazioni con vari gradi di complessità. Si va dalla semplice modellazione flat a un’approssimazione quadratica non lineare. Qui illustreremo i vantaggi e gli svantaggi di ciascun modello:

Modelli Flat / a costo di transazione fisso

I costi di transazione flat sono la forma più semplice di modellazione dei costi di transazione. Si assume un costo fisso associato ad ogni operazione. Pertanto rappresentano al meglio il concetto di fees e commissioni di intermediazione. Non sono molto accurati per la modellazione di comportamenti più complessi come lo slippage o l’impatto sul mercato. In realtà, non considerano affatto la volatilità degli asset o la loro liquidità. Il loro principale vantaggio è che sono computazionalmente semplici da implementare. Tuttavia, è probabile che i costi di transazione siano significativamente inferiori o superiori a seconda della strategia utilizzata. Quindi nella pratica sono raramente usati.

Modelli di costo Lineare / Lineare a tratti / Quadratica

I modelli di costo di transazione più avanzati partono da modelli lineari, proseguono con modelli lineari a tratti e si concludono con modelli quadratici. Si trovano su uno spettro dal meno preciso al più accurato, anche con minimi sforzi di implementazione. Poiché lo slippage e l’impatto sul mercato sono fenomeni intrinsecamente non lineari, le funzioni quadratiche sono le più accurate nel modellare queste dinamiche. I modelli di costo delle transazioni quadratiche sono molto più difficili da implementare e possono richiedere molto più tempo per il calcolo rispetto ai modelli semplici o lineari, ma sono quelli maggiormente usati nella pratica.

I trader algoritmici tentano inoltre di utilizzare i costi effettivi delle operazioni storiche delle loro strategie in produzione come input per i loro attuali modelli di transazione in modo da renderli più accurati. Questo è un aspetto complesso e coinvolge approcci avanzati per la modellizzazione della volatilità, dello slippage e dell’impatto sul mercato. Tuttavia, se la strategia di trading sta muovendo grandi volumi in brevi periodi di tempo, allora stime accurate dei costi di transazione sostenuti possono avere un effetto significativo sulla bottom-line della strategia e quindi vale la pena investire nella ricerca di questi modelli.

Problemi nell'implementazione di una Strategia per il Backtesting

Nonostante i costi di transazione sono un aspetto molto importante per l’implementazione di un backtesting efficiente, ci sono molti altri problemi che possono influenzare le prestazioni della strategia.

Tipi di Ordini

Una scelta che un trader algoritmico deve assolutamnete fare consiste nel prevedere come e quando utilizzare i diversi tipi di ordini disponibili nell’exchange/broker. Questa scelta di solito rientra nell’ambito del sistema di esecuzione, ma possono influenzare notevolmente anche le prestazioni della strategia in backtesting. Esistono due tipi di ordini che possono essere eseguiti: ordini a mercato e ordini limite.

Un ordine a mercato esegue immediatamente una transazione, indipendentemente dal prezzo disponibile. Pertanto, le grandi operazioni con ordini a mercato sono spesso eseguite in un range ampio di di prezzi dato che viene associato una successione di piccoli ordini limite presenti nell’oder-book. Gli ordini di mercato sono considerati ordini aggressivi in ​​quanto sono quasi certamente liquidati, anche se con un costo potenzialmente sconosciuto.

Gli ordini limite forniscono alla strategia un metodo per determinare il prezzo peggiore al quale verrà eseguito un trade, con l’avvertimento che il trade potrebbe non essere eseguito parzialmente o completamente. Gli ordini limite sono considerati ordini passivi poiché spesso non sono disponibili, ma quando lo sono hanno un prezzo garantito. L’insieme degli ordini limite in un singolo exchange è chiamato limiti order-book, che consiste essenzialmente una coda di ordini di acquisto e vendita a determinati prezzi e dimensioni.

Quando si esegue il backtest, è essenziale modellare correttamente gli effetti dell’uso degli ordini a mercato o degli ordini limite. In particolare, per le strategie ad alta frequenza, i backtest possono significativamente sovraperformare il trading dal vivo se gli effetti dell’impatto sul mercato e il limit order-book non sono modellati accuratamente.

Peculiarità dei dati OHLC

Vi sono particolari problemi relativi alle strategie di backtesting quando si utilizzano dati giornalieri sotto forma di dati Open-High-Low-Close (OHLC), specialmente per le azioni. Si noti che questo è esattamente il formato dei dati che è usato dalla maggior parte dei trader algoritmici retail!

I set di dati economici o gratuiti, pur soffrendo del bias di sopravvivenza (che abbiamo discusso nella Parte I), sono spesso feed di prezzi ottenuti dalla composizione dei dati proveniente da più exchange. Ciò significa che i punti estremi (cioè open, close, high e low) dei dati sono molto sensibili ai valori “periferici” dovuti ai piccoli ordini effettuati negli exchange regionali. Inoltre, a volte questi dati hanno più probabilità di contentere gli  errori di tick, che devono ancora essere rimossi.

Ciò significa che se la tua strategia di trading fa ampio uso di uno qualsiasi dei punti OHLC, le prestazioni di backtest possono differire dalla performance dal vivo poiché gli ordini potrebbero essere indirizzati a diversi exchange, a seconda del tuo broker e dell’accesso alla  liquidità disponibile per l’asset scelto. L’unico modo per risolvere questi problemi consiste nell’utilizzare dati con frequenza più alta o ottenere direttamente i dati direttamente da un singolo exchange, piuttosto che un feed composito da più sorgenti.

 

Nei prossimi articoli vedremo come misurare le prestazioni del backtesting, nonché un esempio reale di un algoritmo di backtesting, con molti degli effetti sopra inclusi

Il Backtesting di una Strategia di Trading Algoritmico – Parte I

Questo articolo continua la serie sul trading quantitativo, che è iniziato con il tutorial introduttivo e l’articolo sull’identificazione di una strategia. Entrambi questi articoli sono molti lunghi e dettagliati, quindi continuerò su questo tema e voglio fornire ulteriori dettagli relativi al backtesting di una strategia.

Il backtesting algoritmico richiede competenze in molte aree, tra cui psicologia, la matematica, la statistica, lo sviluppo software e la conoscenza della microstruttura del mercato (o exchange). Non è possibile coprire tutti questi argomenti in un solo articolo, quindi  dividerò la trattazione in due o tre parti. Si inizia definendo cosa si intende per backtesting per poi descrivere le basi del suo funzionamento. Quindi si evidenziano i bias, già discussi nella Guida introduttiva al Trading Algoritmico. Successivamente si confronta i vari software di backtest disponibili.

Negli articoli successivi esamineremo i dettagli delle implementazioni della strategia che sono spesso menzionati a malapena o del tutto ignorati. Si descrive anche come rendere più realistico il processo di backtest includendo le imperfezioni di un trading exchange. Quindi discuteremo i costi di transazione e come modellarli correttamente nel settaggio di backtest. Concluderemo con una discussione sull’esecuzione del backtesting e forniremo infine un esempio di una semplice strategia quantitativa, nota come mean-reverting pairs trade.

Iniziamo discutendo di cosa sia il backtesting e perché dovremmo prevederlo nel trading algoritmico.

Che cosa è il backtesting?

Il trading algoritmico si distingue dagli altri tipi di investimento perché si può fornire in modo più affidabile le aspettative sulle prestazioni future dell’attività di trading, derivanti dalle performance passate, come conseguenza dell’abbondante disponibilità di dati. Il processo con cui viene effettuato questo è noto come backtesting.

In termini semplici, il backtesting viene eseguito esponendo lo specifico algoritmo di una strategia a un flusso di dati finanziari storici, che restiuisce una serie di segnali di trading. Ogni trade (che qui intendiamo come un “round-trip” di due segnali) è associato ad un utile o ad una perdita. L’accumulo di questo profitto / perdita per tutta la durata del backtest della strategia porterà ad un profitto e una perdita totale (noto anche come “P & L” o “PnL”). Questa è l’essenza dell’idea, anche se ovviamente il “diavolo è sempre nei dettagli”!

Quali sono le motivazioni principali per cui si effettua il backtest di una strategia algoritmica?

  • Filtraggio – Come introdotto nell’articolo sull’identificazione della strategia, l’obiettivo della fase iniziale della ricerca consiste nell’impostare una pipeline strategica e quindi filtrare qualsiasi strategia che non soddisfacesse determinati criteri. Il backtesting ci fornisce un altro meccanismo di filtraggio, in quanto possiamo eliminare le strategie che non soddisfano i criteri in termini di prestazioni.
  • Modellazione – Backtesting ci consente di testare (in tutta sicurezza) i nuovi modelli di determinati fenomeni di mercato, i costi di transazione, il routing degli ordini, la latenza, la liquidità o altre inefficienze del mercato.
  • Ottimizzazione – Sebbene l’ottimizzazione della strategia sia ricca di bias, il backtesting ci consente di aumentare le prestazioni di una strategia modificando la quantità o i valori dei parametri associati a tale strategia e ricalcolandone le prestazioni.
  • Verifica – Le strategie vengono spesso acquistate esternamente, tramite la nostra pipeline strategica. Il backtesting di una strategia garantisce che non sia stato implementata in modo errato. Anche se raramente avremo accesso ai segnali generati da strategie esterne, avremo spesso accesso alle metriche prestazionali come il SharpeRatio e il Drawdown. Quindi possiamo confrontarli con la nostra implementazione.

 

Il backtesting offre una serie di vantaggi per il trading algoritmico. Tuttavia, non è sempre possibile eseguire direttamente il backtest di una strategia. In generale, con l’aumentare della frequenza della strategia, diventa più difficile modellare correttamente gli effetti della microstruttura del mercato e degli exchange. Ciò porta a backtest meno affidabili e quindi a una valutazione più complessa della strategia scelta. Questo è un particolare problema dove il sistema di esecuzione è la chiave per le prestazioni della strategia, come con algoritmi a frequenza ultraelevata.

Sfortunatamente, i backtest sono pieni di bias di tutti i tipi. Abbiamo toccato alcuni di questi problemi negli articoli precedenti, ma ora li discuteremo in modo approfondito.

 

I Bias che influenzano il Backtesting di una Strategia

Esistono numerosi bias che possono influire sulle prestazioni del backtesting di una strategia. Sfortunatamente, questi bias tendono a gonfiare la performance piuttosto che a diminuirla. Pertanto, si dovrebbe sempre considerare un backtest come un ideale limite superiore delle performance effettive della strategia. È quasi impossibile eliminare i bias dal trading algoritmico, quindi è compito dell’algotrader cercare di minimizzarli il più possibile in modo da prendere le decisioni corrette.

Ci sono quattro principali tipoliga di bias a cui prestare estrema attenzione: Optimisation BiasLook-Ahead BiasSurvivorship Biasand Psychological Tolerance Bias.

Optimisation Bias

Questo è probabilmente il più insidioso di tutti i bias a cui il backtesting è soggetto. Si tratta di adeguare o introdurre parametri aggiuntivi fino a quando la performance della strategia sul set di dati storico diventano interessanti. Tuttavia, una volta live, le prestazioni della strategia possono essere notevolmente diverse. Un altro nome per questo bias è “curve fitting” o “data-snooping bias”.

Il bias di ottimizzazione è difficile da eliminare in quanto le strategie algoritmiche spesso implicano molti parametri. In questo caso, i “Parametri” possono essere i criteri di ingresso / uscita, i periodi di osservazione, i periodi di calcolo della media (ovvero il parametro di livellamento della media mobile) o la frequenza di misurazione della volatilità. Il bias di ottimizzazione può essere ridotto al minimo mantenendo il numero di parametri al minimo e aumentando la quantità di dati nel set di allenamento. In effetti, si deve anche fare attenzione a questi ultimi poiché i dati storici più vecchi possono essere soggetti a un regime precedente (come un obbligo normativo) e quindi potrebbero non essere rilevanti per l’attuale strategia.

Un metodo per attenuare questo bias consiste nell’eseguire una sensitivity analysis. Questa analisi consiste nel variare i parametri in modo incrementale e tracciare una “superficie” di prestazioni. In particolare, il ragionamento fondamentale per le scelte dei parametri dovrebbe, insieme a tutti gli altri fattori considerati, portare ad una superficie dei parametri più liscia. Se si dispone di una superficie di prestazione molto nervosa, spesso significa che un parametro non riflette un fenomeno ed è un artefatto dei dati del test. Esiste una vasta letteratura sugli algoritmi di ottimizzazione multidimensionale ed è un’area di ricerca molto attiva. Non mi soffermerò su di esso in questo articolo, ma tienilo a mente quando trovi una strategia con un fantastico backtest!

Look-Ahead Bias

Il bias di previsione viene introdotto in un sistema di backtesting quando i dati futuri vengono accidentalmente inclusi in un punto della simulazione in cui tali dati non sarebbero stati effettivamente disponibili. Se stiamo eseguendo il backtest in ordine cronologico e raggiungiamo il punto temporale N, il bias di look-ahead si verifica quando sono utilizzati i dati relativi a qualsiasi instante N + k, dove k > 0. Gli errori del bias di previsione possono essere incredibilmente insidiosi. Ecco tre esempi di come si può introdurre un bias di previsione:

  • Bug tecnici: gli array / i vettori nel codice hanno spesso iteratori o variabili dell’indice. Offset errati di questi indici possono portare a una distorsione look-ahead, incorporando dati a N + k per k>0.
  • Calcolo dei parametri – Un altro esempio comune di bias di previsione si verifica quando si calcolano i parametri ottimali di una strategia, ad esempio con le regressioni lineari tra due serie temporali. Se l’intera serie di dati (compresi i dati futuri) viene utilizzata per calcolare i coefficienti di regressione, e quindi applicata retroattivamente a una strategia di trading a fini di ottimizzazione, i dati futuri verranno incorporati e si verificherà un bias di previsione.
  • Maxima / Minima – Alcune strategie di trading fanno uso di valori estremi in un determinato periodo di tempo, come l’incorporazione dei prezzi massimi o minimi nei dati OHLC. Tuttavia, poiché questi valori massimi / minimi possono essere calcolati solo alla fine del periodo di tempo di riferimento, viene introdotto un bias di previsione se questi valori vengono utilizzati durante il periodo corrente. È sempre necessario ritardare i valori di almeno un punto per farne uso in qualsiasi strategia di trading.

 

Come nel caso dell’ottimizzazione, bisogna essere estremamente cauti per evitare la sua introduzione. Spesso è la ragione principale per cui le strategie di trading sottoperformano significativamente i loro backtests nel “trading dal vivo”.

Survivorship Bias

Il bias di sopravvivenza è un fenomeno particolarmente pericoloso e può portare a prestazioni notevolmente gonfiate per determinati tipi di strategie. Si verifica quando le strategie vengono testate su set di dati che non includono l’intero universo di asset precedenti che potrebbero essere stati scelti in un determinato momento, ma considerano solo quelli che sono “sopravvissuti” fino al tempo corrente.

Ad esempio, si consideri di testare una strategia su una selezione casuale di azioni prima e dopo il crollo del mercato del 2001. Alcuni titoli tecnologici sono andati in bancarotta, mentre altri sono riusciti a rimanere a galla e persino a prosperare. Se avessimo limitato questa strategia solo alle azioni che hanno superato il periodo di abbattimento del mercato, avremmo introdotto un bias di sopravvivenza perché si effettua il backtesting solamente per le azioni che hanno già dimostrato il loro successo. In realtà, questo è solo un altro caso specifico di distorsione previsionale, poiché le informazioni future vengono incorporate nell’analisi passata.

Esistono due modi principali per mitigare i bias di sopravvivenza nei backtests delle strategie:

  • Set di dati senza bias di sopravvivenza – Nel caso di dati azionari è possibile acquistare set di dati che includono entità rimosse, sebbene non siano a buon mercato e tendano ad essere utilizzate solo da aziende istituzionali. In particolare, i dati di Yahoo Finance NON sono privi di bias, ciò nonostante vengono comunemente usato da molti algotrader retail. Si può anche operare su strumenti che non sono inclini al biasdi sopravvivenza, come certe materie prime (e i loro futures derivati​).
  • Usare dati recenti – Nel caso di titoli azionari, l’utilizzo di un set di dati più recente riduce la possibilità che la selezione di azioni scelta sia ponderata ai soli “sopravvissuti”, semplicemente perché vi è meno probabilità di un delisting delle azioni in brevi periodi. Si può anche iniziare a costruire un personale set di dati libero da bias di sopravvivenza, raccogliendo dati dal tempo corrente in poi. Dopo 3-4 anni, avrai un solido set di dati senza bias con cui testare altre strategie.

 

Considereremo ora alcuni fenomeni psicologici che possono influenzare le prestazioni del trading.

Psychological Tolerance Bias

Questo particolare fenomeno non è spesso discusso nel contesto del trading quantitativo. Tuttavia, è ampiamente discusso in merito a metodi di trading più discrezionali. Ha vari nomi, ma ho deciso di chiamarlo “bias di tolleranza psicologica” perché cattura l’essenza del problema. Quando si creano backtests su un periodo di 5 o più anni, è facile guardare una curva equity tendente al rialzo, calcolare il rendimento annuale composto, il SharpeRatio e persino le caratteristiche del drawdown e essere soddisfatti dei risultati. Ad esempio, la strategia potrebbe avere un drawdown relativo massimo del 25% e una durata massima di drawdown di 4 mesi. Questo non sarebbe atipico per una strategia di momentum. È facile convincersi che si possa tollerare tali periodi di perdite perché il quadro generale è roseo. Tuttavia, in pratica, è molto più difficile!

Se i prelievi storici del 25% o più si verificano nei backtests, allora con ogni probabilità vedrai periodi di drawdown simile nel trading dal vivo. Questi periodi di abbattimento sono psicologicamente difficili da sopportare. Ho osservato in prima persona che cosa può comportare un drawdown esteso, e non è piacevole – anche se i backtests suggeriscono che tali periodi si verificheranno. Il motivo per cui l’ho definito un “bias” è che spesso una strategia che altrimenti avrebbe successo viene fermata durante i periodi di drawdown esteso e quindi porterà ad una sottoperformance significativa rispetto al backtest. Pertanto, anche se la strategia è di natura algoritmica, i fattori psicologici possono ancora avere una forte influenza sulla redditività. L’obiettivo è quello di garantire che se si verificano drawdown di una certa percentuale e durata durante il backtesting, allora ci si dovrebbe aspettare che si verifichino anche nel live trading e sarà necessario perseverare per raggiungere nuovamente la redditività.

 

Pacchetti Software per il Backtesting

Lo spazio delle soluzioni software per il backtesting della strategia è molto vasto. Le soluzioni vanno da sofisticati software a livello istituzionale completamente integrati a linguaggi di programmazione come C ++, Python e R, dove quasi tutto deve essere scritto da zero (o con idonei “plug-in”). Come algotrader siamo interessati ad un equilibrio tra il “possedere” il nostro stack tecnologico di trading rispetto alla velocità e all’affidabilità della nostra metodologia di sviluppo. Ecco le considerazioni chiave per la scelta del software:

  • Abilità di programmazione – La scelta dell’ambiente dipenderà in gran parte dalla tua capacità di programmare il software. Direi che avere il controllo dello stack totale avrà un effetto maggiore sul P&L a lungo termine rispetto all’esternalizzazione del software tramite un fornitore. Ciò è dovuto al basso rischio di avere bug esterni o idiosincrasie che non è possibile risolvere nel software del fornitore, che altrimenti sarebbe facilmente risolvibile se si avesse più controllo sul proprio “stack tecnologico”. Desiderate anche un ambiente in grado di trovare il giusto equilibrio tra produttività, disponibilità delle librerie e velocità di esecuzione. Di seguito faccio la mia raccomandazione personale.
  • Funzionalità di esecuzione / Integrazione con il broker – Alcuni software di backtesting, come Tradestation, si collegano direttamente con una società di intermediazione. Non sono un fan di questo approccio poiché ridurre i costi di transazione è spesso un fattore fondamentale per ottenere un SharpeRatio più elevato. Se sei legato a un particolare broker (e Tradestation “obliga” a farlo), allora avrai più difficoltà a passare ad un nuovo software (o ad un nuovo broker) nel caso fosse necessario. Interactive Brokers fornisce una robusta API, sebbene con un’interfaccia leggermente ottusa.
  • Personalizzazione – Un ambiente come MATLAB o Python offre una grande flessibilità quando si creano strategie algoritmiche in quanto forniscono fantastiche librerie per quasi tutte le operazioni matematiche immaginabili, ma consentono anche un’ampia personalizzazione, ove necessario.
  • Complessità della strategia – Alcuni software non sono tagliati per il crunch numerico o per la complessità matematica. Excel è uno di questi software. Mentre è buono per le strategie più semplici, non può davvero far fronte a numerose risorse o algoritmi più complicati.
  • Minimizzazione del bias – un particolare software o set di dati si presta maggiormente ai bias di trading? Nel caso si desideri creare personalmente tutte le funzionalità, È necessario assicurarsi che non si introducano bug che possono causare bias.
  • Velocità di sviluppo – non è necessario passare mesi e mesi a implementare un motore di backtest. La prototipazione dovrebbe richiedere solo alcune settimane. Assicurati che il tuo software non stia ostacolando i tuoi progressi, solo per afferrare qualche punto percentuale extra nella velocità di esecuzione. C ++ è il must in questo ambito.
  • Velocità di esecuzione – Se la tua strategia dipende completamente dalla velocità di esecuzione (come nel  HFT / UHFT), sarà necessario un linguaggio come C o C++. Tuttavia, in questi ambiti siamo al limite dell’ottimizzazione del kernel Linux e dell’utilizzo FPGA, che è al di fuori dello scopo di questo articolo!
  • Costo – molti degli ambienti software con cui è possibile programmare strategie di trading algoritmico sono completamente gratuiti e open source. In effetti, molti hedge fund fanno uso di software open source per tutti i loro stack di trading algoritmico. Inoltre, Excel e MATLAB sono entrambi relativamente economici e ci sono anche alternative gratuite.

 

Ora che abbiamo elencato i criteri con i quali dobbiamo scegliere la nostra infrastruttura software, voglio esaminare alcuni dei pacchetti più popolari e confrontarli tra loro:

Nota: includo solamente i software disponibili per la maggior parte dei professionisti retail e degli sviluppatori di software. Sono disponibili altri software,  come gli strumenti usati a  livello più istituzionale, ma ritengo che questi siano troppo costosi per essere effettivamente utilizzati in un ambiente retail e non ho  esperienza diretta con questi software.

 
MS ExcelDescrizione: WYSIWYG (what-you-see-is-what-you-get) software di spreadsheet. Estremamente diffuso nel settore finanziario. Dati e algoritmo sono strettamente accoppiati.
Esecuzione: Sì, Excel può essere collegato alla maggior parte dei broker.
Personalizzazione: Le macro VBA permettono funzionalità più avanzate a scapito della complessità di implementazione.
Complessità della Strategia: Strumenti statistici avanzati sono più difficili da implementate, così come le strategie che operano su molti asset.
Minimizzazione dei Bias: Il bias Look-ahead è facile da rilevare tramite funzionalità di evidenziazione delle celle (presupponendo che non sia presente VBA).
Velocità di Sviluppo: Le strategie base sono implementate rapidamente.
Velocità di Esecuzione: Bassa velocità di esecuzione – adatto solo per strategie a bassa frequenza.
Costo: Economico o gratuito (a seconda della licenza).
Alternative: OpenOffice
 
MATLABDescrizione: Ambiente di programmazione originariamente progettato per matematica computazionale, fisica e ingegneria. Molto adatto per le operazioni vettorializzate e quelle che coinvolgono l’algebra lineare numerica. Fornisce una vasta gamma di plugin per il trading quantitativo. In uso in molti hedge fund quantitativi.
Esecuzione: Nessuna capacità di esecuzione nativa, MATLAB richiede un sistema di esecuzione separato.
Personalizzazione: Vasta gamma di plug-in per quasi tutte le aree della matematica computazionale.
Complessità della Strategia: Complessità strategica: molti metodi statistici avanzati già disponibili e ben testati.
Minimizzazione dei Bias: i bias di look-ahead sono più difficili da individuare e richiedeno test approfonditi.
Velocità di sviluppo: brevi script possono facilmente generare sofisticati backtest.

Velocità di esecuzione:
MATLAB è altamente ottimizzato per supponendo un algoritmi vettorizzati / parallelizzati. Scarse prestazioni nei cicli iterati tradizionali.
Costo: circa 1,000$ per una licenza.
Alternative: Octave, SciLab
 
PythonDescrizione:
linguaggio di alto livello progettato per avere una semplicità e rapidità di sviluppo. Ampia gamma di librerie per quasi tutte le attività di coding immaginabili. Sta ottenendo sempre maggiori apprezzamenti ed utilizzi da parte dei hedge fund e banche d’investmento. Non veloce come C/C++ relativamente alla velocità di esecuzione.
Esecuzione: esistono plugin Python per i principali broker, come Interactive Brokers. Quindi il backtest e il sistema di esecuzione possono essere parte dello stesso “stack tecnologico”.
Personalizzazione: Python ha una grandissima comunity di sviluppatori ed è un linguaggio maturo. Ciò garantisce un elevato numero di librerie plugin disponibili. NumPy / SciPy forniscono veloci strumenti di calcolo scientifico e di analisi statistica, essenzialiper il trading quantistico.
Complessità della Strategia: esistono molti plug-in per i principali algoritmi, ma non ha una comunità di algotrader abbastanza grande come quella presente per MATLAB.
Minimizzazione dei Bias: soffre degli stessi problemi di minimizzazione dei bias di qualsiasi altro linguaggio di alto livello. Devi essere estremamente attento ai test.
Velocità di sviluppo: il principale vantaggio di Pythons è la velocità di sviluppo, grazie a robuste funzionalità integrate per il testing.
Velocità di Esecuzione: Non è abbastanza veloce come il C++, ma i componenti per il calcolo scientifico sono ottimizzati e Python può utilizzare con il codice C nativo grazie a specifici plugin
Costo: Gratis/Open Source
Alternative: Ruby, Erlang, Haskell
 
RDescrizione: Ambiente progettato per i metodi statistici avanzati e l’analisi di serie temporali. Vasta gamma di strumenti statistici specifici, econometrici e nativi. Grande comunity di sviluppatori.
Esecuzione: R possiede plugin per alcuni broker, in particolare per Interactive Brokers. Quindi un sistema end-to-end può essere scritto interamente in R.
Personalizzazione: R può essere personalizzato con qualsiasi pacchetto, ma i suoi punti di forza sono in ambito statistico / econometrico.
Complessità della Strategia: utile soprattutto se si eseguono strategie econometriche, statistiche o di apprendimento automatico grazie alle librerie disponibili.
Minimizzazione dei Bias: le possibilità di aver bias è simile a quella di qualsiasi linguaggio ad alto livello, come Python o C++. E’ quindi necessario svolgere dei test.
Velocità di Sviluppo: Con R si possono scrivere rapidamente strategie basate su metodi statistici.
Velocità di esecuzione: R è più lento di C ++, ma è relativamente ottimizzato per le operazioni vettorializzate (come con MATLAB).
Costo: Gratis/Open Source
Alternative: SPSS, Stata
 
C++Descrizione: linguaggio maturo e di alto livello progettato per avere un’elevata velocità di esecuzione. Vasta gamma di librerie quantitative e numeriche. Debug più difficile da eseguire e spesso richiede più tempo di implementazione rispetto a Python o MATLAB. Estremamente prevalente sia in lato di acquisto che di vendita.
Esecuzione: la maggior parte delle API dei broker sono scritte in C ++ e Java. Quindi esistono molti plugin.
Personalizzazione C / C ++ consente l’accesso diretto alla memoria sottostante, quindi è possibile implementare strategie di altissima frequenza.
Complessità della Strategia: C++ STL offre un’ampia gamma di algoritmi ottimizzati. Quasi ogni specifico algoritmo matematico ha un’implementazione C / C++ gratuita e open-source sul web.
Minimizzazione dei Bias: il bias di Look-ahead può essere difficile da eliminare, ma non più difficile di altri linguaggi di alto livello. Possiede buoni strumenti di debug, ma bisogna stare attenti quando si ha a che fare con la memoria sottostante.
Velocità di Sviluppo:C++ è piuttosto lento rispetto a Python o MATLAB per lo stesso algoritmo. Più linee di codice (LOC) spesso portano a una maggiore probabilità di errori.
Velocità di Esecuzione: C/C++ ha una velocità di esecuzione estremamente elevata e può essere ottimizzato per specifiche architetture hardware. Questa è la ragione principale per utilizzarlo.
Costo:Costo: vari compilatori: Su Linux / GCC è gratuito, mentre MS Visual Studio ha diverse tipi di licenze.
Alternative: C#, Java, Scala

 

Diverse strategie richiedono quindi diversi pacchetti software. Le strategie HFT e UHFT sono scritte in C / C ++ (dato che spesso eseguite su GPU e FPGA), mentre le strategie direzionali a bassa frequenza sono facili da implementare in TradeStation, a causa della natura “tutto in uno” del software / broker.

La mia personale scelta è Python in quanto fornisce il giusto grado di personalizzazione, velocità di sviluppo, capacità di test e velocità di esecuzione per le mie esigenze e strategie. Se ho bisogno di qualcosa di più veloce, posso “entrare” in C++ direttamente dai miei programmi Python. Un metodo scelto da molti trader algoritmici consiste nel prototipare le loro strategie in Python e quindi convertire le sezioni di esecuzione più lente in C ++ in modo iterativo. Eventualmente l’intero algoritmo può essere scritto

Nei prossimi articoli sul backtesting descriverò alcune criticità relative all’implementazione di un sistema di backtesting per il trading algoritmico. Si evidenzierà come effettuare la misurazione delle prestazioni della strategia e si illustrerà una strategia esemplificativa.

 

Leggi il secondo articolo di questa serie: Il Backtesting di una Strategia di Trading Algoritmico – Parte II

 

Come identificare le Strategie di Trading Algoritmico

In questo articolo voglio parlare dei metodi con cui io stesso identifico le strategie di trading algoritmico più redditizie. L’obiettivo di oggi è capire in dettaglio come trovare, valutare e selezionare tali sistemi. Descrivere in che modo identificare le migliori strategie a seconda sia del nostro stile di trading che delle prestazioni strategiche, come determinare il tipo e la quantità di dati storici da testare, come valutare nel dettaglio una strategia di trading e infine come procedere verso la fase di backtesting e implementazione di una strategia.

Determinare il proprio stile di trading

Per essere un trader di successo – sia discrezionale che algoritmico – è necessario porsi onestamente alcune domande. Il trading ti offre la possibilità di perdere denaro a un ritmo allarmante, quindi è necessario “conoscerti” per capire quale strategia scegliere.

Direi che la considerazione più importante è essere consapevoli della propria personalità. Il trading, in particolare il trading algoritmico, richiede un grado significativo di disciplina, pazienza e distacco emotivo. Dato che stai lasciando che un algoritmo esegua il trading al tuo posto, è necessario essere determinati ad non interferire MAI con una strategia dopo che viene messa ad operare con denaro reale. Questo può essere estremamente difficile, specialmente nei periodi di forte drawdown. Tuttavia, molte strategie che hanno dimostrato di essere altamente redditizie in un backtest possono essere rovinate da semplici interferenze. Comprendi che se desideri entrare nel mondo del trading algoritmico sarai emotivamente messo alla prova e, che per avere successo, è necessario superare queste difficoltà!

La prossima considerazione riguarda il tempo. Hai un lavoro a tempo pieno? Lavori a tempo parziale? Lavori da casa o hai un lungo tragitto giornaliero? Queste domande aiuteranno a determinare la frequenza delle strategia che dovresti cercare. Per quelli di voi che lavorano a tempo pieno, una strategia di futures infragiornaliero potrebbe non essere appropriata (almeno fino a quando non sarà completamente automatizzata!). I tuoi limiti di tempo dettano anche la tipologia della strategia. Se la tua strategia prevede molti trade e dipende dai feed di notizie (come un terminale Bloomberg), devi chiaramente essere realista riguardo alla tua capacità di gestirlo con successo mentre sei in ufficio! Per quelli di voi con molto tempo a disposizione, o le abilità per automatizzare una strategia, potrebbe essere interessante implementare una strategia di trading ad alta frequenza (HFT).

 

In qualsiasi caso, il trading implica studi e ricerche continui sulle strategie da applicare per mantenere un portafoglio costantemente redditizio. Nessuna strategia rimane “redditizia” per sempre. Quindi parte significativa del tempo assegnato al trading è dedicato al ricerca di nuove strategie. Chiediti se sei pronto a farlo, in quanto può essere la differenza tra una forte redditività o un lento declino verso le perdite.

Devi anche considerare il capitale da dedicare al trading. L’importo minimo ideale generalmente previsto per una strategia quantitativa è di 50.000 USD. Se dovessi ricominciare, inizierei con un importo maggiore, probabilmente più vicino a 100.000 USD. Questo perché i costi di transazione possono essere estremamente costosi per le strategie di media e alta frequenza ed è necessario disporre di capitale sufficiente per assorbirli nei periodi drawdown. Se stai pensando di iniziare con meno di 10.000 USD, dovrai limitarti alle strategie a bassa frequenza, scambiando solo uno o due beni, altrimenti i costi di transazione annullerebbero i profitti.

Interactive Brokers, che è uno dei broker più usati dai trader con competenze di programmazione, grazie alla sua API, prevede un capitale iniziale minimo di 10.000 USD.

 

La programmazione è un fattore importante nella creazione di una strategia di trading algoritmica automatizzata. Essere competenti in un linguaggio di programmazione come C++, Java, C#, Python o R permette di creare autonomamente il gestore di archiviazione dei dati end-to-end, il motore di backtest e il sistema di esecuzione. Questo ha una serie di vantaggi, il principale è la completa comprensione di tutti gli aspetti dell’infrastruttura di trading. Permette anche di esplorare le strategie a più alta frequenza in quanto hai il pieno controllo del tuo “stack tecnologico”. Questo significa che puoi testare il tuo software ed eliminare i bug, ma significa anche dedicare più tempo alla codifica dell’infrastruttura e meno all’attuazione delle strategie, almeno nella prima parte della tua carriera da algotrader. Potresti scoprire di essere a tuo agio nel trading in Excel o MATLAB e puoi esternalizzare lo sviluppo di altri componenti. Cosa che comunque non consiglio, in particolare per i trader che operano ad alta frequenza.

Devi chiederti cosa speri di ottenere con il trading algoritmico. Ti interessa un reddito regolare, per cui speri di ricavare guadagni dal tuo conto di trading? Oppure, sei interessato a un guadagno di capitale a lungo termine e puoi permetterti di fare trading senza la necessità di prelevare i fondi? La dipendenza dal reddito determinerà la frequenza della tua strategia. Prelievi più regolari di reddito richiederanno una strategia di trading a frequenza più alta con una minore volatilità (cioè un SharpeRatio più alto). I trader a lungo termine possono permettersi una frequenza di trading più tranquilla.

Infine, non illuderti di diventare estremamente ricco in un breve lasso di tempo! Il trading di Algo NON è uno schema che permette di arricchirsi rapidamente – semmai può essere uno schema che ti fa diventare povero molto più velocemente. Ci vuole una notevole disciplina, ricerca, diligenza e pazienza per avere successo nel trading algoritmico. Possono essere necessari mesi, se non anni, per generare una redditività costante.

Dove trovare nuove idee di trading algoritmico

Nonostante si pensi il contrario, in realtà è abbastanza semplice individuare strategie di trading redditizie tra quele di pubblico dominio. Mai come ora, le idee di trading sono facilmente disponibili per chiunque. Le riviste di finanza accademica, i blog di trading, i forum di trading, le riviste settimanli di trading e i testi specialistici forniscono migliaia di strategie di trading su cui basare le proprie idee.

Il nostro obiettivo come ricercatori di trading quantitativo è stabilire una pipeline di strategie che ci fornirà un flusso di nuove idee di trading. Idealmente vogliamo creare un approccio metodico per la ricerca, la valutazione e l’implementazione delle strategie che incontriamo. Gli obiettivi della pipeline sono di generare una quantità consistente di nuove idee e di fornirci un quadro per respingere la maggior parte di queste idee con un approccio non emotivo.

E’ necessario stare estremamente attenti a non permettere che i bias cognitivi influenzino la nostra metodologia decisionale. Questo potrebbe essere semplice come avere una preferenza per un asset o un mercato rispetto ad un’altro (ad esempio, l’oro e altri metalli preziosi) perché sono percepiti come più esotici. L’obiettivo deve essere sempre quello di trovare strategie costantemente  redditizie, con aspettative positive. La scelta della classe di attività dovrebbe essere basata su altre considerazioni, quali vincoli di capitale, le commissioni di intermediazione e capacità di leva finanziaria.

Se non conosci il concetto di una strategia di trading, il primo posto da guardare sono i libri di testo. I testi classici offrono una vasta gamma di idee più semplici e dirette con cui familiarizzare con il trading quantitativo. Ecco una selezione che raccomando per coloro che sono nuovi nel trading quantitativo, che gradualmente diventano più sofisticati mentre si procede con la lista:

Il passo successivo per trovare idee di strategie più sofisticate consiste nel consultare blog e forum di trading. Tuttavia, una nota di cautela: molti blog di trading si basano sul concetto di analisi tecnica. L’analisi tecnica si basa sull’uso di indicatori stardard e sulla  psicologia del trader che  determina le trendline o schemi di inversione dei prezzi degli asset.

Nonostante sia estremamente popolare nello mondo del trading, l’analisi tecnica è considerata in qualche modo inefficace dal comunity dei trader  quantitativi. Alcuni hanno suggerito che non sia differente dal leggere un oroscopo o studiare i fondi del caffè, in termini di potere predittivo! In realtà ci sono individui di successo che fanno uso dell’analisi tecnica. Tuttavia, come quants abbiamo a disposizione una strumentazione matematica e statistica più sofisticata, possiamo facilmente valutare l’efficacia di tali strategie basate sull’AT e prendere decisioni basate sui dati piuttosto che basarci sulle considerazioni emotive o sui preconcetti.

Ecco una lista dei migliori blog e forum sul trading algoritmico:

Dopo aver testato e valutato alcun delle strategie più semplici, per strategie più sofisticate è tempo di guardare alla letteratura accademica. Alcune riviste accademiche sono difficili da consultare, senza prevedere elevati abbonamenti o costi una tantum, è possibile consultare specifici server, che sono un repository web dei lavori accademici non ancora pubblicati perchè sono oggetto di revisione. Poiché ci interessa solamente le strategie che possiamo replicare, testare e ottenere una discreta redditività, la revisione prima della pubblicazione è un aspetto meno importante. Il principale svantaggio delle strategie accademiche è che possono spesso essere obsolete, richiedere dati storici oscuri e costosi, operate su asset poco liquide o non tenere conto dei costi delle commissioni, slippage o spread. Può anche non essere chiaro se la strategia di trading deve essere eseguita con ordini di mercato, ordini limite o se contiene stop loss ecc. Quindi è assolutamente essenziale replicare la strategia da soli nel miglior modo possibile, effettuare il backtest e aggiungere costi di transazioni realistici, cioè che includa tutti gli aspetti degli strumenti che vogliamo negoziare.

Ecco un elenco dei più noti server e riviste finanziarie da cui è possibile trarre nuove idee:

Trove nuove strategie quantitative richiede generalmente (ma non solo) una buona esperienza in una o più delle seguenti categorie:

  • Market microstructure – In particolare per le strategie ad alta frequenza, è possibile utilizzare la market microstructure, ossia l’analisi delle dinamiche dell’order-book al fine di generare redditività. Mercati diversi avranno vari limiti tecnologici, regolamentazioni, partecipanti al mercato e vincoli, tutti aspetti che possono essere sfruttati a vantaggio del trader tramite strategie specifiche. Questa è una zona molto sofisticata e i trader retail hanno difficoltà ad essere competitivi in questo spazio, in particolare perché i competor sono  hedge fund quantitativi e ben capitalizzati, con forti capacità tecnologiche.
  • Fund structure – I fondi d’investimento, come i fondi pensione, le partnership di investimento private (hedge fund), le società di consulenza e altri tipi di sono sottoposti sia ad una pesante regolamentazione che dall’enorme capitale da dover gestire. Questi vincoli causano un comportamento “prevedile” e possono essere sfruttati da trader più piccoli e quindi più agili. Ad esempio, i fondi di grandi dimensioni sono soggetti a limiti di capacità a causa delle loro dimensioni. Quindi, se hanno bisogno di scaricare rapidamente (vendere) una quantità di titoli, dovranno essere molto cauti altrimenti rischiano di “spostare il mercato”. Algoritmi sofisticati possono trarre vantaggio da questa e da altre inefficiente in un processo generale noto come fund structure arbitrage.
  • Machine learning/artificial intelligence – Negli ultimi anni gli algoritmi di apprendimento automatico si sono diffusi anche nei mercati finanziari. Approcci con reti neurali e algoritmi genetici sono stati tutti usati per prevedere i movimenti dei prezzi o per ottimizzare le strategie di trading. 
    Ci sono, naturalmente, molte altre aree per i quants da investigare. Discuteremo su come elaborare strategie personalizzate in dettaglio in un articolo successivo.

Continuando a monitorare questi siti su base settimanale o giornaliera, si inizia a ricevere un elenco quasi costante di strategie da una vasta gamma di fonti. Il prossimo passo consiste nel determinare come rifiutare un ampio sottoinsieme di queste strategie al fine di minimizzare lo spreco di tempo e risorse per il backtesting di strategie che potrebbero non essere redditizie.

 

Valutazione delle Strategie di Trading

La prima, e probabilmente la più ovvia, considerazione l’effettiva comprensione della strategia. Siamo in grado di spiegare la strategia in modo conciso o richiederà una serie di eventi e un elenco di parametri senza fine? Inoltre, la strategia ha buone e solide basi realistiche? Ad esempio, si potrebbe verificare qualche comportamento del mercato o qualche vincolo a cui i fondi sono soggetti che potrebbe causare i pattern che si sta tentando di sfruttare? Questo vincolo sarebbe ancora valido in caso di modifiche strutturali, come un’improvvisa e ampia modifica al contesto normativo? La strategia si basa su complesse regole statistiche o matematiche? Si applica a tutte le serie finanziare o è specifica per un determinato strumento o asset?

Si deve costantemente valutare tutti questi fattori quando si cercano nuovi metodi di trading, altrimenti si rischia di sprecare una notevole quantità di tempo nel tentativo di backtesting  e ottimizzare strategie non redditizie.

Una volta compresi i principi alla base della strategia si deve decidere se si adatta al proprio stile di trading. Questa non è una considerazione vaga come sembra! Le strategie differiranno sostanzialmente nelle loro caratteristiche di rendimento. Vi sono alcuni tipi di persone che possono gestire periodi di drawdown più significativi o che sono disposti ad accettare un rischio maggiore al fine di ottenere un rendimento maggiore. Nonostante il fatto che noi, come quants, proviamo ad eliminare il più possibile i bias cognitivi e dovremmo essere in grado di valutare oggettivamente una strategia, i bias si insinueranno sempre. Quindi abbiamo bisogno di mezzi meccanici e non emotivi attraverso i quali valutare le prestazioni delle strategie . Ecco l’elenco dei criteri che osservo quando valuto una potenziale nuova strategia:

  • Metodologia – La strategia è basata sul momentum, mean-reverting, market-neutral, direzionale? La strategia si basa su sofisticate (o complesse!) tecniche statistiche o machine learning difficili da comprendere e che richiedono un dottorato di ricerca in statistica? Queste tecniche introducono una quantità significativa di parametri, che potrebbero portare a errori di ottimizzazione? La strategia è in grado di resistere a un cambio di regime (vale a dire una potenziale nuova regolamentazione dei mercati finanziari)?
  • SharpeRatio – Caratterizza euristicamente il rapporto reward/risk della strategia. Quantifica quanto profitto è possibile ottenere con un accettabile livello di volatilità della curva equity. Naturalmente, è necessario determinare il periodo e la frequenza nei quali i rendimenti e la volatilità (cioè la deviazione standard) sono misurati. Una strategia di frequenza più alta richiederà una maggiore frequenza di campionamento della deviazione standard, ma, per esempio, un tempo complessivo più breve.
  • Leverage: la strategia richiede una leva significativa per essere redditizia? La strategia richiede l’uso di contratti derivati ​​con leva (futures, opzioni, swap) al fine di ottenere un rendimento? Questi contratti a leva possono avere una forte volatilità e quindi possono facilmente portare a margin call. Si dispone del capitale e del temperamento per sopportare tale volatilità?
  • Frequenza – La frequenza della strategia è intimamente legata allo stack tecnologico (e quindi alla competenza tecnologica), al SharpeRatio e al livello generale dei costi di transazione. In generale, le strategie ad alta frequenza richiedono più capitale, sono più sofisticate e più difficili da implementare. Tuttavia, supponendo che motore di backtesting sia performante e privo di bug, queste strategie hanno SharpeRatio molto alti.
  • Volatilità: la volatilità è strettamente correlata al “rischio” della strategia. E’ contraddistinto dal SharpeRatio lo contraddistingue. Una maggiore volatilità degli asset class sottostanti, se non controllata, causa spesso una maggiore volatilità della curva equity e quindi un SharpeRatio più basso. Naturalmente presumo che la volatilità positiva sia approssimativamente uguale alla volatilità negativa. Alcune strategie possono avere una maggiore volatilità al ribasso. Devi essere consapevole di queste caratteristiche.
  • Win / Loss, Average Profit / Loss – Le strategie differiscono nelle loro caratteristiche per il numero di vincite/perdite e per la media profitti/perdite. Si può avere una strategia molto redditizia, anche se il numero di trade  perdenti supera il numero di operazioni vincenti. Le strategie di momentum tendono ad avere questo schema in quanto si basano su un piccolo numero di “grandi successi” per essere redditizi. Le strategie di inversione della tendenza tendono ad avere profili opposti in cui ci molti trade “vincenti”, ma le operazioni in perdita possono incidere molto negativemente sul capitale.
  • Drawdown massimo: il drawdown massimo è Il drawdown è la discesa, la correzione, da un precedente massimo assoluto fino ad un minimo assoluto nella curva equity della strategia. Le strategie del momentum sono ben note per soffrire di periodi di estesi drawdown (a causa di una serie incrementale di molti trade perdenti). Molti trader si disperano nei periodi di drawdown estesi, nonostante i test storici hanno suggerito che questo comportamento è “tipico” per questa strategia. Si deve stabile quale percentuale di drawdown (e in quale periodo di tempo) sono accettabili prima di interrompere l’esecuzione della strategia. Questa è una decisione altamente personale e quindi deve essere valutata attentamente.
  • Capacità / Liquidità – A livello retail, a meno che non si stia tradando uno strumento altamente illiquido (come uno stock a ridotta capitalizzazione), non dovrete preoccuparvi molto della capacità strategica. La capacità determina la scalabilità della strategia a seconda del capitale. Gli hedge fund più grandi hanno notevoli problemi di capacità man mano che le loro strategie aumentano nella dotazione di capitale da gestire.
  • Parametri – Alcune strategie (in particolare quelle presenti nella comunity del Machine Learning) richiedono una grande quantità di parametri. Ogni parametro introdotto rende una strategia più vulnerabile al bias di ottimizzazione (noto come “curve-fitting”). E’ consigliato individuare le strategie con il minor numero di parametri possibile o assicurarsi  di disporre di una sufficiente quantità di dati con cui testare le strategie.
  • Benchmark – Quasi tutte le strategie (a meno che non siano  “absolute return”) sono misurate rispetto a un benchmark di performance. Il benchmark è solitamente un indice che caratterizza un ampio campione dello strumento o mercato su cui la strategia opera. Se la strategia negozia titoli azionari statunitensi a grande capitalizzazione, l’S&P500 sarebbe un benchmark naturale per misurare la propria strategia. I termini “alpha” e “beta”, applicati a strategie di questo tipo. Discuteremo questi coefficienti in modo approfondito negli articoli successivi.

 

Da notare che non abbiamo parlato dei rendimenti effettivi di una strategia. In realtà, i rendimenti forniscono informazioni limitate sull’efficacia della strategia. Non permettono di valutare la leva finanziaria, la volatilità, i benchmark o i requisiti patrimoniali. Pertanto le strategie vengono giudicate raramente solo in base ai loro rendimenti. Considerare sempre le prestazioni relative al rischio di una strategia, prima di esaminare i rendimenti.

In questa fase molte delle strategie trovate dalla nostra pipeline sono respinte immediatamente, dal momento che non soddisfano i requisiti di capitale, i vincoli di leva, la massima tolleranza di drawdown o la volatilità. Le strategie che rimangono possono ora essere utilizzate per il backtesting. Tuttavia, prima che sia possibile, è necessario considerare un criterio finale di esclusione, quello sulla disponibilità dei dati storici su cui testare queste strategie.

Ottenere i dati storici

Al giorno d’oggi, la complessità dei requisiti tecnici per l’archiviazione dei dati storici di tutti le asset class è notevole. Al fine di rimanere competitivi, sia i buy-side (fondi) che i sell-side (banche d’investimento) investono pesantemente nella loro infrastruttura tecnica. È imperativo considerare la sua importanza. In particolare, siamo interessati alla tempestività, all’accuratezza e ai requisiti di archiviazione. Si descrive ora i concetti basi per ottenere dati storici e come memorizzarli. Purtroppo questo è un argomento molto vasto e tecnico, quindi questo articolo non può essere esaustivo. Tuttavia, ho in programma di approfondire questo tema con articoli futuri. Nella sezione precedente si era impostata una pipeline strategica che permetteva di scartare determinate strategie sulla base di alcuni criteri.

In questa sezione filtreremo maggiormente le strategie in base agli approcci scelti per ottenere i dati storici. Le considerazioni principali (soprattutto a livello di trader retail) sono i costi dei dati, i requisiti di archiviazione e il livello di competenza tecnica. Dobbiamo anche discutere i diversi tipi di dati disponibili e le diverse considerazioni che ogni tipo comporta.

Iniziamo identificando i tipi di dati disponibili e le questioni chiave su cui dovremo riflettere:

  • Dati fondamentali – Include i dati sugli andamenti macroeconomici, come tassi di interesse, i dati sull’inflazione, le dinamiche societarie (dividendi, scissioni), i bilanci societari, dati sugli utili, i rapporti sulle colture, dati meteorologici, ecc. Questi dati vengono spesso usati per valutare le società o altre attività su aspetti di ambito fondamentale, ad esempio attraverso i valori attesi per i futuri flussi di cassa. Non include le serie dei prezzi delle azioni. Alcuni dati fondamentali sono disponibili gratuitamente dai siti web dei governi. Altri dati fondamentali storici a lungo termine possono essere estremamente costosi. I requisiti di archiviazione spesso non sono particolarmente ampi, a meno che non vengano studiate contemporaneamente migliaia di società.
  • Dati delle notizie – Questi dati sono spesso di natura qualitativa. Consiste in articoli, post di blog, post di microblog (“tweet”) ed editoriali. Le tecniche di apprendimento automatico sono spesso usate per interpretare il sentiment. Questi dati sono spesso anche liberamente disponibili o economici, tramite l’abbonamento ai media. I nuovi database di archiviazione dei documenti “NoSQL” sono progettati per archiviare questo tipo di dati qualitativi non strutturati.
  • Dati sui prezzi degli asset – Questo è il dominio dei dati tradizionalmente utilizzato dagli algotrader. Consiste in serie temporali dei prezzi degli strumenti finanziari. Azioni (titoli), prodotti a reddito fisso (obbligazioni), materie prime e valute sono tutti presenti all’interno di questa tipologia. Per gli asset più diffusi i dati storici giornalieri sono spesso semplici da ottenere, come per le azioni. Tuttavia, una volta che accuratezza e pulizia sono state incluse e le distorsioni statistiche rimosse, i dati possono diventare costosi. Inoltre, i dati delle serie temporali hanno spesso requisiti di archiviazione significativi, specialmente quando si considerano i dati intraday.
  • Strumenti finanziari – Le azioni, le obbligazioni, i futures e le opzioni derivate più esotiche hanno caratteristiche e parametri molto diversi. Quindi non esiste una struttura di database “universale” che possa gestirli. È necessario prestare particolare attenzione alla progettazione e alla realizzazione dei database per i vari strumenti finanziari utilizzati. Si approfondisce questo tema negli articoli relativi ai securities master database.
  • Frequenza – Maggiore è la frequenza dei dati, maggiori sono i costi e i requisiti di archiviazione. Per le strategie a bassa frequenza, i dati giornalieri sono spesso sufficienti. Per le strategie ad alta frequenza, potrebbe essere necessario ottenere dati a livello di tick e persino i dati storici di particolari order-book. L’implementazione di un motore di archiviazione per questo tipo di dati è molto intensa dal punto di vista tecnologico e adatta solo a coloro che hanno un forte background tecnico / di programmazione.
  • Benchmark – Le strategie sopra descritte saranno spesso confrontate con un benchmark. Questo di solito si manifesta come serie temporali finanziarie aggiuntive. Per le azioni, questo benchmark è spesso un indice azionario nazionale, come l’S&P500 (USA) o il FTSE100 (Regno Unito). Per un fondo a reddito fisso, è utile confrontarsi con un paniere delle obbligazioni o di prodotti a reddito fisso. Anche il “risk-free rate” (cioè il tasso di interesse appropriato) è un altro benchmark ampiamente accettato. Tutte le categorie di asset class possiedono un relativo benchmark di riferimento, quindi sarà necessario effettuare una ricerca in base alla propria particolare strategia, se si desidera ottenere un ritorno interessate per la propria strategia.
  • Tecnologia – Le tecnologie usate dietro un centro di archiviazione di dati finanziari sono complesse. Questo articolo può solo introdurre tutti gli aspetti coinvolti nella costruzione di centro di archiviazione. Tuttavia, si concentra su un motore di database, come un sistema di gestione di database relazionale (RDBMS), come MySQL, SQL Server, Oracle) e uno schema di archiviazione di documenti (ad esempio “NoSQL”). Questo è accessibile tramite il codice che implementa la  “business logic”, interrogando il database e fornendo  l’accesso a strumenti esterni, come MATLAB, R o Excel. Spesso questa logica è scritta in C ++, C #, Java o Python. Bisogna anche bisogno di ospitare questi dati da qualche parte, sul un personal computer, o su un server remoto. Prodotti come Amazon Web Services hanno reso più semplice ed economico questo lavoro, ma richiede comunque una notevole esperienza tecnica per ottenere risultati solidi.

Come si può vedere, una volta che una strategia è stata identificata tramite la pipeline, sarà necessario valutare la disponibilità, i costi, la complessità e i dettagli di implementazione di un particolare insieme di dati storici. Potresti scoprire che è necessario scartare una strategia basandosi esclusivamente su valutazioni dei dati storici. Questo è un tema molto ampio ed è oggetto di lavoro di squadre di ricercatori all’interno dei grandi fondi di investimento, assicurandosi che i prezzi siano accurati e tempestivi. Non sottovalutare le difficoltà di creare un robusto data center per i propri scopi di backtesting!

Voglio sottolineare, tuttavia, che molte piattaforme di backtesting possono fornire questi dati automaticamente, ad un determinato costo. Di conseguenza, si toglie molto lavoro alla gestione dei dati e ci si può concentrare esclusivamente sull’implementazione e l’ottimizzazione della strategia. Strumenti come TradeStation possiedono questa capacità. Tuttavia, la mia opinione personale è quella di implementare internamente il più possibile ed evitare di esternalizzare parti dello stack ai fornitori di software. Preferisco le strategie ad alta frequenza grazie ai loro SharpeRatio più attraenti, ma sono spesso strettamente collegate allo stack tecnologico, dove l’ottimizzazione avanzata è fondamentale.

Ora che abbiamo discusso le questioni relative ai dati storici, è ora di iniziare a implementare le nostre strategie in un motore di backtesting. Questo sarà oggetto di altri articoli, poiché si tratta di un’area di discussione altrettanto ampia!