Como funciona o protocolo FIX Segunda-feira, 7 de Março de 2022 – Posted in: Forex trading

Introdução

A história da negociação nas bolsas de valores mudou drasticamente desde o seu início. As primeiras bolsas surgiram há cerca de quatrocentos anos. Naquela época, os negócios eram fechados verbalmente, e as regras de negociação estavam apenas começando a se formar. Mas o mundo não ficou parado e, acompanhando os tempos, as bolsas adotaram todas as ferramentas técnicas que estavam disponíveis em cada época.

Assim, em meados do século XIX, as ordens de negociação feitas a distância da bolsa passaram a ser transmitidas por linhas telegráficas. Depois, o telefone substituiu o telégrafo. E, por fim, chegou o momento em que as primeiras ordens dos traders passaram a trafegar pelas comunicações da internet.

Para ser justo, a negociação por telefone ainda acontece hoje em algumas corretoras. E, para uma parte delas, é a única forma garantida de realizar uma operação. Além disso, desde o surgimento das primeiras bolsas até o início do século XXI, as operações realizadas diretamente no recinto das bolsas eram feitas de viva voz. Esses pregões eram chamados de stock pits e ofereciam um espetáculo que conhecemos dos filmes de Hollywood sobre o tema.

História do protocolo FIX

Um dos protocolos digitais de negociação mais antigos é o protocolo FIX. A sigla significa “Financial Information Protocol” ou “FInancial eXchange protocol” — as duas definições são encontradas. A especificação do protocolo FIX foi criada em 1992 para a troca de informações sobre negociação de ações entre a Fidelity Investments e a Salomon Brothers. Corretoras e fundos de investimento queriam acelerar o processo de negociação na bolsa. O resultado foi um padrão aberto de transmissão eletrônica de informações que não é controlado por nenhuma grande organização. Hoje, o FIX tornou-se o padrão do setor, usado por participantes do mercado financeiro de diversos países para conectar seus produtos.

Inicialmente, esse protocolo de comunicação era usado apenas entre as duas empresas mencionadas acima, chamava-se SBX (Salomon Brothers Exchange) e era usado apenas para negociação de ações. Depois, segundo conta a história, os líderes dessas empresas, percebendo a importância de sua invenção, convidaram a Goldman Sachs e a Putman a participar do desenvolvimento. Desde então, o protocolo recebeu seu nome atual.

Inicialmente, o protocolo suportava apenas 17 tipos de mensagem e 103 tags. A ideia teve tanto sucesso que, em 1995, mais de 70% de todas as corretoras dos EUA usavam o protocolo. Isso se deveu à economia de custos, a despesas menores e à redução de erros de negociação. Afinal, o fator humano tem uma influência muito grande na negociação por telefone. Com o tempo, o protocolo se expandiu significativamente. Foi adicionado suporte à negociação de derivativos, títulos e moedas. A especificação FIX atual descreve 168 mensagens e 7.868 tags e abrange todas as classes de valores mobiliários. Em 1998, o desenvolvimento do protocolo FIX e de suas especificações, bem como das tecnologias relacionadas, foi transferido para o consórcio FIX Protocol Ltd. Mais tarde, o consórcio foi renomeado para FIX Trading Community. Hoje, mais de 270 instituições financeiras líderes são membros da organização.

Como funciona o protocolo FIX

O protocolo FIX funciona sobre TCP. Atualmente, o modelo do protocolo FIX é definido em dois níveis — o nível de sessão ou de controle (criação da sessão, entrega dos dados) e o nível de aplicação (descrição do conteúdo dos dados). A camada de controle é responsável pelos parâmetros básicos da sessão FIX: abrir e fechar a conexão e recuperar mensagens perdidas. A camada de aplicação controla o envio e o recebimento de dados: ordens, execuções, rejeições, dados de mercado e solicitações de informações de status. O protocolo em si é textual, ou seja, usa caracteres da tabela ASCII. Ele tem 2 representações — a tradicional, no formato Tag=Value (Tag=Value ou Key=Value), e a representação em XML (FIXML). A versão mais recente atualmente é a 5.0, mas as mais comuns são as versões 4.2 e 4.4. Corretoras e bolsas diferentes podem usar versões diferentes do protocolo, às vezes várias ao mesmo tempo.

