Hi,

We are subscribing to the MMT_MARKET_PRICE model type via the ELEKTRON_DD service connected to the Reuters EZD application installed on our dedicated Reuters link server.

So I basically send a list of currencies (USD=, ZAR=, AUD=, etc) to the RFA API to retrieve the BID and ASK Price for each of those currencies in real-time. But these BID and ASK prices are returned based on the USD, so USD is returned always as 1.0 and 1.0, whereas ZAR is then returned as 13.98 and 14.02, for example. I need the reverse to happen, so that the data is returned based on ZAR, so ZAR is returned as 1.0 and 1.0, and USD is then returned as 0.07 and 0.06 (i.e. that 1 USD costs 13.98 ZAR).

Would this be possible, or would I have manually calculate the values (i.e. do the conversions myself) to accomplish this?

Thanks,

Not a data expert, but you can refer to the Cross Rate Guide page subscribed from the <CROSS/1> RIC.

For ZAR currency, an application subscribe to <ZARX=> RIC to retrieve available list of calculated cross rates based on ZAR.

Hi Veerapath,

Thanks, that makes sense, but I am retrieving data using the RFA.NET API connecting to the Reuters EZD platform. Nowhere in the API does it (clearly) show me where I can change the currency I am subscribing too. I've gone through all the config files and found no reference to USD as the default RIC. Even the EZD test application does not specify the default RIC, it shows data based on USD.

Thanks,

I think I understand the issue better. Your application subscribes to an item (i.e. equity RIC) but data is returned based on USD currency. So, you want the data to be returned in other currency. Is this correct?

As far as I know, the currency of returned data is based on the exchange of data. There is no method to specify currency in the request. Application needs to be implemented to convert the data's currency manually. It may also need to request the currency exchange RIC such as <ZAR=> to retrieve real-time exchange rate.

Hi, yes, that is exactly what I want.

It should be possible to do the conversion on our side, but I cannot believe that the system can only return data based on USD, since other countries would have the same requirement for their own local currency to be able to compare against others.

I've sent a mail to our local Reuters technical department, but they are taking their time getting back to me, and our dev team needs an answer on this ASAP.

I am going to mail our local account manager now and see if I can get an answer.

Thank you for the assistance.

Also, when we send the Market Price request, we use the INSTRUMENT_NAME_RIC for the AttribInfo data.

Hi Warat B and Veerapath,

Thank you, your suggestions worked perfectly. I did not know you had to specify with the RIC how to retrieve the data, i.e currency vs currency.

I tested it now with a couple of currencies, such as NZD, EUR, etc and it was returning the correct values, as based on ZAR.

Thank you so much for the help and patience!!

Regards,

Hi,

Another question, this is specific to certain currencies, such as Jordanian Dinar, Gibraltar Pound, etc

Can these be returned as a ZAR value? We tested the changes I made now (i.e. changing the call from the USD= RIC to ZARUSD=R), but for currencies such as those above, we do not get any data back from the TREP API. If I do EURJOD=R to convert Dinar to Euro, it works perfectly, but nothing for ZAR. Are there limits to how many currencies can be compared to ZAR?

I checked in the list of RIC's we have, but could not even find Jordanian Dinar, let alone a ZAR to Jordanian Dinar RIC?

Thank you,

Hi Eduard,

A few concepts you'll need to appreciate the full picture here.

You are connecting into a TREP platform. The platform itself is vendor-agnostic, so it may have feeds from multiple vendors on it, say from Thomson Reuters, IDC, Bloomberg and directly from exchanges, from in-house sources. Now, TREP was developed by Thomson Reuters so you almost always see (at a minimum) a Thomson Reuters feed (typically named ELEKTRON or something like that) on a given TREP installation. However, even this is not given. If instead of connecting your application to the TREP you mention, you instead connected it to the TREP in Goldman Sachs or the TREP in Standard Bank then would most likely see more feeds than just "ELEKTRON".

Each feed can use its own convention for how market data items are named. The only limit TREP imposes is that it imposes a length limit of <a lot, can't remember exactly>. Specifically for feed(s) from Thomson Reuters is that they use a naming convention for market data items called "RIC", short for Reuters Instrument Code. In this naming standard market data items for FX spot rates follows a certain convention, something like:

CURx[CURy]=[SOURCE]

The parts in [] are optional. Now, in a given FX Spot rate there are of course always two currencies involved. In the RIC standard, if only one currency is specified then - by convention - the other currency is then implied to be USD. In other words

GBP=

means the spot rate of GBP/USD while

SEK=

means the spot rate of USD/SEK.

You cannot tell the direction of the rate from the RIC name alone. You must know what the market convention is!

The next thing to understand is that the Thomson Reuters feed is from the professional market and you can generally only find quotes on what is traded among professionals. So you cannot (with some exceptions) ask for a rate from this feed for something that isn't actually traded by anyone. Professionals trade USD/ZAR, not/never ZAR/USD. If you want the opposite you'll have to calculate it yourself. The same is true for cross-rate combinations. An example: Nobody in the professional market actually trade say ZAR/SEK. In the real world the professionals would trade USD/ZAR and USD/SEK instead. If you really want a ZAR/SEK rate you would have to calculate it yourself. (and this again poses another question: should this be done via EUR or via USD?, perhaps the answer is obvious for ZAR, but it isn't obvious for European cross-rates). However, as a help for those who really need it, Thomson Reuters actually calculates a number of real-time cross-rates as kind of a courtesy for the consumers. These are the "=R" RICs as already mentioned. These may or may not fit your use case.

Hope this helps

Lars