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:

Copy code
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).

Copy code
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:

cobolCopy code
       *> 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