Install
$ agentstack add skill-benchflow-ai-skillsbench-triangulated-fx-rates ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
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 EUR is the first hop
ZAR 0.0650 EUR EUR is the first hop
BRL 0.3000 ZAR 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 :=
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
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: benchflow-ai
- Source: benchflow-ai/skillsbench
- License: Apache-2.0
- Homepage: https://www.skillsbench.ai
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.