Crítico01
Gap de mensagens na recuperação
Só ResendRequest (35=2). Sem TCP Replayer (BW/BX/URDR/BY). Em queda/reconexão, dá pra perder mensagem.
Página de crítica
TradeMate · FIX 4.4
vs B3 UMDF · FIX 5.0 SP2
Não é um guia neutro. É o dossiê.
O TradeMate errou onde a B3 já tinha padrão
O PUMA UMDF é o feed oficial da B3 — maduro, público, reutilizado por vendors há anos. O TradeMate chegou na renda fixa e, no market data, reinventou enums, entrega e recuperação em vez de reaproveitar o que a própria bolsa já documenta. Resultado: dois stacks B3 incompatíveis para quem já integra a bolsa.
Acusação
TradeMate vs padrão B3 (UMDF) — sem diplomacia
Onde o TradeMate viaja
Oito decisões em que havia padrão B3 e o TradeMate preferiu inventar o próprio.
- 01 Taxonomia reinventada TM SubType 1–10 · B3 1302/1303/1304…
- 02 TradeCondition paralelo TM RFQ / VO · B3 RF
- 03 Tag 290 ainda viva TM usa 290 · B3 deprecou
- 04 MD por assinatura TCP TM 35=x/V · B3 multicast ApplID
- 05 Recuperação clássica TM só ResendRequest · B3 TCP Replayer
- 06 InstrAttribType próprio TM 50–59 · B3 24/34/35
- 07 Sem modelo ApplID TM sem canais tipados · B3 MBO/MBP/TOB
- 08 Tags custom em cima do PUMA TM 35002 / 40001… · B3 família já documentada
Leaks
O que o TradeMate deixa vazando
Exposições e fragilidades — do que aparece no papel ao que se perde numa queda.
Crítico02
Ponto único de falha
DR existe só na RCB (179.127.218.237). RTM e certificação sem IP de contingência.
Médio03
Infra exposta no papel
IPs fixos de PROD, DR e cert nos guias: 179.127.215.237, DR .218.237, cert 200.19.60.182, RTM 10.0.48.x.
Médio04
Doc "Informação Interna" circulando
Material técnico marcado como interno pela B3 serve de base de integração — detalhe sensível fora do círculo restrito.
Médio05
Stack duplicado = parser vaza
Enums/tags próprios (SubType 1–10, RFQ/VO, 290, InstrAttrib 50–59, 35002/40001…). Cada divergência é interpretação errada em potencial.
Baixo06
Throttle represa fluxo
Limite de 50 msg/s por sessão. Em rajada, suas mensagens ficam na fila.
01 Veredito
Veredito: o TradeMate não é “só diferente” — no MD ele custa integração dupla.
Yield, Voice e casadas são domínio de RF (ok). O resto — taxonomia, TradeCondition, tag 290, ApplID,
Replayer, InstrAttrib, tags custom — é reinvenção cara em cima de um padrão B3 que já existia.
Quem já parseia UMDF leva um segundo mapa de enums e um segundo fluxo de recovery só por causa do TradeMate.
TradeMate FIX
Conectividade da plataforma de renda fixa
- FIX 4.4, sessões TCP sobre TLS 1.2
- Order Entry + Market Data + Drop Copy
- Market data por assinatura (request/subscribe)
- Escopo: renda fixa (públicos, CBIO, privados)
- Docs "Informação Interna", em evolução
PUMA UMDF
Feed unificado de market data
- FIX 5.0 SP2 + compressão FAST
- Somente market data (multicast UDP)
- Difusão por broadcast (sem assinatura)
- Escopo: ações, derivativos, FX, RF corporativa
- Docs "Informação Pública", maduras (desde 2009)
A página do PUMA neste link cobre apenas o UMDF (market data). A entrada de ordens no PUMA é o EntryPoint (fora deste link).
02 O que o TradeMate bagunçou
Se você já integra UMDF/PUMA, isto é o que o TradeMate te obriga a reaprender. Coluna azul = TradeMate (o problema) · coluna verde = B3 UMDF (o padrão).
| Aspecto | TradeMate | B3 · UMDF / PUMA |
|---|---|---|
| Protocolo | FIX 4.4 · texto ASCII | FIX 5.0 SP2 + FAST (binário) |
| Transporte | TCP + TLS 1.2 | Multicast UDP (co-location / RCB) |
| Modelo | Pull — assina com 35=x / 35=V | Push — broadcast contínuo |
| Autenticação | Logon CAU (user/senha) | Controle na rede (sem logon no feed) |
| Escopo do produto | Order Entry + Market Data + Drop Copy | Só market data (OE fica no EntryPoint) |
| Mercados | Renda fixa (públicos, CBIO, privados) | Ações, derivativos, FX, RF corporativa |
| Livro | Order Depth (estilo MBP) | MBO · MBP · TOB |
| Precificação RF | Yield, Spread, Spread over B | Per-unit / % / frações de tick |
| Recuperação | ResendRequest (35=2) na sessão | Snapshot loop + TCP Replayer |
| Fluxos extras | Voice / cross · casadas DI/DAP | News · BTB · índices · settlement |
| Throttle | 50 msg/s por sessão | N/A (feed unidirecional) |
03 Dossiê — cada erro com prova
01 Taxonomia
02 TradeCondition
03 Tag 290
04 MD TCP
05 Recuperação
06 InstrAttrib
07 ApplID
08 Tags custom
Taxonomia de instrumentos reinventada
TradeMate fez
762 SecuritySubType = 1–10 (CBIO, CFF, CRA, CRI, DEB, LFT, LTN, NTNB, NTNC, NTNF).
167 = GOVBOND / CORP / CBIO.
Padrão B3 já tinha
No UMDF, RF corporativa já usa 1302 Debênture, 1303 CRI, 1304 CRA, 1306 LF, etc.
Domínios de produto e subtype já existem no dicionário público.
Quem já parseia UMDF precisa de um segundo mapa de enums só para TradeMate.
TradeCondition com vocabulário paralelo
TradeMate fez
Origem de negócio como
RFQ e VO (Voice) em 277 TradeCondition.
Padrão B3 já tinha
UMDF já define
RF (RFQ / Fixed Income Trade), além de MP, TC, TA, RL, etc.
Mesmo conceito, labels diferentes — quebra reaproveitamento de parsers de condição de trade.
MDEntryPositionNo ainda em uso
TradeMate fez
Continua exigindo / usando
290 MDEntryPositionNo no book.
Padrão B3 já tinha
UMDF v2.2.0 deprecou a tag 290 em todos os canais (gestão por preço/prioridade).
TradeMate ficou no modelo antigo enquanto a B3 já migrou o feed oficial.
Market Data por assinatura TCP em vez do modelo UMDF
TradeMate fez
Cliente manda
35=x / 35=V, recebe snapshot + incremental na sessão TCP.
Padrão B3 já tinha
Instrument Definition + Snapshot Recovery + Incremental em multicast (canais ApplID MBO/MBP/TOB).
Volume de RF pode justificar TCP — mas o stack do vendor muda: não reaproveita o decoder FAST/UMDF já certificado.
Recuperação clássica em vez do TCP Replayer
TradeMate fez
Só
ResendRequest (35=2) / GapFill na própria sessão.
Padrão B3 já tinha
TCP Replayer / Historical com
35=BW / BX / URDR / BY — padrão documentado e usado em produção.
ISVs que já implementaram Replayer não reutilizam o mesmo fluxo de gap recovery no MD do TradeMate.
InstrAttribType com domínio próprio
TradeMate fez
Atributos 8, 15, 50–59 (rating, deadline, sector, Spread over B enabled, etc.).
Padrão B3 já tinha
UMDF usa 24 (trade eligibility), 34 (GTD/GTC), 35 (test instrument) — outro dicionário.
Mesma tag FIX (871), significados incompatíveis entre plataformas B3.
Header e canal sem o modelo ApplID do UMDF
TradeMate fez
Header FIX 4.4 completo (BeginString, CompIDs, CheckSum). Sem canais tipados MBO/MBP/TOB.
Padrão B3 já tinha
Header enxuto do UMDF +
1180 ApplID (ex.: MBP101) para identificar feed/canal.
Para OE, FIX 4.4/TCP é o mesmo mundo do EntryPoint — ok. Para MD, o TradeMate não herda o modelo de canais que vendors já operam.
Tags customizadas em cima do que já era EntryPoint/UMDF
TradeMate fez
Extensões como
35002/35003 CoD, 35487 RoutingInstruction,
40001 OriginalTrader, 6032 UniqueTradeID, 9746/9747 MaxOrderQty RFQ/Voice.
Padrão B3 já tinha
Família 37xxx / comportamentos documentados no PUMA (e EntryPoint) para vários desses problemas de sessão e livro.
Parte é domínio de RF (justificável). Parte é “mais um jeito B3 de fazer a mesma coisa”.
O que não é “viajar”: Yield/Spread, Voice/cross, casadas DI/DAP e Cancel-on-Disconnect
são necessidades reais de renda fixa / balcão — o padrão UMDF de ações/derivativos não cobria isso.
A crítica acima é só onde havia padrão B3 reutilizável e o TradeMate escolheu outro caminho.
04 Propósito & escopo
| Dimensão | TradeMate FIX | PUMA UMDF FIX/FAST |
|---|---|---|
| Plataforma | Nova plataforma de renda fixa (cloud-native) | PUMA Trading System (todos os segmentos) |
| Função | Conectividade de negociação completa | Difusão de market data (feed) |
| Sessões / feeds | Order Entry, Market Data, Drop Copy | Instrument Definition, Snapshot, Incremental (+ News) |
| Mercados | Renda fixa: títulos públicos, CBIO, CRA/CRI/CFF, debêntures | Ações, derivativos, FX, RF corporativa |
| Entrada de ordens | Sim (NewOrderSingle, Cross/Voice, etc.) | Não (fica no EntryPoint, fora desta doc) |
| Classificação da doc | Informação Interna | Informação Pública |
| Maturidade | Nova (2023+), "versão preliminar sujeita a alteração" | Madura (v1.0 em 2009 → v2.2.2 em 2026) |
05 Matriz comparativa
| Aspecto | TradeMate FIX | PUMA UMDF |
|---|---|---|
| Versão FIX | FIX 4.4 | FIX 5.0 SP2 (ApplVerID=9); TCP Replayer em FIX 4.4 |
| Codificação | FIX tagvalue ASCII (texto) | FAST (comprimido, binário) sobre FIX 5.0 |
| Transporte | TCP ponto-a-ponto | Multicast UDP (vários canais) |
| Segurança | TLS 1.2 (Stunnel / SocketUseSSL) | Rede privada (co-location / RCB); sem TLS no feed |
| Modelo de dados | Pull — cliente assina (SubscriptionRequestType) | Push — broadcast contínuo |
| Autenticação | Logon com usuário/senha CAU | Nenhuma no feed (controle na rede) |
| Livro de ofertas | Order Depth (MDBookType=3), estilo MBP | MBO, MBP e TOB (canais dedicados) |
| Header | BeginString, BodyLength, Sender/TargetCompID, CheckSum | MsgType, MsgSeqNum, SendingTime, ApplVerID |
| Sequência | Por sessão; reset diário para 1 | Por canal (MsgSeqNum) + RptSeq por instrumento |
| Throttle | 50 msg/s por sessão | N/A (feed unidirecional) |
| Recuperação | ResendRequest (35=2) na própria sessão | Snapshot loop + TCP Replayer/Historical |
06 Transporte & arquitetura
TradeMate — TCP / assinatura
Cada tipo de sessão é uma conexão TCP dedicada, autenticada e criptografada (TLS 1.2). O cliente assina instrumentos e recebe respostas correlacionadas por ID.
xSecurityListRequest
→
VMarketDataRequest
→
WSnapshot + X Incrementais
UMDF — multicast / broadcast
Sinal composto por vários canais multicast, cada um com um conjunto de instrumentos, comprimido com FAST. O cliente apenas ingressa no grupo; não há request de assinatura.
IDInstrument Definition
→
SNSnapshot Recovery
→
INIncremental Stream
Consequência prática: o UMDF é otimizado para latência/banda extremas. O TradeMate prioriza
simplicidade de integração (FIX texto sobre TCP/TLS), adequado ao volume da renda fixa — mas obriga stack separado.
07 Modelo de sessão
| Mensagem de sessão | TradeMate | UMDF |
|---|---|---|
| Logon (35=A) / Logout (35=5) | Sim (CAU user/pass) só TM | Não (feed broadcast) |
| Heartbeat (35=0) | Sim | Sim |
| TestRequest (35=1) | Sim só TM | Não |
| ResendRequest (35=2) | Sim só TM | Não (usa TCP Replayer) |
| Reject (35=3) | Sim só TM | Não |
| SequenceReset (35=4) | Sim (GapFill/NewSeqNo) | Sim (NewSeqNo sempre 1) |
08 Catálogo de Market Data lado a lado
Como o UMDF é só market data, a comparação justa é com a sessão Market Data do TradeMate.
| Mensagem | TradeMate MD | UMDF |
|---|---|---|
| SecurityList (35=y) | ✓ | ✓ |
| MarketDataSnapshotFullRefresh (35=W) | ✓ | ✓ |
| MarketDataIncrementalRefresh (35=X) | ✓ | ✓ |
| SecurityStatus (35=f) | ✓ | ✓ |
| SecurityListRequest (35=x) | ✓ (assinatura) só TM | ✗ (broadcast) |
| MarketDataRequest (35=V) | ✓ (assinatura) só TM | ✗ (broadcast) |
| News (35=B) | ✗ | ✓ só B3 |
| NonFixData (35=n) | ✗ | ✓ (deprecado) |
| Application Msg Request/Report (BW/BX/URDR/BY) | ✗ | ✓ só B3 |
Diferença estrutural: o TradeMate tem mensagens de request (35=x, 35=V) porque é
assinatura sobre TCP. O UMDF transmite; "requests" só na recuperação (TCP Replayer).
10 Recuperação de mensagens
TradeMate
Padrão FIX clássico: ResendRequest (35=2) com a faixa de sequência; o servidor reenvia ou faz SequenceReset/GapFill.
UMDF (multicamadas)
- Snapshot recovery loop (multicast) para perda massiva / late joiners
- TCP Replayer — poucas mensagens do dia (≤ 2000), via FIX 4.4 (
35=BW/BX/URDR/BY) - TCP Historical Replayer — incremental do dia (gráficos)
11 Mais comparativos
Ângulos que ainda não estavam lado a lado: livro, ciclo de vida diário, precificação, peso na rede e tratamento de erro.
Livro de ofertas em detalhe
| Aspecto do livro | TradeMate | UMDF |
|---|---|---|
| Tipo de livro | Order Depth (MDBookType=3), estilo MBP | MBO (ordem a ordem), MBP (agregado) e TOB (topo) |
| Posição da entrada | Explícita via 290 MDEntryPositionNo | Implícita por preço/prioridade (290 deprecada) |
| Atualização | 279 MDUpdateAction New/Change/Delete na sessão | Incremental por canal + RptSeq por instrumento |
| Reconstrução do livro | Snapshot (35=W) sob demanda na assinatura | Snapshot recovery loop contínuo (late joiner entra a qualquer hora) |
| Identidade da ordem no book | Não exposta (agregado) | MBO expõe ordem a ordem |
Ciclo de vida diário
| Momento do dia | TradeMate | UMDF |
|---|---|---|
| Início | Conectar TCP/TLS → Logon (35=A) com CAU → assinar (35=x, 35=V) | Ingressar nos grupos multicast — sem logon |
| Sequência | Reset diário para 1, por sessão | Por canal; SequenceReset com NewSeqNo=1; RptSeq contínuo por instrumento |
| Manter vivo | Heartbeat bidirecional + TestRequest | Heartbeat do feed (unidirecional) |
| Queda no meio do dia | Reconectar, Logon de novo, ResendRequest do gap | Continuar ouvindo; recuperar via snapshot loop ou Replayer |
| Fim do dia | Logout (35=5); throttle zera com a sessão | Feed simplesmente para; nada a encerrar |
Precificação
| Aspecto | TradeMate | UMDF |
|---|---|---|
423 PriceType | 1 % · 2 Per-Unit · 6 Spread · 9 Yield | Preço por unidade / percentual (equities & derivativos) |
| Taxa | 236 Yield quando precifica por taxa | Não se aplica ao domínio |
| Spread sobre referência | 218 Spread + benchmark (699/662/663/761) | Não existe |
| Bandas de preço | 1148/1149 + 6939 PriceBandType (inclui "Spread over B") | Bandas/limites clássicos por instrumento |
| Preço médio | 6 AvgPx sempre 0 (peculiaridade documentada) | Não se aplica (feed) |
Aqui a diferença é legítima: Yield/Spread são o jeito certo de precificar RF — não é drift, é domínio.
Peso na rede (ordem de grandeza)
| Métrica | TradeMate (FIX texto) | UMDF (FAST) |
|---|---|---|
| Mensagem típica de book | Centenas de bytes (tag=valor ASCII + delimitadores) | Dezenas de bytes (template FAST, campos delta) |
| Overhead por mensagem | Header completo (8/9/35/34/49/56/52/10) repetido | Header enxuto por canal |
| Vazão de entrada | Throttle de 50 msg/s por sessão | N/A — feed unidirecional, sem limite de consumo |
| Latência de entrega | TCP + TLS (handshake, retransmissão, head-of-line) | UDP multicast (sem retransmissão, fan-out na rede) |
Valores de tamanho são ordem de grandeza (estimativa pela natureza da codificação), não medição oficial.
Tratamento de erro
| Situação | TradeMate | UMDF |
|---|---|---|
| Mensagem malformada | Reject (35=3) na sessão | Não há — feed não recebe mensagens |
| Request inválido de MD | MarketDataRequestReject (35=Y) | Não se aplica (sem request) |
| Ordem rejeitada | ExecutionReport (35=8) com ExecType=8 | Fora de escopo (OE é no EntryPoint) |
| Sessão duplicada / credencial | Logout/Reject no Logon (CAU) | Não se aplica |
| Queda do provedor | Cancel-on-Disconnect cancela ordens (35002/35003) | Feed A/B redundante (dois grupos multicast) |
Leitura: o TradeMate precisa de todo o aparato de erro porque é bidirecional;
o UMDF resolve confiabilidade com redundância (feed A/B) em vez de diálogo.
12 O que é exclusivo de cada um
Só no TradeMate
- Order Entry completo (
D/G/F/8/9/j) e Drop Copy - Fluxo Voice / cross orders (
s/t/u/BN) - Spread over B e precificação por Yield
- Operações casadas (DI/DAP, via PUMA)
- Assinatura sob demanda + Logon/Throttle/Cancel-on-Disconnect
- Liquidação (
SettlTypeincl. BrokenDate p/ debêntures)
Só no UMDF
- Compressão FAST + multicast UDP
- Livros MBO / MBP / TOB dedicados
- Cobertura multi-mercado (ações, derivativos, FX)
- Mensagem de News (35=B)
- Settlement Price, Open Interest, Imbalance, Volatility, Índices
- Empréstimo de ativos (BTB) e blocos estatísticos
13 Como os dois se relacionam
O market data do TradeMate herda o modelo do UMDF (message blocks, MsgTypes 35=y/W/X/f,
tags 269/279/270/271/1148/1149/326…), mas reempacota em FIX 4.4/TCP com assinatura e reinventa vários
domínios — daí a seção “Onde o TradeMate viaja”. Ponto de convergência real: as “casadas” executam
Futuros DI/DAP no PUMA (524 NestedPartyID = broker no PUMA).
14 Documentos-fonte
TradeMateMessageSpecificationGuidelines v1.1FIX 4.4, sessões, logon, throttle
TradeMateOE v2.7 · MD v2.3 · DC v2.1Referências + XMLs FIX 4.4
PUMA UMDFMessage Reference v2.2.2FIX 5.0 SP2, y/W/X/f/B, TCP Replayer
PUMA UMDFMarket Data Spec v2.2.2Arquitetura multicast/FAST
Fontes: TradeMate · Conectividade FIX e PUMA · FIX/FAST UMDF.