FIXatdl

El lenguaje de definición de negociación algorítmica FIX , más conocido como FIXatdl , es un estándar para el intercambio de metainformación necesaria para habilitar la actividad de negociación algorítmica en los mercados financieros. Funciona en conjunto con el protocolo Financial Information eXchange (FIX), que es la lengua franca de la negociación electrónica en el mercado de valores .

Antes de mediados de los noventa, prácticamente todas las operaciones con valores se realizaban por teléfono, pero con la llegada de FIX, la negociación se trasladó progresivamente a medios electrónicos. El protocolo FIX se utiliza para la comunicación entre los sistemas de gestión de órdenes (OMS) de vendedores y compradores, permitiendo el intercambio de órdenes e información sobre su ejecución sin intervención humana, mediante mensajes y flujos de trabajo estandarizados definidos por el protocolo. Inicialmente, las empresas vendedoras solo proporcionaban acceso a sus mesas de negociación a través de FIX, lo que significaba que, una vez que una orden llegaba al corredor vendedor, era gestionada por un operador humano, al menos al inicio de su ciclo de vida. Posteriormente, las empresas vendedoras comenzaron a ofrecer acceso directo a través de FIX a las bolsas/mercados de los que formaban parte; esto se conoce como acceso directo al mercado (DMA). En ese momento, muchas empresas vendedoras contaban con sus propios sistemas para operar automáticamente en el mercado, utilizando estrategias de negociación algorítmica , y con el tiempo se dieron cuenta de que ofrecer acceso a estas estrategias a los compradores era una forma de atraer clientes y aumentar sus ingresos.

Si bien FIX es un protocolo extensible, surgieron dos desafíos cuando las empresas vendedoras ofrecieron acceso a sus estrategias de negociación algorítmica a través de FIX. El primero fue que cada estrategia vendedora tenía sus propios parámetros que debían incluirse en la orden, por lo que cada empresa terminó requiriendo un conjunto diferente de campos (conocidos en FIX como "etiquetas") en el mensaje FIX. Esto complicó mucho las cosas para las empresas compradoras, y más aún para sus proveedores, ya que agregar nuevos algoritmos a sus sistemas de negociación y gestionar todas las diferentes combinaciones de etiquetas se convirtió en una carga de trabajo significativa para sus operaciones de desarrollo.

El segundo problema para el mercado radicaba en que cada empresa vendedora tenía una forma específica de visualizar sus algoritmos en el sistema de gestión de órdenes (OMS) de la empresa compradora, con controles en la interfaz de usuario organizados lógicamente para facilitar la introducción de órdenes. Esto, una vez más, supuso un reto para los proveedores de sistemas de la empresa compradora, ya que cada nueva pantalla para cada agente vendedor requería un esfuerzo específico de desarrollo y pruebas.

Para abordar estos problemas, FIX Protocol Limited creó el Grupo de Trabajo de Negociación Algorítmica en el tercer trimestre de 2004. ^{[ 1 ]} El enfoque inicial del grupo fue resolver el primero de estos problemas, lo cual logró definiendo un nuevo grupo de campos, StrategyParametersGrp, compuesto por las etiquetas FIX 957 a 960; estas etiquetas se introdujeron formalmente con el lanzamiento de FIX 5.0 en el cuarto trimestre de 2006. Al permitir que las empresas del lado vendedor incluyeran sus campos propietarios en una estructura repetitiva de pares nombre-valor, no fue necesario que los proveedores de OMS definieran estructuras de mensajes FIX específicas para cada destino de negociación del lado vendedor.

Esta solución no se adoptó de forma generalizada, en parte debido a la escasa penetración de FIX 5.0 y en parte porque las empresas ya contaban con implementaciones operativas en el mercado que no estaban dispuestas a modificar sin una buena razón. Quizás aún más importante, no logró resolver el problema más sustancial del mercado: la complejidad para los proveedores del lado comprador derivada de la falta de estandarización.

