El proceso de evaluación de una estrategia pasa por tres fases consecutivas en las que intentaremos obtener datos relevantes que permitan acreditar la robustez del sistema y su capacidad para generar beneficios en las condiciones cambiantes del mercado: (a) Pruebas de validez interna empleando el mayor histórico disponible, (b) pruebas de validez externa mediante simulaciones en tiempo real y (c) pruebas a pequeña escala con una fracción del capital disponible.

Las pruebas tipo backtest.

Poder aplicar un algoritmo basado en reglas discretas a históricos de varios años, para obtener, en pocos segundos, una batería completa de estadísticas y gráficos sobre el comportamiento del sistema constituye, sin duda, uno de los mayores alicientes de las plataformas automatizadas de trading. En principio, y como primera aproximación, no hay nada mejor que conocer -aunque solo sea de manera aproximada e incompleta- lo que pudo haber hecho nuestro sistema en el pasado para intuir lo que podrá seguir haciendo en el futuro.

Sin embargo, a poco que profundicemos en la viabilidad de estas extrapolaciones, nos daremos cuenta que plantean problemas de tipo técnico e incluso de índole filosófica de difícil resolución:

• 1) La homogeneidad en el tiempo de la estructura básica de un mercado: Ciclicidad, distribución de rangos, frecuencias de precios y volúmenes, tamaño medio de las barras, incrementos y decrementos de volatilidad, etc. ¿Es un acto de fe o una compleja cuestión filosófica afirmar que la estructura a gran escala de un mercado se conservará de manera más o menos homogénea en el tiempo?

Por otra parte, los organismos reguladores introducen, ocasionalmente, diferentes normas que afectan a la estructura de las cotizaciones: Por ejemplo, bastará con revisar los horarios de contratación o tocar levemente el tamaño del tick para producir cambios significativos en la estructura serial de las barras. No es lo mismo que un mercado europeo que durante años ha cerrado a las 20:00 h., luego lo haga a las 22:00 h., pues la interacción con los mercados USA se notará, y de qué manera, en el tramo horario ampliado. Del mismo modo, tampoco es igual que el emblemático ZB (bono USA a 30 años) reduzca el tamaño del tick a la mitad (de 31,25$ a 15,625$) Todos estos cambios degradan la fiabilidad del histórico y menguan su carácter predictivo al emplear tales datos como materia prima del backtest.

• 2) Las series continuas de datos. Cuando trabajamos con históricos largos de futuros debemos saber el método empleado para ensamblar los distintos vencimientos del producto puede generar distorsiones que afectan al funcionamiento de los sistemas. Esta cuestión ya fue tratada en mi artículo "La importancia de unos datos históricos de calidad" por lo que recomiendo repasar atentamente sus consideraciones generales sobre el empleo de gráficos continuos. Por otra parte, la calidad del proveedor de datos también es un factor importante: Cuando comparamos históricos de distintas fuentes, vemos que ninguno de ellos coincide al 100%: Algunos están plagados de omisiones, discontinuidades y huecos que se rellenan con datos irreales, etc. Otras veces es el modo de comprensión (o asignación de ticks por barra) lo que dará lugar a discrepancias. En general, y siempre que sea posible, recomiendo utilizar la misma fuente de datos para pruebas backtest y operativa real.

• 3) Proceso de asignación de tiempos. Otra cosa de la que casi nadie habla es la forma de asignación horaria a los datos entrantes; lo que se conoce como time stamp. Los proveedores de datos (data vendors) asignan a cada tick entrante, por lo general, una etiqueta horaria. Sin embargo, los datos de mercado distribuidos por diversos brokers no incluyen esta etiqueta, por lo que algunas plataformas, como Ninja Trader, estampan a cada nuevo dato una etiqueta horaria (local time) basada en el reloj del PC. Y ahí es donde radica el problema; sobre todo en barras de pocos minutos.

Nunca encontraremos dos gráficos idénticos, si:

a. La fuente del histórico procede de ordenadores distintos.

b. Necesitamos hacer una recarga de datos desde el servidor empleado como back-up. (Comprobaremos, con cierto desagrado, que lo que ahora estamos viendo en pantalla difiere ligeramente de lo que ya teníamos)

c. Se produce algún retardo en Internet por saturación (particularmente cuando trabajamos en TR con muchas líneas de datos o la conexión no es lo suficientemente rápida. En tal caso, la estampita asignada a cada tick incorporará el retraso de forma acumulativa.

Incluso con el tiempo de latencia normal (±50 ms.) entre un servidor remoto y nuestro PC podrían ocurrir errores acumulativos de datación. Tal y como afirma el propio manual de NT (Ver el tópico; How does Ninja TraderT Built Charts Bars?): "La única manera de estar seguros de que los datos siempre son los mismos sería cuando el proveedor de datos envía los ticks con la etiqueta de tiempo y los diferentes proveedores se sincronizan (eficientemente) al mismo marco horario"; ¿Por ejemplo, con un reloj atómico?

Situaciones típicas que dan lugar a gráficos diferentes e inciertos (y, en consecuencia, backtests irreales).

- Añado el histórico que ya tengo de un proveedor ( por ejemplo, Visual Chart u Opentick) a los datos que voy recibiendo de Interactive Brokers: MAL ASUNTO.

- Como tengo poco histórico de un mercado, un colega me pasa el suyo y lo añado al mío: MAL ASUNTO.

- Me voy de vacaciones y en un ordenador distinto al mío sigo recibiendo los datos del broker, al regresar los añado a los que ya tengo en el ordenador que empleo habitualmente: MAL ASUNTO.

La casuística sería interminable y, como pueden ver, en cada una de las situaciones imaginables, podríamos acabar con históricos ligeramente distintos. ¡Ojo! Lo cual no significa que sean completamente inútiles para el backtest; pero sí de peor calidad. 

• 4) Finalmente, el modo en que la plataforma sitúa las órdenes en backtest es necesariamente distinto al de la operativa real. Esto se debe a los siguientes motivos:

