A multi-currency ledger is required when a platform holds funds or reports financials in more than one denomination. It is not enough to simply add a currency column to a transaction table. The system must solve the problem of "Relativity": The value of 100 EUR changes relative to USD every second.
For CTOs, the complexity lies in maintaining dual fidelity: preserving the exact original transaction amount (Native Currency) while simultaneously maintaining a normalized view for financial reporting (Base Currency).
The Three-Layer Currency Model
Robust ledgers store three distinct values for every single entry: Transaction Currency (Native): The actual currency moved (e.g., 100 JPY). Account Currency: The denomination of the holding account. (If 100 JPY is deposited into a USD account, this records the converted USD amount). Reporting Currency (Base): The standard currency for the company's books (e.g., USD). The system queries an FX rate table at the timestamp of the transaction T0 to freeze the historical value.
FX Revaluation (Realized vs. Unrealized)
Holding foreign currency creates accounting noise due to exchange rate volatility. Realized FX: Occurs when currency is actually converted. You bought EUR at 1.10 and sold at 1.15. The 0.05 profit is a "Realized Gain" recorded in the P&L. Unrealized FX (Revaluation): You hold 1,000 EUR in a wallet. Last month it was worth $1,100. This month it's worth $1,080. You haven't moved the money, but your "Book Value" has dropped. A multi-currency ledger runs end-of-month revaluation jobs to calculate this shift and post adjusting journal entries to an "Unrealized FX Gain/Loss" account.
