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 quanto segue
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 dato che 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. Di seguito 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 assolutamente 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