El post es adecuado para aquellos que están comenzando el comercio cuantitativo, así como para aquellos que han tenido alguna experiencia con el área.
También analiza los diferentes tipos de mecanismos de backtesting, así como el panorama de software que implementa estos enfoques. Luego discutimos si vale la pena construir su propio backtester, incluso con la prevalencia de herramientas de código abierto disponibles hoy en día.
Finalmente, discutimos los entresijos de un sistema de backtesting basado en eventos, un tema que he cubierto con frecuencia en QuantStart en publicaciones anteriores.
Una prueba de retroceso es la aplicación de reglas de estrategia de negociación a un conjunto de datos históricos de precios. Es decir, si definimos un conjunto de mecanismos para entrar y salir de una cartera de activos, y aplicar esas reglas a los datos históricos de precios de esos activos, podemos intentar entender el rendimiento de esta "estrategia de negociación" que podría haber sido alcanzado en el pasado.
Una vez se dijo que
Las pruebas de retroceso en última instancia nos ayudan a decidir si vale la pena comerciar en vivo un conjunto de reglas de estrategia. Nos proporciona una idea de cómo una estrategia podría haber funcionado en el pasado. Esencialmente, nos permite filtrar las malas reglas de estrategia antes de asignar cualquier capital real.
Es fácil generar backtests. Desafortunadamente los resultados de backtest no son resultados comerciales en vivo. Son en cambio un modelo de la realidad. Un modelo que generalmente contiene muchos supuestos.
Hay dos tipos principales de pruebas de retroceso de software: los sistemas
Cuando se diseña un software de backtesting siempre hay una compensación entre precisión y complejidad de implementación.
Hay muchas trampas asociadas con el backtesting. Todas ellas se refieren al hecho de que un backtest es solo un modelo de la realidad. Algunas de las trampas más comunes incluyen:
Hay algunos problemas más sutiles con backtesting que no se discuten tan a menudo, pero que aún son increíblemente importantes para considerar.
Mucho se ha escrito acerca de los problemas con backtesting.
Un For-Loop Backtester es el tipo más sencillo de sistema de backtesting y la variante más comúnmente vista en publicaciones de blogs cuánticos, puramente por su simplicidad y transparencia.
Esencialmente, el sistema For-Loop se repite durante cada día de negociación (o barra OHLC), realiza algún cálculo relacionado con el precio de los activos, como un promedio móvil del cierre, y luego va largo o corto un activo en particular (a menudo al mismo precio de cierre, pero a veces al día siguiente).
Aquí está el pseudo-código para tal algoritmo:
for each trading bar:
do_something_with_prices();
buy_sell_or_hold_something();
next_bar();PythonCopy
Como se puede ver, el diseño de este sistema es increíblemente simple, lo que lo hace atractivo para obtener una "primera mirada" al rendimiento de un conjunto de reglas de estrategia particular.
Los backtesters de For-Loop son sencillos de implementar en casi cualquier lenguaje de programación y son muy rápidos de ejecutar.
La principal desventaja con los backtesters de For-Loop es que son bastante poco realistas. A menudo no tienen capacidad de costo de transacción a menos que se agreguen específicamente. Por lo general, los pedidos se llenan inmediatamente
Hay un mínimo de reutilización de código entre el sistema de backtesting y el sistema de trading en vivo. Esto significa que el código a menudo necesita ser escrito dos veces, lo que introduce la posibilidad de más errores.
Los backtesters de For-Loop son propensos a tener sesgos de prospección, debido a errores con la indexación.
Los backtesters de For-Loop realmente deben utilizarse únicamente como un mecanismo de filtración. Puede usarlos para eliminar las estrategias obviamente malas, pero debe permanecer escéptico de un buen rendimiento. A menudo se requiere más investigación. Las estrategias rara vez funcionan mejor en el comercio en vivo que en las backtests!
Los backtesters basados en eventos se encuentran en el otro extremo del espectro. Son mucho más similares a las implementaciones de infraestructura de comercio en vivo.
Tales sistemas se ejecutan en un gran bucle
Cuando se identifica un evento en particular, se envía al módulo apropiado (s) de la infraestructura, que maneja el evento y luego potencialmente genera nuevos eventos que vuelven a la cola.
El pseudo-código para un sistema de backtesting impulsado por eventos es el siguiente:
while event_queue_isnt_empty():
event = get_latest_event_from_queue();
if event.type == "tick":
strategy.calculate_trading_signals(event);
else if event.type == "signal":
portfolio.handle_signal(event);
else if event.type == "order":
portfolio.handle_order(event);
else if event.type == "fill":
portfolio.handle_fill(event)
sleep(600); # Sleep for, say, 10 minsPythonCopy
Como puede ver, hay una fuerte dependencia del módulo de manejo de cartera.
Hay muchas ventajas de usar un backtester impulsado por eventos:
Si bien las ventajas son claras, también hay algunas desventajas importantes al utilizar un sistema tan complejo:
En esta sección consideraremos el software (tanto de código abierto como comercial) que existe tanto para sistemas For-Loop como para sistemas impulsados por eventos.
Para los backtesters de For-Loop, los principales lenguajes de programación/software que se utilizan incluyen Python (con la biblioteca Pandas), R (y la biblioteca quantmod) y MatLab.
El mercado de los sistemas basados en eventos es mucho más amplio, ya que los clientes/usuarios a menudo desean que el software sea capaz de realizar pruebas de retroceso y operaciones en vivo en un solo paquete.
Las ofertas comerciales más caras incluyen Deltix y QuantHouse.
Los sistemas de backtesting y trading en vivo basados en la nube son relativamente nuevos.
Las cuantas institucionales a menudo también construyen su propio software interno, debido a una combinación de restricciones regulatorias, relaciones con los inversores/reporte y auditabilidad.
Los cuantos minoristas tienen la opción de usar el enfoque
En términos de software de código abierto, hay muchas bibliotecas disponibles. Están escritas principalmente en Python (por razones que describiré a continuación) e incluyen Zipline (Quantopian), PyAlgoTrade, PySystemTrade (Rob Carver / Investment Idiocy) y QSTrader (el propio backtester de QuantStart
Uno de los aspectos más importantes, sin embargo, es que no importa qué software utilice en última instancia, debe estar emparejado con una fuente igualmente sólida de datos financieros.
Si bien el software se encarga de los detalles para nosotros, nos oculta muchos detalles de implementación que a menudo son cruciales cuando deseamos ampliar la complejidad de nuestra estrategia comercial.
A pesar de tener experiencia como desarrollador de software cuantitativo, no estoy personalmente interesado en las "guerras lingüísticas".
Sólo debemos estar interesados en lo que funciona.
Python es un lenguaje de programación extremadamente fácil de aprender y es a menudo el primer lenguaje con el que las personas entran en contacto cuando deciden aprender a programar.
Tiene algunas bibliotecas excepcionales de aprendizaje cuántico/ciencia de datos/máquina (ML) en NumPy, SciPy, Pandas, Scikit-Learn, Matplotlib, PyMC3 y Statsmodels.
Es ideal para construir sistemas de backtesting tanto de For-Loop como de Event-Driven. De hecho, es quizás uno de los únicos lenguajes que permite directamente la investigación de extremo a extremo, backtesting, despliegue, comercio en vivo, informes y monitoreo.
Tal vez su mayor inconveniente es que es bastante lento de ejecutar en comparación con otros lenguajes como C ++. Sin embargo, se está trabajando para mejorar este problema y con el tiempo Python se está volviendo más rápido.
R es un entorno de programación estadística, en lugar de un lenguaje de programación de primera clase (aunque algunos podrían argumentar lo contrario). Fue diseñado principalmente para realizar análisis estadísticos avanzados para series temporales, estadísticas clásicas / frecuentistas, estadísticas bayesianas, aprendizaje automático y análisis de datos exploratorios.
Es ampliamente utilizado para backtesting For-Loop, a menudo a través de la biblioteca quantmod, pero no es particularmente adecuado para sistemas impulsados por eventos o operaciones en vivo.
C++ tiene la reputación de ser extremadamente rápido. Casi toda la computación científica de alto rendimiento se lleva a cabo ya sea en Fortran o C++. Esta es su principal ventaja. Por lo tanto, si está considerando el comercio de alta frecuencia, o trabajar en sistemas heredados en grandes organizaciones, entonces C++ es probable que sea una necesidad.
Por desgracia, es doloroso para llevar a cabo la investigación de estrategia. Debido a ser de tipo estático es bastante difícil de cargar fácilmente, leer y formatear datos en comparación con Python o R.
A pesar de su edad relativa, recientemente se ha modernizado sustancialmente con la introducción de C ++ 11 / C ++ 14 y otros refinamientos de estándares.
Es posible que también desee echar un vistazo a Java, Scala, C #, Julia y muchos de los lenguajes funcionales. Sin embargo, mi recomendación es quedarse con Python, R y / o C ++, ya que las comunidades de comercio cuántico son mucho más grandes.
Respuesta: Sí.
Es una gran experiencia de aprendizaje escribir su propio sistema de backtesting basado en eventos. En primer lugar, le obliga a considerar todos los aspectos de su infraestructura comercial, no sólo pasar horas retocando en una estrategia particular.
Incluso si usted no termina usando el sistema para el comercio en vivo, le proporcionará un gran número de preguntas que usted debe estar preguntando a sus proveedores comerciales o FOSS backtesting.
Por ejemplo: ¿Cómo su actual sistema en vivo difiere de su simulación backtest en términos de:
Si bien los sistemas basados en eventos no son rápidos ni fáciles de escribir, la experiencia pagará enormes dividendos educativos más adelante en su carrera comercial cuántica.
¿Cómo se escribe un sistema así?
La mejor manera de comenzar es simplemente descargar Zipline, QSTrader, PyAlgoTrade, PySystemTrade, etc. y tratar de leer la documentación y el código.
Rob Carver, de Investment Idiocy también expone su enfoque para construir tales sistemas para el comercio de futuros.
Recuerda que no tienes que ser un experto en el día #1. Puedes tomarlo lentamente, día a día, módulo por módulo. Si necesitas ayuda, siempre puedes ponerte en contacto conmigo u otros blogueros de cantidad dispuestos.
Ahora voy a discutir los módulos que a menudo se encuentran en muchos sistemas de backtesting impulsados por eventos.
Aquí es donde todos los datos de precios históricos se almacenan, junto con su historial de operaciones, una vez que se pone en marcha.
En su lugar, utilizamos una base de datos o un sistema de archivos de primera clase, como PostgreSQL, MySQL, SQL Server o HDF5.
Idealmente, queremos obtener y almacenar datos de nivel de tick ya que nos da una idea de los diferenciales comerciales. También significa que podemos construir nuestras propias barras OHLC, a frecuencias más bajas, si lo deseamos.
Siempre debemos ser conscientes de manejar las acciones corporativas (como las divisiones y dividendos de acciones), el sesgo de supervivencia (deslistado de acciones), así como el seguimiento de las diferencias de huso horario entre varios intercambios.
Las empresas individuales y minoristas pueden competir aquí, ya que muchas tecnologías de base de datos de calidad productiva son maduras, gratuitas y de código abierto.
Todavía hay muchos mercados y estrategias que son demasiado pequeños para que los grandes fondos estén interesados.
El módulo de estrategia de negociación en un sistema basado en eventos generalmente ejecuta algún tipo de mecanismo predictivo o de filtración en nuevos datos de mercado.
Este módulo no está diseñado para producir una cantidad, que se lleva a cabo a través del módulo de tamaño de posición.
El 95% de la discusión del blog de quant generalmente gira en torno a las estrategias comerciales. Personalmente creo que debería ser más como el 20%. Esto se debe a que creo que es mucho más fácil aumentar los rendimientos esperados reduciendo los costos a través de una gestión adecuada del riesgo y el tamaño de la posición, en lugar de perseguir estrategias con
El
El objetivo de este sistema es pasar de la cartera actual a la cartera deseada, minimizando al mismo tiempo el riesgo y reduciendo los costes de transacción.
El módulo relaciona la estrategia, el riesgo, el tamaño de la posición y las capacidades de ejecución de órdenes del sistema.
La principal ventaja de usar un sistema tan complejo es que permite manejar una variedad de instrumentos financieros bajo una sola cartera. Esto es necesario para carteras de estilo institucional con cobertura.
La separación de la gestión de riesgos en su propio módulo puede ser extremadamente ventajosa.
En particular, el módulo de riesgo puede agregar coberturas para mantener la neutralidad del mercado. Puede reducir los tamaños de los pedidos debido a la exposición del sector o los límites de ADV. Puede vetar completamente una operación si el diferencial es demasiado amplio o las tarifas son demasiado grandes en relación con el tamaño de la operación.
Un módulo de posicionamiento separado puede implementar la estimación de volatilidad y las reglas de posicionamiento como el apalancamiento de Kelly.
Tal vez la forma más sencilla de obtener mejores retornos es comenzar a implementar la gestión de riesgos y el tamaño de posición de esta manera.
En la vida real nunca se garantiza que el mercado se llene en el punto medio.
Debemos considerar cuestiones transaccionales como la capacidad, el spread, las tarifas, el deslizamiento, el impacto en el mercado y otras preocupaciones de ejecución algorítmica, de lo contrario, es probable que nuestros rendimientos de backtesting estén muy sobrevalorados.
El enfoque modular de un sistema basado en eventos nos permite cambiar fácilmente el BacktestExecutionHandler con el LiveExecutionHandler y implementarlo en el servidor remoto.
También podemos agregar fácilmente múltiples corredores utilizando el concepto OOP de
Un problema a tener en cuenta es el de la
Las cuentas minoristas pueden y deben tomar prestadas las sofisticadas técnicas de información utilizadas por las cuentas institucionales. Estas herramientas incluyen
Deben realizarse mejoras incrementales consistentes en esta infraestructura. Esto puede realmente mejorar los rendimientos a largo plazo, simplemente eliminando errores y mejorando problemas como la latencia comercial. No se obsesione simplemente con mejorar la
El WGS eventualmente se erosionará debido a la decadencia de
La optimización de la infraestructura puede ser más "aburrida" que el desarrollo de estrategias, pero se vuelve significativamente menos aburrida cuando los rendimientos mejoran.
El despliegue a un servidor remoto, junto con una amplia supervisión de este sistema remoto, es absolutamente crucial para los sistemas de nivel institucional.
Un sistema robusto debe ser desplegado remotamente en la nube o ubicado cerca de un intercambio. banda ancha doméstica, fuentes de alimentación y otros factores significan que utilizar un escritorio o computadora portátil en el hogar es demasiado poco confiable.
Los principales problemas al considerar una implementación remota incluyen; hardware de monitoreo, como CPU, RAM / intercambio, disco y red de E / S, alta disponibilidad y redundancia de los sistemas, un plan bien pensado a través de copia de seguridad y restauración, registro extensivo de todos los aspectos del sistema, así como la integración continua, pruebas de unidades y control de versiones.
Recuerda la ley de Murphy. Si puede fallar, fallará.
Hay muchos proveedores que ofrecen implementaciones de nube relativamente sencillas, incluidos Amazon Web Services, Microsoft Azure, Google y Rackspace.
Desafortunadamente, no hay una solución rápida en el comercio de cantidades. Implica mucho trabajo y aprendizaje para tener éxito.
Tal vez un gran obstáculo para los principiantes (y algunos quantes intermedios!) es que se concentran demasiado en la mejor
También vale la pena invertir mucho tiempo en su infraestructura comercial. Dedique tiempo a temas como el despliegue y el monitoreo. Siempre trate de reducir los costos de transacción, ya que la rentabilidad se trata tanto de reducir costos como de obtener ingresos comerciales.
Te recomiendo escribir tu propio sistema de backtesting simplemente para aprender. Puedes usarlo y mejorarlo continuamente o puedes encontrar un proveedor y luego hacerles todas las preguntas que has descubierto cuando construiste el tuyo. Ciertamente te hará consciente de las limitaciones de los sistemas disponibles comercialmente.
Por último, siempre lea, aprenda y mejore. Hay una gran cantidad de libros de texto, revistas comerciales, revistas académicas, blogs cuánticos, foros y revistas que discuten todos los aspectos del comercio. Para ideas de estrategia más avanzadas recomiendo SSRN y arXiv - Quantitative Finance.