2022 – Publicado en: Forex trading

Introducción

La historia del trading en los mercados bursátiles ha cambiado radicalmente desde sus inicios. Las primeras bolsas aparecieron hace unos cuatrocientos años. Entonces, las operaciones se cerraban de palabra y las reglas de negociación apenas empezaban a formarse. Pero el mundo no se detuvo y, acorde con los tiempos, las bolsas adoptaron todas las herramientas técnicas que tenían a su alcance en cada época.

Así, a mediados del siglo XIX, las líneas telegráficas conectaban con la bolsa las solicitudes de negociación enviadas desde cierta distancia. Después, el teléfono sustituyó al telégrafo. Y finalmente llegó el momento en que las primeras solicitudes de negociación de los traders circularon por Internet.

Para ser justos, en algunos brókers todavía se opera a veces por teléfono en la actualidad. Y para algunos de ellos es la única forma garantizada de realizar una operación. Además, desde el nacimiento de las primeras bolsas hasta principios del siglo XXI, las operaciones realizadas directamente en el recinto de la bolsa se hacían de viva voz. Estos parqués se llamaban «pits» y ofrecían un espectáculo que conocemos por las películas de Hollywood sobre temas similares.

Historia del protocolo FIX

Uno de los protocolos de trading digital más antiguos es el protocolo FIX. Sus siglas significan «Financial Information Protocol» o «FInancial eXchange protocol»; se encuentran ambas definiciones. La especificación del protocolo FIX se creó en 1992 para intercambiar información sobre la negociación de acciones entre Fidelity Investments y Salomon Brothers. Los brókers y los fondos de inversión querían agilizar el proceso de negociación en la bolsa. El resultado es un estándar abierto de transmisión electrónica de información que no controla ninguna gran organización. Hoy, FIX se ha convertido en el estándar del sector que utilizan los participantes de los mercados financieros de distintos países para conectar sus productos.

Inicialmente, este protocolo de comunicación solo se utilizaba entre las dos entidades mencionadas, se llamaba SBX (Salomon Brothers Exchange) y se usaba únicamente para negociar acciones. Después, según cuenta la historia, los directivos de estas empresas, conscientes de la importancia de su invento, invitaron a Goldman Sachs y Putman a sumarse al desarrollo. Desde entonces, el protocolo recibe su nombre actual.

Inicialmente, el protocolo admitía solo 17 tipos de mensajes y 103 tags. La idea tuvo tanto éxito que, en 1995, más del 70% de todas las casas de bolsa de EE. UU. utilizaban el protocolo. Esto se debió al ahorro de costes, a la reducción de gastos y a la disminución de errores de negociación. Al fin y al cabo, el factor humano tiene una influencia muy grande cuando se opera por teléfono. Con el tiempo, el protocolo se amplió considerablemente. Se añadió soporte para la negociación de derivados, bonos y divisas. La especificación FIX actual describe 168 mensajes y 7,868 tags, y abarca todas las clases de valores. En 1998, el desarrollo del protocolo FIX y sus especificaciones, así como el de las tecnologías relacionadas, se transfirió al consorcio FIX Protocol Ltd. Más tarde, el consorcio pasó a llamarse FIX Trading Community. Actualmente forman parte de la organización más de 270 instituciones financieras líderes.

Cómo funciona el protocolo FIX

El protocolo FIX funciona sobre TCP. Actualmente, el modelo del protocolo FIX se define en dos niveles: el nivel de sesión o de control (creación de la sesión, entrega de los datos) y el nivel de aplicación (descripción del contenido de los datos). La capa de control se encarga de los parámetros básicos de la sesión FIX: abrir y cerrar la conexión y recuperar los mensajes perdidos. La capa de aplicación controla el envío y la recepción de datos: solicitudes, ejecuciones, rechazos, datos de mercado y solicitudes de información de estado. El protocolo en sí es de texto, es decir, utiliza caracteres de la tabla ASCII. Tiene 2 representaciones: la tradicional, de la forma Tag=Value (Tag=Value o Key=Value), y la representación XML (FIXML). La versión más reciente es actualmente la 5.0, pero las más extendidas son la 4.2 y la 4.4. Distintos brókers y bolsas pueden utilizar distintas versiones del protocolo y, a veces, varias al mismo tiempo.

Sintaxis Tag=Value

El mensaje tiene un aspecto similar al siguiente:

