Expediente Backtest (Parte II)
 
 

Expediente Backtest (Parte II)

 
AndyG - 24 Ago 2018
1 comentario
 

Muchas veces nos hemos preguntado hasta qué punto los resultados de un backtest pueden considerarse realistas. Pero, en mi opinión, esta pregunta debe formularse a la inversa: ¿Qué nivel de realismo necesitamos para evaluar una estrategia dada? Y, como veremos en este artículo, esto depende básicamente de tres factores: Frecuencia operativa, beneficio medio por operación (BMO) y tipo de órdenes empleadas.


EL PROBLEMA DE LA REPLICABILIDAD DE RESULTADOS

 

Cuando trabajamos en operativa real nuestras operaciones no solo están conducidas por la dinámica de un mercado sino que constituyen el propio mercado: A mayor o menor escala Interactúan con él aumentando su profundidad y moviéndolo en un determinado sentido. Una simple orden contribuye a aumentar o ensanchar la horquilla bid/ask y un paquete grande deja una estela de varios ticks hasta ser absorbido por el mercado.

La microestructura de los principales mercados es extremadamente compleja y genera una ingente cantidad de información que ni está disponible en su totalidad ni puede manejar una plataforma de trading convencional. Por tanto, un backtest es una forma simplificada de evaluar el comportamiento de una estrategia y su grado de realismo dependerá de la calidad y densidad los datos históricos que puede manejar la plataforma así como del algoritmo desarrollado para simular el comportamiento de los distintos tipos de órdenes.

Esta sería una escala de la densidad de datos históricos:

  1. Barras diarias.- Solo se dispone de 4 puntos de datos por sesión: O-H-L-C, por lo que el nivel de resolución solo es adecuado para estrategias Long Term que abren y cierran posiciones con órdenes a mercado. Si se utilizan otro tipo de órdenes, como las limitadas, el motor de backtest tiene que hacer ciertas suposiciones sobre los movimientos de precios intrabarra y también sobre los precios al cierre de barra, aun asumiendo que es virtualmente imposible que una orden se ejecute exactamente al precio de cierre. Las tres principales reglas son:

 

-          Una orden puede ser ejecutada en cualquier nivel válido de la horquilla H-L

-          Si el precio de apertura está próximo al máximo de la barra, se asume que el movimiento intrabarra ocurrió en sentido: O-H-L-C.

-          Si el precio de apertura está próximo al mínimo de la barra, entonces se asume un recorrido: O-L-H-C.


2. Barras de minutos.- Son las adecuadas para estrategias intradiarias con una cadencia operativa media y con BMO > 2 ticks. El comportamiento de los sistemas micro-tendenciales que entren con órdenes a mercado podrá replicarse con fiabilidad aceptable. Sin embargo, el grado de realismo disminuirá considerablemente con órdenes limitadas ya que carecemos de información detallada del libro de órdenes en cada punto de datos, por lo que no hay forma de saber si las órdenes que tocan el límite se ejecutan en su totalidad, parcialmente o no se ejecutan. Cuando se dispone de datos de segundos o ticks estos pueden usarse para mejorar la precisión del posicionamiento. Por ejemplo, con NinjaTrader 8 podemos aumentar la granularidad del análisis con el modo “High Resolution” que permite introducir una serie secundaria de resolución más alta. De este modo la lógica de la estrategia se evalúa en el time frame principal mientras que el algoritmo de llenado de órdenes utiliza el segundo TF.


3. Series bid/ask y de tick.- Algunas estrategias de mayor frecuencia y BMO muy pequeño requieren aún mayor densidad de datos. Por ejemplo, las de scalping, con tiempos de resolución de unos pocos segundos o las de arbitraje estadístico. En estos casos será necesario combinar históricos bid/ask (caros y disponibles en pocos data feeds) con series de ticks. Ni que decir tiene que esta mayor densidad ralentiza enormemente el proceso backtest a pocos años que se estén evaluando. La plataforma MultiCharts soporta este tipo de análisis, evaluando la lógica en el TF de trabajo y utilizando las series bid/ask para el cálculo de la ejecución de órdenes. Pero incluso así, seguiríamos teniendo el problema de las limitadas. Al tener solo un nivel de profundidad de tipo estático continuamos sin saber la prioridad que tendrían nuestras órdenes en la cadena y, en consecuencia, sí pudieron ejecutarse parcial o totalmente. Con esto llegamos al límite de resolución para el trader retail. Pero los profesionales de la alta frecuencia pueden dar aún un paso más.