Sintaxe Tag=Value

A mensagem tem esta aparência:

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 |

Trata-se de uma sequência de texto composta por várias partes separadas por uma barra vertical. Essas partes são chamadas de campos. Por sua vez, cada parte consiste em um par chave-valor separado pelo sinal de igual. À esquerda do sinal está a chave, à direita está o valor. Na especificação FIX, as chaves são chamadas de tags. Uma tag é sempre um número inteiro positivo que, na prática, aponta para o nome de um campo. Todos os nomes de campos e seus valores possíveis são descritos na documentação de cada bolsa. A maioria desses campos é padrão e pode ser encontrada na documentação de qualquer bolsa. Existem também campos personalizados, que são definidos e só têm significado dentro de uma bolsa específica. Enquanto a descrição dos campos padrão pode ser encontrada na especificação geral do protocolo FIX, os campos personalizados devem ser descritos na especificação do protocolo FIX da bolsa. Há também campos obrigatórios, opcionais e condicionalmente obrigatórios (obrigatórios dependendo da presença de outros campos na mensagem). O símbolo SoH (Start of Header) é usado como separador entre os campos. Na verdade, ele não é visível, por isso foi substituído por uma barra vertical neste exemplo. Na codificação UNICODE, esse caractere tem o código “\u0001”.

Por sua vez, além de ser dividida em campos, a mensagem se organiza em mais 3 componentes:

Cabeçalho (Message Header)
Corpo (Message Body)
Trailer da mensagem (checksum)

No FIXT.1.1/FIX 5.0, o cabeçalho contém 5 campos obrigatórios e um campo opcional: 8 (BeginString), 9 (BodyLength), 35 (MsgType), 49 (SenderCompID), 56 (TargetCompID) e 1128 (ApplVerID – se presente, deve estar na 6ª posição). Há dois grupos principais de mensagens — administrativas e de aplicação. As mensagens administrativas tratam dos elementos básicos de uma sessão FIX. Elas permitem iniciar e encerrar uma sessão, bem como recuperar mensagens perdidas. As mensagens de aplicação estão relacionadas ao envio e recebimento de informações de negociação, como o envio de uma ordem ou informações sobre o status atual e a posterior execução dessa ordem.

Vamos analisar esta mensagem:

8=FIX.4.2 – BeginString. A versão do protocolo utilizada. Indica ao programa do trader quais regras aplicar para interpretar os campos desta mensagem.
9=178 – BodyLength. O comprimento do corpo da mensagem é de 178 bytes, incluindo o cabeçalho. É calculado como o número de caracteres da tag 35 (inclusive) até a tag 10 (exclusive). O separador SoH também é contado.
35=D – MsgType. Tipo de mensagem. Neste caso, D significa o envio de uma ordem de negociação. Por exemplo, um campo 35=V indica que estão sendo solicitados dados de mercado sobre o instrumento.
34=1234567 – MsgSeqNum. Número da mensagem. Se os MsgSeqNum das mensagens enviadas não diferirem em 1 na sequência, o servidor retorna um erro e não processa a mensagem.
49=TESTER – SenderCompID. ID do remetente. Emitido pela bolsa. Pode ser um nome de usuário ou o nome de uma corretora, se a mensagem for enviada por uma corretora.
56=PHLX – TargetCompID. ID do destinatário. Também emitido pela bolsa.
52=20071123-05:30:00.000 – SendingTime. Data e hora do envio da mensagem.
11=ATOMNOCCC9990900 – ClOrdID. Número da ordem no sistema de negociação da corretora.
54=1 – Side. Ação de compra do ativo
167=FUT – SecurityType. O ativo é um contrato futuro
55=MSFT – Symbol. Ações da Microsoft. Os tickers podem variar de uma bolsa para outra.
38=15 – OrderQty. O volume da operação é de 15 lotes ou contratos.
40=2 – OrdType. Compra com preço limitado, ordem limitada.
44=15 – Price. Preço de compra – 15
59=0 – TimeInForce. A ordem é válida até o fim do dia útil.
10=128 – CheckSum. Checksum da mensagem. É sempre o último campo da mensagem. É calculado por uma fórmula especial descrita na especificação do protocolo. Obtém-se somando os valores ASCII de todos os caracteres da mensagem, exceto os caracteres do próprio campo de checksum. Em seguida, o valor é dividido por 256 e toma-se o resto da divisão. O checksum deve ter sempre três caracteres. Assim, se o resto for 22, acrescenta-se um zero antes do número – “022”.

