¿Cómo podemos aplicar ingeniería inversa a un mercado de decisiones algoritmo (HFT)?

Question

Considere la posibilidad de un participante de mercado $A$ que es mecánicamente siguiendo un sistema automatizado de liquidez proporcionar algoritmo (HFT) en un número de grandes poblaciones de cap en un intercambio específico.

Supongamos, además, que no son capaces de observar todos los pedidos realizados por de $a$ y que sabemos que el algoritmo utilizado por $Un$ tarda sólo el mercado público de datos como entrada. $A$ se inicia y termina todos los días de negociación con cero inventario.

Queremos realizar ingeniería inversa del algoritmo utilizado por $Un$. Vamos a llamar a este algoritmo de $f(...)$.

El primer paso en la ingeniería inversa del algoritmo de $f(...)$ sería la de recoger el potencial de las variables de entrada para el algoritmo que más tarde puede ser utilizado para inferir la forma exacta de $f(...)$.

El primer problema al que nos enfrentamos es que las variables de entrada debemos recoger con el fin de ser capaz de realizar ingeniería inversa $f(...)$.

Para tener un punto de partida podemos considerar las variables de entrada que se utiliza en Avellaneda & Stoikov (2008). En Avellaneda & Stoikov (2008) , los autores derivan cómo racional de creador de mercado (no especialista) debe establecer sus comillas de compra y venta en un orden de límite mercado del libro. Los resultados son, obviamente, depende de la hipótesis y el modelo de las decisiones tomadas en el papel.

El óptimo de la oferta (o pedir) en Avellaneda & Stoikov (2008) es una función de las siguientes entradas:

• El comerciante del precio de reserva, la cual es una función de la seguridad precio ($S$), el creador de mercado actual del inventario ($q$) y el tiempo que queda hasta la terminal de tiempo de retención ($T t$)
• La relativa a la aversión al riesgo del comerciante ($\gamma$) (obviamente, difícil de observar!)
• La frecuencia de aparición de nuevas comillas de compra y venta ($\lambda_{oferta}$ y $\lambda_{preguntar}$)
• El más reciente cambio en la frecuencia de aparición de nuevas comillas de compra y venta ($\delta\lambda_{oferta}$ y $\delta\lambda_{preguntar}$)

¿Qué posibles variables de entrada debemos recoger con el fin de ser capaz de realizar ingeniería inversa $f(...)$?

Answer 1

Voy a tomar una puñalada en ella, pero esta es realmente una pregunta general.

Una respuesta directa: Bayesiano de modelos con frecuencia el uso de la "probabilidad de que la contraparte esté informado."

Indirectos respuestas: Creo que tu suposición es que el algoritmo opera en cada una de las acciones de forma individual, y no tiene ningún conocimiento de lo que sucede en cualquier otra acción. Pero, es probable que el algoritmo está haciendo una cobertura que no se ve todavía. Usted debe buscar en productos similares (o generación sintética de las cestas) y ver si el algoritmo está cambiando es la cita de los tamaños/precios de otros productos de la comilla de los tamaños/precios de cambio. (También es posible que el algoritmo es consciente de todas las órdenes y posiciones que tiene en todas las acciones y se inclina en mayor medida en algunos de la oferta/las ofertas que los demás, ya que intenta aplanar delta (beta) de la totalidad de la cartera.)

Si estás seguro de que el algoritmo está trabajando en un nombre individual con sólo que el stock de la cartera de pedidos como entrada, entonces yo sería el estudio de los órdenes de activos para ver cuándo y por qué sale. (tal vez el único activo de los pedidos son al final del día, el aplanamiento, en cuyo caso, yo sería el estudio de los pedidos cancelados.) Es fácil hacer un poco de dinero de las ofertas de trabajo y ofertas de la mayoría de las veces, pero en algún momento usted va a obtener la ejecución de más a menos saber cuando salir de la forma (y/o de cobertura). También me gustaría buscar veces cuando algo la detiene. Hay veces cuando no tienen una oferta y una oferta en el libro? Si es así, estos son los tiempos que es seguro, o está en la posición límite (debe ser bastante fácil distinguir cual es cual). Puede ser útil para ver qué es lo que pasa cuando se es 'seguro' de que no iba cuando era seguro.' Esto le ayudará a eliminar los parámetros posibles.

Largo, largo, largo atrás, se utilizó un micro-encargado del precio para obtener una estimación de cuando el precio real era el uso de cosas como la cantidad comercializada en el ask vs cant cotizados en la oferta, y las cantidades de oferta y demanda de tamaños. Inicialmente, el micro-encargado del precio trabajado como un stand-alone de alta frecuencia de liquidez operador. Luego se convirtió en una pieza en un mercado convirtiéndose en algo que era sólo una manera de saber cuándo cancelar los pedidos.

Answer 2

Estoy suponiendo que el algoritmo es una caja negra. [Usted no puede ver cualquiera o todas de el funcionamiento interno].

Usted ingeniería inversa a como lo haría con cualquier otra cosa:

1. Recopilar evidencia de eventos [Señales de compra/venta, cantidades], y el entorno en que opera.
2. Hacer teorías, y, a continuación, el modelo de ellos.
3. Para cada una de las teorías: Hacer un argumento convincente para los eventos, o un caso para refutar el modelo.
4. El más fuerte del modelo que usted tiene es su "mejor creer". Si usted completamente refutar un modelo, y luego acabar con él, y escribir algo sobre el por qué. [Esto es así y si vuelven a la misma pregunta puede volver a verificar las creencias]

Recuerde que los datos de mercado, y sistemas siempre será ruidoso [como operadores humanos]. Usted puede desarrollar hyptohesis, pero rara vez se puede demostrar algo.

Answer 3

Hay un trabajo de investigación que intenta hacer eso: http://www.cs.ucr.edu/~cshelton/documentos/docs/orderflow_emm.pdf

no hay experiencia en la implementación de nada de eso.