El protocolo de intercambio de información financiera ( FIX ) es un protocolo de comunicaciones electrónicas iniciado en 1992 para el intercambio internacional en tiempo real de información relacionada con transacciones y mercados de valores . Con billones de dólares negociados anualmente solo en el NASDAQ , las entidades de servicios financieros están empleando el acceso directo al mercado (DMA) para aumentar su velocidad de acceso a los mercados financieros. La gestión de la entrega de aplicaciones comerciales y el mantenimiento de una latencia baja requieren cada vez más una comprensión del protocolo FIX.
La especificación del protocolo FIX fue creada originalmente en 1992 por Robert "Bob" Lamoureux y Chris Morstatt para permitir la comunicación electrónica de datos de operaciones bursátiles entre Fidelity Investments y Salomon Brothers . FIX inicialmente abordó la información entre los corredores-distribuidores y sus clientes institucionales. En ese momento, esta información se comunicaba verbalmente por teléfono. Fidelity se dio cuenta de que la información de sus corredores-distribuidores podía ser enrutada al operador equivocado, o simplemente perderse cuando las partes colgaban sus teléfonos. Quería que tales comunicaciones fueran reemplazadas por datos legibles por máquina que luego pudieran ser compartidos entre los operadores, analizados, utilizados y almacenados. Por ejemplo, los corredores-distribuidores llaman con una indicación de interés ( IOI ) para comprar o vender un bloque de acciones. La iniciativa FIX creó nuevos mensajes como el IOI .
Según la comunidad comercial FIX, FIX se ha convertido en el estándar de mensajería de facto para la comunicación previa y posterior a la negociación en los mercados de valores globales, y se está expandiendo al espacio posterior a la negociación para respaldar el procesamiento directo , además de continuar expandiéndose en los mercados de divisas , renta fija y derivados . [1]
La Comunidad Comercial FIX es un organismo de normalización sin fines de lucro, impulsado por la industria, cuya misión es abordar los problemas comerciales y regulatorios que impactan el comercio de múltiples activos en los mercados financieros globales a través del mayor uso de estándares, incluido el lenguaje de mensajería del Protocolo FIX, brindando eficiencia operativa, mayor transparencia y menores costos y riesgos para todos los participantes del mercado. [2]
El sistema FIX es ampliamente utilizado tanto por el lado comprador (instituciones) como por el lado vendedor (corredores/distribuidores) de los mercados financieros . Entre sus usuarios se encuentran fondos mutuos , bancos de inversión , corredores, bolsas de valores y ECN .
FIX se ha convertido en el protocolo electrónico estándar para las comunicaciones previas a la negociación y la ejecución de operaciones. Aunque se utiliza principalmente para transacciones de acciones en el área de front office , también se pueden realizar derivados de bonos y transacciones de divisas. Se podría decir que, mientras que SWIFT es el estándar para la mensajería de back office , FIX es el estándar para la mensajería de front office. Sin embargo, hoy en día, la membresía de FIX Protocol Ltd. está extendiendo FIX a la asignación de operaciones en bloque y otras fases del proceso de negociación, en todos los mercados, para prácticamente todas las clases de activos.
Originalmente, el estándar FIX era monolítico, e incluía la semántica de la capa de aplicación, la codificación de mensajes y la capa de sesión en una única especificación técnica. Siguió siendo monolítico hasta la versión 4.2 de FIX. [3] A partir de entonces, las codificaciones de mensajes y las especificaciones de la capa de sesión comenzaron a dividirse en documentos separados y, finalmente, FIX evolucionó hasta convertirse en una familia de estándares técnicos relacionados. [4]
La codificación de mensajes, denominada capa de presentación en el modelo de interconexión de sistemas abiertos (modelo OSI), es responsable del formato de cable de los mensajes.
La codificación de mensajes FIX original se conoce como codificación tagvalue. Cada campo consta de una etiqueta numérica única y un valor. La etiqueta identifica el campo semánticamente. Por lo tanto, los mensajes se describen a sí mismos. La codificación tagvalue se basa en caracteres y utiliza códigos ASCII .
Un mensaje se compone de un encabezado, un cuerpo y un final. Los campos del mensaje están separados por el carácter de inicio de encabezado (SOH) ( ASCII 0x01).
Hasta FIX.4.4, el encabezado contiene tres campos: 8 ( BeginString
), 9 ( BodyLength
) y 35 ( MsgType
).
A partir de FIXT.1.1 / FIX.5.0, el encabezado contiene cinco o seis campos: 8 ( BeginString
), 9 ( BodyLength
), 35 ( MsgType
), 49 ( SenderCompID
), 56 ( TargetCompID
) y el opcional 1128 ( ApplVerID
).
El contenido del cuerpo del mensaje está definido por el tipo de mensaje (35 MsgType
) en el encabezado.
El tráiler contiene el último campo del mensaje, 10 ( Checksum
), siempre expresado como un número de tres dígitos (por ejemplo, 10=002
).
Ejemplo de un mensaje FIX, Informe de ejecución ( 35=8
), con el carácter de barra vertical ( |
) que representa el carácter SOH:
8=FIX.4.2 | 9=178 | 35=8 | 49=PHLX | 56=PERS | 52=20071123-05:30:00.000 | 11=ATOMNOCCC9990900 | 20=3 | 150=E | 39=E | 55=MSFT | 167=CS | 54=1 | 38=15 | 40=2 | 44=15 | 58=PHLX EQUITY TESTING | 59=0 | 47=C | 32=0 | 31=0 | 151=15 | 14=0 | 6=0 | 10=128 |
Los mensajes FIX se forman a partir de varios campos; cada campo tiene un par de valores de etiqueta que está separado del siguiente campo por un delimitador SOH (0x01). La etiqueta es un entero que indica el significado del campo. El valor es una matriz de bytes que contienen un significado específico para la etiqueta en particular (por ejemplo, la etiqueta 48 es SecurityID, una cadena que identifica la seguridad; la etiqueta 22 es IDSource, un entero que indica la clase de identificador que se está utilizando). Los valores pueden estar en texto sin formato o codificados como binario puro (en cuyo caso el valor está precedido por un campo de longitud). El protocolo FIX define significados para la mayoría de las etiquetas, pero deja un rango de etiquetas reservadas para uso privado entre partes que consienten.
El protocolo FIX también define conjuntos de campos que forman un mensaje en particular; dentro del conjunto de campos, algunos serán obligatorios y otros opcionales. El orden de los campos dentro del mensaje generalmente no es importante, sin embargo, los grupos repetidos están precedidos por un recuento y los campos cifrados están precedidos por su longitud. El mensaje se divide en tres secciones distintas: la cabeza, el cuerpo y la cola. Los campos deben permanecer dentro de la sección correcta y, dentro de cada sección, la posición puede ser importante, ya que los campos pueden actuar como delimitadores que evitan que un mensaje se cruce con el siguiente. El campo final en cualquier mensaje FIX es la etiqueta 10 ( suma de comprobación ).
Existen dos grupos principales de mensajes: de administración y de aplicación. Los mensajes de administración se ocupan de los aspectos básicos de una sesión FIX. Permiten iniciar y finalizar una sesión y recuperar mensajes perdidos. Los mensajes de aplicación se ocupan del envío y la recepción de información relacionada con el comercio, como una solicitud de orden o información sobre el estado actual y la ejecución posterior de esa orden.
La longitud del cuerpo es el recuento de caracteres que comienza en la etiqueta 35 (incluida) y termina en la etiqueta 10 (excluida), incluidos los delimitadores SOH finales.
El ejemplo siguiente (que se muestra con los delimitadores SOH como '|') tiene una longitud de cuerpo de 65:
8=FIX.4.2|9=65|35=A|49=SERVIDOR|56=CLIENTE|34=177|52=20090107-18:15:16|98=0|108=30|10=062| ^ 5 + 10 + 10 + 7 + 21 + 5 + 7 ^ = 65
La suma de comprobación de un mensaje FIX es siempre el último campo del mensaje, con etiqueta 10
y un valor de 3 caracteres. [5] Se obtiene sumando el valor ASCII de todos los caracteres del mensaje (excepto el campo de suma de comprobación en sí), y luego módulo 256. [6] Por ejemplo, en el mensaje anterior, la suma de todos los valores ASCII (incluidos los caracteres SOH con valor ASCII 1) da como resultado 4158. Al realizar la operación módulo se obtiene el valor 62. Dado que la suma de comprobación se compone de tres caracteres, el resultado es 10=062
.
FIXML [7] es un esquema XML para mensajes FIX. Es semánticamente equivalente a los mensajes codificados con tagvalue pero aprovecha la tecnología de análisis XML. FIXML se utiliza comúnmente para aplicaciones de back-office y de compensación en lugar de operaciones comerciales.
La codificación binaria simple [8] define un formato de cable que utiliza tipos de datos primitivos que son nativos de los sistemas informáticos. Por lo tanto, la codificación y decodificación de mensajes tiene una latencia mucho menor que los protocolos basados en caracteres, ya que no se necesita traducción para poner los datos en un formato que las computadoras puedan usar. Además de las ventajas de latencia, el rendimiento es más determinista porque los mensajes SBE están limitados por plantillas y se prefieren elementos de datos de longitud fija. Otra consecuencia es que los campos generalmente están en una posición fija, de modo que los filtros de mensajes y los enrutadores no necesitan descifrar un mensaje completo para acceder a los campos clave.
El grupo de trabajo de alto rendimiento FIX desarrolló SBE para respaldar el comercio de alto rendimiento. Se consideró que la codificación Tagvalue ya no era adecuada para este propósito, ya que se basa en caracteres en lugar de binarios y sus campos y mensajes de longitud variable dan como resultado un rendimiento no determinista.
A diferencia de tagvalue y FIXML, un mensaje SBE no se describe a sí mismo. Solo se envían datos por la red con un encabezado mínimo para identificar la plantilla que controla un mensaje. Los metadatos que describen el diseño de un mensaje se intercambian fuera de banda entre pares.
FIX Trading Community publica un esquema XML para los esquemas de mensajes de SBE. Un esquema de mensajes puede contener cualquier cantidad de plantillas de mensajes. Una plantilla describe los campos que constituyen un mensaje. Además, un esquema proporciona una lista de tipos de datos simples y compuestos que pueden reutilizarse en cualquier cantidad de campos.
Desde una perspectiva práctica, suponiendo una implementación de C/C++ y ajustando el orden de bytes: la mayoría de los tipos no compuestos en el mensaje se asignan directamente al mismo tipo en el lenguaje. Por ejemplo, los enteros de 32 bits se asignan a uint32_t
, las cadenas fijas se asignan a const char *
, los puntos flotantes se asignan a , float
etc. Se puede generar un C/C++ struct
a partir de la definición del esquema. Luego, dado un puntero a un búfer de mensajes, acceder a los campos no compuestos del mensaje equivale a convertirlo en un puntero a una estructura y acceder directamente a los miembros de la estructura.
/* Estructura generada a partir del esquema */ struct Message { ... uint32_t qty ; ... const char * symbol ; ... }; void consume_message ( void * mensaje_entrante ) { const struct Mensaje * msg = ( const struct Mensaje * ) mensaje_entrante ; printf ( "Se intercambió %u de %s \n " , msg -> cantidad , msg -> símbolo ); ... }
La comunidad comercial FIX también ha desarrollado asignaciones estándar entre FIX y otros protocolos de mensajes, incluidos:
La capa de sesión es responsable del intercambio de mensajes, incluidos los mecanismos de recuperación de puntos de control.
El protocolo de sesión FIX original no tenía un nombre propio, ya que formaba parte de una especificación monolítica que cubría también la semántica de la capa de aplicación y la codificación de mensajes. Sin embargo, a partir de la versión 5.0 de FIX, la capa de sesión se dividió como una especificación independiente con la introducción de FIXT. [9] FIXT era en gran medida lo mismo que la capa de sesión original sin nombre de la versión 4.x, pero ofrecía una innovación significativa: proporcionaba un mecanismo para mezclar versiones de la capa de aplicación de FIX en una versión de sesión común. La versión actual de FIXT es la 1.1.
En teoría, FIXT es independiente del transporte, pero normalmente se emplea en lugar del Protocolo de control de transmisión (TCP).
FIXT es un protocolo punto a punto. Garantiza la entrega de mensajes en ambas direcciones. Los mensajes enviados en cada dirección llevan un número de secuencia de mensaje en el encabezado del mensaje. Si hay una falla de comunicación, un par puede solicitar la retransmisión de los mensajes perdidos. La entrega de mensajes se admite incluso en caso de desconexión y posterior restablecimiento de una sesión.
Para implementar el establecimiento de sesión y la entrega garantizada, FIXT y FIX 4.x clásico definen estos tipos de mensajes de sesión:
FIXP [10] fue desarrollado por el grupo de trabajo de alto rendimiento de FIX [11] para satisfacer las necesidades de transacciones de alto rendimiento. La necesidad principal es la codificación y decodificación de mensajes de baja latencia y el control de las garantías de entrega de mensajes.
Para proporcionar una baja latencia, se admiten codificaciones de mensajes binarios tanto para la capa de sesión como para los mensajes de aplicación. El formato de cable real se resume en la especificación FIXP, por lo que los usuarios pueden seleccionar una codificación FIX de su elección, siempre que los pares acuerden un protocolo a utilizar. En los primeros desarrollos se ha utilizado la codificación binaria simple.
FIXP cubre casos de uso tanto punto a punto como de multidifusión con primitivas comunes.
Cuando se establece una sesión punto a punto, los pares negocian garantías de entrega entre las siguientes opciones:
Las garantías de entrega pueden ser asimétricas. Por ejemplo, un operador puede ingresar órdenes en un flujo idempotente mientras que las ejecuciones se devuelven en un flujo recuperable. En mercados de rápido movimiento, la demora inherente a la retransmisión suele ser indeseable, lo que da como resultado oportunidades perdidas o malas operaciones.
A continuación se muestra un diagrama de cómo corregir el aspecto de los mensajes entre el lado comprador/cliente y el lado vendedor/proveedor. [12]
La última versión del Protocolo FIX implementa "Independencia de Transporte" al permitir que múltiples versiones de mensajes de aplicación se transmitan a través de una única versión de la Sesión FIX Independiente del Transporte (FIXT.1.1 y superior).
La independencia del transporte también allana el camino para que se utilicen protocolos de transporte como colas de mensajes y servicios web en lugar del tradicional FIX sobre TCP.
FIX ahora admite el comercio algorítmico mediante el uso del lenguaje de definición de comercio algorítmico FIX (FIXatdl) .
En 2005, la comunidad comercial FIX lanzó el protocolo FAST , que significa FIX adaptado para transmisión. FAST es un protocolo binario y se utiliza principalmente para enviar datos de mercado de multidifusión a través de conexiones UDP.
Además, en 2020, la comunidad comercial FIX lanzó una nueva codificación binaria FIX, basada en la codificación binaria simple (SBE), destinada a complementar la codificación FAST existente. [13]