question

Upvotes
Accepted
16 12 15 17

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.

treprfarfa-apisslmarket-feed
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
Accepted
25.3k 87 12 25

Hi @NWM

  1. Correct - you should apply them to your local cache
  2. No - they are not exclusively reference / value add. As stated above a Correct update - contains corrections to previous errors.
  3. 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.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
7.6k 15 6 9

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

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
25.3k 87 12 25

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.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
16 12 15 17

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.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
16 12 15 17

Hi @Umer

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

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.