Multi-Currency Position Management
Prerequisite: Representing Money
Your platform holds €4.2 million in customer funds across a EUR-denominated pooled account. A customer in Mexico requests a payout in MXN. Your system converts EUR to USD, then USD to MXN — two conversions, two spreads, two sets of fees. The customer receives 1.8% less than they would have if you held MXN directly and paid from it. Multiply that across 50,000 monthly payouts and the unnecessary conversion cost exceeds $90,000 per month.
Multi-currency position management is the discipline of holding, tracking, and deploying balances in multiple currencies simultaneously — so that money moves in the currency it needs to arrive in, without routing through intermediary conversions that exist only because your ledger was designed for a single denomination.
The Multi-Currency Account Model
A single-currency ledger stores one balance per account. A multi-currency ledger stores one balance per account per currency. The account customer_12345 does not have a balance — it has a USD balance, a EUR balance, a GBP balance, and a balance in every currency it has ever received or converted into.
CREATE TABLE balances (
account_id TEXT NOT NULL,
currency CHAR(3) NOT NULL,
amount BIGINT NOT NULL DEFAULT 0,
updated_at TIMESTAMPTZ NOT NULL DEFAULT now(),
PRIMARY KEY (account_id, currency)
);The composite primary key (account_id, currency) enforces one balance per currency per account. Entries in the ledger carry both currency and amount, and a debit in EUR cannot draw from a USD balance. This constraint is structural — it lives in the schema, not in application logic.
| Model | Balance query | Conversion logic | Currency isolation |
|---|---|---|---|
| Single-currency | WHERE account_id = ? |
All inflows converted on receipt | None — everything is base currency |
| Multi-currency | WHERE account_id = ? AND currency = ? |
Conversion only when explicitly requested | Full — balances are independent per currency |
See Representing Money. Currency amounts are stored as integers in minor units (cents, pence, sen). A multi-currency ledger inherits every representation rule from the handbook — the currency code determines the minor unit exponent.
Base Currency Accounting
Your ledger holds balances in 14 currencies. Your financial statements report in USD. Every foreign-currency balance must be translated to USD for consolidated reporting — and the rate you choose changes the number on the balance sheet.
Three rate conventions exist, each appropriate for different contexts.
| Rate type | When to use | Source |
|---|---|---|
| Spot rate | Transaction-level recording — the rate at the moment money moved | Market data feed, refreshed sub-second |
| Daily average rate | Revenue and expense translation — smooths intraday volatility | Central bank published rate or volume-weighted average |
| Month-end closing rate | Balance sheet translation — the rate at reporting period close | Central bank or ECB reference rate at 16:00 CET |
ASC 830 (US GAAP) and IAS 21 (IFRS) both require monetary assets and liabilities — cash, receivables, payables — to be translated at the closing rate. Revenue and expenses use the rate at the transaction date, or a weighted average if transactions are numerous and rates do not fluctuate significantly.
The engineering implication: every entry in your ledger needs both the transaction currency amount and the base currency equivalent at the rate used. You cannot reconstruct the base currency amount later without storing which rate was applied — and applying a different rate retroactively changes your reported revenue.
Currency Conversion Strategies
The simplest multi-currency model converts everything to base currency on receipt. A EUR payment arrives, you sell EUR and buy USD immediately, and your ledger holds only USD. This eliminates FX exposure but introduces conversion cost on every inflow.
The opposite strategy is to hold foreign currency indefinitely and convert only at the moment of outflow in a different currency. This minimizes unnecessary conversions but creates open FX positions that fluctuate in value.
| Strategy | Conversion cost | FX exposure | Operational complexity |
|---|---|---|---|
| Convert on receipt | Every inflow incurs spread | None — single currency | Low |
| Hold and convert on demand | Only cross-currency outflows | Open positions in each held currency | Medium |
| Threshold-based conversion | Excess above threshold converted | Bounded by threshold | High |
The threshold model is a hybrid. Set a target balance per currency based on forecasted outflow demand. When the balance exceeds the threshold, sweep the excess to base currency. When the balance falls below a floor, convert base currency to replenish. The thresholds are set from historical outflow data — if you pay out €200,000/month in EUR, holding €250,000 in EUR avoids most conversions while capping exposure.
The Matching Currency Insight
PingPong — a cross-border payments platform operating across 82 licences — discovered that their commercial card program was converting every transaction through a base currency. A customer with a EUR balance making a EUR purchase would see: EUR balance → USD (base) → EUR (card settlement). Two conversions. Two spreads. The customer paid for a round trip to the same currency.
The fix: match the card’s spend currency to the customer’s held currency. If the customer holds EUR and the merchant settles in EUR, draw directly from the EUR balance. No conversion. The savings on a 0.3% spread each way — compounded across millions of transactions — represented one of the highest-ROI infrastructure changes in the platform’s history.
Before: EUR balance → USD → EUR settlement (0.6% total spread)
After: EUR balance → EUR settlement (0% spread)This pattern generalizes. Any outflow should first check whether the customer holds a balance in the settlement currency. The routing logic is:
- Customer holds settlement currency → debit directly, no conversion
- Customer holds a liquid major currency that converts cheaply to the settlement currency → single conversion
- All other cases → convert from base currency
Currency matching requires knowing the settlement currency before routing. Card networks settle in the merchant’s local currency, which may differ from the transaction currency displayed to the cardholder. Your matching logic must use the settlement currency, not the presentment currency.
Unrealized Gain and Loss
Every foreign-currency balance is an open position. A €500,000 balance when EUR/USD is 1.10 is worth $550,000. When EUR/USD moves to 1.08, the same balance is worth $540,000. You have not sold any EUR, but your USD-denominated net worth has changed by $10,000. That is an unrealized FX loss.
Unrealized gains and losses must be tracked and reported — they appear on the balance sheet even though no transaction has occurred. The calculation is straightforward: for each currency, compute (current_rate - booked_rate) × position_size.
SELECT
currency,
SUM(amount) AS position_minor_units,
SUM(amount) * current_rate AS current_value_base,
SUM(amount) * booked_rate AS booked_value_base,
SUM(amount) * (current_rate - booked_rate) AS unrealized_pnl_base
FROM balances
JOIN fx_rates ON fx_rates.currency = balances.currency
WHERE account_id = $1
GROUP BY currency, current_rate, booked_rate;The booked_rate is the weighted average rate at which the position was acquired — not the rate of the most recent transaction, but the blended rate across all inflows. When you receive €100,000 at 1.10 and another €100,000 at 1.08, the booked rate is 1.09.
At each reporting period close, unrealized gains and losses are recognized in the income statement under “Other Comprehensive Income” (GAAP) or reclassified per IAS 21. The ledger entries for this recognition are non-cash — they adjust the base-currency valuation without moving money.
FX Rate Management
Your rate source determines your conversion accuracy. Stale rates cost money — a rate that is 30 seconds old during a volatile session can be 10-20 basis points off the current market. On a $1M conversion, 20 basis points is $2,000.
| Source | Freshness | Cost | Use case |
|---|---|---|---|
| Interbank feed (Reuters, Bloomberg) | Sub-second | $5K–$50K/month | Real-time trading, large conversions |
| Banking partner API | 1–30 seconds | Usually free with relationship | Mid-market reference, medium conversions |
| ECB/central bank reference | Daily at 16:00 CET | Free | Accounting, period-end revaluation |
| Aggregator (XE, Open Exchange Rates) | 1–60 seconds | $50–$500/month | Small conversions, display rates |
Rate caching is necessary — you cannot call an external API for every balance query or conversion estimate. Cache the rate with a TTL matched to your staleness tolerance. A 5-second TTL for conversion execution. A 60-second TTL for display rates. A 24-hour TTL for reporting rates.
The spread between buy and sell rates is where your FX provider makes money — and where your customers lose it. A “zero fee” conversion with a 1.5% spread costs more than a $5 fee with a 0.2% spread on any transaction above $333. Track the effective spread per provider, per currency pair, per time of day. Spreads widen during low-liquidity hours (Asian session for EUR/USD) and around economic data releases.
Multi-Currency Reconciliation
Reconciling a multi-currency ledger introduces a problem that single-currency ledgers do not have: rounding asymmetry across currencies. JPY has zero decimal places. BHD has three. USD has two. A conversion from USD to JPY rounds to the nearest yen — and the rounding difference must go somewhere.
The standard approach: book rounding differences to a dedicated FX rounding account per currency pair. If a $100.00 conversion at 149.83 JPY/USD produces ¥14,983 (rounded from ¥14,983.00), there is no rounding difference. But $100.01 at the same rate produces ¥14,984.4983 — rounded to ¥14,984 — and the 0.4983 yen difference is a rounding entry.
| Currency | Minor units | Rounding threshold | Typical tolerance |
|---|---|---|---|
| USD, EUR, GBP | 2 (cents) | 0.005 | ±$0.01 per entry |
| JPY, KRW | 0 (whole units) | 0.5 | ±¥1 per entry |
| BHD, KWD, OMR | 3 (fils/mills) | 0.0005 | ±0.001 per entry |
Reconciliation across currencies requires converting all positions to a common base for comparison. The reconciliation assertion is: SUM(all_currency_balances_in_base) == total_base_position ± tolerance. The tolerance accounts for accumulated rounding across all currencies and all conversion events. A platform processing 100,000 multi-currency transactions per month might accumulate $50–$200 in rounding differences — immaterial for financial reporting but important to track and explain.
Ledger Design for Multi-Currency
Every entry in a multi-currency ledger carries four fields beyond the standard entry schema.
CREATE TABLE entries (
id BIGINT PRIMARY KEY,
account_id TEXT NOT NULL,
currency CHAR(3) NOT NULL,
amount BIGINT NOT NULL,
base_currency CHAR(3) NOT NULL DEFAULT 'USD',
base_amount BIGINT NOT NULL,
fx_rate NUMERIC(18,8) NOT NULL,
fx_rate_source TEXT NOT NULL,
booking_time TIMESTAMPTZ NOT NULL DEFAULT now()
);amount and currency are the transaction denomination — the currency in which the money actually moved. base_amount and base_currency are the reporting equivalent at the fx_rate applied at booking_time. fx_rate_source records provenance — which rate feed, at what timestamp, was used for this conversion.
Storing both denominations at write time is non-negotiable. If you store only the transaction currency and attempt to derive the base equivalent later, you must know which rate was in effect at the exact moment of booking. Rate feeds are not perfectly reproducible — the rate you would fetch now for a timestamp 3 hours ago may differ from the rate you actually observed 3 hours ago by several basis points. Storing both amounts at write time eliminates this ambiguity.
Never store only the base currency equivalent without the original transaction currency amount. An auditor will ask: “What was the actual amount in the currency of the transaction?” If you can only answer in base currency, you cannot prove the conversion was correct.
Regulatory Reporting
Multi-currency positions trigger regulatory requirements that single-currency platforms avoid. Banks and licensed money transmitters holding foreign currency must report their positions — and in some jurisdictions, hold capital against the FX risk.
The Basel III framework requires banks to hold capital against net open FX positions exceeding 2% of eligible capital. A bank with $100M in eligible capital can hold up to $2M in net open FX positions before the capital charge applies. Above that threshold, the capital charge is 8% of the excess — so a $10M net open position costs $640,000 in required capital.
Money transmitters face state-level requirements in the US. Most states require that customer funds be held in the currency of the obligation — if you owe a customer EUR, holding the equivalent in USD may not satisfy the surety requirement. The Multi-State MSB Examination Manual specifies that permissible investments must match the currency of outstanding obligations.
Position reporting is typically daily. The report captures: net open position per currency, gross long and short positions, the VaR (Value at Risk) of the combined position at a 99% confidence interval over a 10-day horizon, and any positions exceeding internal limits. Automated generation from the ledger is the only sustainable approach — manual position reports at scale are both slow and error-prone.