Troca de informações financeiras - Financial Information eXchange

"FIXT" redireciona aqui. Para empresa de mídia e gravadora, consulte FiXT .

O protocolo Financial Information eXchange ( FIX ) é um protocolo de comunicações eletrônicas iniciado em 1992 para a troca internacional em tempo real de informações relacionadas a transações e mercados de valores mobiliários . Com trilhões de dólares negociados anualmente apenas na NASDAQ , as entidades de serviços financeiros estão empregando o acesso direto ao mercado (DMA) para aumentar sua velocidade nos mercados financeiros. Gerenciar a entrega de aplicativos de negociação e manter a latência baixa exige cada vez mais uma compreensão do protocolo FIX.

História

A especificação do protocolo FIX foi originalmente criada em 1992 por Robert "Bob" Lamoureux e Chris Morstatt para permitir a comunicação eletrônica de dados de negociação de ações entre a Fidelity Investments e a Salomon Brothers . A FIX inicialmente tratava de informações entre corretoras e seus clientes institucionais. Na época, essas informações eram comunicadas verbalmente por telefone. A Fidelity percebeu que as informações de suas corretoras poderiam ser encaminhadas para o comerciante errado ou simplesmente perdidas quando as partes desligassem seus telefones. Ele queria que essas comunicações fossem substituídas por dados legíveis por máquina que pudessem então ser compartilhados entre os comerciantes, analisados, atuados e armazenados. Por exemplo, corretoras ligam com uma indicação de interesse ( IOI ) para comprar ou vender um lote de ações. A iniciativa FIX criou novas mensagens, como a IOI .

De acordo com a comunidade de comércio FIX, o FIX se tornou o padrão de mensagens de fato para comunicação pré-negociação e comercial nos mercados de ações globais e está se expandindo no espaço de pós-negociação para oferecer suporte ao processamento direto , bem como continuar a expandir nos mercados de câmbio , renda fixa e derivativos .

Comunidade de comércio FIX

A FIX Trading Community é um organismo de padrões sem fins lucrativos e orientado para a indústria com a missão de abordar os negócios e questões regulatórias que impactam o comércio de múltiplos ativos nos mercados financeiros globais por meio do aumento do uso de padrões, incluindo a linguagem de mensagens do protocolo FIX. eficiência operacional, maior transparência e redução de custos e riscos para todos os participantes do mercado.

Comercial

O FIX é amplamente utilizado tanto pelo lado da compra (instituições) quanto pelo lado da venda (corretores / distribuidores) dos mercados financeiros . Entre seus usuários estão fundos mútuos , bancos de investimento , corretoras, bolsas de valores e ECNs . Consulte a Organização da Comunidade de Comércio FIX para obter uma lista extensa dos principais usuários do FIX.

O FIX tornou-se o protocolo eletrônico padrão para comunicações pré-negociação e execução de negociações. Embora seja usado principalmente para transações de ações na área de front office , obrigações, derivativos e transações de câmbio também são possíveis. Pode-se dizer que, enquanto SWIFT é o padrão para mensagens de back office , FIX é o padrão para mensagens de front office. No entanto, hoje, a associação da FIX Protocol Ltd. está estendendo a FIX para a alocação de negociação em bloco e outras fases do processo de negociação, em todos os mercados, para virtualmente todas as classes de ativos.

Especificações técnicas

Originalmente, o padrão FIX era monolítico, incluindo semântica de camada de aplicativo, codificação de mensagem e camada de sessão em uma única especificação técnica. Ele permaneceu monolítico até o FIX versão 4.2. Depois disso, as codificações de mensagens e as especificações da camada de sessão começaram a ser divididas em documentos separados e, por fim, o FIX evoluiu para uma família de padrões técnicos relacionados.

Codificações de mensagens

A codificação da mensagem, chamada de Presentation Layer no modelo Open Systems Interconnection (modelo OSI), é responsável pelo formato de fio das mensagens.

Codificação Tagvalue (clássico FIX)