a. Durante las pruebas de backtest la única información disponible es la de barra (O-H-L-C), por lo que el proceso de colocación de órdenes se hace considerando solamente estos cuatro puntos.

b. No se tiene en cuenta de manera dinámica el factor pecio x volumen para determinar si una orden pudo haberse ejecutado o no.

c. Casi todas las plataformas incorporan algoritmos que establecen prioridades entre órdenes y fijan de manera estática o liberal el punto de colocación de ordenes. Pero esto, se hace de manera monótona, mientras que, en operativa real, viene determinado por la compleja dinámica del mercado.

d. También se puede considerar el slippage, pero mediante un valor fijo que en absoluto representa la sensibilidad de la estrategia a los aumentos / decrementos de volatilidad o al tamaño y volumen de la horquilla posicional en cada momento.

Con todo, las pruebas de backtest son necesarias y proporcionan información relevante (aunque preliminar, nunca concluyente) a desarrolladores y usuarios sobre algunos de los siguientes aspectos del desarrollo e implementación de sistemas:

- Determinar el potencial de una estrategia en relación a otros sistemas del mismo tipo.

- Selección de parámetros mediante diferentes algoritmos de optimización y metodologías tipo Walk-forward.

- Elección del time-frame más adecuado al tipo de operativa modelizada.

- Como prueba de validez interna de las reglas empleadas.

- Como forma de aprender, investigar y familiarizarse con el desarrollo e implementación de estrategias.

Operativa simulada en tiempo real.

El segundo e ineludible paso para certificar el funcionamiento de una estrategia será someterla mediante simuladores de operativa (algunos estarán basados en la plataforma caso de NT o VC, en el Broker; cuentas paper trading de IB o en proyectos independientes como Colective2) al flujo continuo de datos del mercado. Este proceso debe ser lago y cuidadoso. Es lo que yo denomino "poner en cuarentena una estrategia". Personalmente, antes de arriesgar un solo euro, suelo tener mis sistemas operando de forma simulada, incluso con diferentes configuraciones de reglas, parámetros y TF, al menos unos seis meses.

El principal objetivo de la operativa simulada es comprobar las respuesta dinámica del sistema en el día a día. Ello proporcionará información mucho más precisa que las anteriores pruebas de backtest, pues:

a) Las órdenes se ejecutan considerando el flujo entrante de información que dará lugar a la formación de cada barra en el TF elegido.

b) Para el posicionamiento se toman en consideración el precio y volumen. Por lo que una orden se completará total o parcialmente en función del volumen asociado a cada unidad de información entrante.

c) También se tomará en consideración el tamaño de la horquilla posicional y el número de contratos disponibles en oferta y demanda (bid-ask).

d) Algunas estrategias utilizan (siempre que la plataforma lo permita) dispositivos de cierre de posiciones que se activan en modo de tick. Lo que dará lugar a stoploss y target-profits mucho más precisos.

Pero, en cualquier caso, no nos engañemos, este tipo de simulaciones, aunque más realistas, tienen algunas limitaciones que conviene conocer:

- El deslizamiento no es igual que el que tiene lugar al introducir las órdenes en el mercado correspondiente. Entre otras cosas, porque el tiempo de retardo en que se incurre al transmitir las órdenes en la secuencia; plataforma > broker > mercado, no se toma en consideración.

- Por desgracia, los procesos psicológicos asociados a la actividad del trader no pueden ser simulados. Cuando el operador sabe que no arriesga su dinero, se limita a observar y raramente interfiere con la operativa del sistema. Pero está por ver si cuando observa en tiempo real que su capital de faena puede aumentar o disminuir cientos o miles de euros en pocas horas será capaz de soportar la fuerte carga emocional asociada.

Por estos motivos, muchos críticos de la operativa simulada consideran que el proceso de evaluación de un sistema sólo se cierra cuando nos aventuramos a operar durante un tiempo relativamente significativo (quizá otros seis meses) en tiempo real y poniendo sobre la mesa dinero real.

En consecuencia, recomiendo a quienes crean superadas las dos anteriores etapas, que den un último paso, arriesgando una pequeña fracción del capital de faena para probar durante un tiempo sus estrategias con dinero contante y sonante. Sólo de este modo habrán cerrado el círculo de "Sistemas y demonios." Por cierto, hace ya casi un año que elaboré esta presentación multimedia. Quizá me anime a publicar otra en breve.

Andrés A. García.

© Tradingsys.org, 2008