TradeMate: panorama técnico
Uma leitura objetiva de onde o TradeMate está tecnicamente atrás do padrão mais moderno da própria B3 (o PUMA UMDF) — e dos fatores de contexto que ajudam a explicar essas escolhas. Sem juízo de valor: só o que a documentação mostra.
01 Contexto
02 Onde está tecnicamente atrás
Pontos, de forma objetiva, em que o TradeMate adota um modelo mais antigo do que o padrão atual da B3.
FIX 4.4 em texto
Usa FIX 4.4 tagvalue ASCII. O padrão atual (UMDF) é FIX 5.0 SP2 com compressão FAST — mais enxuto e eficiente na banda.
Assinatura via TCP
Market data por request/subscribe ponto-a-ponto. O padrão moderno é difusão por multicast, que escala melhor para muitos consumidores.
Apenas ResendRequest
Recuperação de lacunas só pela sessão (35=2). O UMDF oferece TCP Replayer/Historical dedicado (BW/BX/URDR/BY).
Sem canais tipados (ApplID)
Não adota o modelo de canais MBO/MBP/TOB identificados por ApplID, hoje padrão no feed da B3.
Enums e tags próprios
Taxonomia (SecuritySubType 1–10), TradeCondition e InstrAttribType divergem do dicionário consolidado do UMDF.
Throttle de 50 msg/s
Limite por sessão adequado ao volume de RF, porém modesto frente à infraestrutura de alta frequência do PUMA.
03 Padrão atual × TradeMate
| Aspecto | Padrão atual (PUMA UMDF) | TradeMate |
|---|---|---|
| Versão FIX | 5.0 SP2 (ApplVerID) | 4.4 |
| Codificação | FAST (binário comprimido) | Tagvalue ASCII (texto) |
| Transporte | Multicast UDP | TCP ponto-a-ponto (TLS) |
| Modelo | Push (broadcast) | Pull (assinatura) |
| Livro | MBO · MBP · TOB (canais) | Order Depth (estilo MBP) |
| Recuperação | Snapshot loop + TCP Replayer | ResendRequest (35=2) |
| Identificação de canal | ApplID | — |
04 Fatores de contexto
Nem toda diferença é defasagem sem motivo. Alguns fatores explicam, com justiça, as escolhas do TradeMate.
- Domínio de renda fixa: Yield, Spread, Spread over B, casadas DI/DAP e fluxo de voz/balcão são necessidades reais de RF que o UMDF de ações/derivativos não cobria.
- Perfil de volume: a renda fixa negocia menos mensagens que ações — TCP/assinatura é suficiente e mais simples de operar do que multicast.
- FIX 4.4 é amplamente suportado: a maioria das bibliotecas e OMS já fala 4.4, reduzindo a barreira de integração para o público de RF.
- Plataforma relativamente nova: nativa em nuvem, priorizou entregar a jornada de RF ponta a ponta (OE + MD + DC) em vez de replicar a stack de market data de altíssima performance.
- Interoperabilidade humana: texto ASCII é mais fácil de depurar e auditar em um mercado com forte componente de negociação assistida.
05 A régua: evolução do FIX e onde cada um parou
Contexto de indústria: o protocolo FIX evoluiu em camadas — sessão, codificação e performance. Colocando B3 e TradeMate na mesma régua, a posição de cada um fica visível.
FIX 4.4 · tagvalue ASCII
Sessão e aplicação acopladas, texto puro. Virou o "inglês" dos OMS — quase tudo fala 4.4 até hoje.
← TradeMate está aqui (OE, MD e DC)FIX 5.0 / SP2 + FAST
Separa transporte da aplicação (FIXT), adiciona compressão FAST para market data de alto volume.
← PUMA UMDF está aqui (feed oficial)SBE + FIXP · binário de baixa latência
Simple Binary Encoding com layout fixo (decodificação em nanossegundos) e sessão FIXP enxuta. É o modelo do CME iLink 3 — e do Binary EntryPoint da própria B3 para entrada de ordens no PUMA.
← Estado da arte, já em produção na B306 O custo real: manter dois stacks B3
Para um integrador que já opera PUMA/UMDF, aderir ao TradeMate significa duplicar camadas inteiras. É aqui que a defasagem vira custo concreto.
| Camada | Já existia (PUMA/UMDF) | Precisa construir p/ TradeMate |
|---|---|---|
| Decoder | FAST / SBE certificado | Parser FIX 4.4 tagvalue com dialeto próprio |
| Dicionário | Enums UMDF (SubType, TradeCondition, InstrAttrib) | Segundo mapa de enums só para RF |
| Recuperação | Snapshot loop + TCP Replayer | Lógica de ResendRequest/GapFill por sessão |
| Conectividade | Multicast (co-location/RCB) | Túnel TLS (Stunnel/SocketUseSSL) + assinatura |
| Certificação | Roteiro UMDF já cumprido | Novo roteiro de certificação TradeMate |
| Monitoração | Gap por canal/RptSeq | Gap por MsgSeqNum de sessão + throttle de 50 msg/s |
Seis camadas duplicadas — nenhuma por limitação do integrador; todas por decisão de design da plataforma.
07 Exercício: como o TradeMate alcançaria a régua
Não é um plano da B3 — é um exercício de arquitetura sobre o que reaproveitar, em ordem de esforço.
Alinhar o dicionário
Adotar os enums do UMDF (SubType 1302+, TradeCondition RF, InstrAttrib 24/34/35) e aposentar a tag 290. Sem mudar transporte — só vocabulário. Maior ganho pelo menor esforço.
Recuperação decente
Expor um Replayer TCP (BW/BX/URDR/BY) reutilizando o padrão já documentado do UMDF. Elimina o risco de gap na reconexão.
Canais tipados
Introduzir ApplID e separar instrument list / snapshot / incremental em canais lógicos — mesmo mantendo TCP como transporte.
Codificação moderna
Longo prazo: oferecer SBE/FIXP como alternativa ao tagvalue — alinhando com o Binary EntryPoint que a B3 já opera no PUMA.
08 Contexto internacional: RF eletrônica é RFQ mesmo
Justiça de novo: no mundo, renda fixa eletrônica não se parece com equities. As grandes plataformas globais também giram em torno de RFQ e sessões dedicadas.
RFQ como centro do fluxo
Tradeweb, MarketAxess e Bloomberg operam RF eletrônica centrada em request-for-quote, não em livro contínuo de alta frequência. O TradeMate seguir RFQ/Voice não é atraso — é o padrão do segmento.
Infraestrutura, não fluxo
O que essas plataformas não fazem é reinventar dicionário dentro da própria casa. A crítica justa ao TradeMate não é "por que RFQ?" — é "por que enums e recuperação diferentes do padrão da própria B3?".
09 Leitura final
Fontes: documentação FIX do TradeMate (B3) e página FIX/FAST UMDF do PUMA (B3). Para o detalhamento tag a tag, veja a comparação completa.
▲ Voltar ao topo