A codificação da mensagem FIX original é conhecida como codificação tagvalue. Cada campo consiste em uma tag numérica exclusiva e um valor. A tag identifica o campo semanticamente. Portanto, as mensagens são autodescritivas. A codificação de tagvalue é baseada em caracteres, usando códigos ASCII .

Formato de mensagem FIX tagvalue

Os campos da mensagem são delimitados usando o caractere ASCII 01 <início do cabeçalho>. Eles são compostos por um cabeçalho, um corpo e um trailer.

Até FIX.4.4, o cabeçalho continha três campos: tags 8 ( BeginString), 9 ( BodyLength) e 35 ( MsgType).

De FIXT.1.1 / FIX.5.0, o cabeçalho contém cinco 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 )

O conteúdo no corpo da mensagem é especificado por (tag 35, MsgType) tipo de mensagem definido no cabeçalho.

O último campo da mensagem é o tag 10, FIX Message Checksum. É sempre expresso como um número de três dígitos (por exemplo 10=002).

Cabeçalho + Corpo + Trailer: FIX Conteúdo

Exemplo de uma mensagem FIX: Relatório de Execução (o caractere Pipe é usado para representar o caractere 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 |

No FIXMessage Body, o comprimento 9 está correto e a soma de verificação 10 foi verificada usando a fonte disponível no QuickFIX , uma implementação FIX de código-fonte aberto.

Corpo

As mensagens FIX são formadas por vários campos; cada campo é um par de valores de tag separado do próximo campo por um delimitador SOH (0x01). A tag é um número inteiro que indica o significado do campo. O valor é uma matriz de bytes que contém um significado específico para a tag em particular (por exemplo, a tag 48 é SecurityID, uma string que identifica a segurança; a tag 22 é IDSource, um inteiro que indica a classe identificadora que está sendo usada). Os valores podem estar em texto simples ou codificados como binário puro (nesse caso, o valor é precedido por um campo de comprimento). O protocolo FIX define significados para a maioria das marcas, mas deixa uma variedade de marcas reservadas para uso privado entre as partes consentindo.

O protocolo FIX também define conjuntos de campos que formam uma mensagem específica; dentro do conjunto de campos, alguns serão obrigatórios e outros opcionais. A ordem dos campos na mensagem geralmente não é importante; no entanto, os grupos de repetição são precedidos por uma contagem e os campos criptografados são precedidos por seu comprimento. A mensagem é dividida em três seções distintas: a cabeça, o corpo e a cauda. Os campos devem permanecer dentro da seção correta e dentro de cada seção a posição pode ser importante, pois os campos podem atuar como delimitadores que impedem uma mensagem de passar para a próxima. O campo final em qualquer mensagem FIX é tag 10 ( checksum ).

Existem dois grupos principais de mensagens - admin e aplicativo. As mensagens do administrador tratam do básico de uma sessão FIX. Eles permitem que uma sessão seja iniciada e encerrada e para a recuperação de mensagens perdidas. As mensagens do aplicativo tratam do envio e recebimento de informações relacionadas ao comércio, como uma solicitação de pedido ou informações sobre o estado atual e a execução subsequente desse pedido.

Cabeçalho
Comprimento do corpo

O comprimento do corpo é a contagem de caracteres começando na tag 35 (incluída) até a tag 10 (excluída). Os delimitadores SOH contam no comprimento do corpo.
Por exemplo: (SOH foi substituído por '|')

8=FIX.4.2|9=65|35=A|49=SERVER|56=CLIENT|34=177|52=20090107-18:15:16|98=0|108=30|10=062|
     0   + 0  + 5  +   10    +   10    +  7   +        21          + 5  +  7   +   0    = 65

Tem um comprimento de corpo de 65.
O delimitador SOH no final de um Tag = Value pertence ao Tag.

Trailer: soma de verificação

A soma de verificação de uma mensagem FIX é sempre o último campo da mensagem. É composto por três caracteres e possui tag 10. É dado somando o valor ASCII de todos os caracteres da mensagem, exceto aqueles do próprio campo de checksum, e executando o módulo 256 sobre o somatório resultante. Por exemplo, na mensagem acima, a soma de todos os valores ASCII (incluindo o caractere SOH, que tem um valor de 1 na tabela ASCII) resulta em 4158. A execução da operação de módulo fornece o valor 62. Como a soma de verificação é composta por três caracteres, 062 é usado.

FIXML

FIXML é um esquema XML para mensagens FIX. É semanticamente equivalente às mensagens codificadas com tagvalue, mas aproveita a tecnologia do analisador XML. FIXML é comumente usado para aplicativos de back-office e compensação, em vez de comércio.

Codificação Binária Simples (SBE)

A codificação binária simples define um formato de fio usando tipos de dados primitivos que são nativos para sistemas de computação. A codificação e decodificação de mensagens têm, portanto, latência muito menor do que os protocolos baseados em caracteres, uma vez que nenhuma tradução é necessária para colocar os dados em um formato que os computadores possam usar. Além das vantagens de latência, o desempenho é mais determinístico porque as mensagens SBE são restringidas por modelos e os elementos de dados de comprimento fixo são preferidos. Outra consequência é que os campos geralmente estão em uma posição fixa, de modo que os filtros de mensagem e roteadores não precisam quebrar uma mensagem inteira para acessar os campos-chave.

SBE foi desenvolvido pelo Grupo de Trabalho de Alto Desempenho FIX para apoiar negociações de alto desempenho. A codificação tagvalue não foi mais considerada adequada para o propósito, uma vez que é baseada em caracteres em vez de binária e seus campos e mensagens de comprimento variável resultam em desempenho não determinístico.

Ao contrário de tagvalue e FIXML, uma mensagem SBE não é autodescritiva. Apenas os dados são enviados na conexão com um cabeçalho mínimo para identificar o modelo que controla uma mensagem. Metadados que descrevem um layout de mensagem são trocados fora de banda entre pares.

A FIX Trading Community publica um esquema XML para esquemas de mensagens SBE. Um esquema de mensagem pode conter qualquer número de modelos de mensagem. Um modelo descreve os campos que constituem uma mensagem. Além disso, um esquema fornece uma lista de tipos de dados simples e compostos que podem ser reutilizados por qualquer número de campos.

De uma perspectiva prática, assumindo uma implementação C / C ++ e ajustando para endianness: a maioria dos tipos não compostos na mensagem mapeia diretamente para o mesmo tipo na linguagem. Por exemplo, mapas inteiros de 32 bits para uint32_t, mapas de strings fixas const char *, mapas de ponto flutuante para floate assim por diante. Pode-se gerar um C / C ++ a structpartir da definição do esquema. Em seguida, dado um ponteiro para um buffer de mensagem, acessando campos não compostos da quantidade da mensagem para convertê-la em um ponteiro para a estrutura e acessando os membros da estrutura diretamente. 

/* Generated struct from schema */
struct Message {
  ...
  uint32_t qty;
  ...
  const char *symbol;
  ...
};

void consume_message(void *incoming_message) {
  const struct Message *msg = (const struct Message*) incoming_message;
  printf("Traded %u of %s\n", msg->qty, msg->symbol);
  ...
}

Outras codificações FIX

A FIX Trading Community também desenvolveu mapeamentos padrão entre FIX e outros protocolos de mensagem, incluindo:

Protocolos de sessão

A camada de sessão é responsável pela troca de mensagens, incluindo mecanismos de recuperação de ponto de verificação.

Transporte FIX (FIXT)

O protocolo de sessão FIX original não tinha seu próprio nome, pois fazia parte de uma especificação monolítica que abrangia a semântica da camada de aplicativo e também a codificação de mensagens. No entanto, a partir do FIX versão 5.0, a camada de sessão foi dividida como uma especificação independente com a introdução do FIXT. FIXT era basicamente o mesmo que a camada de sessão original sem nome na versão 4.x, mas oferecia uma inovação significativa - fornecia um mecanismo para misturar versões de camada de aplicativo FIX em uma versão de sessão comum. A versão atual do FIXT é 1.1.

Teoricamente, FIXT é independente de transporte. No entanto, geralmente é empregado sobre o protocolo de controle de transmissão (TCP).

FIXT é um protocolo ponto a ponto. Ele garante a entrega da mensagem em ambas as direções. As mensagens enviadas em cada direção carregam um número de sequência da mensagem no cabeçalho da mensagem. Se houver uma falha de comunicação, um par pode solicitar a retransmissão das mensagens perdidas. A entrega de mensagens é suportada mesmo em caso de desconexão e posterior restabelecimento de uma sessão.

Para implementar o estabelecimento de sessão e entrega garantida, FIXT e FIX clássico 4.x definem estes tipos de mensagem de sessão:

  • Batimento cardiaco
  • Pedido de Teste
  • ResendRequest
  • Rejeitar
  • SequenceReset
  • Sair
  • Entrar
  • XMLnonFIX

Camada de sessão de desempenho FIX (FIXP)

O FIXP foi desenvolvido pelo Grupo de Trabalho de Alto Desempenho FIX para atender às necessidades de negociação de alto desempenho. A necessidade primária é para codificação e decodificação de mensagens de baixa latência e controle sobre as garantias de entrega de mensagens.

Para fornecer baixa latência, as codificações de mensagens binárias são suportadas tanto para a camada de sessão quanto para as mensagens do aplicativo. O formato do fio real é abstraído na especificação FIXP, então os usuários podem selecionar uma codificação FIX de sua escolha, desde que os pares concordem com um protocolo a ser usado. O desenvolvimento inicial usou a codificação binária simples.

FIXP cobre casos de uso ponto a ponto e multicast com primitivos comuns.

Quando uma sessão ponto a ponto é estabelecida, os pares negociam garantias de entrega entre as seguintes opções:

  • Recuperável: entrega de mensagem exatamente uma vez. Se forem detectadas lacunas, as mensagens perdidas podem ser recuperadas por retransmissão.
  • Idempotente: entrega no máximo uma vez. Se forem detectadas lacunas, o remetente será notificado, mas a recuperação estará sob o controle do aplicativo, se for feita.
  • Sem sequência: não oferece garantias de entrega. Essa escolha é apropriada se as garantias forem desnecessárias ou se a recuperação for fornecida na camada do aplicativo ou por meio de um canal de comunicação diferente.
  • Nenhum: nenhuma mensagem de aplicativo deve ser enviada em uma direção de uma sessão.

As garantias de entrega podem ser assimétricas. Por exemplo, um trader pode inserir ordens em um fluxo idempotente enquanto as execuções são retornadas em um fluxo recuperável. Em mercados de movimentação rápida, o atraso inerente à retransmissão é freqüentemente indesejável, resultando em oportunidades perdidas ou negociações ruins.

Representação diagramática do sistema FIX

Abaixo está um diagrama de como as mensagens FIX se parecem entre Buyside / Customer e Sellside / Supplier.

Diagrama de conectividade do sistema de troca de informações financeiras.svg

Últimos desenvolvimentos no protocolo FIX

A versão mais recente do protocolo FIX implementa "Independência de transporte", permitindo que várias versões de mensagens de aplicativo sejam transportadas em uma única versão da Sessão FIX independente de transporte (FIXT.1.1 e superior).

A independência de transporte também abre caminho para que protocolos de transporte, como filas de mensagens e serviços da Web, sejam usados ​​em vez do tradicional FIX sobre TCP.

O FIX agora oferece suporte à negociação algorítmica pelo uso da Linguagem de Definição de Negociação Algorítmica FIX FIXatdl .

A FIX Protocol Limited lançou o protocolo FAST, que significa FIX Adapted for Streaming. FAST é um protocolo binário usado principalmente para enviar dados de mercado multicast por meio de conexões UDP.

Ferramentas de teste

Muitas empresas oferecem produtos e serviços de teste FIX:

  • Sensiple PhiFIX
  • Lefinsys Testamatiq
  • B2Bits FATOS
  • CameronTec VeriFIX
  • Esprow ETP Studio para FIX
  • Ferramentas de teste Exactpro
  • Ignição FIX Flyer
  • GDS Fizzer - FIX Fuzzing Framework
  • Wipro FIX Examen
  • FixSpec Central

Veja também

Notas

links externos