triangulated-fx-rates

# Triangulated FX rates Most rate feeds list a direct rate to the reporting currency (typically USD). Less liquid currencies are often quoted *through* a more liquid vehicle currency (commonly EUR or USD itself). On a batch rate tape this is encoded as a second "via" column on the same row: ``` CCY RATE VIA USD 1.0000 EUR 1.0850 GBP 1.2750 CHF 0.9200 EUR <-- CHF -> EUR is the first hop ZAR 0.0650 EUR <-- ZAR -> EUR is the first hop BRL 0.3000 ZAR <-- BRL -> ZAR -> EUR -> USD : TWO via hops JPY 0.0064 ``` A blank `VIA` column means the row is already a direct quote against the reporting currency. A non-blank `VIA` column means the row gives the rate from CCY to VIA — and you still need to convert from VIA to the reporting currency. ## The via chain can be longer than one hop This is the part that is easy to get wrong. The via currency named on a row is **not guaranteed to be a direct quote** — it may have its own non-blank via column, which in turn may have another, and so on. A single via lookup is therefore only correct when the via happens to be direct. To get a correct effective rate you must **follow the chain**: keep multiplying in the next leg's primary rate, moving to that leg's via, until you reach a row whose via is blank (a true direct quote against the reporting currency). ``` effective_rate(CCY) = primary(CCY) × primary(via(CCY)) × primary(via(via(CCY))) × … ──────────────────────────────────────────────────────────── until the via column is blank (a direct quote) ``` Worked examples against the table above: - **One hop (CHF):** CHF→EUR is 0.9200, EUR is direct (1.0850). `0.9200 × 1.0850 = 0.99820` → 0.9982 (4dp). - **Two hops (BRL):** BRL→ZAR is 0.3000, ZAR→EUR is 0.0650, EUR is direct (1.0850). `0.3000 × 0.0650 × 1.0850 = 0.0211575` → 0.0212 (4dp). Stopping after the first via (treating ZAR's 0.0650 as if it were ZAR→USD) gives `0.3000 × 0.0650 = 0.0195`, wrong by the whole EUR leg. ## Failure modes Two distinct defects show up here: 1. **No multiply at all** — the via is read into a field but the row rate is used verbatim. Triangulated currencies are then off by a multiplicative factor equal to the rest of the chain. 2. **Single-hop only** — the first via is multiplied in, but the code assumes that via is always direct and never checks whether the via has its own via. One-hop currencies look correct; multi-hop currencies are wrong by every leg past the first. This one is subtle because the common currencies are usually one hop, so it passes casual inspection. ## Rounding Carry the running product at **full precision** (enough decimals that no intermediate leg is truncated — the product of N four-decimal rates has up to 4·N decimals) and round **once at the end** to the rate field's precision (typically 4 decimals) with `COMPUTE … ROUNDED` (half-away-from-zero in COBOL, matching Python `Decimal` `ROUND_HALF_UP`). Rounding each leg to the rate-field precision before the next multiply corrupts low-rate currencies. ## Control flow (placeholder names) Resolve the rate with a loop that walks the chain, not a one-shot via lookup. Sketched with **generic** names — substitute your own rate-table and working-storage identifiers: ```cobol *> placeholders: acc is a wide running product, cur is the currency *> currently being resolved, leg/leg-via come from the matched row. acc := 1 cur := <currency to price> REPEAT (leg, leg-via) := primary-rate and via of the row matching cur acc := acc * leg *> carry full precision, no per-hop round IF leg-via is blank done ELSE cur := leg-via *> follow the chain one more hop END-IF UNTIL done eff := ROUND(acc) to the rate-field precision ``` A guard on the maximum number of hops is prudent so a malformed (cyclic) via column cannot loop forever. How you store `acc`/`eff` and which field you round into depend on your program's own declarations. ## Verification tip Pick the currency with the **longest** via chain and compute its effective rate by hand, multiplying every leg through to the direct quote, then reconcile against one account whose balance is entirely in that currency. If single-hop currencies reconcile but the multi-hop one is off by a clean constant factor, the chain is being cut short after the first via. ## References - ISO 4217 currency codes used in the CCY / VIA columns - IBM Enterprise COBOL Language Reference for `COMPUTE … ROUNDED` semantics and `PIC … V…` decimal alignment