Descrevendo esta mensagem de forma geral, trata-se de uma ordem de compra de futuros de ações da Microsoft na quantidade de 15 contratos ao preço limite de 15, com validade até o fim do dia.

Para oferecer mais flexibilidade, o protocolo FIX contém os chamados campos definidos pelo usuário (User Defined Fields). Eles são usados para a troca de dados entre organizações financeiras parceiras. Os números de tag de 5000 a 9999 foram reservados para campos personalizados, que podiam ser registrados no site oficial do padrão. Esses números acabaram sendo todos usados, então foi alocado um novo intervalo, de 20.000 a 39.999.

Sintaxe FIXML

O trabalho nessa sintaxe começou em 1998, e a primeira versão foi lançada em 1999. Ela é semanticamente equivalente às mensagens codificadas com tags, mas usa a tecnologia de análise XML. Uma nova ordem no formato FIXML fica assim:

<FIXML>

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

Acct=”26522154″>

</Order>

</FIXML>

No formato XML, um bloco específico de código é delimitado pela chamada tag (outra tag, não aquela usada pelo próprio protocolo). Por exemplo, existe a tag de nível superior <FIXML>. Toda tag delimita um trecho específico de código ou mensagem e o fecha com a mesma tag, mas com uma barra na borda esquerda interna. Assim, a tag mencionada fecha o bloco da seguinte forma: </FIXML>.

Em seguida, dentro dessa tag, vemos a seguinte tag:

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

Acct=”26522154″>.

Aqui vemos o nome da tag – Order, e dentro dos sinais há informações adicionais (os mesmos campos, pares chave=valor, como na sintaxe Tag=Value).

Neste caso:

ClOrdID=”123456″ – id da ordem no sistema de negociação da corretora

Side=”2″ – ordem de venda

TransactTm=”2001-09-11T09:30:47-05:00″ data e hora da operação

OrdTyp=”2″ – tipo de ordem – ordem limitada

Px=”93.25″ – o preço do ativo para compra ou venda

Acct=”26522154″ – número da conta do usuário

Assim como a tag XML anterior, esta tag XML é fechada com uma barra – </Order>

O conteúdo entre a tag XML de abertura e a de fechamento é chamado de corpo da tag. Assim, a tag Order é o corpo da tag FIXML. Dentro da tag Order, como corpo, há mais duas tags: Instrmt e OrdQty.

Próxima tag:

Aqui vemos que ela é de abertura e de fechamento ao mesmo tempo: no final há uma barra. Isso acontece quando a tag não tem corpo e não faz sentido criar uma tag de fechamento separada. Esta tag contém informações sobre o ticker do instrumento, seu id etc.

Na tag <OrdQty Qty=”1000″/> vemos informações sobre o volume da operação; ela também é uma tag de fechamento sem corpo.

O FIXML costuma ser usado em aplicações de back-office e compensação, e não para negociação.

Camada de sessão FIX

Os exemplos anteriores descreveram a camada de aplicação. A especificação define tipos especiais de campos responsáveis pelo nível de sessão entre o cliente e a bolsa:

35=A – Logon. Usado para autenticar o usuário no sistema da bolsa ao se conectar. Esta mensagem é enviada primeiro e sinaliza à bolsa o início da sessão de dados. Em caso de envio bem-sucedido, chega uma mensagem de resposta. Se a conexão falhar, um erro é retornado.
35=5 – Logout. Esta mensagem é usada para encerrar a autorização no servidor e fechar a sessão de negociação com a bolsa.
35=0 – Heartbeat. Batimento cardíaco, ou pulso. Esta mensagem é trocada entre os dois lados da conexão e indica que ambos estão prontos para receber e enviar mensagens. A frequência do heartbeat é definida na primeira mensagem de Logon.
35=1 – Test Request. Esta é uma mensagem de teste, enviada quando a contraparte não enviou uma mensagem de heartbeat dentro de um período definido. A sessão será encerrada se esta mensagem ficar sem resposta.
35=2 – Resend Request. Esta mensagem é uma solicitação de reenvio caso alguma informação tenha sido perdida.
35=3 – Reject, ou rejeição. Enviada pela contraparte se a mensagem anterior estiver malformada ou não puder ser executada.
35=4 – Sequence Reset, ou redefinição da sequência de envio de mensagens. Pode ter duas formas.

– 123=”Y” – Há uma tag GapFillFlag com o valor especificado. Indica uma solicitação para ignorar mensagens administrativas caso estejam sendo reenviadas.

– usada para zerar o contador MsgSeqNum

Implementação do FAST como aprimoramento da FIX API

Grandes volumes de dados FIX sofriam atrasos significativos no processamento, o que dificultava aos traders desenvolver estratégias de negociação eficazes. Logo após a identificação desse problema, foram dados os primeiros passos para corrigir a situação. O objetivo do protocolo FAST era permitir a transmissão de grandes volumes de dados, evitando atrasos na obtenção das informações. FAST (FIX Adapted for STreaming, ou seja, FIX adaptado para streaming) é um padrão tecnológico desenvolvido pela FIX Protocol Ltd. especificamente para otimizar a representação dos dados na rede. Trata-se essencialmente de um formato binário do protocolo FIX, que permite transferir grandes volumes de informações sobre operações e sobre o ambiente de mercado de forma compacta. Isso possibilita seu uso em sistemas de negociação de alta velocidade que exigem baixos atrasos de transmissão. O Fast foi desenvolvido no California Institute of Technology, em Pasadena. Atualmente, a versão mais recente é a FAST 1.2. A aplicação mais comum é a conexão direta às bolsas, sem passar pelo sistema de negociação das corretoras. O protocolo FAST é o protocolo padronizado de distribuição de informações de mercado e o mais popular do mundo. Antes, todo o tráfego da internet era baseado no Transmission Control Protocol (TCP), desenvolvido nos anos setenta do século passado. O TCP é uma conexão por socket que exige confirmação da entrega dos pacotes. Ele divide arquivos e mensagens grandes em pacotes de 1500 bytes, cada um contendo os endereços de origem e destino. O remetente aguarda a confirmação de que o pacote enviado foi entregue com sucesso e só então envia o próximo. Se a entrega falhar ou o sinal de entrega não chegar dentro do tempo limite especificado, o pacote é reenviado, mas a uma taxa menor. E isso pode continuar indefinidamente, com a velocidade caindo exponencialmente, até chegar o sinal de entrega bem-sucedida. Fica claro que até pequenos problemas na linha podem afetar seriamente a taxa de dados, já que cada envio malsucedido é uma perda de preciosos milissegundos. Por isso, o FAST introduziu uma solução alternativa: o sistema monitora constantemente os pacotes e as mensagens recebidas quanto à entrega correta, para detectar imediatamente problemas na linha e definir o próximo envio a uma taxa estável, ainda que ligeiramente reduzida. Essa abordagem elimina, na maioria dos casos, a necessidade de reenviar pacotes, pois não se perde tempo sondando a queda de desempenho. Em algumas bolsas, a interface de conexão é implementada por dois tipos de conexão: UDP e TCP. Enviar todos os dados pelo socket UDP não faz sentido, pois esse tipo de conexão não exige confirmação de entrega, e os pacotes simplesmente desapareceriam sem que nenhuma das partes soubesse. Por isso, a maior parte dos dados é transmitida pelo socket UDP, e apenas os conjuntos de dados não entregues são transmitidos por TCP. Em mercados de movimentação rápida, o atraso associado à retransmissão costuma ser indesejável, levando a oportunidades perdidas ou a maus negócios.

Como o FAST funciona