4. Datos tipo ITCH.- Si queremos conocer en detalle la miroestructura de un mercado no nos queda otra que emplear la pila completa de órdenes recibidas en un instante dado. Con esta información sería posible obtener una imagen dinámica del libro de órdenes y, en teoría (luego veremos que aun así nos faltaría alguna información), reconstruir la historia completa de un mercado. El  ITCH es un protocolo específico del NASDAQ que permite conocer el status de cada orden desde que es enviada al mercado hasta su ejecución o cancelación. Los mensajes ITCH están disponible por suscripción y pueden obtenerse en tiempo real. El NYSE dispone de un servicio similar: OpenBook Ultra. Algunas plataformas profesionales como Lime Strategy Studio pueden utilizar estos y otros protocolos para realizar backtests muy precisos a estrategias de alta frecuencia y BMO < 1 tick. 

 

Pero incluso con datos de la mayor resolución disponible la replicabilidad total tampoco está garantizada. Los valores más líquidos cotizan en múltiples mercados y cuando damos una orden de compra no sabemos a cuál de ellos irá a parar. Ciertamente hay muchas posibilidades de que el broker la envíe al mercado principal en el que cotiza ese valor, al ser el más líquido. Pero en realidad un broker tiene otras posibilidades y puede hacer lo siguiente:


  • Enviar la orden a un mercado regional regulado (Cboe EDGA Exchange, BOX Options Exchange, Miami International Securities Exchange, etc.)
  • Enviarla a un Third Market Maker o a un OTC (OTCQX, OTCQB, OTCBB, etc.)
  • Internalizar la orden, dando él mismo contrapartida mediante su autocartera.
  • Tratar de completar la orden, sobre todo si es limitada, a través de una ECN


Ciertamente debe cumplir la regla de cerrar la operación al mejor precio disponible, que en teoría y en los mercados USA, es el establecido en el NBBO. Pero existe un amplio debate sobre su verdadera utilidad y las mil formas en que las empresas de HFT obtienen mejores precios y ganan sistemáticamente los rebates al inversor retail

Por otra parte, hay órdenes con modificadores especiales que no están al alcance de todos y que no dejan rastro en el libro de órdenes. Tal es el caso de las hide‐and‐light e ISO. Esto nos impedirá conocer con total precisión la prioridad de nuestras órdenes limitadas en la cadena.

Como hemos dicho al comienzo de este artículo, desde el punto de vista del trading de sistemas, más que una replicabilidad completa barcktest/operativa real, nos interesa obtener un nivel de realismo en consonancia con el tipo de estrategia que estamos evaluando. Para ello debemos tomar en consideración los tres factores ya mencionados: Frecuencia, BMO y tipo de órdenes.


A) Frecuencia operativa: Está relacionada con el tiempo de permanencia en el mercado (TPM). Normalmente las estrategias de alta frecuencia (HFT) basan su performance en un elevadísimo número de operaciones con un TPM muy pequeño, en ocasiones inferior al segundo. En el otro extremo, las estrategias tipo Long Term realizan muy pocas operaciones con un TPM de semanas o meses. Podemos definir el TPM como la duración media de las operaciones realizadas por una estrategia. La permanencia de cada operación en el mercado debe medirse desde que se produce la confirmación de apertura hasta la confirmación del cierre. Para poder evaluar correctamente una estrategia el TPM debe ser varias veces superior al time frame empleado. Por ejemplo, no podemos hacer un backtest adecuado a una estrategia con TPM de 5 min. empleando un time frame de 15 min.

