Verify record(318) and Correct record(317) in MarketFeed message
Dear Team,
In the MarketFeed messages, the Verify record(318) and Correct record(317) are also distributed from time to time along with the regular Image and Update records.
What are the possible causes that will trigger the distribution of
Verify record(318) and Correct record(317)?
What is the correct way to handle 318 & 317 type records when received in the data feed?Thank you.
Best Answer
-
Hi @NWM
- Correct - you should apply them to your local cache
- No - they are not exclusively reference / value add. As stated above a Correct update - contains corrections to previous errors.
- As mentioned above, the Correct is sent to correct a previous error in the data. I am not a content expert, but I believe these are typically determined by the originating exchange and Refinitiv is just passing it along.The Verify could be sent when there is concern that records have become out of sync e.g. after a temporary connectivity or feed issue etc.
Also, according to the ADS manual, when converting from RSSL to MF - which I assume is happening on your TREP system as you have mentioned MF data - there is a flag convertVerifyNoSyncToCorrection which controls whether an unsolicited Refresh Msg is converted to a Correction(317) or Verify(318).
You may wish to check with your MarketData team to confirm which setting they have in place - as this would impact the answers we have provided above.
The default value for the flag is false- i.e. convert an unsolicited Refresh to a Verify. Therefore, you will get a Verify whenever the originating feed issues an unsolicited Refresh message - i.e. you have not requested a Refresh, but the feed sends one - in order to republish a full set of fields - typically when there is a possibility of fields being out of sync.0
Answers
-
@NWM
As far as I understand based on the Reuters Marketfeed Reference Manua l(MFData.pdf from RFA package).Verify_Record(318) are sent at any time of day to allow the publishing and subscribing
applications to verify that records are synchronized. The Verify_Record information is sent using an image or unsolicited image event.
All verify messages should be applied by the application unless they contain no data fields. In general, a Verify_Record is an image; however, sink applications should accept a Verify_Record in all circumstances. A Verify_Record does not reflect a real market movement. When delivered as an unsolicited image (after the initial image), a Verify_Record may contain exactly the same fields as the
subscribing application’s copy of the record, a subset of the fields, or possibly additional fields. In each case, the local copy of the record should be adjusted accordingly.Correct_Record(317) are similar to updates, but are sent intentionally to correct previous errors in data. They do not imply real market movement. The Correct_Record information is sent using an update event.
The Correct_Record data contains a subset of the fields in the record. The application should update the value from correction message to item cache accordingly.0 -
Hi @NWM
Record corrections are similar to updates, but are sent intentionally to correct previous errors in data. They do not imply
real market movement. The Correct Record information is sent using an update event. You should update your local copy of the record with any fields contained in the Correct Record update.Verify_Record messages are sent at any time of day to allow the publishing and subscribing applications to verify that
records are synchronized. The Verify_Record information is sent using an image event. All verify messages should be
applied by the application unless they contain no data fields.In general, a Verify_Record is an image/refresh; your application should accept a Verify_Record in all circumstances. A
Verify_Record does not reflect a real market movement. When delivered as an unsolicited image / refresh (after the initial image/ refresh), a Verify_Record may contain exactly the same fields as your application’s copy of the record, a subset of the fields, or possibly additional fields.
In each case, your local copy
of the record should be adjusted accordingly.
A Verify_Record may contain:• All fields in the record (full verify1), in which case it replaces the current image, or
• Only a subset of the fields (partial verify2), in which case it should be treated as an update.0 -
Hi @Umer, @moragodkrit.chumsri_1
Thanks for the responses. So, as per my understanding, even though Verify & Correct records do not reflect real market update, the application should process these records and apply the FIDs value in these records to the application cache?
during trading when there is real market movement, value changes in the price FIDs are usually sent as update records. Since Verify and Correct do not reflect real market movement, are the FIDs contained in Verify & Correct records reference/value-add FIDs only?
And what are the actual causes that trigger the sending of Verify/Correct records?
Thanks.
0
Categories
- All Categories
- 3 Polls
- 6 AHS
- 36 Alpha
- 166 App Studio
- 6 Block Chain
- 4 Bot Platform
- 18 Connected Risk APIs
- 47 Data Fusion
- 34 Data Model Discovery
- 690 Datastream
- 1.5K DSS
- 629 Eikon COM
- 5.2K Eikon Data APIs
- 11 Electronic Trading
- 1 Generic FIX
- 7 Local Bank Node API
- 3 Trading API
- 2.9K Elektron
- 1.4K EMA
- 255 ETA
- 560 WebSocket API
- 39 FX Venues
- 15 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 25 Messenger Bot
- 3 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 280 Open PermID
- 45 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 23 RDMS
- 2K Refinitiv Data Platform
- 721 Refinitiv Data Platform Libraries
- 4 LSEG Due Diligence
- LSEG Due Diligence Portal API
- 4 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.2K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 12 World-Check Customer Risk Screener
- 1K World-Check One
- 46 World-Check One Zero Footprint
- 45 Side by Side Integration API
- 2 Test Space
- 3 Thomson One Smart
- 10 TR Knowledge Graph
- 151 Transactions
- 143 REDI API
- 1.8K TREP APIs
- 4 CAT
- 27 DACS Station
- 121 Open DACS
- 1.1K RFA
- 106 UPA
- 194 TREP Infrastructure
- 229 TRKD
- 918 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 95 Workspace SDK
- 11 Element Framework
- 5 Grid
- 19 World-Check Data File
- 1 Yield Book Analytics
- 48 中文论坛