8=FIX.4.2 | 9=178 | 35=D | 34=1234567 | 49=TESTER | 56=PHLX | 52=20071123-05:30:00.000 | 11=ATOMNOCCC9990900 | 54=1 | 167=FUT | 55=MSFT | 38=15 | 40=2 | 44=15 | 59=0 | 10=128 |

Es una cadena de texto formada por varias partes separadas por una barra vertical. Estas partes se llaman campos. A su vez, cada una de ellas consiste en un par clave-valor separado por un signo igual. A la izquierda del signo está la clave y a la derecha, el valor. En la especificación FIX, las claves se llaman tags. Un tag es siempre un número entero positivo que, en esencia, apunta al nombre de un campo. Todos los nombres de campo y sus posibles valores se describen en la documentación de cada bolsa. La mayoría de estos campos son estándar y se encuentran en la especificación de cualquier bolsa. También hay campos personalizados, que se definen y tienen significado solo dentro de una bolsa concreta. Mientras que la descripción de los campos estándar se encuentra en la especificación general del protocolo FIX, los campos personalizados deben describirse en la especificación del protocolo FIX de la bolsa. También hay campos obligatorios, opcionales y condicionalmente obligatorios (obligatorios según la presencia de otros campos en el mensaje). Como separador entre campos se usa el símbolo SoH (Start of Header). En realidad no es visible, por lo que en este ejemplo se sustituye por una barra vertical. En la codificación UNICODE, este carácter tiene el código «\u0001».

A su vez, aunque el mensaje se divide en campos, estos definen 3 componentes más:

Encabezado (Message Header)
Cuerpo (Message Body)
Cola del mensaje (Message Trailer, checksum)

En FIXT.1.1/FIX 5.0, el encabezado contiene 5 campos obligatorios y uno opcional: 8 (BeginString), 9 (BodyLength), 35 (MsgType), 49 (SenderCompID), 56 (TargetCompID) y 1128 (ApplVerID; si está presente, debe ocupar la 6.ª posición). Hay dos grupos principales de mensajes: administrativos y de aplicación. Los mensajes administrativos gestionan los aspectos básicos de una sesión FIX. Permiten iniciar y finalizar una sesión, así como recuperar mensajes perdidos. Los mensajes de aplicación están relacionados con el envío y la recepción de información de negociación, como la solicitud de una orden o la información sobre el estado actual y la posterior ejecución de esa orden.

Analicemos este mensaje:

8=FIX.4.2 – BeginString. Versión del protocolo utilizada. Indica al programa del trader qué reglas aplicar para analizar los campos de este mensaje.
9=178 – BodyLength. La longitud del cuerpo del mensaje es de 178 bytes, incluido el encabezado. Se calcula como el número de caracteres desde el tag 35 (incluido) hasta el tag 10 (excluido). También se cuenta el separador SoH.
35=D – MsgType. Tipo de mensaje. En este caso, D significa la colocación de una solicitud de operación. Por ejemplo, un campo 35=V indica que se solicitan datos de mercado sobre el instrumento.
34=1234567 – MsgSeqNum. Número del mensaje. Si los MsgSeqNum de los mensajes enviados no difieren en 1 dentro de la secuencia, el servidor devuelve un error y no procesa el mensaje.
49=TESTER – SenderCompID. ID del remitente. Lo emite la bolsa. Puede ser un nombre de usuario o el nombre de un bróker si el mensaje lo envía un bróker.
56=PHLX – TargetCompID. ID del destinatario al que se envía. También lo emite la bolsa.
52=20071123-05:30:00.000 – SendingTime. Fecha y hora de envío del mensaje.
11=ATOMNOCCC9990900 – ClOrdID. Número de la solicitud en el sistema de trading del bróker.
54=1 – Side. Acción de compra del activo
167=FUT – SecurityType. El activo es un futuro
55=MSFT – Symbol. Acciones de Microsoft. Los tickers pueden variar de una bolsa a otra.
38=15 – OrderQty. El volumen de la operación es de 15 lotes o contratos.
40=2 – OrdType. Compra a precio limitado, orden limitada.
44=15 – Price. Precio de compra: 15
59=0 – TimeInForce. La solicitud es válida hasta el final de la jornada.
10=128 – CheckSum. Suma de verificación del mensaje. Siempre es el último campo del mensaje. Se calcula mediante una fórmula especial descrita en la especificación del protocolo. Se obtiene sumando los valores ASCII de todos los caracteres del mensaje, excepto los caracteres del propio campo de checksum. A continuación, el valor se divide entre 256 y se toma el resto de la división. El checksum debe tener siempre tres caracteres. Así, si el resto es 22, se añade un cero delante del número: «022».

