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

• Azioni societarie – Errata gestione delle scissioni azionari e gli aggiustamenti dei dividendi. Bisogna essere assolutamente sicuri che le formule siano state implementate correttamente.
• Spike: i picchi di prezzo che superano di gran lunga determinati livelli storici di volatilità. Bisogna stare molto attenti a questi picchi quando si verificano. I picchi possono anche essere causati dal non prendere in considerazione le divisioni azionarie, quando si verificano. Gli script di spike-filter vengono utilizzati per informare i trader di tali situazioni.
• Aggregazione OHLC – I dati OHLC gratuiti, come quelli di Yahoo / Google, sono particolarmente soggetti a situazioni di “cattiva aggregazione di ticker” in cui le piccole borse trattano piccoli scambi ben al di sopra dei prezzi di scambio “principali” per un singolo giorno, portando così a massimi / minimi eccessivi una volta aggregati questi dati. Questo non è un vero e proprio ‘errore’ in quanto tale, ma al più  un problema di cui stare attenti.
• Dati mancanti: i dati mancanti possono essere causati dalla mancanza di scambi in un particolare periodo di tempo (comune nei dati con timeframe al minuti o secondi in azioni small-cap ed illiquidi), dalle giornate di chiusura dei mercati o semplicemente da un errore nel sistema dell’exchange. I dati mancanti possono essere riempiti (cioè riempiti con il valore precedente), interpolati (linearmente o in altro modo) o ignorati, a seconda del sistema di trading.

Molti di questi errori si basano sul giudizio manuale per decidere come procedere. È possibile automatizzare la notifica di tali errori, ma è molto più difficile automatizzare la loro soluzione. Ad esempio, si deve scegliere la soglia per essere informati sui picchi: quante deviazioni standard usare e su quale periodo di ritorno? Un livello troppo alto di stdev salterà alcuni picchi, mentre un livello troppo basso produce molti falsi positivi (come molti annunci di notizie insolite). Tutti questi problemi richiedono un giudizio da parte dell’algotrader.

È anche necessario decidere come correggere gli errori. Gli errori devono essere corretti non appena sono individuati e, in caso affermativo, deve essere eseguita una procedura di controllo? Ciò richiederà una tabella aggiuntiva nel DB. Questo ci porta al tema del back-filling, che è un problema particolarmente insidioso per il backtesting. Riguarda la correzione automatica dei dati errati a monte. Ad esempio se il fornitore di dati inizia a corregge un errore storico, ma la nostra strategia di trading in produzione è stata ottimizzata (backtested)in base alla ricerca dei precedenti dati non validi, è necessario prendere decisioni in merito all’efficacia della strategia. Questo problema può essere un po’ attenuato grazie ad uno studio approfondito delle metriche sul rendimento della strategia (in particolare la variazione delle caratteristiche di vincita / perdita per ogni trade). Le strategie dovrebbero essere scelte o progettate in modo tale che un singolo dato non possa distorcere le prestazioni della strategia.