Por otra parte, a medida que el TPM disminuye, hay que tomar en consideración la latencia. Si operamos el típico sistema VBO en un TF de 30 min. y con un TPM de varias horas, un retraso de unos pocos milisegundos no va a afectar de forma apreciable a los resultados de la estrategia. Pero si la operativa se realiza con un sistema de “gatillo fácil” en gráficos de ticks y con TPM de unos pocos segundos la latencia será un factor decisivo. El problema es que la latencia no es una variable estática sino que fluctúa considerablemente y de forma impredecible a lo largo de la sesión: En un momento dado puede ser de 15 ms. Y al poco rato subir a 150 ms. para luego volver a descender. Esto hace que sea un componente de la operativa imposible de simular en backtest.

 

Cuando hablamos de latencia tenemos que considerar al menos estos tipos:


  • Recepción de datos: Podemos medirla como el tiempo desde la ocurrencia de un tick en el mercado y su recepción en nuestra plataforma. Este tipo de latencia depende de cada proveedor de datos. En la práctica, y pese a la propaganda que realicen, es muy difícil encontrar proveedores con latencias por debajo de 15 ms.
  • Envío de órdenes: Tiempo que transcurre desde el algoritmo genera una orden hasta que se recibe en los mercados. Aquí hay dos tramos independientes: plataforma-broker y broker-mercado.
  • Estatus de las órdenes: Tiempo que transcurre entre una cancelación, modificación, ejecución parcial, rechazo, etc. Y la recepción de la notificación.
  • Procesamiento de datos: Tiempo que transcurre debido a los cálculos internos de la plataforma y otros dispositivos asociados.


Como quiera que son fuentes de latencia distintas, suelen sumarse generando una latencia global que resultará mucho más palpable en sistemas de muy alta frecuencia. Este es el motivo por el que los traders retail  no pueden competir en la liga del HFT; la infraestructura tecnológica necesaria para reducir la latencia al mínimo es muy costosa. 


B) Beneficio Medio por Operación (BMO): Cuanto mayor sea más resistente será nuestro sistema al peso de los gastos e ineficiencias de todo tipo. Esto conduce a que los backtests realizados a sistemas con BMO alto tengan un mayor grado de realismo. El BMO hay que ponerlo en relación con el Gasto Medio por Operación (GMO). Como sabemos, el gasto tiene un componente conocido, las comisiones, y otro desconocido, el deslizamiento. Este último tiene numerosas fuentes: liquidez del producto, latencia, tipo de orden, etc. Y, en la práctica, solo puede ser estimado empíricamente; comparando los precios teóricos a los que abrimos y cerramos las órdenes en la plataforma con los precios reales de ejecución. Es un error realizar una simulación asumiendo ½ tick de deslizamiento.

 Un trader retail nunca debería operar sistemas con BMO < GMO *3. En nuestra opinión este es el umbral mínimo de una simulación realista. En trading de alta frecuencia es posible encontrar BMOs sub-tick. No nos engañemos, ese tipo de estrategias no se pueden evaluar adecuadamente. Los recursos necesarios no están al alcance del trader particular, ni de la mayor parte de los profesionales. Casi todas las estrategias HFT se basan en el uso intensivo de órdenes limitadas y ese es precisamente el gran problema de las simulaciones como seguidamente veremos.   


C) Tipos de órdenes: En general los tipos de órdenes varían según dos arquitecturas generales: Reversión a la media (MR) y momento (VBO, ORB y miro-tendenciales). Los sistemas MR suelen posicionarse mediante órdenes limitadas simples y los HFT utilizan modificadores especiales para los órdenes limitadas (como hide‐and‐light) que les permiten situarse a la cabeza de la cadena de órdenes. Los sistemas de momento entran a mercado con órdenes por lo mejor, en stop o stop-limit. En las salidas suelen utilizarse limitadas para los profit target y órdenes en stop para los stop loss.

 


