UMDFConflated MarketDataSpecification2.0.11

UMDF PUMA Conflated
FIX Market Data Specification
Version: 2.0.11
Last modified: 6/27/2019
Contacts
• Services Development Department (GDS): handles all enquiries for connectivity setup
and general exchange supported services.
o [email protected]
• Trading Certification: performs certification of all software solutions applying for

MarketData connectivity.
o [email protected]
o +55 11 2565-5029
• Trading Support Channel: provides real time connectivity monitoring and

troubleshooting.
o [email protected]
o +55 11 2565-5000, option 2
UMDF PUMA Conflated Market Data Specification Version 2.0.11
Index
REVISION HISTORY ....................................................................................................................... 4
1 PREFACE ............................................................................................................................... 6
1.1 ABBREVIATIONS ................................................................................................................ 6

1.2 GLOSSARY ....................................................................................................................... 6
2 MARKET DATA ARCHITECTURE......................................................................................... 7
2.1 PHYSICAL/LINK LAYER OPTIONS ........................................................................................ 7

2.1.1 RCCF .......................................................................................................................... 7
2.1.2 RCB ............................................................................................................................ 7
2.2 NETWORK SETUP .............................................................................................................. 7
2.3 COMPRESSION LAYER ....................................................................................................... 8
2.4 SESSION ASSIGNMENT ...................................................................................................... 8
3 FIX PROTOCOL...................................................................................................................... 9
3.1 FIX PROTOCOL SYNTAX .................................................................................................... 9

3.2 MESSAGE FORMAT............................................................................................................ 9
3.3 DATA TYPES ................................................................................................................... 10
4 SESSION MANAGEMENT ................................................................................................... 11
4.1 STANDARD FIX 4.4 SESSION BEHAVIOR ........................................................................... 11

4.2 MESSAGE HEADER FORMAT ............................................................................................. 11
4.3 MESSAGE TRAILER FORMAT ............................................................................................. 11
4.4 LOGON ........................................................................................................................... 12
4.4.1 Logon Request (MsgType=A) .................................................................................. 12
4.4.2 Logon Response ...................................................................................................... 12
4.4.3 Logon Failure ........................................................................................................... 12
4.5 ADMINISTRATIVE MESSAGES ............................................................................................ 13
4.5.1 Heartbeat messages (MsgType=0) .......................................................................... 13
4.5.2 Other messages ....................................................................................................... 13
4.6 REJECT MESSAGES......................................................................................................... 13
4.7 LOGOUT MESSAGES ........................................................................................................ 13
5 INCREMENTAL BOOK MANAGEMENT ............................................................................. 14
5.1 BOOK MANAGEMENT CONSIDERATIONS............................................................................ 14

5.2 ORDER DEPTH BOOK ....................................................................................................... 14
5.3 PRICE DEPTH BOOK ......................................................................................................... 15
5.4 PRICE-DEPTH BOTTOM ROW HANDLING ........................................................................... 15
5.5 MARKET DATA CONFLATION (MARKET DATA THROTTLING)................................................ 17
6 APPLICATION MESSAGES (MESSAGING FUNCTIONALITY) ......................................... 19
6.1 MESSAGE TYPES ............................................................................................................ 19

6.2 MESSAGE FLOW ............................................................................................................. 19
6.3 INSTRUMENT IDENTIFICATION BLOCK ................................................................................ 20
6.4 SECURITY LIST................................................................................................................ 20
© B3
2
6.4.1 Security List Request (MsgType = x) ....................................................................... 21

6.4.2 Security List (MsgType = y) ...................................................................................... 23
6.5 MARKET DATA MESSAGES............................................................................................... 33
6.5.1 Market Data Request (MsgType = V)....................................................................... 33
6.5.2 Market Data Request Reject (MsgType = Y) ........................................................... 36
6.5.3 Market Data Snapshot/Full Refresh (MsgType = W) ............................................... 36
6.5.4 Market Data Incremental Refresh (MsgType = X) ................................................... 46
6.5.5 Security Status (MsgType = f) .................................................................................. 54
6.5.6 News (MsgType = B) ................................................................................................ 56
6.6 TRADE HISTORY.............................................................................................................. 58
6.6.1 Trade History Request (MsgType = UTHQ) ............................................................. 58
6.6.2 Trade History Response (MsgType = UTHP) .......................................................... 59
6.7 MARKET TOTALS ............................................................................................................. 62
6.7.1 Market Totals Request (MsgType = UTOTQ) .......................................................... 63
6.7.2 Market Totals Response (MsgType = UTOTP) ........................................................ 63
6.7.3 Market Totals Broadcast (MsgType = UTOT) .......................................................... 63
6.7.4 Market Totals Composition (MsgType = UTOTC) .................................................... 64
6.7.5 Unsupported FIX Messages ..................................................................................... 64
6.8 MARKET DATA MESSAGES PER ENTRY TYPE ................................................................... 65
6.8.1 Book Updates (269=0,1) .......................................................................................... 65
6.8.2 Book Reset (269=J).................................................................................................. 65
6.8.3 Trade (269=2) ........................................................................................................... 66
6.8.4 Index Value (269=3) ................................................................................................. 68
6.8.5 Opening Price (269=4) ............................................................................................. 69
6.8.6 Closing Price (269=5) ............................................................................................... 69
6.8.7 Trading Session High, Low and VWAP (269=7, 8, 9) .............................................. 70
6.8.8 Auction Imbalance (269=A) ...................................................................................... 71
6.8.9 Price and Quantity Bands (269=g, h) ....................................................................... 71
6.8.10 Trade Volume (269=B)......................................................................................... 72
6.8.11 Open Interest (269=C) ......................................................................................... 73
6.8.12 Settlement Price (269=6) ..................................................................................... 73
6.8.13 Composite Underlying Price (269=D) .................................................................. 74
6.8.14 Security Trading Phase/State (269=c) (Snapshot only) ...................................... 75
6.8.15 Volatility price (269=v).......................................................................................... 76
7 CERTIFICATION PROCESS ................................................................................................ 77
© B3
3
Revision History
Date Version Description Author
Jun, 27st,2019 2.0.11 - Added new domain for tag 277 in section 6.8.3. AYSF
Aug. 6th, 2018 2.0.10 - Added new domains for tag 762. AYSF
- Added section 6.8.15 about volatility prices and AYSF/

Sep, 21st, 2017 2.0.9 corresponding tags 811-PriceDelta, 31-LastPx and 1025- JLRM
FirstPx to sections 6.5.3 and 6.5.4.
- Updated sections 6.5.3, 6.5.4, 6.8.1 and 6.8.3 with new
May 3rd, 2016 2.0.8 tags 37023, 37024, 37025 and new domain for tag 37019 JLRM
in conformance to the BTB Security Lending system
changes.
- Changed the domain of tag 762-SecuritySubType, adding
Nov, 11st, 2015 2.0.7 new types for Foreign Indices and the new BDR products. JLRM
- Added domain M2 to tag 37011-GovernanceIndicator.
Apr, 7th, 2014 2.0.6 - Added new domains for tags 167 and 762 to reflect the JLRM
addition of Fixed Income ETF products.
- Yet another change to the description of tag 1150-
Nov, 13th, 2014 2.0.5 TradingReferencePrice, this time clearing up that it´s only JLRM
used by Economic Indicators in the Derivatives segment.
- Changed description of tag 1150-TradingReferencePrice.
- Changed descriptions of tags 37016-MDInsertDate and
37017-MDInsertTime for Trade History messages,
explaining that these tags are only returned for 269=2
Oct, 24th, 2014 2.0.4 Trade blocks. JLRM
- Added a warning on sections 6.4.1 and 6.5.1 stating that
all subscriptions must hold at least one filter to be valid,
thus a customer that wants to subscribe to all market data
will have to hold more than one simultaneous
subscription.
- Updated description of tag 1020-TradeVolume on 6.5.3,
6.5.4 and 6.6.2, explaining it could also be present on
Trade Volume groups (269=B).
- Updated section 6.8.3 explaining tag 1020-TradeVolume
is only sent for electronic trades.
- Section 6.8.12, on settlement tag 286 can be only 1,4.
July, 15th, 2014 2.0.3 - Added “1” as the default value for tag 336- JLRM
TradingSessionID on sections 6.5.3, 6.5.4 and 6.6.2.
- Tag 262 message 35=UTHQ on section 6.6.1 is no longer
required to be unique.
- Reviewed diagram on section 6.2, clarifying the business
message flow.
- Edited description of section 6.5.1 to better describe the
behavior of Snapshot messages (35=W).
© B3
4
- Added a new domain to tags 281 and 560 indicating that

a maximum number of subscriptions have been exceeded
on sections 6.4.2 and 6.5.2. Also added matching
explanation on section 6.5.1.
- Removed domain 5(Overlay) from tag 279-
MDUpdateAction, as this value is only used on TOB feeds
on section 6.5.4.
- Reordering of fields in most messages, to match with the
actual order being produced on sections.
- Removed 269=2,3,4 from section 6.8.1 header, as it´s not
book related.
- Added tag 346-NumberOfOrders to section 6.8.1.
- Changed section 6.8.2 and 6.8.9, removing mentions
about channels (inexistent on TCP Market Data).
- Added a table clarifying on the usage of tag 277 on
section 6.8.3.
- Removed unused error messages from tag 560 on
section 6.4.2.
- Update the error messages on 6.5.2, including new value
May, 2nd, 2014 2.0.2 “T” and removing unused values. JLRM
- Updated the error messages on section 6.6.2, removing
value 1, and adding “T”.
- Updated derivatives phase and state behavior (added tag
1174 on section 6.5.5)
- Corrected tags 9325-LastTradeDate and 37019-
EarlyTermination from derivatives only to equities only
(used for BTC instruments) on section 6.5.3.
- Added in detail explanation about subscription filters to
sections 6.4.1 and 6.5.1.
- Included better explanation of usage for Trade history on
section 6.6.
- Noted on Section 2.3 (Compression Layer) that only the
outbound messages from BVMF are compressed and
that the reference implementation is not available at the
FTP site yet.
- Section 6.4.1 updated to clarify about multiple
subscriptions and about cancelation.
- Section 6.5.1 updated to clarify about multiple
Mar, 25th, 2014 2.0.1 subscriptions and about cancelation. Also marked 1021- JLRM
MDBookType as required to properly reflect the restriction
to allow a subscription to use either MBP or MBO, not
both.
- Added a legend to the column names used on tables, on
chapters 4 and 6.
- Included extended the domains of tag 167 and 762 to
classify Corporate Fixed Income on sections 6.4.1, 6.4.2
and 6.5.1.
Feb, 13nd, 2014 2.0.0 - Customer spec first release. JLRM
© B3
5
1 Preface
UMDF PUMA Conflated provides a TCP protocol based, conflated market data feed for Equities,
Derivatives and FX listed in the BM&FBOVESPA Trading System using their native currency.
This document outlines UMDF PUMA Conflated system FIX 4.4 market data messages features
and is targeted at third-parties which need to consume those messages from UMDF PUMA
Conflated.
FIX is a technical specification for electronic communication of trade-related messages. It is an

