Get best of the week

Cómo no perder todo el dinero en un par de minutos o administrar el riesgo en el comercio algorítmico



El contenido del articulo


Introducción


Ahora la situación no es simple tanto en el mundo como en el comercio de acciones. Muchos comerciantes de repente se convierten en millonarios, mientras que otros pierden instantáneamente todo su dinero. La alta volatilidad del mercado ofrece una buena oportunidad para que los operadores algorítmicos ganen. Y para dormir tranquilo y no soñar, los cisnes negros deben proteger sus cuentas de los robots furiosos y otros problemas de comercio algorítmico.

"El Algotrader está dormido, ¡el comercio está en marcha! ", A algunos comerciantes les gusta decir. Pero la realidad no es tan simple. ¿Dónde crees que comienza el comercio algorítmico? ¿De conectarse al intercambio o escribir un algoritmo? Para un participante profesional, el comercio comienza con el desarrollo de la gestión de riesgos .

Se cree que el comercio algorítmico es mucho más efectivo que el comercio clásico. Debido a que los robots no tienen soluciones emocionales, están listos para trabajar las 24 horas, los 7 días de la semana, saben exactamente cuándo comprar y cuándo vender, hacen transacciones a una velocidad que no es accesible para una persona común. Sin embargo, en virtud de sus superpoderes, crean una mayor clase de riesgos.
Por ejemplo, un caso bien conocido que pasó a la historia como  "La venganza de los automóviles" causó pérdidas de $ 460 millones, o un robot roto causó pérdidas de $ 4,3 millones o fallas en la Bolsa de Moscúdando lugar a paradas y pérdidas para los comerciantes, etc. Uno de esos incidentes es suficiente y las cuentas comerciales pueden sufrir daños irreparables. Esto es especialmente cierto si el comercio es marginal, cuando el precio del error aumenta varias veces.

Un comerciante no puede saber cuánto ganará, pero debe saber exactamente cuánto puede perder. De hecho, cualquier operación se reduce al control de riesgos, y las ganancias son una recompensa por observarlas.

En este artículo, intentaré revelar, si es posible, los riesgos potenciales asociados con la ejecución de algoritmos comerciales en el comercio real y medidas para proteger contra fallas en el sistema comercial. Al mismo tiempo, no mencionaré la administración del dinero , la diversificación de la cartera de negociación y la lógica de las estrategias de negociación, esta es una historia diferente.

1. Soluciones arquitectónicas


Antes de proceder a la clasificación de riesgos, hablaré un poco sobre las soluciones estándar en la parte comercial del comercio algorítmico.

Desde los requisitos hasta la velocidad de ejecución de las aplicaciones, los robots comerciales se construyen de diferentes maneras. Si este HFT (por ejemplo, arbitraje o creación de mercado ) es sensible a los retrasos, entonces intentan minimizar la ruta de aplicación desde el algoritmo hasta el intercambio y la cuenta en retrasos se gasta en microsegundos. Como regla general, dichos algoritmos tienen una arquitectura específica y están optimizados para una estrategia específica. En este caso, la gestión de riesgos se integra directamente en la estrategia.

Básicamente, las estrategias comerciales están en posición desde unos pocos minutos hasta varias horas, y cuanto menos tiempo el algoritmo esté en posición, más fácil será controlar los riesgos. Sin embargo, con un aumento en la frecuencia de las transacciones, aumentan los costos de comisión, lo que reduce la rentabilidad de los algoritmos. Por lo tanto, las estrategias comerciales intentan encontrar un equilibrio entre riesgo y ganancias.

Los algoritmos de negociación rara vez se negocian uno a la vez. Por lo general, se trata de familias enteras de estrategias que se recopilan en carteras para diversificar y estabilizar la curva de equidad . Al mismo tiempo, los datos de intercambio para algoritmos comerciales pueden provenir de varias fuentes, y las aplicaciones pueden enviarse a varios intercambios. En el núcleo del sistema de negociación se encuentran los motores.esa ruta y optimizar datos entre algoritmos e intercambios (ver Figura 1). Por lo general, existen otros motores, por ejemplo, para trabajar con datos históricos o backtesting, pero en aras de la simplificación no los muestro.


Figura 1. El esquema arquitectónico para el servidor comercial.

2. Clasificación general de riesgos.


  • 2.1. Riesgos de infraestructura
  • 2.2. Problemas para conectarse al intercambio / corredor
  • 2.3. Problemas en la lógica de las estrategias comerciales.

2.1. Riesgos de infraestructura


La mayor parte de los problemas en esta clase está asociada con los servidores comerciales. Para el comercio algorítmico, incluso una PC muy poderosa no es adecuada por muchas razones: equipo poco confiable, conexión a Internet inestable, fuente de alimentación deficiente, etc.