Para simular estos tipos de órdenes los algoritmos de backtest tienen que hacer algunas suposiciones:

  • Las órdenes limitadas se consideran ejecutadas cuando los precios tocan el límite o cuando lo rebasan por al menos 1 tick?  Por ejemplo, supongamos un MR aplicado al ES que lanza una compra limitada en 2857,25. La plataforma de backtest, funcionando en modo “simple” o “liberal”, puede dar por buena la operación si el precio retrocede exactamente hasta ese valor y luego se da la vuelta. En modo “conservador” o “realista” la operación solo se considerará cerrada si el precio retrocede a 2857. La diferencia es de 1 tick que en ese mercado son $12,5. Aunque en principio pueda parecer una cantidad pequeña para preocuparse, en la práctica puede suponer la diferencia entre que esa estrategia sea viable o no; todo depende de su BMO. ¿Entonces por qué no evaluar siempre un enfoque “liberal”? Porque eso equivaldría a suponer que, por arte de magia, nuestras órdenes son las que tienen mayor prioridad. Lo cual nos llevaría a resultados aún menos realistas. Si evaluamos la estrategia con enfoque liberal debemos asumir que un porcentaje significativo de las limitadas nunca se van a ejecutar en operativa real. El problema es que no hay forma de saber su valor exacto.


  • Las órdenes son completadas sin tener en cuenta el volumen. En operativa real se producen muchas ejecuciones parciales o a niveles distintos mientras que la operativa simulada, al no tomar en consideración la profundidad del mercado sino únicamente la secuencia de precios, todas estas órdenes aparecen como ejecutadas a un precio fijo + el deslizamiento fijado de antemano en el simulador. Por ejemplo, si realizamos una compra en stop de 15 contratos del NQ  cotizando a 7427 lo normal es encontrar una ejecución de este tipo: 4c. = 7427, 3c. = 7427,25, 5c.= 7427,5, 3c= 7427,75. Sin embargo el simulador, en modo realista, asumirá 15 = 7427,25 (+1 tick). Si la orden fuese limitada solo deberíamos ver una ejecución parcial de 4 contratos. Para que un simulador pueda tener en cuenta los nieves de precios y ejecuciones parciales no basta con evaluar la estrategia en una serie primaria, necesitaremos conocer la profundidad del libro de órdenes en cada punto de datos de la serie primaria. E incluso así, como ya hemos dicho, tampoco sería posible un realismo total. 


  • ¿Cómo computamos las órdenes de cierre a fin de sesión y de entrada en la apertura? En operativa real podemos programar una salida por fin de sesión por ejemplo 30 s. antes de la hora de cierre, ¿Pero cómo calculamos esto en las simulaciones en modo de barra? ¿Cuál sería la mejor aproximación? Para esto existen 4 posibilidades pero ninguna es satisfactoria:


- Tomar como referencia el precio de cierre de barra.

- Precio de cierre de barra ± x ticks.

- Precio de apertura de barra en la siguiente sesión.

- Utilizar una serie secundaria más granular (segundos, ticks)

 


Algunos brokers disponen de órdenes de apertura y cierre, con algoritmos específicos para su implementación en operativa real.  Por ejemplo, en Interactive Brokers tendríamos:

Órdenes en subasta.- Se introducen en el sistema antes de la apertura y se intentan ejecutar al precio de apertura calculado. Si no fuera posible, se convierten automáticamente en limitadas con límite en dicho precio.

Precio al cierre.- Se intentan ejecutar al final de la sesión operativa. Las órdenes grandes se fragmentan automáticamente en paquetes más pequeños para minimizar el riesgo de deslizamiento. Se pueden especificar el tiempo de inicio y el ritmo de ejecución.

Mercado al cierre.- Diseñadas para ejecutarse tan cerca del punto de cierre como sea posible.

Mercado a la apertura.- Se pueden enviar hasta unos minutos antes de la hora de apertura y se intentan ejecutar a la primera cotización o al precio más próximo al de apertura.


Lógicamente estas órdenes trabajan con el flujo dinámico de información en tiempo real. Su emulación al hacer un bracktest no es posible y las mejores aproximaciones son las que hemos comentado. 


 

Andrés A. García

© Tradingsys.Org, 2018



 

Comentarios

 

- Backtest II

Artículo genial enhorabuena, hay que conocer las posibilidades del trader retail por eso no hago sistemas en tiempos menores de 15 minutos por barra y no complicarse la vida, para las latencias y deslizamientos es fácil añadir 1 o 2 pips más al backtest para ser un poco más realista.

Añadir comentario

 
Modificado por AndyG - 24 Ago 2018
 
 

* Campos obligatorios

 
 

 
 

Secciones

 
 
 

Entradas recientes

 
 

Enlaces