Foreign exchange day rates - update time doesn't match date property

⚙️ API 🙋🏽‍♀️🙋🏽‍♂️ Ask Questions
1

Hey all,

We are about to start using the foreign exchange day rates (as returned from Daily Rate Object), however I have a question about when the rates are refreshed.

The documentation says that the rates are refreshed at 2100 UTC time. I ran some code that pulled the rates every hour to validate that claim and it is true - the rates did indeed change at 2100 UTC. However, the date property of the returned object remained the same - it only switched over to the next day on 0000 UTC. Note that this was performed on the SANDBOX Rapyd servers.

Since it is a day rate, I intend to cache the values returned for 24 hours, however the trouble I have is knowing when the rate has changed?

Due to clock skew and other strangeness, I intend to stop caching “around” 2100 UTC, and only cache the rate once the refresh has occurred. Since the date property does not change at the same time as the rate, my only option is to check whether the rate is different to the previous one. I realise it is unlikely, however it is conceivable that the rate remains unchanged from one day to the next. If this happens, I am unable to determine when to start caching the rate.

Does anyone have advice on what is going on here?

Thanks,
John.

2

Hi @JohnTownes, thanks for sharing. After discussing this with one of our product managers, and based on my understanding of your question of when to cache the values, I would suggest caching the values about 10 minutes past 2100 UTC time.

At 2110 UTC time you could cache the values knowing the refresh has occurred and if the rate has changed or stayed the same.

3

Thanks Kyle.

That sounds like a non-deterministic way to manage a cache.

While I agree that 10 minutes is a long time in terms of clock-skew, the only sure-fire way to determine if the rate returned is for “today” is by looking at the date property. Since the date property does not match the underlying refresh schedule, it is effectively unusable. What happens if Rapyd change it’s update time? The only way consumers of your API would know is by checking the documentation site.

Are you able to go back to your product managers/developers and get this changed?

John.

4

Thanks @JohnTownes, I really appreciate you sharing. Before take this back, I want to fully understand your thoughts.

The only sure-fire way to determine if the rate returned is for “today” is by looking at the date property

This would be the date under Daily Rate Object.

You’re saying since there is no direct value in the API that relates to the exact refresh time, you need to go to the documentation to confirm it’s at 2100 UTC.

Screen Shot 2022-02-15 at 8.24.33 PM
Screen Shot 2022-02-15 at 8.24.33 PM954×328 42 KB

All that to say your question would be, is the exact refresh time something that could be developed in the API?

1 Like
5

G’day Kyle,

Yes, that is exactly what I am saying.

As background information, we advertise rates to our customers so it could have real-world financial implications for us if we post incorrect rates.

I want to stop relying on the documentation to determine how long to cache the daily rate. As it stands now, I only know when the rate refreshes because the documentation tells me what time it is supposed to refresh. If the Rapyd policy changes (or you get a new FX provider or some other reason) and you refresh at a different time of day, how do I (as an API consumer) know about this change?

Your previous advice is to cache until 10 minutes after the refresh time. My line of thinking goes like this:

  • If I keep the rate until after the refresh time, we will be advertising an incorrect rate for a 10 minute period to our customers.
  • Imagine if I get the rate at 2102 UTC. How do I know if it the rate is current or not? The date property does not tell me (because it changes at 0000 UTC).
  • What if Rapyd’s rate refresh fails for some reason, and it doesn’t actually refresh? The date property value is the same at 2050 and 2115, so I have no idea if the rates returned at 2110 UTC have actually been updated. If I cache the value returned at 2110 and it is wrong then we are advertising an incorrect rate for 24hours!

On further reflection, it would be useful (from an API consumers point of view) to include an expiry property of some sort (ether a UTC date/time or timespan). This way the API consumer is made aware of how long the day rate is valid for. Once that is known, intelligent decisions can be made about cache period and all of that.

Thanks for your help Kyle – please let me know how you go with your product team.

On another note, I have raised a ticket with your support time (#76828) regarding this issue on 3 Feb (!), and this is the first response I have had from Rapyd. I also have 3 other tickets that I am waiting for information on. Are you able to nudge your support teams into giving me some help?

Thanks again,

John.

6

Thanks @JohnTownes, I have passed this on to our support, and our FinOps team will follow up with you.

In the meantime, I will pass this on to our product team. Thanks so much for your thoughts and reflections here.

7

With respect, I hope they do. I have several tickets that are simply being ignored.

Thanks again for your response,

John.