Los principales riesgos:

  • pérdida total / parcial del rendimiento del servidor;
  • reinicio de emergencia del sistema operativo;
  • falla física del servidor.

La calidad de resolver estos problemas, por regla general, depende de su presupuesto y los requisitos de sus algoritmos de negociación.

2.1.1 Opciones de solucion


  • Colocación de intercambio. Opción ideal y más cara. Por lo general, se usa en algoritmos HFT altamente rentables o en grandes empresas, por ejemplo, bancos, donde esta infraestructura se reutiliza para otras soluciones comerciales.
  • Alquiler de servidor virtual / dedicado. Si no es un gran fondo de cobertura o un operador privado, entonces probablemente use esta opción. Una solución simple, fácilmente personalizable y escalable. Siempre puede encontrar un proveedor que coincida con los parámetros de precio / calidad.
  • . . , / , .

2.1.2.


  • / . TIER III uptime 99,98% . .
  • . , . .
  • La reserva de energía es de al menos 40-50% (CPU, RAM, SSD) en comparación con el modo comercial habitual. Como regla general, en movimientos fuertes en el mercado, la carga en los flujos de datos aumenta y los algoritmos comienzan a ejecutar transacciones activamente. En este momento crucial, no debería haber ningún freno en sus servidores.

2.2. Problemas de conectividad


En bolsas y corredores, las fallas técnicas ocurren de vez en cuando. Por ejemplo, el funcionamiento de la plataforma de negociación de Sberbank se estrelló o fue "subtrabajado" en la Bolsa de Moscú , la bolsa cerró durante el almuerzo , la Bolsa de Moscú suspendió las operaciones debido a un fracaso , etc.

Los principales riesgos:

  • la conexión se rompe;
  • altas demoras;
  • Datos Incorrectos;
  • Pérdida parcial de datos.


2.2.1. La conexión se rompe


La información de interrupción de conexión se puede obtener de varias maneras:

  • API de eventos de conector: conectado , desconectado .
  • Usar algoritmos de verificación de conexión como Heartbeat , que generalmente están presentes en la API.
  • Indirectamente. Por la falta de datos en los flujos de datos.

Puede configurar la conexión para que si la conexión se pierde / desconecta, el intercambio retirará las órdenes activas o cerrará posiciones. Sin embargo, debe tener cuidado con esta funcionalidad, ya que en caso de pausas breves, es muy probable que un cierre no planificado de posiciones genere pérdidas y más daños que ayuda.

Además, a menudo sucede que cuando algo se rompe, se rompe por completo y las primeras opciones para advertir sobre los descansos no funcionan y solo indirectamente logran descubrir que algo salió mal.

2.2.2. Problemas de datos


Para comenzar, considere los principales tipos de datos de existencias. Dependiendo del tipo de conector e intercambio, estos datos no varían mucho, pero básicamente los más o menos son los mismos.

Cambios entrantes:

  • Intercambio de gafas / libro de pedidos
  • Ofertas
  • Aplicaciones
  • Artículos de línea
  • Equilibrar

Datos salientes:

  • Solicitudes de registro

Los datos entrantes y salientes pueden provenir de una o de diferentes conexiones. Sucede que uno de los hilos puede caerse "en silencio", mientras que el resto funcionará en modo normal. Incluso si los datos provienen de la misma fuente, aún necesita monitorear cada transmisión individualmente.

Los problemas de datos generalmente se resuelven implementando algoritmos de seguimiento como WatchDog . Todos los hilos deben pasar por estos módulos.

Seguimiento de WatchDogs :

  • frecuencia de actualizaciones de datos en la secuencia;
  • retrasos de fecha y hora en los datos y la hora actual;
  • La disponibilidad de datos determina la presencia de comunicación con el intercambio.

Si durante un tiempo determinado no se obtuvieron datos del conector o los retrasos exceden el máximo permitido, se generan los eventos correspondientes y se toman decisiones sobre acciones adicionales.

Para el cálculo correcto de los retrasos, se debe implementar un sistema independiente para la sincronización precisa de la hora del sistema. Por ejemplo, con servidores NTP .

2.2.3. Opciones de solucion


Si se producen los problemas anteriores, el sistema debe desconectar de inmediato los flujos de datos de los algoritmos e intentar reconectarse con la frecuencia y el número de intentos dados. Debe tenerse en cuenta que existen causas de roturas completamente justificadas y previamente imprevistas. Por ejemplo, debido a una sesión comercial acortada en días festivos nacionales o una actualización inesperada de la API y otros escenarios no razonados. En cada conexión particular, la reconexión debe abordarse individualmente. De lo contrario, el intercambio puede percibir el número excesivo de intentos de reconexión como un ataque de spam y provocar el bloqueo de la cuenta.

