<\/p>\n
<\/strong>La historia del trading en los mercados burs\u00e1tiles ha cambiado radicalmente desde sus inicios. Las primeras bolsas aparecieron hace unos cuatrocientos a\u00f1os. Entonces, las operaciones se cerraban de palabra y las reglas de negociaci\u00f3n apenas empezaban a formarse. Pero el mundo no se detuvo y, acorde con los tiempos, las bolsas adoptaron todas las herramientas t\u00e9cnicas que ten\u00edan a su alcance en cada \u00e9poca.<\/p>\n As\u00ed, a mediados del siglo XIX, las l\u00edneas telegr\u00e1ficas conectaban con la bolsa las solicitudes de negociaci\u00f3n enviadas desde cierta distancia. Despu\u00e9s, el tel\u00e9fono sustituy\u00f3 al tel\u00e9grafo. Y finalmente lleg\u00f3 el momento en que las primeras solicitudes de negociaci\u00f3n de los traders circularon por Internet.<\/p>\n Para ser justos, en algunos br\u00f3kers todav\u00eda se opera a veces por tel\u00e9fono en la actualidad. Y para algunos de ellos es la \u00fanica forma garantizada de realizar una operaci\u00f3n. Adem\u00e1s, desde el nacimiento de las primeras bolsas hasta principios del siglo XXI, las operaciones realizadas directamente en el recinto de la bolsa se hac\u00edan de viva voz. Estos parqu\u00e9s se llamaban \u00abpits\u00bb y ofrec\u00edan un espect\u00e1culo que conocemos por las pel\u00edculas de Hollywood sobre temas similares.<\/p>\n <\/strong>Uno de los protocolos de trading digital m\u00e1s antiguos es el protocolo FIX. Sus siglas significan \u00abFinancial Information Protocol\u00bb o \u00abFInancial eXchange protocol\u00bb; se encuentran ambas definiciones. La especificaci\u00f3n del protocolo FIX se cre\u00f3 en 1992 para intercambiar informaci\u00f3n sobre la negociaci\u00f3n de acciones entre Fidelity Investments y Salomon Brothers. Los br\u00f3kers y los fondos de inversi\u00f3n quer\u00edan agilizar el proceso de negociaci\u00f3n en la bolsa. El resultado es un est\u00e1ndar abierto de transmisi\u00f3n electr\u00f3nica de informaci\u00f3n que no controla ninguna gran organizaci\u00f3n. Hoy, FIX se ha convertido en el est\u00e1ndar del sector que utilizan los participantes de los mercados financieros de distintos pa\u00edses para conectar sus productos.<\/p>\n Inicialmente, este protocolo de comunicaci\u00f3n solo se utilizaba entre las dos entidades mencionadas, se llamaba SBX (Salomon Brothers Exchange) y se usaba \u00fanicamente para negociar acciones. Despu\u00e9s, seg\u00fan 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.<\/p>\n Inicialmente, el protocolo admit\u00eda solo 17 tipos de mensajes y 103 tags. La idea tuvo tanto \u00e9xito que, en 1995, m\u00e1s del 70% de todas las casas de bolsa de EE. UU. utilizaban el protocolo. Esto se debi\u00f3 al ahorro de costes, a la reducci\u00f3n de gastos y a la disminuci\u00f3n de errores de negociaci\u00f3n. Al fin y al cabo, el factor humano tiene una influencia muy grande cuando se opera por tel\u00e9fono. Con el tiempo, el protocolo se ampli\u00f3 considerablemente. Se a\u00f1adi\u00f3 soporte para la negociaci\u00f3n de derivados, bonos y divisas. La especificaci\u00f3n 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\u00ed como el de las tecnolog\u00edas relacionadas, se transfiri\u00f3 al consorcio FIX Protocol Ltd. M\u00e1s tarde, el consorcio pas\u00f3 a llamarse FIX Trading Community. Actualmente forman parte de la organizaci\u00f3n m\u00e1s de 270 instituciones financieras l\u00edderes.<\/p>\n <\/strong>El protocolo FIX funciona sobre TCP. Actualmente, el modelo del protocolo FIX se define en dos niveles: el nivel de sesi\u00f3n o de control (creaci\u00f3n de la sesi\u00f3n, entrega de los datos) y el nivel de aplicaci\u00f3n (descripci\u00f3n del contenido de los datos). La capa de control se encarga de los par\u00e1metros b\u00e1sicos de la sesi\u00f3n FIX: abrir y cerrar la conexi\u00f3n y recuperar los mensajes perdidos. La capa de aplicaci\u00f3n controla el env\u00edo y la recepci\u00f3n de datos: solicitudes, ejecuciones, rechazos, datos de mercado y solicitudes de informaci\u00f3n de estado. El protocolo en s\u00ed 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\u00f3n XML (FIXML). La versi\u00f3n m\u00e1s reciente es actualmente la 5.0, pero las m\u00e1s extendidas son la 4.2 y la 4.4. Distintos br\u00f3kers y bolsas pueden utilizar distintas versiones del protocolo y, a veces, varias al mismo tiempo.<\/p>\n Sintaxis Tag=Value<\/p>\n El mensaje tiene un aspecto similar al siguiente:<\/p>\n 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 |<\/p>\n 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\u00e1 la clave y a la derecha, el valor. En la especificaci\u00f3n FIX, las claves se llaman tags. Un tag es siempre un n\u00famero 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\u00f3n de cada bolsa. La mayor\u00eda de estos campos son est\u00e1ndar y se encuentran en la especificaci\u00f3n de cualquier bolsa. Tambi\u00e9n hay campos personalizados, que se definen y tienen significado solo dentro de una bolsa concreta. Mientras que la descripci\u00f3n de los campos est\u00e1ndar se encuentra en la especificaci\u00f3n general del protocolo FIX, los campos personalizados deben describirse en la especificaci\u00f3n del protocolo FIX de la bolsa. Tambi\u00e9n hay campos obligatorios, opcionales y condicionalmente obligatorios (obligatorios seg\u00fan la presencia de otros campos en el mensaje). Como separador entre campos se usa el s\u00edmbolo SoH (Start of Header). En realidad no es visible, por lo que en este ejemplo se sustituye por una barra vertical. En la codificaci\u00f3n UNICODE, este car\u00e1cter tiene el c\u00f3digo \u00ab\\u0001\u00bb.<\/p>\n A su vez, aunque el mensaje se divide en campos, estos definen 3 componentes m\u00e1s:<\/p>\n <\/p>\n 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\u00e1 presente, debe ocupar la 6.\u00aa posici\u00f3n). Hay dos grupos principales de mensajes: administrativos y de aplicaci\u00f3n. Los mensajes administrativos gestionan los aspectos b\u00e1sicos de una sesi\u00f3n FIX. Permiten iniciar y finalizar una sesi\u00f3n, as\u00ed como recuperar mensajes perdidos. Los mensajes de aplicaci\u00f3n est\u00e1n relacionados con el env\u00edo y la recepci\u00f3n de informaci\u00f3n de negociaci\u00f3n, como la solicitud de una orden o la informaci\u00f3n sobre el estado actual y la posterior ejecuci\u00f3n de esa orden.<\/p>\n Analicemos este mensaje:<\/p>\n <\/p>\n En t\u00e9rminos generales, este mensaje es una orden de compra de futuros sobre acciones de Microsoft por 15 contratos a un precio l\u00edmite de 15, v\u00e1lida hasta el final del d\u00eda.<\/p>\n Para dar m\u00e1s 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\u00ed. Para los campos personalizados se reservaron los n\u00fameros de tag del 5000 al 9999, que pod\u00edan reservarse en el sitio web oficial del est\u00e1ndar. Posteriormente estos n\u00fameros se agotaron, por lo que se asign\u00f3 un nuevo intervalo, del 20,000 al 39,999.<\/p>\n El trabajo sobre esta sintaxis comenz\u00f3 en 1998 y la primera versi\u00f3n se public\u00f3 en 1999. Es sem\u00e1nticamente equivalente a los mensajes codificados con tags, pero utiliza tecnolog\u00eda de an\u00e1lisis XML. Una nueva solicitud de operaci\u00f3n en formato FIXML tiene este aspecto:<\/p>\n <FIXML><\/p>\n <Order ClOrdID=\u00bb123456″ Side=\u00bb2″ TransactTm=\u00bb2001-09-11T09:30:47-05:00″ OrderTyp=\u00bb2″ Px=\u00bb93.25″<\/p>\n Acct=\u00bb26522154″><\/p>\n <Instrmt Sym=\u00bbIBM\u00bb ID=\u00bb459200101″ IDSrc=\u00bb1″\/><\/p>\n <OrdQty Qty Qty=\u00bb1000″\/><\/p>\n <\/Order><\/p>\n <\/FIXML><\/p>\n En formato XML, cada bloque de c\u00f3digo 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\u00f3digo o de mensaje y lo cierra con la misma etiqueta, pero con una barra inclinada junto al borde izquierdo. As\u00ed, la etiqueta mencionada cerrar\u00e1 el bloque de esta forma: <\/FIXML>.<\/p>\n A continuaci\u00f3n, dentro de esta etiqueta, vemos la siguiente:<\/p>\n <Order ClOrdID=\u00bb123456″ Side=\u00bb2″ TransactTm=\u00bb2001-09-11T09:30:47-05:00″ OrderTyp=\u00bb2″ Px=\u00bb93.25″<\/p>\n Acct=\u00bb26522154″>.<\/p>\n Aqu\u00ed vemos el nombre de la etiqueta, Order, y dentro de los corchetes hay informaci\u00f3n adicional (los mismos campos, pares clave=valor, como en la sintaxis Tag=Value).<\/p>\n En este caso:<\/p>\n ClOrdID=\u00bb123456″ – ID de la orden en el sistema de trading del br\u00f3ker<\/p>\n Side=\u00bb2″ – Orden de venta<\/p>\n TransactTm=\u00bb2001-09-11T09:30:47-05:00″ fecha y hora de la operaci\u00f3n<\/p>\n OrdTyp=\u00bb2″ – Tipo de solicitud: orden limitada<\/p>\n Px=\u00bb93.25″ – Precio del activo para comprar o vender<\/p>\n Acct=\u00bb26522154″ – n\u00famero de cuenta del usuario<\/p>\n Al igual que la etiqueta XML anterior, esta etiqueta XML se cierra con una barra: <\/Order><\/p>\n El contenido entre la etiqueta XML de apertura y la de cierre se denomina cuerpo de la etiqueta. As\u00ed, la etiqueta Order es el cuerpo de la etiqueta FIXML. Dentro de la etiqueta Order, como cuerpo, hay dos etiquetas m\u00e1s: Instrmt y OrdQty.<\/p>\n Siguiente etiqueta:<\/p>\n <Instrmt Sym=\u00bbIBM\u00bb ID=\u00bb459200101″ IDSrc=\u00bb1″\/><\/p>\n Aqu\u00ed 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\u00f3n sobre el ticker del instrumento, su ID, etc.<\/p>\n En la etiqueta <OrdQty Qty=\u00bb1000″\/> vemos la informaci\u00f3n sobre el volumen de la operaci\u00f3n; tambi\u00e9n es una etiqueta de cierre sin cuerpo.<\/p>\n <\/p>\n FIXML se utiliza normalmente en aplicaciones de back-office y de compensaci\u00f3n, no para operar.<\/p>\n <\/strong>Los ejemplos anteriores describ\u00edan la capa de aplicaci\u00f3n. La especificaci\u00f3n define tipos de campo especiales que se encargan del nivel de sesi\u00f3n entre el cliente y la bolsa:<\/p>\n – 123=\u00bbY\u00bb: existe un tag GapFillFlag con el valor indicado. Indica una solicitud para ignorar los mensajes administrativos si se est\u00e1n reenviando.<\/p>\n – se utiliza para poner a cero el contador MsgSeqNum<\/p>\n Los grandes vol\u00famenes de datos FIX sufr\u00edan retrasos importantes en su procesamiento, lo que dificultaba a los traders desarrollar estrategias de trading eficaces. Poco despu\u00e9s de detectarse este problema, se dieron los primeros pasos para corregir la situaci\u00f3n. El objetivo del protocolo FAST era permitir la transmisi\u00f3n de grandes vol\u00famenes de datos evitando retrasos en la obtenci\u00f3n de la informaci\u00f3n. FAST (FIX Adapted for STreaming, es decir, FIX adaptado para streaming) es un est\u00e1ndar tecnol\u00f3gico desarrollado por FIX Protocol Ltd. dise\u00f1ado espec\u00edficamente para optimizar la representaci\u00f3n de los datos en la red. Es, en esencia, un formato binario del protocolo FIX y permite transferir grandes vol\u00famenes de informaci\u00f3n 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\u00f3n. Fast se desarroll\u00f3 en el Instituto de Tecnolog\u00eda de California, en Pasadena. Actualmente, la \u00faltima versi\u00f3n es FAST 1.2. Su aplicaci\u00f3n m\u00e1s com\u00fan es la conexi\u00f3n directa a las bolsas, sin pasar por el sistema de trading de los br\u00f3kers. El protocolo FAST es el protocolo estandarizado de distribuci\u00f3n de informaci\u00f3n de mercado y el m\u00e1s popular del mundo. Antes, todo el tr\u00e1fico de Internet se basaba en el sistema Transmission Control Protocol (TCP), desarrollado en los a\u00f1os setenta del siglo pasado. TCP es una conexi\u00f3n de socket que requiere confirmaci\u00f3n 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\u00f3n de que el paquete enviado se entreg\u00f3 correctamente y solo entonces env\u00eda el siguiente. Si la entrega falla o la se\u00f1al 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\u00f1al de entrega correcta. Resulta evidente que incluso peque\u00f1os problemas en la l\u00ednea pueden afectar gravemente a la velocidad de los datos, ya que cada env\u00edo fallido supone perder valiosos milisegundos. Por eso, FAST introdujo una soluci\u00f3n 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\u00ednea y fijar el siguiente env\u00edo a una velocidad estable, aunque ligeramente reducida. Este enfoque elimina en la mayor\u00eda 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\u00f3n se implementa mediante dos tipos de conexi\u00f3n: UDP y TCP. Enviar todos los datos por el socket UDP no tiene sentido, ya que este tipo de conexi\u00f3n no requiere confirmaci\u00f3n de entrega y los paquetes simplemente desaparecer\u00edan 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\u00e1pido, el retraso asociado a la retransmisi\u00f3n suele ser indeseable, ya que provoca oportunidades perdidas o malas operaciones.<\/p>\n Como ya sabemos, el protocolo FIX es una secuencia de campos que, a su vez, consisten en pares clave=valor. Adem\u00e1s de que el formato de cadena es en s\u00ed mismo redundante, se puede observar que cada mensaje tiene elementos duplicados, como los nombres de campo y los caracteres \u00ab=\u00bb. FAST elimina la redundancia mediante una plantilla que describe toda la estructura del mensaje. Este m\u00e9todo se denomina etiquetado impl\u00edcito. Como los tags FIX de los datos transmitidos solo est\u00e1n \u00abimpl\u00edcitos\u00bb, la sintaxis Tag = Value cambia de la siguiente manera:<\/p>\n 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\u00edcil identificar los valores de esos campos. Por tanto, las plantillas permiten transmitir directamente solo los datos, sin necesidad de transferir caracteres redundantes. Esta codificaci\u00f3n se denomina codificaci\u00f3n binaria simple, o SBE. As\u00ed, la codificaci\u00f3n y decodificaci\u00f3n 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\u00f3n fija en el mensaje, es mucho m\u00e1s f\u00e1cil 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\u00edan los datos con un encabezado m\u00ednimo que identifica la plantilla que rige el mensaje. Los metadatos (plantillas) que describen la estructura del mensaje se intercambian fuera del canal de comunicaci\u00f3n principal. Tras recibir las plantillas necesarias, el servidor de trading sabe en qu\u00e9 formato enviar los datos al cliente dentro de esa sesi\u00f3n conectada. As\u00ed, antes de transferir datos, los sistemas acuerdan entre s\u00ed c\u00f3mo comunicarse en adelante. El esquema de mensajes se env\u00eda normalmente en formato XML. Puede contener cualquier n\u00famero de plantillas de mensajes. La plantilla describe los campos que componen el mensaje. Adem\u00e1s, el esquema proporciona una lista de tipos de datos simples y complejos que pueden reutilizarse en cualquier n\u00famero de campos.<\/p>\n Implementaciones abiertas del protocolo FIX para distintos lenguajes<\/p>\n Java – QuickFIX\/J – http:\/\/www.quickfixj.org\/<\/p>\n .NET\/C# – QuickFIX\/N – http:\/\/quickfixn.org\/<\/p>\n Analizador en l\u00ednea gratuito de mensajes FIX – FIX Parser – https:\/\/fix.aprics.net\/<\/p>\n Implementaciones abiertas de FAST para distintos lenguajes<\/p>\n Para C – Implementaci\u00f3n de referencia de FPL – www.fixprotocol.org\/fastdownload<\/p>\n Para C# – Implementaci\u00f3n de referencia de FPL – www.fixprotocol.org\/fastdownload<\/p>\n Para Java – OpenFAST – www.openfast.org<\/p>\n www.sourceforge.net\/projects\/openfastdotnet\/<\/p>\n Para C++ – QuickFAST – www.quickfast.org<\/p>\n Para Golang – goFAST – www.github.com\/co11ter\/goFAST<\/p>\n Otras codificaciones del protocolo FIX<\/p>\n La comunidad FIX tambi\u00e9n desarroll\u00f3 correspondencias est\u00e1ndar entre el protocolo FIX y otros protocolos de serializaci\u00f3n de datos, como:<\/p>\n |ASN.1<\/p>\n Por lo general, la abreviatura aparece precisamente con ambas palabras juntas. Se utiliza para obtener diversa informaci\u00f3n financiera de las bolsas: tablas de instrumentos financieros (precios, vol\u00famenes, etc.), cotizaciones, todas las operaciones, \u00edndices, as\u00ed como informaci\u00f3n sobre todas las \u00f3rdenes an\u00f3nimas. El conjunto de datos obtenido puede variar seg\u00fan la bolsa. Los principales usuarios de FIX\/FAST son:<\/p>\nHistoria del protocolo FIX<\/strong><\/h3>\n
C\u00f3mo funciona el protocolo FIX<\/strong><\/h2>\n
\n
\n
Sintaxis FIXML<\/strong><\/h3>\n
Capa de sesi\u00f3n de FIX<\/strong><\/h3>\n
\n
Implementaci\u00f3n de FAST como mejora de la FIX API<\/strong><\/h3>\n
C\u00f3mo funciona FAST<\/strong><\/h3>\n
\n
\n
\u00c1mbitos de aplicaci\u00f3n del protocolo FIX\/FAST<\/strong><\/h2>\n
\n