| name | triangulated-fx-rates |
| description | Reference for multi-hop / triangulated currency conversion on batch rate tapes. When a rate row carries an explicit "via" currency, the row's rate is only one leg of the conversion, and the via currency may ITSELF be quoted through another via — so the effective rate is the product of every leg, resolved by walking the chain until a direct quote is reached. Useful when an FX feed lists some pairs directly to the reporting currency and others as triangulated (or doubly-triangulated) quotes through vehicle currencies. |
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:
- 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.
- 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:
*> 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