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 @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
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
- 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 中文论坛