Después de volver a conectar y descargar los datos perdidos, es necesario notificar a los algoritmos comerciales sobre la restauración del trabajo y transferirles los datos perdidos. Los algoritmos deben analizar los cambios que han tenido lugar y decidir qué hacer a continuación. Permanezca en la posición actual, cámbiela o ciérrela por completo. Esta lógica debe implementarse en todas las estrategias comerciales.

El orden de restauración del trabajo:

  • reconectar
  • cargar datos perdidos;
  • notificar algoritmos de recuperación de comunicación;
  • transferir datos perdidos a los algoritmos;
  • cambiar transmisiones en tiempo real;
  • La lógica de negociación de los algoritmos debería normalizar sus posiciones y reemplazar las órdenes.

Del mismo modo, en el caso de datos problemáticos o una pérdida parcial de funcionalidad, primero debe restaurar completamente la conexión y normalizar los flujos de datos. Es imposible comerciar con una capacidad de trabajo parcial, es obvio que esto no terminará con nada bueno.

2.3. Problemas en la lógica de las estrategias comerciales.


Los problemas más peligrosos, insidiosos e impredecibles acechan en la lógica programada de las estrategias comerciales. No importa cuán reflexivos puedan ser los algoritmos comerciales, es imposible prever todos los escenarios. Varios factores y su combinación pueden dar lugar a comportamientos inesperados. Además, algunos errores pueden acechar por años y "emerger" en el momento más inesperado.

2.3.1. Clasificación de problemas.


  1. Errores en aplicaciones:
    • Precio / volumen negativo;
    • Direccion contraria;
    • Tipo incorrecto, etc.
  2. Errores de API:
    • No todos los campos se completan en la transacción;
    • Usar una versión desactualizada de la API;
    • ..
  3. :
    • ;
    • ;
    • ;
    • « »;
    • .
  4. :
    • ;
    • ;
    • .
  5. :
    • ;
    • .
  6. :
    • ;
    • ;
    • ;
    • .
  7. :
    • ;
    • ;
    • Una gran cantidad de aplicaciones que no conducen a transacciones.
  8. Falta de manejo de excepciones en el código del programa de estrategias comerciales

Sin embargo, algunos errores pueden dar lugar a otros. Por ejemplo, detener el algoritmo debido a un error grave provocará una violación de la posición y, como consecuencia, una violación de los límites.

2.3.2. Opciones de solucion


La solución a estos problemas se reduce a controlar las aplicaciones y los límites de las estrategias comerciales (ver sección 3). Además, cualquier excepción en el código del programa debería llevar a una parada inmediata del algoritmo problemático y al retiro de todas sus aplicaciones activas.

3. Seguimiento de aplicaciones y límites de estrategias comerciales


Quizás estas son las formas más importantes de gestionar los riesgos del sistema comercial. Cualquier error eventualmente conducirá a una desviación en el puesto, las solicitudes y el efectivo. La tarea es notar estos cambios lo más rápido posible y tomar medidas con prontitud.

Los cheques se pueden dividir en dos tipos:
3.1. Verificación básica de las aplicaciones
3.2. Análisis y control de límites.

3.1. Verificación básica de la aplicación


Todas las solicitudes salientes deben verificarse para:

  • errores graves
  • corrección y suficiencia de los datos para la API;
  • cumplimiento de las especificaciones de los instrumentos negociados;
  • cumplimiento de las bases de licitación, etc.

Estas verificaciones se llevan a cabo antes de enviar las solicitudes al intercambio. Cuanto antes se encuentre un error, más fácil será eliminar sus consecuencias. No espere a que salgan errores obvios del conector. Es mejor resolver los problemas antes de que aparezcan. Además, el envío de transacciones erróneas puede dar lugar a varias sanciones por parte del intercambio.

3.2. Control de límites


Para controlar los límites, se verifica lo siguiente:
3.2.1. Cambio de equilibrio y posición antes de realizar una solicitud
3.2.2. Cambio en el saldo actual y posición
3.2.3. Precio y volumen de aplicación
3.2.4. Comportamiento de la aplicación

3.2.1. Análisis de cambios en el equilibrio y la posición antes de realizar una solicitud.


Antes de enviar una solicitud de registro, se verifica un posible cambio en el saldo y la posición en caso de ejecución de la solicitud. Si hay un exceso del límite para este algoritmo, la orden no se envía y se envía un mensaje de error a la estrategia comercial.

3.2.2. Análisis de cambios en el saldo actual y posición


Los límites se forman en los cambios en el volumen negociado y la posición en los instrumentos por períodos de tiempo: 15 segundos, 30 segundos, 1 minuto, 5 minutos, 15 minutos, 1 hora, 1 día. El monitoreo constante de los cambios en los períodos de tiempo le permitirá ver la desviación en el comportamiento y detener el comercio, hasta el momento en que la desviación se vuelva crítica.