Como já sabemos, o protocolo FIX é uma sequência de campos que, por sua vez, consistem em pares chave=valor. Além de o formato de texto ser essencialmente redundante, é possível notar que cada mensagem tem elementos duplicados, como nomes de campos e caracteres “=”. O FAST elimina a redundância usando um template que descreve toda a estrutura da mensagem. Esse método é chamado de marcação implícita (implicit tagging). Como as tags FIX nos dados transmitidos ficam apenas “implícitas”, a sintaxe Tag = Value muda da seguinte forma:

Um template descreve um conjunto estruturado de campos com seus operadores;
A sequência de campos na mensagem corresponde à sequência de tags no template;
Somente as alterações nos dados são enviadas na mensagem.

Cada valor de tag tem um comprimento fixo em bytes. Conhecendo o comprimento de um campo específico e a ordem em que os campos são colocados na mensagem, não é difícil identificar os valores desses campos. Por isso, os templates permitem transmitir diretamente apenas os próprios dados, sem precisar transferir caracteres redundantes. Essa codificação é chamada de simple binary encoding, ou SBE. Assim, a codificação e a decodificação das mensagens têm latência muito menor do que nos protocolos de caracteres, pois não é necessário converter os dados para um formato que os computadores possam usar. Como os campos correspondentes ficam em posição fixa na mensagem, é muito mais fácil acessar o valor desejado. Basta conhecer seu deslocamento em relação ao início da mensagem e o comprimento do seu valor. Ao contrário do formato de tags e do FIXML, uma mensagem SBE não é autodescritiva. Apenas os dados, com um cabeçalho mínimo que identifica o template que rege a mensagem, são enviados pela rede. Os metadados (templates) que descrevem a estrutura da mensagem são trocados fora do canal principal de comunicação. Depois de receber os templates necessários, o servidor de negociação sabe em que formato enviar os dados ao cliente no âmbito dessa sessão conectada. Assim, antes de transferir os dados, os sistemas combinam entre si como vão se comunicar dali em diante. O esquema de mensagens normalmente é enviado em formato XML. Ele pode conter qualquer número de templates de mensagem. O template descreve os campos que compõem a mensagem. Além disso, o esquema fornece uma lista de tipos de dados simples e complexos que podem ser reutilizados em qualquer número de campos.

Implementações abertas do protocolo FIX para diferentes linguagens

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

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

Parser on-line gratuito de mensagens FIX – FIX Parser – https://fix.aprics.net/

Implementações abertas do FAST para diferentes linguagens

Para C – implementação de referência da FPL – www.fixprotocol.org/fastdownload

Para C# – implementação de referência da 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

Outras codificações do protocolo FIX

A comunidade FIX também desenvolveu mapeamentos padrão entre o protocolo FIX e outros protocolos de serialização de dados, como:

JSON
Google (Protocol buffers)

|ASN.1

Áreas de aplicação do protocolo FIX/FAST

Em geral, a sigla aparece justamente com as duas palavras juntas. É usado para obter diversas informações financeiras das bolsas: tabelas de instrumentos financeiros (preços, volumes etc.), cotações, todas as operações, índices, bem como informações sobre todas as ordens anônimas. O conjunto de dados obtidos pode variar conforme a bolsa. Os principais usuários do FIX/FAST são:

Traders privados, para negociação [FIX API Forex Trading]
Programadores que criam produtos baseados nessa tecnologia, como plataformas de trading via FIX API, conectores para diferentes bolsas, sistemas de negociação, sistemas de coleta de dados e estatísticas.
Troca de informações entre bolsas
Obtenção dos dados mais atualizados por diversas agências de informação

O uso mais comum é por traders de alta frequência, para obter vantagem sobre outros participantes do mercado por meio do Direct Market Access (DMA). Esse protocolo pode ser incorporado ao ecossistema de negociação por bolsas de valores, bancos e corretoras forex. As exchanges de criptomoedas, segundo dados amplamente conhecidos, não usam essa tecnologia. Historicamente, essas exchanges usam principalmente conexões WebSocket para obter informações de mercado e conexões HTTP REST API para realizar operações de negociação, oferecendo conexões diretas aos servidores de negociação dos traders. Se a tecnologia WebSocket ainda é comparável em velocidade a uma conexão TCP, a HTTP REST API perde muito. Conheça a SharpTrader Easy FIX API