En términos generales, este mensaje es una orden de compra de futuros sobre acciones de Microsoft por 15 contratos a un precio límite de 15, válida hasta el final del día.

Para dar más flexibilidad a FIX, el protocolo incluye los llamados campos definidos por el usuario (User Defined Fields). Se utilizan para transferir datos entre organizaciones financieras que colaboran entre sí. Para los campos personalizados se reservaron los números de tag del 5000 al 9999, que podían reservarse en el sitio web oficial del estándar. Posteriormente estos números se agotaron, por lo que se asignó un nuevo intervalo, del 20,000 al 39,999.

Sintaxis FIXML

El trabajo sobre esta sintaxis comenzó en 1998 y la primera versión se publicó en 1999. Es semánticamente equivalente a los mensajes codificados con tags, pero utiliza tecnología de análisis XML. Una nueva solicitud de operación en formato FIXML tiene este aspecto:

<FIXML>

<Order ClOrdID=»123456″ Side=»2″ TransactTm=»2001-09-11T09:30:47-05:00″ OrderTyp=»2″ Px=»93.25″

Acct=»26522154″>

</Order>

</FIXML>

En formato XML, cada bloque de código se enmarca en una llamada etiqueta (otro tipo de tag, no el que usa el propio protocolo). Por ejemplo, existe la etiqueta de nivel superior <FIXML>. Cada etiqueta abre un fragmento concreto de código o de mensaje y lo cierra con la misma etiqueta, pero con una barra inclinada junto al borde izquierdo. Así, la etiqueta mencionada cerrará el bloque de esta forma: </FIXML>.

A continuación, dentro de esta etiqueta, vemos la siguiente:

<Order ClOrdID=»123456″ Side=»2″ TransactTm=»2001-09-11T09:30:47-05:00″ OrderTyp=»2″ Px=»93.25″

Acct=»26522154″>.

Aquí vemos el nombre de la etiqueta, Order, y dentro de los corchetes hay información adicional (los mismos campos, pares clave=valor, como en la sintaxis Tag=Value).

En este caso:

ClOrdID=»123456″ – ID de la orden en el sistema de trading del bróker

Side=»2″ – Orden de venta

TransactTm=»2001-09-11T09:30:47-05:00″ fecha y hora de la operación

OrdTyp=»2″ – Tipo de solicitud: orden limitada

Px=»93.25″ – Precio del activo para comprar o vender

Acct=»26522154″ – número de cuenta del usuario

Al igual que la etiqueta XML anterior, esta etiqueta XML se cierra con una barra: </Order>

El contenido entre la etiqueta XML de apertura y la de cierre se denomina cuerpo de la etiqueta. Así, la etiqueta Order es el cuerpo de la etiqueta FIXML. Dentro de la etiqueta Order, como cuerpo, hay dos etiquetas más: Instrmt y OrdQty.

Siguiente etiqueta:

Aquí vemos que es a la vez de apertura y de cierre: al final lleva una barra inclinada. Esto ocurre cuando la etiqueta no tiene cuerpo y no tiene sentido crear una etiqueta de cierre aparte. Esta etiqueta contiene información sobre el ticker del instrumento, su ID, etc.

En la etiqueta <OrdQty Qty=»1000″/> vemos la información sobre el volumen de la operación; también es una etiqueta de cierre sin cuerpo.

FIXML se utiliza normalmente en aplicaciones de back-office y de compensación, no para operar.

Capa de sesión de FIX

Los ejemplos anteriores describían la capa de aplicación. La especificación define tipos de campo especiales que se encargan del nivel de sesión entre el cliente y la bolsa:

35=A – Logon. Se utiliza para autenticar al usuario en el sistema de la bolsa al conectarse. Este mensaje se envía primero e indica a la bolsa el inicio de la sesión de datos. Si el envío es correcto, llega un mensaje de respuesta. Si la conexión falla, se devuelve un error.
35=5 – Logout. Este mensaje se utiliza para cerrar la autenticación con el servidor y finalizar la sesión de trading con la bolsa.
35=0 – Heartbeat. Latido o pulso. Ambos lados de la conexión se envían este mensaje mutuamente para indicar que están listos para recibir y enviar mensajes. La frecuencia del heartbeat se fija en el primer mensaje de Logon.
35=1 – Test Request. Es un mensaje de prueba que se envía cuando la contraparte no ha enviado un mensaje de heartbeat dentro del periodo establecido. La sesión se cerrará si este mensaje queda sin respuesta.
35=2 – Resend Request. Este mensaje es una solicitud de reenvío si se ha perdido alguna información.
35=3 – Reject, o rechazo. Lo envía la contraparte si el mensaje anterior está mal formado o no puede ejecutarse.
35=4 – Sequence Reset, o restablecimiento de la secuencia de envío de mensajes. Puede tener dos formas.