Sucede que los problemas con el algoritmo no aparecen de inmediato. Puede comenzar a "fusionarse" lentamente y sin romper los límites por un corto período de tiempo. Puede despertarse por la mañana y encontrar una reducción significativa debido a un algoritmo no "roto". ¿Lo necesitamos? No lo necesitamos.

3.2.3. Análisis de precio y volumen.


Antes de enviar la solicitud de registro, se verifica el límite de exceder el volumen máximo y mínimo en la aplicación. Desafortunadamente, nadie canceló los errores aritméticos en fórmulas y cálculos.

Es importante, si es posible, verificar la desviación del precio ofertado del precio promedio de mercado. Para hacer esto, verifique el precio de otras fuentes para un instrumento comercial similar. Estas verificaciones son especialmente relevantes si la negociación se realiza en un intercambio no líquido o se observa una volatilidad anormalmente alta para un instrumento negociado.

Si los cambios exceden los límites especificados, las solicitudes se rechazan antes de enviarse al intercambio.

3.2.4. Análisis de comportamiento de aplicaciones


Marcado aquí:

  • la cantidad de aplicaciones que no conducen a transacciones;
  • número de aplicaciones activas;
  • frecuencia de aplicación por períodos de 1 seg, 3 seg, 5 seg, 15 seg, 30 seg, 1 min.

Los intercambios tienen sus propios límites en el número de órdenes activas y la frecuencia de su envío, si exceden el acceso a la negociación, pueden suspenderse. Y será posible normalizar las posiciones solo manualmente.

Una de las situaciones más peligrosas y riesgosas es cuando un robot comercial comienza a comprar y vender sin control, haciendo una gran cantidad de pedidos por segundo. Antes de que el robot tome una posición grande o termine una comisión, esta protección debería funcionar. Como mínimo, debe dar tiempo extra para que otros mecanismos de protección puedan funcionar.

Estas comprobaciones se llevan a cabo en varios niveles:

1. En el nivel del conector.La protección del conector "ralentiza" las aplicaciones cuando la frecuencia de exposición se acerca al máximo. Esto es necesario para no perder el acceso al intercambio. Estas medidas son extremas, por lo que es importante calcular correctamente la carga en el conector de antemano.

2. A nivel de una estrategia comercial. Si el algoritmo excede su límite en la frecuencia de presentación de solicitudes, entonces se detiene por la fuerza con un error. En este caso, se eliminan todas las aplicaciones activas enviadas previamente.

4. Integración de la gestión de riesgos en la solución arquitectónica.


La integración de la gestión de riesgos se puede dividir en dos partes principales (ver Fig. 2):

  • PRE-TRADE incluye control básico de pedidos, control del precio y volumen del pedido, control de cambios en el saldo y posición antes de que se envíe el pedido, el comportamiento de los pedidos también se analiza aquí.
  • POST-COMERCIO incluye comprobaciones de interrupciones de conexión y la exactitud de los datos del mercado, se realiza un monitoreo constante de los cambios en el saldo y las posiciones actuales, el comportamiento de las órdenes también se analiza aquí.



Higo. 2. El esquema de integración de la gestión de riesgos en la solución arquitectónica para el servidor comercial.

5. Registro e informes


No olvide que también se producen situaciones no estándar y que hoy en día no pueden prescindir de la intervención humana, incluso en sistemas altamente automatizados. Por lo tanto, si algo salió mal, debe notificar de inmediato a todas las partes interesadas (comerciantes, desarrolladores, el gerente) enviando automáticamente mensajes por correo, sms, telegramas o de cualquier otra manera conveniente. Idealmente, siempre debe haber un operador de servicio que supervise el rendimiento del sistema de comercio.

En caso de falla, debe encontrar rápidamente el problema, solucionarlo y volver a poner en funcionamiento el sistema de negociación. Para hacer esto, es necesario mantener registros detallados del comercio y del sistema, especialmente en sistemas altamente cargados con un gran flujo de aplicaciones. Si no se encuentran las causas de la falla, la siguiente falla puede ser fatal. El intercambio, como regla, no perdona los errores e inmediatamente castiga el rublo.

Conclusión


Por lo general, comienzan a "ajustar" la gestión de riesgos a los algoritmos de negociación en el último turno, cuando ya han ocurrido un par de incidentes y se ha llegado a la conclusión de que no se puede prescindir de ellos.

Así como las medidas de seguridad se escriben en sangre, la gestión de riesgos en el comercio algorítmico se escribe en llamadas de margen y cuentas fusionadas.

Sin embargo, si construye correctamente un sistema de comercio y configura la gestión de riesgos, puede dormir tranquilo y asegurarse de que " Algotrader está dormido, ¡el comercio está en marcha! " . ¡ Buen comercio para

todos!

More articles:


All Articles