MBP Message Payload
I am referring to document "REFINITIV ROBUST FOUNDATION API V8.2.2.L1" pdf document section 8.3 Data: Response Message Payload.
a rfa::message::RespMsg message got from a rfa::common::Event will contain a Map which may have n FieldList. Again similar to my 97802 question:
- So user code can receive an update of FieldList containing BID and ASK data. May I say at most 1 BID and 1 ASK? Is it possible that a FieldList could containing m BID and n ASK?
- within a FieldList, there is a update timestamp (for example either FID 6527 or FID 14268; or both conceptually one bcos user should use only one of them)? And this timestamp is applicable to all BID/ASK data within the same FieldList (optional, I may apply its value to all BID/ASK data anyway)
- This n possible BID/ASK entries within a FieldList has nothing to do with subscription method/options used (if a FieldList can contain at most 1 BID and 1 ASK, then we can ignore item 3).
Best Answer
-
Hi @ming.cheng
As per the above replies and the article, the FieldList object contained within each map entry of an MBP payload does not have BID or ASK fields - therefore the question of 1 BID or 1 ASK does not make sense.
Each Map entry would only contains field like the following:
Fields":{
"ACC_SIZE":22415,
"LV_TIM_MS":53520032,
"NO_ORD":7,
"ORDER_PRC":106.68,
"ORDER_SIDE":"ASK"
},As you will note, there is no BID or ASK field. The ORDER_SIDE field would indicate whether the order is a BID order or an ASK order.
As it is an order book, each entry represents orders - i.e. the number of buy orders or sell orders at the specified ORDER_PRC. Therefore, the idea of a single entry representing both BID and ASK orders does not make sense.
Furthermore, if you look at the Data Dictionary files (RDMFieldDictionary + enumtype.def) the ORDER_SIDE field is an enumerated field
ORDER_SIDE "ORDER SIDE" 3428 NULL ENUMERATED 3 ( 3 ) ENUM 1
and the valid Enum values for the field are:
! VALUE DISPLAY MEANING
! ----- ------- -------
0 " " undefined
1 "BID" Bid
2 "ASK" Ask0
Answers
-
According to no duplicated FID within a FieldList principle , then seems each FieldList can contain either a BID or a ASK; can't have both.
0 -
Hi,
Please see the answer in the original thread post.1 -
Hi Wasin
If you don't mind, please kindly confirm that a FieldList from MBP can only contain
- 1 BID
- or 1 ASK
Thanks.
0 -
Hi @ming.cheng
Are your questions related to MarketPrice (MP) or MarketByPrice(MBP) ?
MBP represents a Market Depth Aggregated Order Book i.e. a Collection of orders for an instrument grouped by Price point i.e. multiple orders per ‘row’ of data.
If you wish to understand the MBP data format please see the following article - the introduction contains some useful information - How to Sort & Process Level 2 Orderbook Data using EMA C++ API | Refinitiv Developers
As you will note from the above article, an MBP message (Refresh or Update) can contain multiple BID and or ASK prices - as they don't use the BID and ASK fields.
1 -
Hi Umer,
Only L2 MBP in this thread as highlighted in Subject. So a FieldList (please be noted just 1 FieldList) may support these scenario:
- just m BID(s) m >= 1
- just n ASK(s) n >=1
- and m BID(s) plus n ASK(s).
I mean after aggregation by price. for m BIDs situation, for example
A FieldList has bid@10 and bid@9. bid are those data related to a bid.
0 -
Hi @ming.cheng
Please read the above article which explains the format of the data. Also as mentioned earlier there is no BID or ASK field in the payload of an MBP map entry, so I don't understand your question about the BID and ASK fields.
A Refresh message Map could contain the following (a short extract)
and so on for the complete order book. As you can see the field names rename the same, ORDER_SIDE field indicates whether the order is an ASK or BID side.
And then an Update message Map could contain the following:
"Map":{
"Entries":[
{
"Action":"Update",
"Fields":{
"ACC_SIZE":7491,
"LV_TIM_MS":53520071,
"NO_ORD":3,
"ORDER_PRC":106.64,
"ORDER_SIDE":"BID"
},
"Key":"MTA2LjY0Qg=="
},
{
"Action":"Update",
"Fields":{
"ACC_SIZE":16254,
"LV_TIM_MS":53520071,
"NO_ORD":5,
"ORDER_PRC":106.62,
"ORDER_SIDE":"BID"
},
"Key":"MTA2LjYyQg=="
},
{
"Action":"Update",
"Fields":{
"ACC_SIZE":22415,
"LV_TIM_MS":53520032,
"NO_ORD":7,
"ORDER_PRC":106.68,
"ORDER_SIDE":"ASK"
},
"Key":"MTA2LjY4QQ=="
}
],
"KeyType":"Buffer",
"Summary":{
"Fields":{
"SEQNUM":20174992,
"TIMACT_MS":53520071
}
}
}1 -
Actually it's my bad. Everytime when read an Exchange/broker's tech document, I feel almost 99.99% it should this or that. Howeve I still prefer to play a safe game to confirm with the source directly. No shame no harm.
Come to this particular question, I thought it should be quite straightforward that for any MBP FieldList data, it should only contain one side FIDs. Should your above sample have confirmed my conclusion?
0 -
Hi @ming.cheng
Can you please clarify your last question - I don't understand?
If there is something about my previous answer or the article which is not clear - please explain with example so that I can try and clarify.
0 -
A FieldList object from MBP event update can only contain
- 1 BID
- or 1 ASK
No both BID and ASK data in the same FieldList object.
0 -
Hi Umer
When I said BID and ASK, I should have made it clear that BID here means BID side price and size etc. Sorry for the confuse caused. Not just that particular BID/ASK FIDs.
0 -
My bad that I should have made my BID/ASK definition clear that these BID/ASK are not Refinitiv FIDs but more like industrial concept which at least should include price and size. So my basic concern is that a FieldList from MBP should only contain one side data including price and size for example. No situation that a FieldList object may have both bid side price/size and ask side price/size.
0 -
Hi @ming.cheng
No worries - hope my answer confirmed the situation.
0
Categories
- All Categories
- 6 AHS
- 37 Alpha
- 161 App Studio
- 4 Block Chain
- 4 Bot Platform
- 16 Connected Risk APIs
- 47 Data Fusion
- 30 Data Model Discovery
- 608 Datastream
- 1.3K DSS
- 577 Eikon COM
- 4.9K Eikon Data APIs
- 7 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- Trading API
- 2.7K Elektron
- 1.3K EMA
- 236 ETA
- 519 WebSocket API
- 33 FX Venues
- 10 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 20 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 59 Open Calais
- 264 Open PermID
- 39 Entity Search
- 2 Org ID
- PAM
- PAM - Logging
- 8.4K Private Comments
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 20 RDMS
- 1.4K Refinitiv Data Platform
- 367 Refinitiv Data Platform Libraries
- 3 Refinitiv Due Diligence
- LSEG Due Diligence Portal API
- 3 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.1K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 10 World-Check Customer Risk Screener
- 990 World-Check One
- 44 World-Check One Zero Footprint
- 45 Side by Side Integration API
- Test Space
- 3 Thomson One Smart
- 1.2K TR Internal
- Global Hackathon 2015
- 2 Specialists Who Code
- 10 TR Knowledge Graph
- 150 Transactions
- 142 REDI API
- 1.7K TREP APIs
- 4 CAT
- 21 DACS Station
- 117 Open DACS
- 1.1K RFA
- 103 UPA
- 172 TREP Infrastructure
- 224 TRKD
- 886 TRTH
- 5 Velocity Analytics
- 5 Wealth Management Web Services
- 59 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