open standard managed by members of FIX Protocol Limited (http://www.fixprotocol.org/).
It is assumed that the reader of this document has previous knowledge of the basic functioning of
the FIX protocol.
1.1 Abbreviations
Abbreviation Description
FIX Financial Information Exchange Protocol
IP Internet Protocol
TCP Transport Control Protocol
1.2 Glossary
Term Definition
BM&FBOVESPA Electronic Link One of BM&FBOVESPA’s solutions for
accessing its electronic trading platform.
BM&FBOVESPA
Securities, Commodities and Futures
Exchange, based in São Paulo, Brazil. For
more information, visit
http://www.bmfbovespa.com.br.
Broker A broker is an individual or firm who acts

as an intermediary between a buyer and
seller, usually charging a commission.
Brokerage
Used interchangeably with broker when
referring to a firm rather than an individual.
Also called brokerage house or brokerage
firm.
FIX Gateway Service that provides connectivity to third-

party clients and brokerages using the FIX
protocol.
Instrument Financial capital in a readily tradable form.
Market Data A collective term for quotes, last sales,
volume statistics and other information
used by the market to evaluate trading
opportunities.
© B3
6
Security A stock, bond or contract that has been

authorized for trading on, and by, a
registered exchange. Each exchange has
different criteria to determine a security's
eligibility for listing.
2 Market Data Architecture

UMDF PUMA Conflated provides a conflated single feed market data stream with the “Tag=Value”
FIX 4.4 pattern syntax using the TCP protocol which allows efficient message delivery to customers’
applications. The following sections describe the connectivity features.
2.1 Physical/Link Layer Options

Market participants can choose from the following connectivity options, described as follows:
2.1.1 RCCF
RCCF (“Rede de Comunicações da Comunidade Financeira” or Financial Community
Communications Network) is an MPLS network that connects all brokerage firms to
BM&FBOVESPA, as well as some distributors and other interested clients. This network allows
specific SLAs and contingency features. It is typically used to receive market data and transactional
messages (order management).
2.1.2 RCB
RCB (“Rede de Comunicação BM&FBOVESPA” or BM&FBOVESPA Communications Network) is
a newer communication option available to the BM&FBOVESPA’s customers. Based on Ethernet
over SONET (EoS/EoSDH), it allows participants to choose from a vast array of link speeds and
service levels, which contrasts with RCCF, as the latter offers packaged, predefined solutions.
2.2 Network Setup

Before a client can connect to the FIX market data interface, there are some configuration
parameters that must be agreed between the FIX client and the System, such as:
• The customer´s FIX client is responsible for initiating a TCP connection to the UMDF TCP
Market Data Port.
• UMDF PUMA Conflated does not support encryption of FIX messages.
• BVMF Market Operations will provide clients with the IP addresses and port numbers of
UMDF PUMA Conflated Market Data Ports.
• The default heartbeat interval for the FIX connection is set to 30 seconds unless otherwise
agreed on with the participants.
Before connecting to BM&FBOVESPA, the counterparty must undergo the certification process
according to the activity it will perform.
The certification process is better described in section 6.8.15 of this document. The physical link
used for certification may vary from the one to be used in production, once it is the application that
is being certified, and not the physical layer. Hence, a client application which will run using either
© B3
7
RCCF or a dedicated link in the production environment may be certified through an Internet VPN
connection.
The diagram below illustrates the connection schema in respect to the remainder of the PUMA
Platform:
2.3 Compression Layer

The connection to the UMDF PUMA Conflated used an intrinsic compression layer using the
standard ZLIB compression algorithm (RFC 1950, accessible at http://tools.ietf.org/html/rfc1950)
for bandwidth optimization purposes. The customer application must be able to decode this stream
of compressed bytes before processing the market data messages. Please note that only outbound
messages are compressed, the customer application should always send plain, uncompressed
messages.
In the near future, a reference implementation to decode this compressed market data will be
available at:
ftp://ftp.bmf.com.br/FIXFAST/reference/UMDFTCP/
2.4 Session Assignment

FIX comp IDs and IP addresses for connection are assigned by BM&FBOVESPA for connecting
counterparties. The process is differentiated according to the counterparty category (banks, trading
firms, DMA providers, vendors, other exchanges). For more details, please contact:
BM&FBOVESPA Trading Support Group (TSG)

+55 11 2565-5000, option 2 (São Paulo)
[email protected]
© B3
8
3 FIX Protocol
The FIX Protocol is a free and open messaging standard that was developed in 1992 by Jim Leman,
Jacques Perold, Bob Lamoureux, and Chris Morstatt of Salomon Brothers and Fidelity Investments
to facilitate a bi-lateral communications framework for equities trading.
Since its conception, its usage has significantly expanded in response to evolving industry needs
and today it is the predominant messaging standard for pre-trade and trade communication globally
within the equity markets.
The FIX Protocol is a generic protocol with a flexible structure that allows more than one possible
implementation. This chapter describes the specific features for the implementation of the FIX
protocol in the UMDF PUMA Conflated system.
More info about the FIX Protocol can be obtained at http://www.fixprotocol.org/.
3.1 FIX Protocol Syntax

There are two FIX Protocol Syntax patterns, traditional (“Tag=Value”) and XML (FIXML). UMDF
PUMA Conflated uses the traditional “Tag=Value” FIX syntax. The current FIX version in use by
UMDF PUMA Conflated is FIX 4.4.
3.2 Message Format

The general format of a FIX message is a standard header followed by the message body fields
and terminated with a standard trailer.
Each message is composed by a stream of <tag>=<value> fields with a field delimiter between
fields in the stream. Tags are of data type TagNum (see table in section 3.3). All tags must have a
specified value. Optional fields without values should not be specified in the FIX message. A Reject
(MsgType=3) message will be the response to a tag with no value.
Except where noted, fields within a message can be defined in any sequence (Relative position of
a field within a message is inconsequential.) The exceptions to this rule are described below:
1. General message format is composed by the standard header followed by the body
followed by the standard trailer.
2. The first three fields in the standard header are: tag 8-BeginString followed by tag 9-
BodyLength followed by tag 35-MsgType.
3. The last field in the standard trailer is the tag 10-CheckSum.
Field Delimiter:
All the fields in a FIX message are terminated by a delimiter character. The non-
printing, ASCII "SOH" (#001, hex: 0x01, referred to in this document as <SOH>), is
used for field termination. Messages are delimited by the “SOH” character following
the CheckSum field. All messages begin with the “8=FIX.x.y<SOH>” string and
terminate with “10=nnn<SOH>“.
© B3
9
3.3 Data Types

FIX 4.4 has 35 data types available. They are described as follows:
Name Base Type First Introduced

Amt float FIX 4.2
Boolean char FIX 4.2
Char FIX 4.2
Country string FIX 4.2
Currency string FIX 4.2
Date date FIX 4.0
DayOfMonth int FIX 4.1
Exchange string FIX 4.2
Float float FIX 2.7
Int int FIX 2.7
Length int FIX 4.3
LocalMktDate string FIX 4.2
MonthYear string FIX 4.1
MultipleCharValue string FIX 4.4
MultipleStringValue string FIX 4.2
NumInGroup int FIX 4.3
Pattern FIX 4.4
Percentage float FIX 4.3
Price fix FIX 4.2
PriceOffset float FIX 4.2
Qty float FIX 4.2
Reserved1000Plus pattern FIX 4.4
SeqNum int FIX 4.3
String FIX 4.2
TZTimeOnly string FIX 4.4
TZTimestamp String FIX 4.4
TagNum Int FIX 4.3
Tenor pattern FIX 4.4
Time FIX 4.0
UTCDate String FIX 4.2
UTCDateOnly String FIX 4.0
UTCTimeOnly String FIX 4.2
UTCTimestamp String FIX 4.2
© B3
10
4 Session Management
This section describes session-level FIX messages sent between UMDF PUMA Conflated and FIX
clients.
In the following tables the REQ column means the tag is Required (Y), Conditionally Required (C)
or Non Required (N) in FIX.
4.1 Standard FIX 4.4 Session Behavior

In a typical production UMDF PUMA Conflated setup, multiple Market Data servers are installed
for each client. One of the Market Data servers functions as Primary whereas the others function
as Standby servers. Clients should first initiate the session to the Primary Market Data server. If
the connection fails, clients should retry the primary connection after 30 seconds. If the primary re-
connection is not possible yet, then the client can connect to a standby server.
It is a responsibility of the client to detect any message gaps after a connection break. If the
incoming sequence number is greater than expected, a retransmission of the messages can be
requested by sending the Resend Request (MsgType=2) message to the System.
4.2 Message header format

All UMDF PUMA Conflated Market Data messages carry the following fields in the header:
TAG FIELD NAME REQ COMMENTS

8 BeginString Y FIX4.4 (Must be the first field in
the message)
9 BodyLength Y (Must be the second field in the
message)
35 MsgType Y (Must be the third field in the
message)
34 MsgSeqNum Y See standard FIX protocol
specification
43 PossDupFlag N Always required for
retransmissions, whether
prompted by the sending system
or as a result of a resend request.
49 SenderCompID Y The value used must be
recognized and agreed by BVMF.
52 SendingTime Y Indicates the time the message
was sent by BVMF.
56 TargetCompID Y Please use the value as provided
by BVMF Market Operations
4.3 Message trailer format

All UMDF PUMA Conflated Market Data messages carry the following fields in the trailer:
© B3
11

10 CheckSum Y (Always unencrypted, always last
field in the message)
4.4 Logon
4.4.1 Logon Request (MsgType=A)
The logon message authenticates a user establishing a connection to UMDF PUMA Conflated. The
logon message must be the first message sent to UMDF PUMA Conflated by the client.

Message Header Y MsgType=A
98 EncryptMethod Y Always unencrypted. Must send a
value = 0
108 HeartBtInt Y Default value used by UMDF PUMA
Conflated is 30. Please set this to 30
unless otherwise agreed with BVMF
Market Operations.
141 ResetSeqNumFlag N
789 NextExpectedMsgSeqNum N
Message Trailer Y
The sequence number, in the initial logon for each trading day, must be set to “1”.
• If a client receives a sequence number that is less than expected, the client
must terminate the session immediately and contact BVMF Market
Operations to correct the problem.
• BVMF strongly advises clients to reset the sequence number on logon for
market data sessions
4.4.2 Logon Response

Once UMDF PUMA Conflated receives a Logon request, it validates the header tag 49-
SenderCompID. No messages should be sent to UMDF PUMA Conflated until a Logon message
is received in reply from UMDF PUMA Conflated.
When UMDF PUMA Conflated returns a positive Logon response, the client can start performing
the following:
• Start the heartbeat timer

• Start exchanging messages with the System
4.4.3 Logon Failure

If the validation fails, UMDF PUMA Conflated shuts down the connection; no Logout message is
sent before the termination.
© B3
12
4.5 Administrative messages

This section describes the minimum requirements to keep the session alive and synchronized.
4.5.1 Heartbeat messages (MsgType=0)

UMDF PUMA Conflated must receive a message from the client at least once in the heartbeat
interval (default to 30 seconds) defined in the logon. If the session is idle and no message is
received within two heartbeat intervals, UMDF PUMA Conflated considers the session dead. A
Logout message is sent to the client and the session is disconnected.
UMDF PUMA Conflated sends a message at least once in the heartbeat interval.
4.5.2 Other messages

UMDF PUMA Conflated handles the following FIX 4.4 standard administration messages:
• Test Request (MsgType=1)
• Resend Request (MsgType=2)
• Sequence Reset (MsgType=4)
• Logout (MsgType=5)
Please note that the tag 122-OrigSendingTime is ignored by UMDF PUMA Conflated in all
messages.
4.6 Reject Messages

Reject messages (MsgType=3) received by UMDF PUMA Conflated will be ignored by the System.
However, clients must not send a Resend Request (MsgType=2) for the rejected message.
Otherwise, it is possible to fall into an infinite resend loop. Reject messages (MsgType=3) sent by
UMDF PUMA Conflated will include the sequence number of the rejected message with the reject
reason in the text field, and tag 373-SessionRejectReason, whenever possible.
When UMDF PUMA Conflated receives a message with a sequence number that is less than
expected during normal session processing, a Logout (MsgType=5) message will be sent to the
client and the session will be terminated.
In the event of UMDF PUMA Conflated receiving a sequence number that is less than expected
when the client reconnects after a break in the session during the same trading day, the session
will be terminated immediately without sending a Logout. The client should contact the BVMF
Market Operations to correct the problem.
4.7 Logout Messages

The Logout message (MsgType=5) initiates or confirms the termination of a FIX session.
Disconnection without the exchange of logout messages should be interpreted as an abnormal
condition, for instance, network level disconnection.
There are other scenarios where the client’s FIX session can be disconnected. Depending on the
situation, UMDF PUMA Conflated may either wait or not for the logout response message from the
client before terminating the connection, e.g. idle session with no message after two heartbeat
intervals.
© B3
13
5 Incremental Book Management

The book received via FIX 4.4 session is incremental, i.e. changes to the book are relayed on
individual messages providing “deltas” of the previous state of the book.
The actions to be executed by the client system receiving the incremental message are determined
by the tag 279-MDUpdateAction, whose value carries an instruction that can be either add, delete,
change, delete from or delete through. The items in the order book that are affected by the action
stated in the tag 279 are stated in the tag 290-MDEntryPositionNo, which contains a position in the
order book.
5.1 Book Management Considerations

For bid or offer book entries (price depth book), the deletion is based on the entry’s position (field
MDEntryPositionNo). For example, assume ten bids for a security. Adding a bid with
MDEntryPositionNo=2 requires the receiver to move down other Market Data Entries, i.e. the
Market Data Entry on the 2nd display position will move to the 3rd, the 3 moves to the 4th, etc. UMDF
rd
PUMA Conflated will not send a modification of all MDEntries on the 2nd through the final position
just to update the MDEntryPositionNo field; the counterparty must infer the change.
Similarly, deleting a Market Data Entry on the 2nd position causes the 3rd Market Data Entry to move
into the 2nd position, the 4th to move into the 3rd position, etc. UMDF PUMA Conflated will not issue
a change action to modify the position of an entry in the book. Change updates are only sent when
a value applicable to a specific MDEntryPositionNo – such as total quantity or number of orders –
changes.
All Snapshot and Incremental Market Data messages containing book information (entry types
269=0,1) are sent on a separated message, containing only the book updates. This message will
have the tag 1021-MDBookType tag set to indicate the type of book to which is refers (Order depth
or Market depth).
However, Snapshot and Incremental Market Data messages containing statistics (all other entry
types different from 269=0,1) will be separated from messages containing book updates and these
messages will never contain the tag 1021-MDBookType.
5.2 Order depth book

Order depth book contains order by order information, where each entry represents an individual
order. For example, this is how an order-depth book looks like:
BID OFFER
PosNo Size Px Px Size PosNo
One entry per order: same
1 5000 10.58 11.03 7000 1 price on more than one
entry.
2 4000 10.58 11.03 2000 2
3 3000 10.57 11.05 1000 3
4 4000 10.54 4
© B3
14
Usually BVMF provides the full depth of the book for order-depth book, however, for instruments
with extremely deep books, even book by order can impose a limited depth. Client systems must
determine the book depth for an instrument from the tag 264-MarketDepth in the Security List
(MsgType=y) message.
In general, if a trade occurs, BVMF will send a delete or change data block to update the book. The
trade data block itself is not used to update the order book.
5.3 Price depth book

Price-depth book contains price by price information, where each entry represents the aggregation
of all order quantities at that price. The following table illustrates the price-depth book of the same
book described above:
One entry
BID OFFER per price:
PosNo NoOrders Size Px Px Size NoOrders PosNo more than
1 2 9000 10.58 11.03 9000 2 1 one order
2 1 3000 10.57 11.05 1000 1 2 per entry.
3 1 4000 10.54 3
In addition to the quantity and the price, the price-depth book also makes the number of orders that
composes a specific price available. BVMF presets the depth of the book that will be made available
per instruments, usually defaulting to 10. Client systems must determine the book depth for an
instrument from the tag 264-MarketDepth in the SecurityList (MsgType=y) message.
The change data block is sent to update characteristics of a price level without changing the price
itself, or impacting any other prices in the book (update to the order count or quantity at that price).
5.4 Price-depth Bottom Row Handling

For price-depth book only, the recipient of the market data must know how many price levels are
being supplied by UMDF PUMA Conflated. The recipient must delete the bottom price row when
the number of price rows is exceeded – UMDF PUMA Conflated will not send a delete of the bottom
row when the number is exceeded. UMDF PUMA Conflated will send the bottom row again when
a higher level row is deleted.
The following example illustrates this behavior:
BID
PosNo NoOrders Size Px Top row of the book (best bid).
1 2 9000 10.58
2 1 3000 10.57
3 1 4000 10.54
4 4 10000 10.53
5 3 8000 10.50
Bottom row of the book.
New buy order is received (BUY 1000 @ 10.60), updating the top of the book (bid):
© B3
15
Market Data Incremental Refresh

MDEntryPositionNo 1
MDUpdateAction New
MDEntrySize 1000
MDEntryPx 10.60
NumberOfOrders 1
Bid
PosNo NoOrders Size Px New bottom row of the book
1 1 1000 10.60
2 2 9000 10.58
3 1 3000 10.57
4 1 4000 10.54
5 4 10000 10.53 Implicit deletion of the previous
6 3 8000 10.50 bottom row.
The order with price 10.57 is deleted (CANCEL BUY 3000 @ 10.57):

MDEntryPositionNo 3
MDUpdateAction Delete
MDEntryPositionNo 5
MDUpdateAction New
MDEntrySize 8000
MDEntryPx 10.50
NumberOfOrders 3
© B3
16
So, the book will miss the last row until the insertion in the last position:
Bid
PosNo NoOrder Size Px
s
1 1 1000 10.60
2 2 9000 10.58
3 1 4000 10.54
4 4 10000 10.53
New bottom row will be sent by BVM&F:

MDEntryPositionNo 5
MDUpdateAction New
MDEntrySize 8000
MDEntryPx 10.50
NumberOfOrders 3
The book after the event will be:
Bid
PosNo NoOrders Size Px New bottom row will be sent by
1 1 1000 10.60 BVM&F.
2 2 9000 10.58
3 1 4000 10.54
4 4 10000 10.53
5 3 8000 10.50
5.5 Market Data Conflation (Market Data Throttling)

In order to facilitate customers coping with the increasing market data messaging volumes and
bandwidth requirements, the UMDF PUMA Conflated market data platform feed is throttled. Being
throttled, book updates are sent at specific intervals, consolidating the end state of the order book
to reduce the amount of book updates and convey the same end result.
The throttling interval (i.e. the interval at which the book updates are sent) is deemed to be optimal
at 300 ms. Depending on the market data velocity, this interval may be increased to avoid the need
for bandwidth updates by end customers. It is known that such interval does not affect negatively
in any way the ability for a human trader to operate the markets. Customers willing to receive more
or less frequent Market Data, can adopt these different intervals (such as 100 ms or 500ms).
IMPORTANT
Please note that trades and statistical data (such as high price, low price, security
state and trading phase changes) are still sent without being throttled, in real time.
© B3
17
Consider the instrument PETR4 and the arbitrary amount of time passed since the beginning of the
measurement period (“Δt”). As various market participants issue orders for this instrument, a non-
throttled market data feed would contain the following flow of messages:
PETR4 market data message sequence

Security Instruction Side Price Quantity Δt(ms)
PETR4 INSERT BUY 24.00 100 0
PETR4 INSERT SELL 24.03 300 200
PETR4 INSERT SELL 24.05 100 300
PETR4 MODIFY BUY 24.00 200 500
PETR4 MODIFY SELL 24.05 200 600
PETR4 DELETE SELL 24.05 200 700
PETR4 MODIFY BUY 24.01 100 800
PETR4 DELETE BUY 23.99 500 1000
Total number of messages sent: 11
The end state of buy and sell orders for PETR4 is shown below:
Buy Quantity Buy Price Sell Price Sell Quantity

100 24.01 24.03 300
200 24.00
400 23.98
If the throttling mechanism is applied to the same market data feed as before, all the changes to
the order prices are batched in the same message, generating a snapshot of the order prices. This
mechanism aggregates the end state of the order book in the same message, thus reducing the
messaging overhead.
The following sequence of messages would be generated.

Security Instruction, Side, Price, Quantity Δt(ms)
INSERT BUY 24.01 200
INSERT SELL 24.03 300
INSERT SELL 24.05 100

Security Instruction, Side, Price, Quantity Δt(ms)
MODIFY BUY 24.00 200
DELETE SELL 24.05 200
PETR4 MODIFYBUY 24.01 100 1100
Total number of messages sent: 3
The end state of buy and sell orders for PETR4 is shown below:
© B3
18
Buy Quantity Buy Price Sell Price Sell Quantity

100 24.01 24.03 300
200 24.00
400 23.98
Note a decrease of approximately 72% in the number of messages sent to achieve the same end
result of the order book at the end of the time interval.
6 Application Messages (Messaging Functionality)

This section describes the application-level FIX messages sent and accepted by UMDF PUMA
Conflated.
In the following tables, the REQ column means the tag is Required (Y), Conditionally Required (C)
or Non Required (N) in the FIX message. An X in the EQ column means the tag is used for Equities
and Corporate Fixed Income products, while an X in the DER column means the tag is used for
Derivatives/FX.
6.1 Message Types

MsgType Definition
35=x SecurityListRequest - Instrument definition list request
35=y SecurityList - Instrument definition list
35=V MarketDataRequest - Market Data request
35=W MarketDataFullRefresh - Market Data snapshot
35=X MarketDataIncrementalRefresh - Incremental Market data update
35=f SecurityStatus - Security status change notification
35=UTHQ TradeHistoryRequest - message to request past trades
35=UTHP TradeHistoryResponse - message responding past trades requests
35=UTOTQ MarketTotalsRequest - message used to (un)subscribe to Market Totals
35=UTOTP MarketTotalsResponse - response to a subscription request
35=UTOTC MarketTotalsComposition - reports the composition of Market Totals
35=UTOT MarketTotalsBroadcast - periodically reports the value of Market Totals
IMPORTANT
If a customer application sends repeated messages that result in a reject, the
respective session may get disconnected automatically.
6.2 Message Flow

The figure below illustrates the basic message flow in the UMDF PUMA Conflated platform, after
the FIX 4.4 session is established:
© B3
19
6.3 Instrument Identification Block

This block is common to most market messages. It contains the tags that uniquely identify an
instrument, and works as a “stamp” of the instrument identification in the message specification.
In the following table REQ means the field is Required (Y), Conditionally Required (C) or Non
Required (N) in FIX.

22 SecurityIDSource Y SecurityID qualifier. Value issued by
BVMF:
8 = Exchange Symbol (BVMF security
identification).
207 SecurityExchange Y Value supported by UMDF PUMA
Conflated: BVMF
48 SecurityID Y Unique instrument identifier for a given
qualifier (SecurityIDSource)
6.4 Security List

This set of FIX messages are utilized so that the connecting parties are able to determine which
instruments can be traded via UMDF PUMA Conflated. Instrument definition messaging is based
© B3
20
on a subscription model, in which the clients subscribe to receive instrument definitions according
to specific criteria, and optionally receive updates afterwards. The subscription may be cancelled
at any time.
6.4.1 Security List Request (MsgType = x)

The Security List Request message is used by customers to send a request UMDF PUMA
Conflated to retrieve a list of securities that are available for trading. Its response is a SecurityList
message, which contains information about the instruments traded. In case the request fails, the
response will be a SecurityList message with the tag 560-SecurityRequestResult indicating the
reason for the rejection.
The new subscription mechanics on UMDF PUMA Conflated is entirely based on filters, hence
sometimes the selected filters will result in an empty instrument set. Since the platform supports
online creation of instruments, a subscription that results in an empty set is perfectly valid (the set
can receive new instruments later, during the day). Thus customers applications must know how
to handle 35=y responses containing no instruments.
For instance, one could subscribe to a SecurityGroup that usually contains only UDS instruments,
this group could start the day with no valid instruments, but subscribing to this will guarantee that if
one such instrument is ever created the customer will receive the related messages.
Also, two subscriptions could match instruments previously subscribed; in this case the response
will carry all matched instruments, even if they are repeated. However, incremental changes to
them will be relayed only once to each session.
It´s possible to maintain many simultaneous subscriptions, each with a unique value for tag 320-
SecurityReqID. In the event of instrument creation during the session, users will receive the
correspondent SecurityList messages, as long as it matches one of the subscription filters.
Cancellation of the subscription may be done by setting the field SubscriptionRequestType to 2

(unsubscribe). To define which request is to be unsubscribed, it needs to be properly identified by
sending tag 320-SecurityReqID with the same value used when subscribing.
Additionally, if subscribing to a set of securities, the response may contain only the securities the
session has permission to access.
IMPORTANT
Since the new subscription policy is based on filters, it´s always mandatory for each
request to have at least one filter. This implies that to subscribe to all instruments
one will have to hold many simultaneous subscriptions.
TAG FIELD NAME REQ EQ DER COMMENTS

Message Header Y X X MsgType=x
167 SecurityType N X X Specifies the SecurityType of the desired
instruments. (FILTER)
Valid Values (Corporate Fixed Income):
© B3
21
- ETF (Exchange Traded Fund)

- CORP (Corporate)
Valid Values (Derivatives and FX):

- FUT (Futures)
- SPOT (Spot Market)
- SOPT (Spot Options)
- FOPT (Future Options)
- DTERM (Derivative Forward or
“Termo”)
Valid Values (Equities):

- CASH (rights, etc)
- OPT (Option)
- FORWARD (Equity Forward or
“Termo”)
- INDEX (Non Tradeable index)
- OPTEXER (Option Exercise)
- MLEG (Multileg Instrument, UDS)
- CS (Common Stock)
- PS (Preferred Stock)
- SECLOAN (Security loan, or BTB)
- INDEXOPT (Option on Index)
263 SubscriptionReques Y X X Subscribe or unsubscribe for security
tType changes in the request. Values accepted
by UMDF PUMA Conflated:
1 = Securities + Updates (Subscribe)
2 = Disable previous request
(Unsubscribe)
320 SecurityReqID Y X X Unique ID of the Security List Request.
It´s strongly recommended that this value
is unique throughout the trading day
since it will be used to cross reference
the request to the response.
When unsubscribing, this tag should
contain the ID of the request being
canceled.
460 Product N X X Specifies the Product of the desired
instruments. (FILTER)
Valid Values:
2 = COMMODITY
3 = CORPORATE
4 = CURRENCY
5 = EQUITY
6 = GOVERNMENT
7 = INDEX
15 = ECONOMIC INDICATOR
16 = MULTILEG
© B3
22
461 CFICode N X X Specifies the CFICode of the desired

instruments. Please refer to ANNA CFI &
ISO 10962 for details on how to use this
field (http://www.anna-
web.org/index.php/home/cfiaiso10962/).
(FILTER)
6.4.2 Security List (MsgType = y)

This message is used to relay instrument information, such as insertion, update or deletion. Each
message can contain multiple instruments (default is 15) and clients usually receive multiple
messages in response to each request.
Just after subscribing to security list, the response will come as a series of Security List messages
(35=y), marked with tags 393-TotNoRelatedSym and 893-LastFragment. The customer application
should process all such messages until all securities are received (number of received securities
is equal to the value of tag 393) and the message containing tag 893-LastFragment equal to “Y” is
received.
There is a maximum limit of subscriptions that can be held simultaneously. This limit is configured
by the Market Surveillance, but it should be reasonable enough for customers to maintain several
subscriptions without degrading server performance.
Updates to any security will be sent out to customers on separate Security List messages (35=y)
in an ad-hoc fashion, carrying a single security per message. In this case the Security List message
will not carry request related tags such as 320-SecurityReqID, 560-SecurityRequestResult, 393-
TotNoRelatedSym and 893-LastFragment.
TAG FIELD NAME REQ EQ DER COMMENTS

Message Header Y X X MsgType=y
320 SecurityReqID C X X Echoed back from the
Security List Request
message that caused this
message to be sent. Always
sent when this message is a
reply to a Security List
Request.
322 SecurityResponseID C X X Unique ID of this message,
generated by UMDF PUMA
Conflated. Only sent when
this message is a response
to a Security List Request.
560 SecurityRequestResult C X X The results returned to the
Security List Request
message. Always sent when
this message is a reply to a
Security List Request.
Values issued by UMDF
PUMA Conflated: (also used
to confirm unsubscription)
0= Valid request
1 = Invalid or unsupported
request
6 = Duplicate SecurityReqID
© B3
23
M = Maximum number of
subscriptions exceeded
393 TotNoRelatedSym C X X Total number of securities

being returned for this
request. Always sent when
this message is a reply to a
Security List Request.
893 LastFragment C X X Indicates whether this
message is the last in the
sequence of messages
requested. Not sent by
default.
Valid values:
Y = Last message
146 NoRelatedSym C X X Specifies the number of
repeating instruments
specified. Not sent if this
message is reporting an error
(tag 560 > 0).
➔ 55 Symbol Y X X Instrument symbol
➔ 48 SecurityID Y X X Unique instrument id.
➔ 22 SecurityIDSource Y X X Security ID qualifier.
➔ 207 SecurityExchange Y X X Market to which the
instrument belongs.
➔ 1141 NoMDFeedTypes Y X X Number of MD Feed Types.
➔ ➔ 1022 MDFeedType Y X X Indicates feed type as
standard or implied. Not sent
for MBO.
Valid values:
STD = Standard MBP
IMP = Implied MBP (not
used)
➔ ➔ 264 MarketDepth Y X X Identifies the number of
depth levels of the book.
➔ ➔ 1021 MDBookType Y X X Used to request a specific

type of book updates when
subscribing. If not sent means
to subscribe for all available
book types.
Valid Values:
2 = Price Depth
3 = Order Depth
➔ 201 PutOrCall C X X Indicates whether an option
contract is a put or call.
➔ 454 NoSecurityAltID C X X Number of alternate security
identifiers.
➔ ➔ 455 SecurityAltID C X X Security Alternate identifiers
for this security
➔ ➔ 456 SecurityAltIDSource C X X Identifies class or source of
the SecurityAltID (455) value.
Required if SecurityAltID is
© B3
24
specified. Values issued by

UMDF PUMA Conflated:
8= ExchangeSymbol
4= ISIN Number
H= Clearing
house/organization
➔ 460 Product Y X X Indicates the type of product
the security is associated
with.
Valid Values:
2 = COMMODITY
3 = CORPORATE
4 = CURRENCY
5 = EQUITY
6 = GOVERNMENT
7 = INDEX
15 = ECONOMIC
INDICATOR
16 = MULTILEG
➔ 461 CFICode Y X X Classification of Financial

Instruments (CFI code)
values, which indicate the
type of security using ISO
10962 standard.
➔ 1151 SecurityGroup Y X X Indicates the group this
instrument belongs to.
➔ 167 SecurityType Y X X Valid Values (Corporate
Fixed Income):
- ETF (Exchange Traded
Fund)
- CORP (Corporate)
Valid Values (Derivatives and

FX):
- FUT (Futures)
- DTERM (Derivative
Forward or “Termo”)
Valid Values (Equities):

- OPT (Option)
- FORWARD (Equity
Fund)
- INDEX (Non Tradeable
index)
- OPTEXER (Option
Exercise)
- MLEG (Multileg Instrument,
UDS)
- CS (Common Stock)
© B3
25
- SECLOAN (Security loan,
or BTB)
- INDEXOPT (Option on
Index)
➔ 762 SecuritySubType Y X X
The sub type of the instrument.
Values for derivatives/FX:

4 - FX spot
10 - Gold
20 - Index
30 - Interest rate
40 - FX rate
50 - Foreign debt
60 - Agricultural
70 - Energy
80 - Economic Indicator
90 - Strategy
100 - Future-style Option
110 - Volatility
120 - Swap
130 - MiniContract
140 - Financial RollOver
141 - Agricultural RollOver
142 – Stock RollOver
150 – Target Rate
190 - Carbon credit
Values for equities:

1001 - Ordinary Rights (DO)
1002 - Preferred Rights (DP)
1003 - Common Shares (ON)
1004 - Preferred Shares (PN)
1005 - Class A preferred
shares (PNA)
1006 - Class B preferred
shares (PNB)
1007 - Class C preferred
shares (PNC)
1008 - Class D preferred
shares (PND)
1009 - Ordinary Receipts (ON
REC)
1010 - Preferred Receipts (PN
REC)
1100 - Common Forward
1101 - Flexible Forward
1102 - Dollar Forward
1103 - Index Points Forward
1104 - Non-tradable ETF Index
1105 - Predefined Covered
Spread
1106 - Tradable ETF
1107 - Non-tradable Index
1108 - User defined spread
1109 - Exchange defined
spread (not currently in use)
1110 - Security Loan
1111 - Tradable Index
1112 - Brazilian Depositary
Receipt
1113 - Fund
1114 - Other Receipt
© B3
26
1115 - Other Right

1116 - UNIT
1117 - Class E Preferred Share
(PNE)
1118 - Class F Preferred Share
(PNF)
1119 - Class G Preferred Share
(PNG)
1120 - Warrant
1122 - Non-tradable Security
Lending
1123 - Foreign Index ETF
1125 - Government ETF
1126 - IPO or Follow on
1127 - Gross Auction
1128 - Net Auction
1129 - Tradable Index in
Partnership
1130 - Nontradable Index in
Partnership
1999 – Others
Values for corporate fixed

income:
1106 - Tradable ETF
1124 - Fixed Income ETF
1131 - Nontradable Fixed
Income ETF
1300 - Outright purchase
1301 - Specific collateral repo
1302 - Debenture
1303 - Real State Receivable
Certificate
1304 - Agribusiness
Receivable Certificate
1305 - Promissory Note
1306 - Letra Financeira
1307 - American Depositary
Receipt
1308 - Unit Investment Fund
1309 - Receivable Investment
Fund
1310 - Outright T+1
1311 - Repo T+1
1312 - Non-tradable gross
settlement
1313 - Non-tradable net
settlement
1314 - ETF Primary Market
1316 - Shares Primary Market
1317 - Rights Primary Market
1318 - Unit Primary Market
1319 - Fund Primary Market
1320 - Foreign Index ETF
Primary Market
1321 - Warrant Primary Market
1322 - Receipt Primary Market
2002 - German Public Debts
➔ 200 MaturityMonthYear C X X Month and year of the
maturity (for futures and
options).
Required for Futures and
Options.
© B3
27
➔ 541 MaturityDate C X X Date of instrument maturity.

For all but Spot and
Forwards.
➔ 225 IssueDate Y X X The date which the security
is issued/activated.
➔ 470 ContryOfIssue Y X X ISO country code of
instrument issue.
➔ 202 StrikePrice C X X Strike price of option.
Required if an Option
➔ 947 StrikeCurrency C X X Currency of option’s strike
price.
Required if an Option.
➔ 1194 ExerciseStyle C X X Type of exercise of a
derivatives security.
➔ 231 ContractMultiplier C X Specifies the ratio or
multiply factor to convert
from “nominal” units (e.g.
contracts) to total units (e.g.
shares) (e.g. 1.0, 100, 1000,
etc).
➔ 107 SecurityDesc Y X X Descriptive string of the
security
➔ 667 ContractSettlMonth C X X Specifies when the contract
will settle.
➔ 873 DatedDate C X X The date of the security
activation, if different from
the IssueDate.
➔ 916 StartDate N X Start date of a financing
deal, i.e. the date the buyer
pays the seller cash and
takes control of the
Collateral.
➔ 63 SettlType C X X
Indicates order settlement
period using:
Dx = FX tenor expression for

“days” where “x” is any
integer > 0.eg. D5
➔ 64 SettlDate C X X Specific date of trade

settlement. Format is
YYYYMMDD. If present this
field overrides SettlType (63).
➔ 917 EndDate N X End date of a financing deal,
i.e. the date the seller
reimburses the buyer and
takes back control of the
collateral.
➔ 37012 PriceDivisor C X Value that divides the Price
field to produce the actual
order price (based on Step of
Quotation). (e.g. 1, 100,
1000, etc).
© B3
28
➔ 980 SecurityUpdateAction Y X X When sent as a request

response will always carry
“M”.
Valid values:
A = Add
D = Delete
M = Modify
➔ 969 MinPriceIncrement C X X Number of minimum tick
increments
➔ 5151 TickSizeDenominator C X X Number of decimals, used for
pricing this instrument, e.g.
price = 0.001, decimals = 3.
➔ 9749 MinOrderQty C X X Minimum quantity of an order
for the security.
➔ 9748 MaxOrderQty C X X Maximum quantity of an
order for the security.
➔ 870 NoInstrAttrib C X X Number of repeating
InstrAttribType entries.
➔ ➔ 871 InstrAttribType C X X Code to represent the type of

instrument attributes.
Valid values:
24 = Trade type eligibility
details for security.
34 = Eligibility for GTD/GTC
➔ ➔ 872 InstrAttribValue C X X Attribute value appropriate to

the InstrAttribType (871)
field.
Valid values for 871=24:

1 = Electronic Match Eligible
3 = Block Trade Eligible
17 = Negotiated Quote
Eligible
Valid values for 871=34:

1 = GTD/GTC Eligible
➔ 711 NoUnderlyings C X X Number of underlying

instruments.
➔ ➔ 311 UnderlyingSymbol Y X X Underlying instrument’s

ticker symbol.
Conditionally required if
NoUnderlyings > 0.
➔ ➔ 309 UnderlyingSecurityID Y X X Underlying instrument’s
security identifier.
NoUnderlyings > 0.
➔ ➔ 305 UnderlyingSecurityIDSource Y X X Qualifier for underlying

instrument’s security ID.
Valid Values:
© B3
29
8 = Exchange Symbol
➔ ➔ 308 UnderlyingSecurityExchange Y X X Underlying instrument’s

exchange.
Valid Values:
BVMF
➔ ➔ 6919 IndexPct C X Used to provide % of each
Equity in Index Calculation
➔ ➔ 37021 IndexTheoreticalQty C X The theoretical quantity of
this underlying belonging to
an index.
➔ 15 Currency C X X Currency used for the price
➔ 120 SettlCurrency C X X Currency used for the
settlement
➔ 6937 Asset N Asset associated with the
security , such as DOL, BGI,
OZ1, WDL, CNI, etc.
➔ 7595 NoSharesIssued C X X Social Capital – Total
number of shares issued for
Cash Equity Instrument
➔ 7534 SecurityStrategyType C Strategy type definition.
Required for strategy
instruments.
➔ 6938 SecurityValidityTimestamp Y X X Indicates the UTC timestamp
when trading for this security
expires, i.e. when it is not
eligible to trade anymore.
➔ 1205 NoTickRules C Number of tick rules. This
block specifies the rules for
determining how a security
ticks, i.e. the price
increments which it can be
quoted and traded,
depending on the current
price of the security
For future use.
➔ ➔ 1206 StartTickPriceRange C Starting price range for
specified tick increment
For future use.
➔ ➔ 1207 EndTickPriceRange C Ending price range for the
specified tick increment
For future use.
➔ ➔ 1208 TickIncrement C Tick increment for stated
price range. Specifies the
valid price increments which
a security can be quoted and
traded
For future use.
➔ ➔ 1209 TickRuleType C Specifies the type of tick rule
which is being described
For future use.
➔ 555 NoLegs C X X Number of instrument legs.
➔ ➔ 600 LegSymbol C X X Leg symbol.
© B3
30
NoLegs > 0.
➔ ➔ 602 LegSecurityID C X X Unique identifier for the
instrument leg, as per
LegSecurityIDSource.
NoLegs > 0.
➔ ➔ 603 LegSecurityIDSource C X X Qualifier for tag

LegSecurityID.
NoLegs > 0.
Valid Values:
8 = Exchange Symbol
➔ ➔ 623 LegRationQty C X X Ratio of the individual leg

relative to the entire security
➔ ➔ 609 LegSecurityType C X X Indicates the type of the
individual leg
Valid Values (Corporate

Fixed Income):
Fund)
- CORP (Corporate)
Valid values (derivatives):

- FUT (Futures)
- DTERM (Derivative
Forward markets, or
“Termo”)
Valid values (equities):

- CS (Common Stock)
- FORWARD (Equity
Fund)
- OPT (Option)
- INDEX (Non Tradeable
index)
- OPTEXER (Option
Exercise)
- MLEG (Multileg Instrument)
- SECLOAN (Security loan,
or BTB)
- INDEXOPT (Option on
Index)
© B3
31
➔ ➔ 624 LegSide C X X The side of this individual leg

(multi-leg security).
NoLegs > 0.
Valid Values:
1 = Buy
2 = Sell
➔ ➔ 616 LegSecurityExchange C X X Exchange code the leg

security belongs to.
NoLegs > 0.
Valid Values: BVMF
➔ 1300 MarketSegmentID C X Identifies the Market
Segment ID (for list orders)
➔ 37010 CorporateActionEventID C X Unique numeric identifier for

a corporate action event
associated with the security.
The identifier is unique
within the security.
Note. This tag does not
represent the type of the
Corporate Action.
➔ 37011 GovernanceIndicator C X Corporative governance
level indicator.
Valid Values:
N1 = Level 1
N2 = Level 2
N3 = Level 3
NM = New Market
MA = MAIS Market
MB = SOMA Market
M2 = MAIS 2 Market
➔ 37015 SecurityMatchType N X Type of matching that

occurred.
Required for Special
Auctions
Valid values:
8 = Issuing/Buy Back
Auction
➔ 1234 NoLotTypeRules C X Number of Lot Type Rules
for the instrument
© B3
32
➔ ➔ 1093 LotType C X Defines the lot type for the

instruments.
Valid Values:
1 = Odd Lot
2 = Round Lot
3 = Block Lot
➔ ➔ 1231 MinLotSize(round) C X Minimum lot size allowed

based on lot type specified in
LotType(1093)
➔ 561 RoundLot C X The trading lot size of the
security
➔ 1377 MultiLegModel C X Used for multileg security
only. Defines whether the
security is pre-defined or
user-defined.
Valid Values:
0 = Predefined Multileg
Security
1 = User-Defined Multileg
Security
➔ 1378 MultiLegPriceMethod C X Used for multileg security
only. Defines the method
used when applying the
multileg price to the legs.
Valid Values: 3 = Individual
➔ 1144 ImpliedMarketIndicator C Indicates that an implied
market should be created for
either the legs of a multi-leg
instrument (Implied-in) or for
the multi-leg instrument
based on the existence of the
legs (Implied-out).
This tag is reserved for
future use.
Valid values:
0 = Not implied (default)
Message Trailer Y X X
6.5 Market Data Messages

6.5.1 Market Data Request (MsgType = V)
A Market Data Request is a general request for market data for tradable securities in UMDF PUMA
Conflated. A successful Market Data Request is replied by a single Market Data Full Snapshot
message for each instrument that matches the request. Upon receiving one of such messages,
incremental updates (Market Data Incremental Refresh messages) start being generated for
instruments whose snapshots have been already received.
Like on section 6.4.1, the subscription mechanics on UMDF PUMA Conflated, entirely based on
filters, allows subscriptions where the selected filters will result in an empty instrument set. Since
the platform supports online creation of instruments, a subscription that results in an empty set is
perfectly valid (the set can receive new instruments later, during the day). Thus customers
© B3
33
applications must know how to handle 35=W responses containing no instruments (empty
Snapshots).
For instance, one could subscribe to a SecurityGroup that usually contains only UDS instruments,
this group could start the day with no valid instruments, but subscribing to this will guarantee that if
one such instrument is ever created the customer will receive the related incremental messages.
Also, two subscriptions could match instruments previously subscribed; in this case the response
will carry all matched instruments´ snapshots, even if they are repeated. However, incremental
updates (35=X) to them will be relayed only once for each session.
If the repeating group 146-NoRelatedSym is omitted it is assumed that the subscription pertains all
available instruments.
It´s possible to have multiple subscriptions using different filtering tags, providing the customer
sends different values for tag 262-MDReqID. For example, to subscribe to both Price depth and
Order depth books it´s necessary to send two subscriptions.
There is a maximum limit of subscriptions that can be held simultaneously. This limit is configured
by the Market Surveillance, but it should be reasonable enough for customers to maintain several
subscriptions without degrading server performance.
To cancel a subscription, tag 262-MDReqID must match another value used in a previous
subscription. After a successful cancelation of subscription, no confirmation messages will be
received (A 35=Y is still generated in case of failure).
IMPORTANT
Since the new subscription policy is based on filters, it´s always mandatory for each
request to have at least one filter. This implies that to subscribe to all market data
one will have to hold many simultaneous subscriptions.
Tag Tag Name RE EQ DER Comment

Q
Message Header Y X X MsgType = V
262 MDReqID Y X X Must be unique, or the ID of previous Market
Data Request to disable if
SubscriptionRequestType = Disable previous
Request (2).
263 SubscriptionRequestTyp Y X X Indicates what type of response is expected.
e
Valid values:
1 = Snapshot + Updates (Subscribe)
2 = Disable previous Request (Unsubscribe)
1021 MDBookType Y X X Used to request a specific type of book updates
when subscribing.
Valid Values:
2 = Price Depth
3 = Order Depth
© B3
34
146 NoRelatedSym N X X Number of instruments requested.
➔ 48 SecurityID Y X X Unique instrument id. (FILTER)

➔ 20 SecurityExchange Y X X Market to which the instrument belongs.
7
167 SecurityType N X X Indicates type of security. (FILTER)
Valid Values (Fixed Income):

- CORP (Corporate)
Valid values (derivatives):

- FUT (Futures)
- DTERM (Derivative Forward markets, or
“Termo”)
Valid values (equities):

- CS (Common Stock)
- FORWARD (Equity Forward or “Termo”)
- OPT (Option)
- INDEX (Non Tradeable index)
- OPTEXER (Option Exercise)
- MLEG (Multileg Instrument)
- SECLOAN (Security loan, or BTB)
- INDEXOPT (Option on Index)
37022 NoSecurityGroups N X X Number of SecurityGroups the customer wants
to subscribe.
➔ 1151 SecurityGroup Y X X The quotation group the client wants to

subscribe to. Required when 37022 > 0.
(FILTER)
461 CFICode N X X Classification of Financial Instruments (CFI
code) values, which indicate the type of security
using
the ISO 10962 standard. (FILTER)
460 Product N X X Indicates the type of product the security is
associated with. (FILTER)
2 = COMMODITY
3 = CORPORATE
4 = CURRENCY
5 = EQUITY
6 = GOVERNMENT
7 = INDEX
15 = ECONOMIC INDICATOR
16 = MULTILEG
© B3
35
6.5.2 Market Data Request Reject (MsgType = Y)

The Market Data Request Reject will be issued by UMDF PUMA Conflated when it is not able to
handle the Market Data Request, due to business or technical reasons.
Tag Tag Name REQ EQ DE Comment

R
MsgHeader Y X X MsgType = Y
58 Text N X X Descriptive text of reason for rejection
262 MDReqID Y X X Echoes back the ID of Market Data
Request message that triggered this
rejection.
281 MDReqRejReason Y X X Reason for the rejection of a Market
Data request.
Valid values:
1 = Duplicate MDReqID
3 = Insufficient permissions
4 = Unsupported
SubscriptionRequestType
T = Processing of prior request in
progress
M = Maximum number of
subscriptions exceeded
Y = MDReqID not found (attempt to
cancel an unknown subscription
request)
Z = Invalid request
6.5.3 Market Data Snapshot/Full Refresh (MsgType = W)

The Market Data Snapshot/Full Refresh messages are sent as the response to a Market Data
Request message. The message refers to only one Market Data Request. It will contain the
appropriate MDReqID tag value to correlate the request with the response.
Tag Tag Name REQ EQ DER Comment

Message Header Y X X MsgType = W
262 MDReqID Y X X Echoed back from the
Market Data Request
message.
911 TotNumReports N X X Total number of
snapshots to be returned.
893 LastFragment N X X Indicates whether this
default.
Valid values:
Y = Last message
© B3
36
75 TradeDate N X X Used to specify the

trading date which a set of
market data applies for, in
YYYYMMDD format.
Absence of this field
indicates current day
(expressed in local time in
the place of trade).
[ Instrument identification block ]
See Section “Instrument Identification Block” for tag values
268 NoMDEntries Y X X Number of entries

following.
➔ 269 MDEntryType Y X X Type Market Data entry.
Valid values:
0 = Bid
1 = Offer
2 = Trade
3 = Index Value*
4 = Opening Price
5 = Closing Price
6 = Settlement Price
7 = Trading Session High
Price
8 = Trading Session Low
Price
9 = Trading Session
VWAP Price
A = Imbalance
J = Rebuild Book
g = Price Band
h = Quantity Band
B = Trade Volume
C = Open Interest
D = Composite
Underlying Price
c = Security trading state/
phase
v = Volatility price
➔ 270 MDEntryPx C X X Price of the MD entry.
the MD entry relates to a
price.
➔ 15 Currency C X X Identifies the currency of
the MDEntryPx
➔ 271 MDEntrySize C X X Quantity represented by
the Market Data Entry.
Conditionally required
when MDEntryType = Bid
(0), Offer (1), Trade (2) or
Opening Price (4).
© B3
37
➔ 272 MDEntryDate Y X X Date of Market Data

Entry.
➔ 273 MDEntryTime Y X X Time of Market Data
Entry, up to milliseconds
(hhmmssSSS).
➔ 274 TickDirection C X X Direction of the price tick.
reporting a Trade. Valid
values:
0 = Plus Tick
1 = Zero-Plus Tick
2 = Minus Tick
3 = Zero-Minus Tick
➔ 336 TradingSessionID C X X Used to mark Non-
Regular Session trades.
If it is not present the
default value is “1”
(Regular Day Session).
Valid values:
1= Regular Day Session
6= Non Regular Session
➔ 625 TradingSessionSubID C X X Identifier for the trading
phase. Conditionally
required when
MDEntryType=’c’. If
absent the default value is
17 = Open.
Valid Values:
02 = Trading halt (Pause)
04 = No-Open (Close)
17 = Ready to trade
(Open)
18 = Not available for
Trading (Forbidden)
21 = Pre-Open (Reserved)
➔ 276 QuoteCondition N X X Space-delimited list of
conditions describing a
quote.
Valid values:
“R” = Retransmission of
the order
“K” = Implied Price
➔ 277 TradeCondition N X X For optional use in
reporting
Trades/Imbalance. Space
delimited list of conditions
describing a
trade/imbalance.
© B3
38
Valid values:
R = Opening Price
X = Crossed
L = Last Trade at the Same
Price Indicator
P = Imbalance more
buyers
Q = Imbalance more
sellers
U = Exchange Last
3 = Multi Asset Trade
(Termo Vista)
1 = Leg trade
2 = Marketplace entered
trade (trade on behalf)
RL = RLP Trade
➔ 286 OpenCloseSettlFlag C X X Identifies if the opening
price in field MDEntryPx
represents a theoretical
opening price and
applicable to describe
when the settlement data
are related to.
Valid values:
0 = Daily open/Close
settlement entry
1 = Session Open/Close
settlement entry
4 = Entry from previous
business day
5 = Theoretical settlement
entry
➔ 432 ExpireDate C X Date of order expiration
(last day the order can
trade), always expressed
in terms of the local market
date.
➔ 287 SellerDays N X Specifies number of days
that may elapse before
delivery of security.
➔ 37 OrderID C X X Unique identifier for Order
as assigned by the
exchange, maps to the
SecondaryOrderID field in
the Execution Report
message for the
derivatives market (for the
FX market, it is the actual
OrderID). Required for
© B3
39
Bids or Offers for market

by order.
➔ 288 MDEntryBuyer N X X For optional use in
reporting trades (buying
party) or indicating a new
bid entry.
Note: not sent for MBP
book messages.
➔ 289 MDEntrySeller N X X For optional use in
reporting trades (selling
offer entry.
book messages.
➔ 346 NumberOfOrders C X X Number of orders at this
price level.
➔ 290 MDEntryPositionNo C X X Display the position of a
bid or offer, numbered
from the most competitive
to the least competitive,
per market side, beginning
with 1. Conditionally
required when
MDEntryType = 0 or 1 (Bid
or offer)
➔ 326 SecurityTradingStatus C X X Identifier for the security
trading status.
when MDEntryType=’c’. If
absent the default value is
17 = Open.
Valid Values:
17 = Ready to trade
(Open)
18 = Not available for
Trading (Forbidden)
20 = unknown or invalid
➔ 342 TradSesOpenTime C X X Indicates the time the
auction is scheduled to
end. Conditionally
required when
MDEntryType=’c’ and
SecurityTradingStatus=21.
➔ 423 PriceType C X X Code to represent the
price type. If it is not
present the default value
is “2” (Per unit).
© B3
40
Valid Values:
1=percentage
2=per unit (i.e. per share
or contract)
3=fixed amount (absolute
value)
➔ 451 NetChgPrevDay C X X Net change from previous
trading day’s closing price
vs. last traded price
(offshore currency).
➔ 711 NoUnderlyings C X This group is
conditionally required for
269=D, Index Composite
Entry Type.
Number of repeating
groups is based on Index
Composite.
➔ ➔ 309 UnderlyingSecurityID Y X Underlying instrument’s
NoUnderlyings > 0.
➔ ➔ 305 UnderlyingSecurityIDSource Y X Qualifier for underlying
instrument’s securityID.
Valid Values:
8 = Exchange Symbol
➔ ➔ 308 UnderlyingSecurityExchange Y X Underlying instrument’s
exchange.
Valid Values:
BVMF
➔ ➔ 810 UnderlyingPx Y X Underlying instrument
price reflected in Index
value.
➔ ➔ 37018 UnderlyingPxType Y X Indicates the Underlying
Instrument price type
refelected in Index value.
Valid Values:
0 = Trade (default)
1 = Average of TOB
➔ 731 SettlPriceType C X X Type of settlement price:
1=final
2=theoretical/preview
3=updated
➔ 1003 TradeID C X X Contains the unique
identifier for this trade per
instrument + trading date,
as assigned by the
exchange. Required if
reporting a Trade.
➔ 1020 TradeVolume N X X Total traded quantity
(shares/contracts) of the
trading day. It could be
© B3
41
present only in the Trade

(269=2) and Trade Volume
(269=B) blocks.
➔ 1021 MDBookType C X X Required for book related
messages. Not used for
statistics and trades.
Valid Values:
1 = Top of Book (not

available)
2 = Price Depth
3 = Order Depth
➔ 1140 MaxTradeVol C X The maximum order
quantity that can be
submitted for a security.
The value is the minimum
between % of shares
issued and % of average
traded quantity within 30
days.
➔ 1025 FirstPx C X The price for the short
future on a volatility price
(269=v).
➔ 31 LastPx C X The price for the long
future on a volatility price
(269=v).
➔ 811 PriceDelta C X The rate of change in the
price of a derivative with
respect to the movement
in the price of the
underlying instrument(s)
upon which the derivative
instrument price is based.
Only used for 269=v
(Volatility price).
This value is normally
between -1.0 and 1.0.
➔ 1148 LowLimitPrice N X X Allowable low limit price
for the trading day. A key
parameter in validating
order price. Used as the
lower band for validating
order prices. Orders
submitted with prices
below the lower limit will
be rejected.
➔ 1149 HighLimitPrice N X X Allowable high limit price
for the trading day. A key
parameter in validating
order price. Used as the
upper band for validating
© B3
42
order prices. Orders

submitted with prices
above the upper limit will
be rejected.
➔ 1150 TradingReferencePrice C X Reference price for the
current trading price range.
The value may be the
settlement price or closing
price of the prior trading
day. Sent only for
Economic Indicators.
➔ 1174 SecurityTradingEvent N X X Identifies an event related
to a
TradingSessionSubID.
Possible value:
4 – Reset Statistics
101 – Security Status
separated from Group
Phase
102 – Security Status
following Group Phase
➔ 1306 PriceLimitType N X X Indicates if price value is
expressed in tick,
percentage, or actual price
terms.
This tag not sent for 269=g
for economic indicator.
Valid Values:
0=price
1=ticks
2=percentage
➔ 1500 MDStreamID N X X The identifier or name of
the price stream. The
default value is “E”
(Electronic).
Valid Values:
E = Electronic
X - Ex-pit
T = Termo
O = Option Exercise
(E&B)
N = Index
L = Lending (BTB)
A = All
➔ 6939 PriceBandType C X X Indicates type of price
banding.
Valid Values:
1= Hard Limits
2= Auction Limits
3= Rejection Band
© B3
43
4= Static Limits
➔ 9325 LastTradeDate C X Date the instrument last
traded.
Used as an input in the
calculation of the
MaxTradeVol and used to
trigger an Auction. Not
published if the product has
never been traded.
Published as part of
Adjusted Closing Price
block 269=5 286=4.
➔ 37003 AvgDailyTradedQty C X Daily average shares
traded within 30 days –
equity market only.
Previously known as
DailyAvgShares30D.
➔ 37008 PriceBandMidpointPriceType C X X Band Midpoint Type, used
with Auction Price
Banding
Valid Values:
0 = Last Traded Price
(default)
1 = Complementary Last
Price
2 = Theoretical Price
➔ 37013 PriceAdjustmentMethod C X Indicator of previous day´s
closing price.
Valid Values:
0 = no adjustment (default)
1= Theoretical price of EX
share.
2 = Theoretical price of EX
share when greater than
WITH price.
share, resulting from
dividends in different types
of stocks/companies.
4 =Price arbitrated by
Market Authority
➔ 37014 MDEntryInterestRate C X Interest Rate of the Termo
Trade Expressed in
decimal form. For
example, 1% points is
expressed and sent as
0.01. One basis point is
represented as 0.0001.
➔ 37016 MDInsertDate N X X The date when the order
was inserted or re-
© B3
44
inserted into the order

book or manually altered
by MktOps
➔ 37017 MDInsertTime N X X The time when the order
was inserted or re-
inserted into the order
book or manually altered
by MktOps, The time is
expressed up to
milliseconds
(hhmmssSSS).
➔ 37019 EarlyTermination C X Indicates if the deal is
subject to anticipated
liquidation (early
termination of the
borrowing/lending). Used
for BTB instruments only.
Valid values:
0 = Normal termination
(default)
1 = Early termination
2 = Early termination also
in case of PTO
➔ 37023 BTBCertIndicator C X Indicates if the security
lending offer or pre-
contract is certified.
If not sent, means the offer
or pre-contract is not
certified.
Used for BTB instruments
only.
Valid values:
0 = Certified (default)
1 = Not certified
➔ 37024 BTBContractInfo C X Denotes extra information
about the BTB pre-
contract.
only.
Valid values:
1 = pre-contract (default)
2 = intention
➔ 37025 BTBGraceDate C X Indicates the minimum
date from when the
borrower can call the loan
contract to an end. Used
for BTB instruments only.
➔ 37100 IndexSeq C X Index Value Sequence.
Message Trailer Y X
© B3
45
6.5.4 Market Data Incremental Refresh (MsgType = X)

After a subscription for Market Data messages succeeded and the Market Data Snapshot/Full
Refresh has been issued, further updates will be communicated to the subscriber via the Market
Data Incremental Refresh message. These messages will be sent until the client institution cancels
the subscription with a Market Data Request with SubscriptionRequestType=2.

Message Header Y X X MsgType = X
75 TradeDate N X X Used to specify the trading
date which a set of market
data applies for, in
YYYYMMDD format.
Absence of this field
indicates the current day
(expressed in the local time
of the place of the trade).
1021 MDBookType N X X Required for book related
messages. Not used for
statistics and trades.
Valid Values:
1 = Top of Book (not

available)
2 = Price Depth
3 = Order Depth
268 NoMDEntries Y X X Number of entries following.
➔ 279 MDUpdateAction Y X X Type of Market Data update
action. Valid values:
0 = New
1 = Change
2 = Delete
3 = Delete Thru
4 = Delete From
➔ 15 Currency C X X Identifies the currency of the
MDEntryPx
➔ 37 OrderID C X X Unique identifier for Order as
assigned by the exchange,
maps to the
SecondaryOrderID field in
the Execution Report
message for the derivatives
market (for the FX market, it
is the actual OrderID).
Required for Bids or Offers
for market by order.
➔ [ Instrument identification block ]
Valid values:
0 = Bid
© B3
46
1 = Offer
2 = Trade
3 = Index Value*
4 = Opening Price
5 = Closing Price
6 = Settlement Price
7 = Trading Session High
Price
8 = Trading Session Low
Price
9 = Trading Session VWAP
Price
A = Imbalance
J = Rebuild Book
g = Price Band
h = Quantity Band
B = Trade Volume
C = Open Interest
D = Composite Underlying
Price
v = Volatility Price
➔ 270 MDEntryPx C X X Price of the Market Data
Entry. Required when this
market data entry involves a
price. Represents the
notional value for trade
volume (B). Other entry types
that do not involve price do
not require this tag.
➔ 271 MDEntrySize C X X Quantity or volume
represented by the Market
Data Entry. Required when
MDUpdateAction = New (0)
and MDEntryType = Bid (0),
Offer (1), Trade (2), Trade
Volume (B) or Opening Price
(4).
➔ 272 MDEntryDate Y X X Date of Market Data Entry.
➔ 273 MDEntryTime Y X X Time of Market Data Entry,
up to milliseconds
(hhmmssSSS).
Used as part of a trade
message.
Ex. Order price sequence 90,
100, 100 will have 274=1
Valid values:
0 = Plus Tick
1 = Zero-Plus Tick
2 = Minus Tick
© B3
47
3 = Zero-Minus Tick
➔ 276 QuoteCondition N X X Space-delimited list of

conditions describing a
quote.
Valid values:
“R” = Retransmission of the
order
“K” = Implied Price
➔ 277 TradeCondition N X X For optional use in reporting
describing a
trade/imbalance.
Valid values:
R = Opening Price
X = Crossed
L = Last Trade at the Same
Price Indicator
P = Imbalance more buyers
Q = Imbalance more sellers
U = Exchange Last
3 = Multi Asset Trade (Termo
Vista)
1 = Leg trade
RL = RLP Trade
➔ 286 OpenCloseSettlFlag C X X Identifies if the opening price
in field MDEntryPx
opening price and applicable
to describe when the
settlement data are related
to. Valid values issued by
BVMF:
settlement entry
settlement entry
business day
5 = Theoretical settlement
entry
© B3
48
➔ 287 SellerDays N X Specifies the number of days

that may elapse before the
delivery of the security. Only
used for some types of trades
in the forward market.
➔ 288 MDEntryBuyer N X X For optional use in reporting
trades (buying party) or
indicating a new bid entry.
Note: not sent in FX
messages (blind screen).
➔ 289 MDEntrySeller N X X For optional use in reporting
trades (selling party) or
indicating a new offer entry.
Note: not sent in FX
messages (blind screen).
➔ 290 MDEntryPositionNo C X X Display the position of a bid
or offer, numbered from most
competitive to least
competitive, per market side,
beginning with 1.
Conditionally required when
MDEntryType=0 or 1 (Bid or
Offer).
➔ 336 TradingSessionID C X X Identifier for Trading
Session. Used on Non-
Regular Trading Session
messages only. If it is not
present the default value is
“1” (Regular Session).
Valid values:
1= Regular Day Session
6 = Non Regular Session
(After Hours)
➔ 346 NumberOfOrders C X X Contains the number of
orders that make up the
aggregate quantity at the
price point. Required if this is
a price-depth book entry.
➔ 423 PriceType C X X Code to represent the price
type (applicable to settlement
data). The default value is “2”
(Per unit).
Valid values:
1 – Percentage
2 – Per unit (i.e. per share or
contract)
3 – Fixed amount (absolute
value)
© B3
49
➔ 432 ExpireDate C X Date of order expiration (last

day the order can trade),
always expressed in terms of
the local market date.
Used in BTB contracts only.
trading day’s closing price vs.
last traded price (offshore
currency).
➔ 711 NoUnderlyings C X Number of repeating groups

is based on Index
Composition. Only used
when representing Index
Composite Underlying Price
(269=D).
➔ ➔ 309 UnderlyingSecurityID Y X Underlying instrument’s
➔ ➔ 305 UnderlyingSecurityIDSource Y X Qualifier for underlying
instrument’s security ID.
➔ ➔ 308 UnderlyingSecurityExchange Y X Underlying instrument’s
exchange.
➔ ➔ 810 UnderlyingPx Y X Underlying instrument price
reflected in Index value.
➔ ➔ 3701 UnderlyingPxType Y X Indicates the Underlying
8 Instrument price type
reflected in Index value.
Valid values:
0 = Trade (default)
1 = Average of TOB
➔ 731 SettlPriceType C X X Required only for
MDEntryType=6 (Settlement
Price).
Valid values:
1 = Final
2 = Theoretical/Preview
3 = Updated
➔ 1003 TradeID C X X Contains the unique identifier
for this trade per instrument +
trading date, as assigned by
the exchange. Conditionally
required if reporting a Trade.
(269=2) and Trade Volume
(269=B) blocks.
© B3
50
➔ 1140 MaxTradeVol C X The maximum order quantity

that can be submitted for a
security.
The value is the minimum
between % of shares issued
and % of average traded
quantity within 30 days.
➔ 1025 FirstPx C X The price for the short future
on a volatility price (269=v).
➔ 31 LastPx C X The price for the long future
on a volatility price (269=v).
➔ 811 PriceDelta C X The rate of change in the
price of a derivative with
respect to the movement in
the price of the underlying
instrument(s) upon which the
derivative instrument price is
based. Only used for 269=v
(Volatility price).
This value is normally
between -1.0 and 1.0.
➔ 1148 LowLimitPrice N X X Allowable low limit price for
the trading day. A key
parameter in validating order
price. Used as the lower
band for validating order
prices. Orders submitted with
prices below the lower limit
will be rejected.
➔ 1149 HighLimitPrice N X X Allowable high limit price for
the trading day. A key
parameter in validating order
price. Used as the upper
band for validating order
prices. Orders submitted with
prices above the upper limit
will be rejected.
➔ 1150 TradingReferencePrice C X Reference price for the
current trading price range.
The value may be the
settlement price or closing
price of the prior trading day.
Sent only for Economic
Indicators.
➔ 1306 PriceLimitType N X X Describes how the prices are
expressed. The default value
is “0” (Price Unit).
Valid values:
0 = Price Unit
1= Ticks
© B3
51
2 = Percentage
➔ 1500 MDStreamID N X X The identifier or name of the
price stream. The default
value is “E” (Electronic).
Valid Values:
E = Electronic
X - Ex-pit
T = Termo
O = Option Exercise (E&B)
N = Index
L = Lending (BTB)
A = All
➔ 6939 PriceBandType C X X Indicates the type of price
banding (tunnel):
Used for Price Banding when

MDEntryType (269) = g and
when tags 1148 and 1149
are sent.
Valid values:
1= Hard Limit
2= Auction Limits
3= Rejection Band
4= Static Limits
➔ 9325 LastTradeDate C X Date the instrument last
traded.
Used as an input in the
calculation of the
MaxTradeVol and used to
trigger an Auction. Not
published if the product has
never been traded.
Published as part of Adjusted

Closing Price block 269=5
286=4.
➔ 37003 AvgDailyTradedQty C X Daily average shares traded
within 30 days – equity
market only. Previously
known as
DailyAvgShares30D.
➔ 37008 PriceBandMidpointPriceType C X X Band Midpoint Type
Complementary Last Price
(CLAST) follows special rules
described in 3BR6.2.3.1
Used with Auction Price
Banding.
Valid values:
© B3
52
0 = Last Traded Price

(default)
1 = Complementary Last
Price
2 = Theoretical Price
➔ 37013 PriceAdjustmentMethod C X Indicator of previous day´s
closing price.
Used for Closing price

adjustments related to
Corporate Actions.
Valid values:
0 = No adjustment (default)
share.
share when greater than
WITH price.
share, resulting from
dividends in different types of
stocks/companies.
4 = Price arbitrated by Market
Authority
➔ 37014 MDEntryInterestRate C X Interest Rate of the Termo
Trade.
Expressed in decimal form.
For example, 1% points is
expressed and sent as 0.01.
One basis point is
represented as 0.0001.
➔ 37016 MDInsertDate N X X Date when the order was
inserted or re-inserted into
the order book (used for
GTD/GTC orders, only for
equities market).
For PUMA: In Trade (269=2 -
New or Delete) – original
trade date or manually
entered by MktOps
➔ 37017 MDInsertTime N X X The time when the order was
inserted or re-inserted into
the order book or manually
altered by MktOps, up to
milliseconds (hhmmssSSS).
➔ 37019 EarlyTermination C X Indicates if the deal is subject
to anticipated liquidation
(early termination of the
borrowing/lending). Used for
BTB instruments only.
© B3
53
Valid values:
0 = Normal termination
(default)
1 = Early termination
2 = Early termination also in
case of PTO
➔ 37023 BTBCertIndicator C X Indicates if the security
lending offer or pre-contract
is certified.
If not sent, means the offer or
pre-contract is not certified.
only.
Valid values:
0 = Certified (default)
1 = Not certified
➔ 37024 BTBContractInfo C X Denotes extra information
about the BTB pre-contract.
only.
Valid values:
1 = pre-contract (default)
2 = intention
➔ 37025 BTBGraceDate C X Indicates the minimum date
from when the borrower can
call the loan contract to an
end. Used for BTB
instruments only.
➔ 37100 IndexSeq C X Index Value sequence
number. Used only for index
instruments.
6.5.5 Security Status (MsgType = f)

The Security Status message relays trading phase changes of a specific instrument or instrument
group. The client knows by the usage of the Security List message which instruments belong to a
group. The new trading phase is specified in the TradingSessionSubID field.
When tag 1174-SecurityTradingEvent is sent with value “4”, a statistics reset must be performed
by the client, erasing the memory values of the following statistics blocks:
MDEntryType Description
2 Last Trade
3 Index Value
4 Opening Price
4 Theoretical Price (tag 286=5)
7 Trading Session High Price
8 Trading Session Low Price
© B3
54
9 Trading Session VWAP Price

B Trade Volume
The same statistics will no longer be available at the Snapshot message (35=W) for future
subscriptions, upon the receipt of message SecurityStatus (tag 35=f) with SecurityTradingEvent
field (tag 1174) = 4 (Change of Trading Session).

Message Header Y X X MsgType = f
60 TransactTime Y X X Timestamp when the business
transaction represented by the
message occurred.
75 TradeDate Y X X Trade date of the Market Data
messages.
326 SecurityTradingStatus C X X Status related to a given instrument.
Valid values:
17 = Ready to trade (Open)
18 = Not available for trading
(Forbidden)
20 = Unknown or invalid
101 = Final Closing Call
336 TradingSessionID C X Identifier for Trading Session.
Valid values:
1 = Regular Day Session
6 = Non Regular Session (After
Hours)
342 TradSesOpenTime C X X Indicates the time the auction is
scheduled to end.
625 TradingSessionSubID C X X Phase related to a given
SecurityGroup.
Valid values:
17 = Ready to trade (Open)
18 = Not available for trading (Pre-
close)
21 = Pre-Open
101 = Final Closing Call
1151 SecurityGroup C X X The instrument group that is
changing the trading phase.
© B3
55
1500 MDStreamID N X X The identifier or the name of the

market data stream.
If missing, default=E.
Valid values:
E = electronic
A = all
X = ex-pit
S = surveillance
O = option exercise
C = over the counter
S = surveillance
1174 SecurityTradingEvent C X X Identifies an event related to a
TradingSessionSubID.
Possible value:
4 - Change of Trading Session =
Reset Trading Statistics.
101 – Security Status separated
from Group Phase
102 – Security Status following
Group Phase
6.5.6 News (MsgType = B)

The News message is sent to communicate market information.

Message Header Y X X MsgType = B
42 OrigTime N X X Time of message origination.
6940 NewsSource Y X X Indicates the source of the news.
Valid values for derivatives market:

“1” – DCM
“2” – BBMNet
“3” – MarketSurveillance
“4” – Internet
“5” – DPR-VE
”19” – Mkt Ops FX Agency
“20” – Mkt Ops Derivatives Agency
Valid values for equities market:

“11” – Over-the-counter news
agency
”13” – Electronic Purchase
Exchange
”14” – CBLC News Agency
”15” – BOVESPA – Index Agency
© B3
56
”16” – BOVESPA – Institutional

Agency
”17” – Mkt Ops Equites Agency
”18” – BOVESPA – Companies
Agency
1472 NewsID N X X Unique identifier for News message.
Not sent for automated Trading
Engine News messages.
1474 LanguageCode N X X Indicates the language the news is

in. Represented by the two-letter
ISO 639-1 standard identification.
Absence of this field defaults to “pt”
– Portuguese.
148 Headline Y X X The headline of a News message.
358 EncodedHeadlineLen N X X Must be set if EncodedHeadline

field is specified and must
immediately precede it.
359 EncodedHeadline N X X Encoded (non-ASCII characters)
representation of the Headline field
in the encoded format specified via
the MessageEncoding field.
146 NoRelatedSym N X X Specifies the number of repeating
symbols (instruments) specified.
➔ [ Instrument identification block ]
*no changes to this block*
33 NoLinesOfText Y X X Identifies number of lines of text
body.
➔ 58 Text Y X X Free format text string.
➔ 354 EncodedTextLen N X X Length of EncodedText field.
➔ 355 EncodedText N X X Encoded (non-ASCII characters)
representation of the Text (58) field
in the encoded format specified via
the MessageEncoding (347) field.
149 URLLink N X X
A URL (Uniform Resource Locator)
link to additional information
(e.g.
http://www.bvmf.com/news.html)
© B3
57
6.6 Trade History

The trade history functionality allows customer applications to request missing trades and index
values for the current trading day. This means that customers will not be able to recover missing
bid/asks or any book changes using this feature, only trades and indexes values. Each request
must be performed per instrument (since TradeIDs and IndexSeqs are valid per instrument).
When recovering trades/index values, it´s advised to request the latest snapshot for a given
instrument first to obtain the latest value for TradeID (or IndexSeq), as the Snapshot message
(35=W) always contains the last Trade / Index Value (when available).
Using the TradeID / IndexSeq obtained in the Snapshot message (35=W), assemble a request
passing the last known value in tag 7174-StartSequence (or “0” when no previous value was
received).
Please be advised that only up to 1000 trades / index values will be returned per request.
The request can contain a maximum delta between tags 7174 and 7175 of 10000 ids (meaning an
average of 1000 trades, since they are usually issued by increments of 10).
If the last Trade History Response message (35=UTHP) received is the last message (893-
LastFragment = Y) and the TradeID or IndexSeq returned does not match the last value received
in the Snapshot, the customer application should assemble another request using the highest value
received and repeat this process until the last UTHP message contains the requested TradeID /
IndexSeq.
It´s only possible to request data for instruments which a given session has access for.
This feature is meant to recover missing trades/index values only. Customers that
require the recovery of all market data messages for the session, for charting
purposes, are encouraged to use the TCP Historical Replay feature in standard
UMDF PUMA platform.
6.6.1 Trade History Request (MsgType = UTHQ)

Message Header Y X X MsgType = UTHQ
262 MDReqID Y X X
263 SubscriptionReques Y X X Indicates what type of response is expected.

tType Valid values:
0 = Snapshot
146 NoRelatedSym Y X X Number of instruments requested. A maximum of
50 instruments may be specified per request.
➔ 48 SecurityID Y X X Unique instrument id.
➔ 207 SecurityExchange Y X X Market to which the instrument belongs.
© B3
58
➔ 7174 StartSequence Y X X Starting TradeID / IndexSeq for recovery of

trades or index values. If unknown use value = 0
to indicate to recover from the first one available.
➔ 7175 EndSequence Y X X Ending TradeID / IndexSeq for recovery of trades
or index values.
6.6.2 Trade History Response (MsgType = UTHP)

Message Header Y X X MsgType = UTHP
281 MDReqRejReason N X X Reason for the rejection
of a Trade History
request request.
Valid values:
0 = Unknown instrument
3 = Insufficient
permissions
4 = Unsupported
SubscriptionRequestType
T = Processing of prior
request in progress
X = Response temporary
unavailable
Z = Invalid request
262 MDReqID Y X X Echoed back from the
Trade History Request
message.
893 LastFragment N X X Indicates whether this
default.
Valid values:
Y = Last message
See Section “Instrument Identification Block” for tag values.
Always sent, except when a query with no specified instrument is
replied with an empty response.

following.
Valid values:
2 = Trade
3 = Index Value*
➔ 75 TradeDate N X X Used to specify the
trading date which a set
of market data applies
© B3
59
for, in YYYYMMDD
format. Absence of this
field indicates current day
(expressed in local time
in the place of trade).
➔ 270 MDEntryPx C X X Price of the MD entry.
the MD entry relates to a
price.
➔ 271 MDEntrySize C X X Quantity represented by
the Market Data Entry.
when Trade (2) or
Opening Price (4).
➔ 272 MDEntryDate Y X X Date of Market Data
Entry generation.
➔ 273 MDEntryTime Y X X Time of Market Data
Entry generation.
reporting a Trade. Valid
values:
0 = Plus Tick
1 = Zero-Plus Tick
2 = Minus Tick
3 = Zero-Minus Tick
➔ 277 TradeCondition N X X For optional use in
reporting
describing a
trade/imbalance.
Valid values:
R = Opening Price
X = Crossed
L = Last Trade at the
Same Price Indicator
P = Imbalance more
buyers
Q = Imbalance more
sellers
U = Exchange Last
3 = Multi Asset Trade
(Termo Vista)
1 = Leg trade
RL = RLP Trade
© B3
60
➔ 279 MDUpdateAction N X X Type of Market Data

update action. The
default value is 0.
Valid values:
0 = New
1 = Change
2 = Delete
➔ 286 OpenCloseSettlFlag C X X Identifies if the opening

price in field MDEntryPx
opening price and
applicable to describe
when the settlement data
are related to.
Valid values:
settlement entry
settlement entry
business day
5 = Theoretical
settlement entry
➔ 288 MDEntryBuyer N X X For optional use in
reporting trades (buying
bid entry.
book messages.
➔ 289 MDEntrySeller N X X For optional use in
reporting trades (selling
offer entry.
book messages.
➔ 336 TradingSessionID C X X Used to mark Non-
Regular Session trades.
If it is not present the
default value is “1”
(Regular Session).
Valid values:
1= Regular Session
6= Non Regular Session
trading day’s closing
price vs. last traded price
(offshore currency).
© B3
61
➔ 1003 TradeID C X X Contains the unique

identifier for this trade per
instrument + trading date,
as assigned by the
exchange. Required if
reporting a Trade.
(269=2) and Trade
Volume (269=B) blocks.
➔ 1500 MDStreamID N X X The identifier or name of
the price stream. The
default value is “E”
(Electronic).
Valid Values:
E = Electronic
X - Ex-pit
T = Termo
O = Option Exercise
(E&B)
N = Index
L = Lending (BTB)
A = All
➔ 37016 MDInsertDate N X X The date when the trade
was inserted. Only used
for trades (269=2).
➔ 37017 MDInsertTime N X X The time when the trade
was inserted. Only used
for trades (269=2).
➔ 37100 IndexSeq C X Index Value Sequence.
Only available in 269=3
(Index value) blocks.
Message Trailer Y X
6.7 Market Totals

The Market Totals functionality aggregates information regarding total trades on a given market
segment. Currently the system informs the gross traded amount, total number of trades and total
volume traded.
After a successful Logon, the customer application may subscribe / unsubscribe to Market Totals
by sending a 35=UTOTQ message. Currently it´s only possible to subscribe to all Market Totals
instruments at once.
After a successful subscription (replied by a 35=UTOTP message without errors being reported on
tag 281-MDReqRejReason), the system generates one or more 35=UTOTC messages informing
the composition of each Market Totals instrument.
© B3
62
After all 35=UTOTC messages are received, the system starts to periodically send 35=UTOT
messages informing the current totals for each Market Totals instrument.
6.7.1 Market Totals Request (MsgType = UTOTQ)

Message Header Y X X MsgType = UTOTQ
262 MDReqID Y X X Must be unique. When unsubscribing, must be a
MDReqID used previously by this session
263 SubscriptionRequest Indicates what type of response is expected.
Type Valid values:
Y X X 1 = Subscribe
2 = Disable previous subscription
6.7.2 Market Totals Response (MsgType = UTOTP)

Message Header Y X X MsgType = UTOTP
262 MDReqID Y X X Must be unique
281 MDReqRejReason N X X Reason for the rejection of a Market Totals

request. Not sent in case of success.
Valid values:
1 = Duplicate MDReqID
Y = MDReqID not found (attempt to cancel an
unknown subscription request)
6.7.3 Market Totals Broadcast (MsgType = UTOT)

Message Header Y X X MsgType = UTOT
following.
Valid values:
t = Market Total
Broadcast
➔ 55 Symbol Y X X Symbol identifying the

Market Total
➔ 272 MDEntryDate Y X X Date of Market Total
calculation.
➔ 273 MDEntryTime Y X X Time of Market Total
calculation.
➔ 381 GrossTradeAmt Y X X Total amount traded (i.e.
quantity * price)
expressed in units of
currency.
© B3
63
➔ 387 TotalVolumeTraded Y X X Total volume traded.

➔ 6139 TotalNumOfTrades Y X X Total number of trades.
6.7.4 Market Totals Composition (MsgType = UTOTC)

E DE
Tag Tag Name REQ Comment
Q R
Message Header Y X X MsgType = UTOTC
393 TotNoRelatedSym Y X X Total number of Market
Totals instruments being
returned for this request.
893 LastFragment Y X X Indicates whether this
default.
Valid values:
Y = Last message
6107 IndexID N X X The Symbol of the
referred index. Only used
when the Market Totals
refers to one.
146 NoRelatedSym Y X X Specifies the number of
repeating instruments
specified.
➔ 55 Symbol Y X X Symbol identifying the
Market Total
➔ 107 SecurityDesc Y X X Description of the Market
Total.
➔ 37022 NoSecurityGroups Y X X Number of underlying
SecurityGroups.
➔ ➔ 1151 SecurityGroup Y X X Indicates a security group

included in this Market
Total.
6.7.5 Unsupported FIX Messages
Apart from the messages mentioned herein this document, UMDF PUMA Conflated
does not support any other FIX message types.
© B3
64
6.8 Market Data Messages Per Entry Type

6.8.1 Book Updates (269=0,1)
See chapter 5 for more details.
Here are the FIX tags that are associated with book updates repeating groups (X=required,
C=conditional):
Tag Name Values Comments

279 MDUpdateAction “0”,”1”,”2”,”3”,”4”
269 MDEntryType “0”,”1”
48 SecurityID X
22 SecurityIDSource X
207 SecurityExchange X
1500 MDStreamID C “L” - for BTB book
270 MDEntryPx C Not sent for MOA and MOC, or deletes
271 MDEntrySize C Not sent on deletes
432 ExpireDate C Used for BTB contracts only
37019 EarlyTermination C Used for BTB contracts only
37023 BTBCertIndicator C Used for BTB contracts only
346 NumberOfOrders C Always sent on MBP bids and offers
272 MDEntryDate X
273 MDEntryTime X
37016 MDInsertDate C Only sent on MBO bids and offers
37017 MDInsertTime C Only sent on MBO bids and offers
276 QuoteCondition “C”, ”R” “R” – On book retransmission
288 MDEntryBuyer C Sent on bids, but not on MBP or FX, or deletes
289 MDEntrySeller C Sent on offers, but not on MBP or FX, or

deletes
290 MDEntryPositionNo X
37 OrderID C Not sent for MBP or 279=3,4
6.8.2 Book Reset (269=J)

In case of component failure, BVMF will issue a market data incremental message with an entry
type ‘J’ (Book Reset) to notify client systems that a book for specific instrument is corrupted.
© B3
65
Here are the FIX tags sent for such a repeating group (X= required, C=conditional):

279 MDUpdateAction “0”
269 MDEntryType “J”
48 SecurityID X
272 MDEntryDate X
273 MDEntryTime X
6.8.3 Trade (269=2)

The trade data block is sent when a trade occurs to provide volume and trade statistics.
Below is the usage table for tag 277 in this block (X= required) :
Tag 277 Value EQ DER Description
R = Opening Price X X First trade on the session

(also applies to after-
hours session).
X = Crossed X X Cross trade (intentional).
L = Last Trade at the Same Price Indicator X X Indicates the trade uses
the same price as the
previous trade.
U = Exchange Last X X Indicates the trade is

being resent as the last
trade (used on Market
Data Snapshot message
also), this trade should
never be considered as
a new trade.
3 = Multi Asset Trade (Termo Vista) X - Trade generated

automatically when a
Termo Vista had a trade
and was flagged
accordingly.
© B3
66
2 = Marketplace entered trade (trade on behalf) X - Trade entered by the

market surveillance.
1 = Leg trade X - Trade generated

automatically when a User
Defined Strategy (UDS)
had a trade, indicating the
trades on the respective
legs.
RP = RLP Trade X X Trade generated with

Retail Liquidity Provider
order.
Here are the FIX tags sent for a trade repeating group (X= required, C=conditional):

279 MDUpdateAction “0”,”2”
269 MDEntryType “2”
48 SecurityID X
1500 MDStreamID “E”,”T”,“O”
270 MDEntryPx C Not sent for Block Trades (BTF)
271 MDEntrySize X
37014 MDEntryInterestRate C Only sent for Termo trades
272 MDEntryDate X
273 MDEntryTime X
37016 MDInsertDate X
37017 MDInsertTime X
37019 EarlyTermination C Used for BTB instruments only.
37024 BTBContractInfo C Used for BTB instruments only.
37025 BTBGraceDate C Used for BTB instruments only.
274 TickDirection C
277 TradeCondition C
336 TradingSessionID C Sent on NRS trades
288 MDEntryBuyer C Not for FX trades
© B3
67
289 MDEntrySeller C Not for FX trades
451 NetChgPrevDay C Always sent on New Trades
287 SellerDays C Sent for Termo
1020 TradeVolume C Total traded volume for the session (only sent
when 1500=E)
1003 TradeID X
NOTE 1
The last received repeating group MDEntryType (tag 269) = 2 (Trade) does not
mean it is the last traded price. Please per attention to the following fields to
determine the last traded price: MDEntryTime (tag 273) and TradeID (tag 1003).
NOTE 2
When receiving a message with the repeating group whose MDEntryType (tag 269)
= 2 (Trade) and TradeCondition (tag 277) contains U (Exchange Last), it means
that it is not a “real” trade, but only information of the last valid trade. Therefore, the
related repeating group only informs the price and quantity, and not contains other
information like buying and selling parties, trade identification, etc.
6.8.4 Index Value (269=3)

This group of information is only applicable to indexes for equity markets. For this specific
functionality, the following other entry types are valid: 4 (Opening Price), 5 (Closing Price), 6
(Settlement Price), 7 (Trading Session High Price), 8 (Trading Session Low Price), and 9 (Trading
Session Average Price).
Market Data entry type Index Value (3) is used to inform the current value of given index and
described as follows:

279 MDUpdateAction “0”,”1”,”2”
48 SecurityID X
1500 MDStreamID “N”
270 MDEntryPx X The current index point value
© B3
68
37100 IndexSeq X
272 MDEntryDate X
273 MDEntryTime X
274 TickDirection C
6.8.5 Opening Price (269=4)

This repeating group carries the summary information about opening trading session events per
market data stream.
The theoretical opening price is also sent on this block (indicated by the presence of the tag 286-
OpenCloseSettlFlag) and is calculated and updated based on the orders presented in the book
during every auction including the pre-opening / pre-closing auction.
The repeating group is described below (X= required, C=conditional):

48 SecurityID X
1500 MDStreamID “E”,“O”,”N” Not sent for theoretical open
270 MDEntryPx C For theoretical open, represents TOP
271 MDEntrySize C Only sent for theoretical open, as TOQ
37014 MDEntryInterestRate C Only sent for Termo trades
272 MDEntryDate X
273 MDEntryTime X
286 OpenCloseSettlFlag “0”,”5”
451 NetChgPrevDay C Not sent for theoretical open
6.8.6 Closing Price (269=5)

There are two forms of closing prices sent, differentiated by the tag 286-OpenCloseSettlFlag. When
this tag has value “4”, the price refers to the Adjusted Closing Price, also known as “Reference
Price” for Equities.
Summary information about closing trading sessions per market data stream is described below
(X= required, C=conditional):
© B3
69

279 MDUpdateAction “0” Always replace, never delete
48 SecurityID X
1500 MDStreamID “E”,”O”,”T” ,”N”
270 MDEntryPx X
9325 LastTradeDate C Always sent for Adjusted close (286=4)
37013 PriceAdjustmentMethod C Can be sent for Adjusted close (286=4)
272 MDEntryDate X
273 MDEntryTime X
286 OpenCloseSettlFlag “0”,”4” 3 – used for index preliminary close
6.8.7 Trading Session High, Low and VWAP (269=7, 8, 9)

The high trade price data block is sent for a trade event that has produced the highest trade price
for the current session. Likewise, the low trade price data block indicates that a trade event has
produced the lowest trade price for a given session. High, low and Volume-Weighted Average Price
(VWAP) trade prices are helpful in tracking market trends. They also provide historical information
for the current session regarding market behavior.
The FIX message syntax for Session High/Low/VWAP Trade Price repeating groups lie below (X=
required, C=conditional):

269 MDEntryType “7”,”8”,”9”
48 SecurityID X
1500 MDStreamID “E”,”O”,”T”
270 MDEntryPx X
272 MDEntryDate X
273 MDEntryTime X
© B3
70
6.8.8 Auction Imbalance (269=A)

This repeating group carries auction imbalance information, indicating the remaining quantity and
to which side (buyer or seller) the auction is pending towards.
Below is the usage table for tag 277 in this block:
Tag 277 Value EQ DER Description
P = Imbalance more buyers X X Used to indicate that the auction imbalance

pends towards buyers.
Q = Imbalance more sellers X X Used to indicate that the auction imbalance

pends towards sellers.
Here are the FIX tags normally sent for this type of repeating group (X= required, C=conditional):

269 MDEntryType “A”
48 SecurityID X
271 MDEntrySize X Indicates the remaining auction quantity
272 MDEntryDate X
273 MDEntryTime X
277 TradeCondition “P”,”Q”
NOTE
Customer applications are responsible for deleting the existing theoretical opening price and
imbalance information from memory after trading phase changes from Pre-Open (tag 625-
TradingSessionSubID = 21) for each instrument in the group whose trading status is different
from Pre-Open status (tag 326-SecurityTradingStatus = 21).
6.8.9 Price and Quantity Bands (269=g, h)

Most of the information regarding price and quantity tunnels and bands is relayed on the Market
Data for each specific instrument. The following types of bands and limits are now supported:
– Hard limits (269=g|6939=1) – fixed price range that triggers a rejection

– Rejection band (269=g|6939=2) – movable price range that triggers a rejection
© B3
71
– Auction band (269=g|6939=3) – movable price range that triggers an auction

– Static limits (269=g|6939=4) – to enable per-instrument circuit breakers
– Quantity limit (269=h) – restricting maximum match size, or triggering an auction
The Price Band (269=g) group is also used to send the Trading Reference Price for Derivative
instruments.

279 MDUpdateAction “0” Always replace, never delete
269 MDEntryType “g”, “h”
48 SecurityID X
6939 PriceBandType “1”,”2”,”3”,”4” Not sent for reference price and quantity limits
1306 PriceLimitType “0”,”2” Not sent for reference price and quantity limits
1148 LowLimitPrice X
1149 HighLimitPrice X
1150 TradingReferencePrice C Sent as reference price for Economic Indicators

in Derivatives.
37008 PriceBandMidpointPriceType “0”,”1”,”2” Sent for Rejection and Auction Bands
37003 AvgDailyTradedQty C Sent for Quantity Limits
1140 MaxTradeVol C Sent for Quantity Limits
272 MDEntryDate X
273 MDEntryTime X
6.8.10 Trade Volume (269=B)

This repeating group contains information about trade volume or options exercise summary from
the registration system such as financial traded volume (in local and foreign currencies), number
of trading events etc. The full description for the group is below (X= required, C=conditional):

279 MDUpdateAction “0” No delete, always replace
269 MDEntryType “B”
48 SecurityID X
© B3
72
1500 MDStreamID “E”,”O”,“L”,”N”
270 MDEntryPx C Indicates the financial volume (R$1 mi traded)
271 MDEntrySize C Indicates the number of trades of the session
15 Currency X
272 MDEntryDate X
273 MDEntryTime X
1020 C Total traded volume for the session, currently

TradeVolume
only sent it for E&B instruments.
6.8.11 Open Interest (269=C)

Open interest (also known as open contracts or open commitments) denotes the total number of
contracts in a commodity or options market that are still open; that is, they have not been exercised,
close out, or allowed to expire. The term also applies to a particular commodity or, in case of
options, to the number of contracts outstanding on a particular underlying security.
Below is the basic template of both market data entry type (C) (X= required, C=conditional):

269 MDEntryType “C”
48 SecurityID X
1500 MDStreamID “E”,”L” “L” – for BTB statistics
270 MDEntryPx C Sent for BTB
271 MDEntrySize X Indicates current open volume
272 MDEntryDate X
273 MDEntryTime X
6.8.12 Settlement Price (269=6)

The price data block is sent to update opening (current trading session), previous day adjustment
and settlement price. This data block is useful for obtaining the settlement price and the previous
© B3
73
day’s adjusted closing price and is sent after the close of the trading session and the opening price
(price of first trades in the current session).

48 SecurityID X
1500 MDStreamID “A”,”N”
270 MDEntryPx X
423 PriceType C Never sent for index instruments
272 MDEntryDate X
273 MDEntryTime X
286 OpenCloseSettlFlag “1”, “4”
731 SettlPriceType “1”,”2”, “3”
Usually, settlement prices are sent in a regular order during the trading day. However, Market
Surveillance can issue corrections or updates to the settlement price for the previous or current
session. Hence, it´s advised that the customer application is able to process any combination for
the tags 286-OpenCloseSettlFlag and 731-SettlPriceType.
The following table illustrates the regular schedule:
Event time [286] [731] Description

Before session 4 1 Previous day final settle
During session 4 3 Previous day updated settle
During session 1 2 Current day preview settle
After session 1 1 Current day Final settlement
6.8.13 Composite Underlying Price (269=D)

For future use by indexes over BTFs.

279 MDUpdateAction 0
269 MDEntryType “D”
48 SecurityID X
© B3
74
1500 MDStreamID “N”
37100 IndexSeq X
711 NoUnderlyings X
309 UnderlyingSecurityID X
305 UnderlyingSecurityIDSource X
308 UnderlyingSecurityIDExchange X
810 UnderlyingPx X
37018 UnderlyingPxType C
272 MDEntryDate X
273 MDEntryTime X
6.8.14 Security Trading Phase/State (269=c) (Snapshot only)

269 MDEntryType “c”
48 SecurityID X
272 MDEntryDate X
273 MDEntryTime X
326 SecurityTradingStatus C Sent when instrument is not following the group.
625 TradingSessionSubID C Sent when instrument is following the group.
336 TradingSessionID N Sends “6” when non-regular session.
342 TradSesOpenTime N Sent when the auction informed open time.
1174 SecurityTradingEvent N Can only be 101 or 102.
© B3
75
6.8.15 Volatility price (269=v)

269
MDEntryType “v” Volatility Price
83
RptSeq X
48
SecurityID X
22
SecurityIDSource X
207
SecurityExchange X
1500 MDStreamID “E” Not sent for theoretical open
811
PriceDelta C Only sent for MDEntryType =”v”
1025
FixPx C Only sent for MDEntryType =”v”
31
LastPx C Only sent for MDEntryType =”v”
272
MDEntryDate X
273
MDEntryTime X
© B3
76
7 Certification Process
Before connecting to BM&FBOVESPA, the counterparty must undergo the certification process,
which is described in details in separate documents at www.bmfbovespa.com.br, follow ‘Services’
➔ ‘Certification’.
For network connectivity to the exchange, please contact the Trading Support Group (TSG). For
certification arrangements, email the Certification and Testing Center (CTC). Check the ‘Contacts’
section for details.
The network setup is similar for all segments, once connectivity will be provided via a Certification
FIX Gateway. The physical link used for certification may vary from the one to be used in
production, as it is the application that is being certified, and not the physical layer. Hence, a client
application which will run using either RCCF or RCB in the production environment may be certified
through an Internet VPN connection.
When the participant considers that the application is ready to be certified, he will connect to a
certification FIX gateway, and will follow the BM&FBOVESPA’s certification document for market
data. The counterparty will perform a series of tests which are pre-specified by BM&FBOVESPA,
and the result will be used as an evidence of passing the certification.
© B3
77

UMDFConflated MarketDataSpecification2.0.11

Uploaded by

Copyright:

Available Formats

UMDFConflated MarketDataSpecification2.0.11

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UMDFConflated MarketDataSpecification2.0.11

Uploaded by

Copyright:

Available Formats

UMDF PUMA Conflated

FIX Market Data Specification

• Trading Certification: performs certification of all software solutions applying for

• Trading Support Channel: provides real time connectivity monitoring and

1.1 ABBREVIATIONS ................................................................................................................ 6

2.1 PHYSICAL/LINK LAYER OPTIONS ........................................................................................ 7

3.1 FIX PROTOCOL SYNTAX .................................................................................................... 9

4.1 STANDARD FIX 4.4 SESSION BEHAVIOR ........................................................................... 11

5.1 BOOK MANAGEMENT CONSIDERATIONS............................................................................ 14

6.1 MESSAGE TYPES ............................................................................................................ 19

6.4.1 Security List Request (MsgType = x) ....................................................................... 21

Date Version Description Author

- Added section 6.8.15 about volatility prices and AYSF/

- Added a new domain to tags 281 and 560 indicating that

FIX is a technical specification for electronic communication of trade-related messages. It is an

Broker A broker is an individual or firm who acts

FIX Gateway Service that provides connectivity to third-

Security A stock, bond or contract that has been

2 Market Data Architecture

2.1 Physical/Link Layer Options

2.2 Network Setup

2.3 Compression Layer

2.4 Session Assignment

BM&FBOVESPA Trading Support Group (TSG)

More info about the FIX Protocol can be obtained at http://www.fixprotocol.org/.

3.1 FIX Protocol Syntax

3.2 Message Format

3.3 Data Types

Name Base Type First Introduced

4.1 Standard FIX 4.4 Session Behavior

4.2 Message header format

TAG FIELD NAME REQ COMMENTS

4.3 Message trailer format

TAG FIELD NAME REQ COMMENTS

TAG FIELD NAME REQ COMMENTS

4.4.2 Logon Response

• Start the heartbeat timer

4.4.3 Logon Failure

4.5 Administrative messages

4.5.1 Heartbeat messages (MsgType=0)

4.5.2 Other messages

4.6 Reject Messages

4.7 Logout Messages

5 Incremental Book Management

5.1 Book Management Considerations

5.2 Order depth book

5.3 Price depth book

5.4 Price-depth Bottom Row Handling

Market Data Incremental Refresh

Market Data Incremental Refresh

New bottom row will be sent by BVM&F:

Market Data Incremental Refresh

The book after the event will be:

5.5 Market Data Conflation (Market Data Throttling)

PETR4 market data message sequence

Buy Quantity Buy Price Sell Price Sell Quantity

The following sequence of messages would be generated.

PETR4 market data message sequence

PETR4 market data message sequence