Legacy Example_56: reversed FX/RATE key order for USD/GBP and USD/CHF in market.txt

[mcraveiro]

Hi ORE Developers,

I just bumped into an issue whilst importing ORE Samples into ORE Studio [1]. I just wanted to clarify that this is indeed an issue - I guess you probably don't care too much about the legacy examples; but as part of our completeness checks at ORE Studio we need to ensure that all ORE Samples works as expected. If you agree with the analysis I will submit a PR to update the market data.

What follows is the issue as investigated by Claude, with minor formatting changes for clarity:

In Examples/Example_56/Input/market.txt, the FX spot block (around line 733) reads:

20160205 FX/RATE/EUR/CHF 1.125046
20160205 FX/RATE/EUR/GBP 0.811938
20160205 FX/RATE/EUR/JPY 128.15046
20160205 FX/RATE/EUR/SEK 9.657638
20160205 FX/RATE/EUR/USD 1.132337
20160205 FX/RATE/USD/GBP 1.394610179594994
20160205 FX/RATE/USD/CHF 1.006480623903378

Every EUR/xxx row follows the convention "value of 1 CCY1 in CCY2" (e.g. 1 EUR = 1.132337 USD). The last two rows don't: their
values are mathematically EURUSD/EURGBP and EURUSD/EURCHF respectively — i.e. EURUSD/EURGBP = 1.394610... is the value of 1 GBP in USD (GBPUSD), and EURUSD/EURCHF = 1.006480... is the value of 1 CHF in USD (CHFUSD), not "1 USD in GBP/CHF" as the USD/GBP/USD/CHF key order implies. Taken literally, USD/GBP = 1.394610 would mean 1 USD buys 1.39 GBP — the reverse of reality for that date.

This doesn't affect the example's own ORE run — todaysmarket.xml sources its FX spots from a separate FX/<CCY1>/<CCY2> key namespace (no /RATE/), unrelated to these market.txt rows — but it's a data-quality trap for anyone consuming market.txt directly by key convention (as we were, sourcing reference FX values for a downstream project). Suggest relabelling to FX/RATE/GBP/USD and FX/RATE/CHF/USD (values unchanged) for consistency with the rest of the file.

[1] https://github.com/OreStudio/OreStudio

[mcraveiro]

Actually, it seems this is more prevalent than expected:

Same bug, safe (key not load-bearing in that example's own ORE run):

1. external/ore/examples/Legacy/Example_56/Input/market.txt
2. external/ore/examples/Legacy/Example_44/Input/market.txt
3. external/ore/examples/InitialMargin/Input/Simm/simm_market.txt
4. external/ore/examples/XvaRisk/Input/market_20160205_eonia_200bp_up.txt
5. external/ore/examples/XvaRisk/Input/market_20160205_eur6m_200bp_up.txt
6. external/ore/examples/ORE-Python/Notebooks/Example_7/Input/market.txt

Same bad key/value, but curveconfig.xml in each references FX/RATE/USD/GBP/FX/RATE/USD/CHF directly
as a input for FX forward curve bootstrapping, so a blind rename would break the example (dangling key). This needs an
ORE-side answer on whether the forward-curve builder intentionally expects spot in this reciprocal form, before touching:

7. external/ore/examples/ORE-API/Input/market_20160205_flat.txt
8. external/ore/examples/ORE-Python/Notebooks/Example_9/Input/market_20160205_flat.txt
9. external/ore/examples/ORE-Python/Notebooks/Example_4/Input/market_20160205_flat.txt
10. external/ore/examples/ORE-Python/Notebooks/Example_3/Input/market.txt

[pcaspers]

Hi @mcraveiro, thank you for looking into this, this is terrible... the data in Examples/Input/market_2016-02-05.txt looks more consistent, although I am not sure about the fx forward quotes there either tbh.

To answer your question, the only restriction in the forward-curve builder is that domestic and foreign currencies must be the same for the fx spot and fx forward quotes.

[mcraveiro]

Hi @pcaspers thanks for the swift reply. What I'll do then is, I will update them locally in ORE Studio and re-run all the samples - I need to do that for ORE Studio's purposes anyway because we have import tests. Then, if nothing breaks then I will update ORE and submit a PR. It will take me a while, mind you, but its part of my internal test plan so I will get to it eventually :-) Cheers

[pcaspers]

Sounds good, thanks @mcraveiro