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.

Find more posts tagged with

trep

rfa

ssl

rfa-api

market-feed

Accepted answers

umer.nalla

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.

All comments

moragodkrit.chumsri_1

@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.

umer.nalla

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.

NWM

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.

umer.nalla

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.

NWM

Hi @Umer

Thank you for the explanation. Let me check the ADS setting and revert later.

EXPLORE OUR SITES