La idea de utilizar una estructura XML para describir la presentación de las interfaces de usuario de algoritmos y sus parámetros asociados fue sugerida inicialmente dentro del grupo de trabajo por Daniel Clayden, entonces de JP Morgan Chase, en una publicación de foro de 2005. ^{[ 2 ]} Los miembros del grupo de trabajo desarrollaron esta idea durante 2006 y en enero de 2007 invitaron a una participación más amplia de la industria en un taller para revisar sus ideas. ^{[ 3 ]} Finalmente se elaboró ​​una especificación y esta comenzó las pruebas beta en julio de 2007. ^{[ 4 ]} Esta especificación se convirtió en FIXatdl 1.0, que fue aprobada por el Comité Técnico Global (GTC) de FPL el 28 de marzo de 2008.

A pesar del entusiasmo inicial, la versión 1.0 tuvo una acogida poco entusiasta en el mercado. Algunos proveedores vieron la oportunidad de ofrecer servicios relacionados con el estándar, como ULLINK (ahora parte de Itiviti) con su herramienta UL AMS, que incluye la publicación y gestión de algoritmos. Sin embargo, si bien los principales proveedores de OMS se mostraron molestos por la complejidad de implementar nuevos algoritmos para los intermediarios, habían llegado a disfrutar de los ingresos que podían obtener tanto de sus clientes como de los intermediarios interesados ​​en incorporar sus algoritmos a las mesas de negociación de los compradores.

Aunque la versión 1.0 supuso un gran avance, presentaba algunas limitaciones importantes. En particular, la definición de los datos a transmitir y su presentación en la interfaz de usuario estaban estrechamente vinculadas, lo que limitaba la flexibilidad de los intermediarios del lado vendedor para definir sus algoritmos. La especificación 1.0 también ofrecía un control insuficiente en cuanto al diseño de la interfaz de usuario. El grupo de trabajo se propuso abordar estas limitaciones en lo que se convertiría en la versión 1.1 de la especificación. El primer cambio importante fue separar la definición del contenido de los datos de su presentación, definiendo lo que se denomina un "Contrato de Datos" independiente, compuesto por los parámetros del algoritmo, sus tipos de datos e información complementaria, como los valores mínimos y máximos. Una sección aparte del documento XML se ocupa del diseño de la interfaz de usuario, los controles que se deben usar para cada parámetro y su ubicación en la pantalla. Se proporciona un esquema XSD para garantizar que los archivos FIXatdl sean válidos y estén bien formados.

La versión 1.1 de FIXatdl fue aprobada preliminarmente por el GTC el 9 de febrero de 2010, cuando entró en un período de comentarios públicos, y finalmente aprobada el 3 de marzo de 2010. La especificación se presentó formalmente al mercado en la conferencia de FPL para Europa, Oriente Medio y África el 23 de marzo de 2010. ^{[ 5 ]}

Se realizaron algunos trabajos iniciales en una versión 1.2 ^{[ 6 ]} del estándar, pero la falta de interés de la industria en incorporar más cambios hizo que el estándar permaneciera en la versión 1.1.

Un documento FIXatdl puede contener una o más definiciones de estrategia. Dentro de una definición de estrategia, hay cuatro secciones principales, como se indica a continuación:

• Sección de metadatos que define a qué regiones geográficas, mercados (bolsas) y clases de activos se aplica la estrategia.
• Sección de parámetros, donde se enumeran todos los parámetros utilizados por la estrategia, sus tipos de datos, restricciones (por ejemplo, valores mínimos y máximos) y cómo deben representarse en el mensaje FIX resultante.
• La sección StrategyLayout define los controles de la interfaz de usuario que se utilizarán para esta estrategia, cómo deben distribuirse en la pantalla y cómo se corresponden con los parámetros descritos en la sección anterior del documento.
• Sección StrategyEdit que describe las reglas de validación que se aplicarán; normalmente, se tratará de validaciones entre campos.