– 123=»Y»: existe un tag GapFillFlag con el valor indicado. Indica una solicitud para ignorar los mensajes administrativos si se están reenviando.

– se utiliza para poner a cero el contador MsgSeqNum

Implementación de FAST como mejora de la FIX API

Los grandes volúmenes de datos FIX sufrían retrasos importantes en su procesamiento, lo que dificultaba a los traders desarrollar estrategias de trading eficaces. Poco después de detectarse este problema, se dieron los primeros pasos para corregir la situación. El objetivo del protocolo FAST era permitir la transmisión de grandes volúmenes de datos evitando retrasos en la obtención de la información. FAST (FIX Adapted for STreaming, es decir, FIX adaptado para streaming) es un estándar tecnológico desarrollado por FIX Protocol Ltd. diseñado específicamente para optimizar la representación de los datos en la red. Es, en esencia, un formato binario del protocolo FIX y permite transferir grandes volúmenes de información sobre operaciones y sobre el entorno de mercado de forma compacta. Esto permite usarlo en sistemas de trading de alta velocidad que requieren bajos retrasos de transmisión. Fast se desarrolló en el Instituto de Tecnología de California, en Pasadena. Actualmente, la última versión es FAST 1.2. Su aplicación más común es la conexión directa a las bolsas, sin pasar por el sistema de trading de los brókers. El protocolo FAST es el protocolo estandarizado de distribución de información de mercado y el más popular del mundo. Antes, todo el tráfico de Internet se basaba en el sistema Transmission Control Protocol (TCP), desarrollado en los años setenta del siglo pasado. TCP es una conexión de socket que requiere confirmación de la entrega de los paquetes. Divide los archivos y mensajes grandes en paquetes de 1500 bytes, cada uno con las direcciones de origen y destino del paquete. El emisor espera la confirmación de que el paquete enviado se entregó correctamente y solo entonces envía el siguiente. Si la entrega falla o la señal de entrega no llega dentro del tiempo de espera especificado, el paquete se vuelve a enviar, pero a una velocidad menor. Y esto puede prolongarse indefinidamente, con la velocidad disminuyendo de forma exponencial, hasta que llega la señal de entrega correcta. Resulta evidente que incluso pequeños problemas en la línea pueden afectar gravemente a la velocidad de los datos, ya que cada envío fallido supone perder valiosos milisegundos. Por eso, FAST introdujo una solución alternativa: el sistema supervisa constantemente los paquetes y los mensajes recibidos para comprobar su correcta entrega, con el fin de detectar de inmediato los problemas en la línea y fijar el siguiente envío a una velocidad estable, aunque ligeramente reducida. Este enfoque elimina en la mayoría de los casos la necesidad de reenviar paquetes, ya que no se pierde tiempo sondeando un rendimiento lento. En algunas bolsas, la interfaz de conexión se implementa mediante dos tipos de conexión: UDP y TCP. Enviar todos los datos por el socket UDP no tiene sentido, ya que este tipo de conexión no requiere confirmación de entrega y los paquetes simplemente desaparecerían sin que ninguna de las partes lo supiera. Por eso, la mayor parte de los datos se transmite por el socket UDP y solo los conjuntos de datos no entregados se transmiten por TCP. En mercados que se mueven rápido, el retraso asociado a la retransmisión suele ser indeseable, ya que provoca oportunidades perdidas o malas operaciones.

Cómo funciona FAST

Como ya sabemos, el protocolo FIX es una secuencia de campos que, a su vez, consisten en pares clave=valor. Además de que el formato de cadena es en sí mismo redundante, se puede observar que cada mensaje tiene elementos duplicados, como los nombres de campo y los caracteres «=». FAST elimina la redundancia mediante una plantilla que describe toda la estructura del mensaje. Este método se denomina etiquetado implícito. Como los tags FIX de los datos transmitidos solo están «implícitos», la sintaxis Tag = Value cambia de la siguiente manera:

Una plantilla describe un conjunto estructurado de campos con sus operadores;
La secuencia de campos del mensaje coincide con la secuencia de tags de la plantilla;
En el mensaje solo se envían los cambios en los datos.

Cada valor de tag tiene una longitud fija en bytes. Conociendo la longitud de un campo concreto y el orden en que se colocan los campos en un mensaje, no es difícil identificar los valores de esos campos. Por tanto, las plantillas permiten transmitir directamente solo los datos, sin necesidad de transferir caracteres redundantes. Esta codificación se denomina codificación binaria simple, o SBE. Así, la codificación y decodificación de los mensajes tienen una latencia mucho menor que en los protocolos de caracteres, porque no es necesario convertir los datos a un formato que los ordenadores puedan usar. Como los campos correspondientes ocupan una posición fija en el mensaje, es mucho más fácil acceder al valor deseado. Solo hay que conocer su desplazamiento respecto al inicio del mensaje y la longitud de su valor. A diferencia de la sintaxis de tags y de FIXML, un mensaje SBE no es autodescriptivo. Por la red solo se envían los datos con un encabezado mínimo que identifica la plantilla que rige el mensaje. Los metadatos (plantillas) que describen la estructura del mensaje se intercambian fuera del canal de comunicación principal. Tras recibir las plantillas necesarias, el servidor de trading sabe en qué formato enviar los datos al cliente dentro de esa sesión conectada. Así, antes de transferir datos, los sistemas acuerdan entre sí cómo comunicarse en adelante. El esquema de mensajes se envía normalmente en formato XML. Puede contener cualquier número de plantillas de mensajes. La plantilla describe los campos que componen el mensaje. Además, el esquema proporciona una lista de tipos de datos simples y complejos que pueden reutilizarse en cualquier número de campos.

Implementaciones abiertas del protocolo FIX para distintos lenguajes

Java – QuickFIX/J – http://www.quickfixj.org/

.NET/C# – QuickFIX/N – http://quickfixn.org/

Analizador en línea gratuito de mensajes FIX – FIX Parser – https://fix.aprics.net/

Implementaciones abiertas de FAST para distintos lenguajes

Para C – Implementación de referencia de FPL – www.fixprotocol.org/fastdownload

Para C# – Implementación de referencia de FPL – www.fixprotocol.org/fastdownload

Para Java – OpenFAST – www.openfast.org

www.sourceforge.net/projects/openfastdotnet/

Para C++ – QuickFAST – www.quickfast.org

Para Golang – goFAST – www.github.com/co11ter/goFAST

Otras codificaciones del protocolo FIX

La comunidad FIX también desarrolló correspondencias estándar entre el protocolo FIX y otros protocolos de serialización de datos, como:

JSON
Google (Protocol buffers)

|ASN.1

Ámbitos de aplicación del protocolo FIX/FAST

Por lo general, la abreviatura aparece precisamente con ambas palabras juntas. Se utiliza para obtener diversa información financiera de las bolsas: tablas de instrumentos financieros (precios, volúmenes, etc.), cotizaciones, todas las operaciones, índices, así como información sobre todas las órdenes anónimas. El conjunto de datos obtenido puede variar según la bolsa. Los principales usuarios de FIX/FAST son:

Traders particulares para operar [Trading en forex con FIX API]
Programadores que crean productos basados en esta tecnología, como plataformas de trading con FIX API, conectores a distintas bolsas, sistemas de trading, sistemas de recopilación de datos y estadísticas.
Intercambio de información entre bolsas
Obtención de los datos más actualizados por parte de diversas agencias de información

El uso más común es el de los traders de alta frecuencia para obtener ventaja sobre otros participantes del mercado mediante el acceso directo al mercado (DMA). Las bolsas, los bancos y los brókers de forex pueden incorporar este protocolo a su ecosistema de trading. Según los datos comúnmente conocidos, los exchanges de criptomonedas no utilizan esta tecnología. Históricamente, estos exchanges utilizan sobre todo conexiones WebSocket para obtener información de mercado y conexiones HTTP REST API para realizar operaciones de trading, ofreciendo conexiones directas a los servidores de trading de los traders. Si bien la tecnología WebSocket sigue siendo comparable en velocidad a una conexión TCP, la HTTP REST API pierde mucho. Conozca SharpTrader Easy FIX API