13 / 74
13
TRADERS´ 05.2019
representativa del universo objeto de estudio (que cubra
el máximo tipo de mercados posible) Debemos tratar
de simular las condiciones que nos encontraremos
operando en live, como pueden ser las comisiones o
las desviaciones sobre los precios teóricos y los ejecu-
tados (slippage) o que los datos tengan propiedades
homogéneas, por ejemplo, que los cierres tengan lugar
a la misma hora. Como no, deberemos realizar diversas
pruebas de stress, etc. pero esto no es objeto de este
artículo. Centrémonos en los datos, nuestra materia
prima.
Datos de calidad
Como en todo, hay feeds de datos en tiempo real mejores
y peores y lo mismo ocurre con los datos históricos e
igualmente con el software que tiene que procesar esa
información, datos y reglas del sistema.
Estas tres partes son importantes para comprender lo
que es una base de datos de calidad. Los datos histó-
ricos tienen que ser homogéneos en comportamiento y
construcción a los datos live que recibimos en tiempo
real. Y el procesamiento de los datos que hagamos en
live debe ser el mismo que hacemos en el BackTest.
Dicho de otra manera, el BackTest tiene que seguir las
mismas reglas de evaluación que seguirá en live, algo
que no todas las plataformas hacen, con lo que los resul-
tados obtenidos en BackTest no serán reproducibles en
live. Esto último es también muy descuidado o mejor
dicho ignorado, simplemente ni nos cuestionamos si la
forma de evaluar las reglas de nuestro sistema es igual
en live que en BackTest y esto es sencillamente vital
para poder valorar correctamente al sistema. Pues no
lo es en muchas ocasiones, pero volveremos a ello más
adelante. Sigamos ahora con los datos.
En efecto, la muestra debe ser representativa del
universo objeto de estudio y también debe ser repre-
sentativa del comportamiento actual del mercado. Es
muy frecuente ver que en la mayoría de las plataformas
o “feed” de datos, que los datos históricos recientes
tienen buena calidad, sin demasiados gaps erróneos
o ticks perdidos. En cambio, a media que vamos retro-
cediendo hacia atrás, la base de datos va perdiendo
calidad y empiezan a aparecer errores visibles incluso
a simple vista. Si no nos tomamos la molestia de revisar
el histórico esto nos pasará por alto. El problema es que,
estos errores no siempre son visibles a simple vista, por
lo que necesitamos algún método para comprobar si los
datos históricos son correctos o no. El mejor camino
es contratar los datos a un proveedor externo que se
encargue de realizar esta verificación diariamente. Así,
podremos comparar los datos de nuestra plataforma
con los que hemos comprado e incluso usar estos datos
para nuestros BackTest si la plataforma nos permite
importarlos. La comprobación visual puede ser una
tarea ardua pero necesaria; no obstante, puede hacerse
también mediante un código que compare ambas bases
de datos y pinte en un indicador la diferencia entre ellos
o incluso hay algunas plataformas que incluyen herra-
mientas para comparar bases de datos y nos generan un
informe al respecto.
Y lo mismo aplica a los datos en tiempo real. Aunque
aquí debería de haber poca diferencia entre proveedores
de datos, la realidad es que en ocasiones la hay. Depen-
diendo del tipo de barras que usemos esto es más crítico
o menos. El gráfico de ticks suele ser muy conflictivo ya
que al construir las barras usando n número de ticks, si
el feed de datos pierde algunos ticks todas las barras
que se construyan durante la jornada con posterioridad a
esa pérdida quedarán comprometidas. En cambio, en las
barras construidas por tiempo, una pérdida de algunos
ticks afectará a la barra en cuestión, pero no afectará
a las posteriores. Por tanto, si queremos trabajar con
ticks hay que prestar mucha atención en evaluar al
proveedor de datos en tiempo real. También debemos
estar atentos si usamos barras por tiempo. Una de las
principales fuentes de errores es el estampado de la
hora de las velas, lo que puede afectar de manera critica
a los cierres del gráfico.
Los datos en tiempo real son algo que también tenemos
que verificar y, en todo caso, recordar que los datos
de BackTest deben tener las mismas propiedades y
comportamiento que los de live. Si los datos en live
vemos que no son correctos comparados con una base
de datos verificada como fiable, tenemos un problema.
En ocasión un colega me comentó que la solución a
este problema es optimizar en los datos de este mismo
proveedor que estamos viendo que no difunde correcta-
mente los datos. Él defendía que, aunque los datos estén
mal, si optimizamos con ellos ya estamos teniendo
en cuenta el error en la optimización y, por lo tanto, el
sistema se ajustará al error. En mi opinión, esto es total-
mente absurdo. Los datos reales, veraces, son solo unos.
El mercado ayer cerró a un precio, hizo un máximo y un
mínimo. Cualquier otro dato que no sea el real es fruto
de una casualidad o mala praxis en el etiquetado de las
barras, por ejemplo. Por tanto, cualquier regla extraída
de esos datos es casual porque un error de difusión de
datos no es estable. Un error es un error. Recordemos
que un sistema explota una ventaja o ineficiencia, trata
de capturar la señal del mercado que explota tratando de
PERSPECTIVAS