Los documentos FIXatdl deben validarse según el conjunto de esquemas XSD proporcionados por FPL. Estos esquemas están organizados en las siguientes cuatro categorías:

• Núcleo (define el contenido de los datos, los tipos de datos, las restricciones, etc.)
• Diseño (define los controles que se pueden usar y cómo se disponen)
• Validación (autoexplicativo)
• Flujo (permite habilitar/deshabilitar, ocultar/mostrar y actualizar controles, dependiendo del estado o contenido de otros controles).

La versión 1.1 admite 14 controles de interfaz de usuario diferentes, que se pueden agrupar de la siguiente manera:

• Etiquetas
• Campos de entrada de texto (a menudo denominados cuadros de texto)
• Casillas de verificación y botones de opción, tanto individualmente como en listas.
• Cuadros de lista, tanto de selección única como de selección múltiple.
• Listas desplegables, tanto editables como no editables.
• Controles del reloj para la introducción de fecha y hora.
• Deslizadores para seleccionar uno de un pequeño número de configuraciones.
• Selectores numéricos, tanto simples como dobles, para números enteros y de punto flotante respectivamente.

Los controles se organizan mediante una jerarquía de paneles (denominados StrategyPanels), cada uno de los cuales puede tener orientación horizontal o vertical. La imagen de la derecha muestra cómo los elementos XML hacen referencia a los paneles individuales dentro de un diseño determinado.

A diferencia de la versión anterior, la versión 1.1 fue ampliamente aceptada y adoptada por el sector de valores. Incluso a finales de 2009, ya había empresas que utilizaban el estándar 1.1, a pesar de su estado de prelanzamiento. Algunos ejemplos de empresas que respaldan el estándar FIXatdl son:

• Sistema de gestión de ejecución RealTick , por Eze Software Group ^{[ 7 ]}
• Módulo de gestión de pedidos de SimCorp Dimension ^{[ 8 ]}
• Itiviti, con su Sistema de Gestión de Algoritmos, UL AMS
• El sistema de gestión de ejecución de Portware ^{[ 9 ]}
• RapidAddition, con su editor FIXatdl
• Assimilate Technology, con su producto Visual FIX.
• Cornerstone Technology, con su servicio de consultoría empaquetado FIXatdl Jump-Start, ^{[ 10 ]} talleres de capacitación públicos de FIXatdl ^{[ 11 ]} y servicio gratuito de validación de FIXatdl, AtdlTools

También existen implementaciones de código abierto para Java y .NET , atdl4j y Atdl4net respectivamente, que cumplen con la versión 1.1.

A menudo se pregunta por qué FIXatdl no utiliza un estándar de interfaz de usuario comercial , como XUL de Mozilla , Windows Presentation Foundation de Microsoft o Apache Flex . Si bien es una pregunta válida, parece que los autores de la especificación buscaban mantener una independencia total de la plataforma , y ​​adoptar una plataforma en particular podría comprometer este objetivo. Aunque carece del grado de sofisticación de algunas de estas plataformas, la especificación actual ofrece un control aceptable sobre el diseño de la interfaz de usuario sin ser excesivamente restrictiva. Queda por ver cómo resultará esta decisión de diseño, y es probable que se requiera un mayor perfeccionamiento de esta parte de la especificación a medida que aumente su adopción.

• Comercio algorítmico
• Comercio electrónico
• Protocolo de corrección

• Especificación formal en el sitio web oficial.
• El Grupo de Trabajo que desarrolla y mantiene FIXatdl (abierto a todos, pero se requiere inscripción).
• Foro de discusión y soporte (abierto para leer, registro gratuito para publicar)
• Vídeo de presentación de FIXatdl
• FIXatdl - Cambiando el panorama del trading estratégico , FIXGlobal, número de diciembre de 2009/enero de 2010.