Picture a finance team closing the month. Revenue came in as EUR and GBP, suppliers were paid in USD, and part of the treasury moved through stablecoins. If each of those lives in its own wallet, the close means exporting four statements in four formats, matching internal transfers by hand, and explaining to an accountant why one conversion appears as three unrelated transactions. That afternoon of matching numbers is the real cost of a design decision made long before the business signed up.
The decision is this: when a platform supports multiple currencies, does it build one wallet per currency, or one account with multiple balances? They sound like the same thing. Underneath, they are opposites — and the difference surfaces every time money converts, reconciles, or gets reported.
What "one wallet per currency" really means
Separate wallets are the natural first build: each currency gets its own ledger, its own transaction history, its own reference format. The architecture is simple, which is why so many platforms start there.
The cost appears the moment currencies interact. Converting EUR to USD across independent wallets isn't one operation — it's three: a withdrawal from the EUR ledger, a conversion event in an FX engine, and a deposit into the USD ledger, each with its own reference number. The wallets don't know about each other, so nothing in the system records that these three events were ever one action. Reconstructing that link is left to the customer, one spreadsheet row at a time — and there's a second, quieter problem: with the conversion split across entries, the exchange rate actually applied is nowhere stated, which makes calculating FX gains and losses for reporting a forensic exercise rather than a lookup.
What we built instead: one ledger, many balances
A SpeedyX account holds EUR, GBP, and USD as balances on a single ledger — not as neighbouring wallets. Every movement, in any currency, is an entry in one book, under one reference scheme, in one chronological history.
That makes a conversion what it conceptually always was: one transaction. Confirming a EUR→USD conversion writes a single linked entry — a debit on the EUR balance and a credit on the USD balance, bound to one transaction ID, with the executed rate recorded on the entry itself. Both legs settle together or not at all; there is no state where the euros have left but the dollars haven't arrived. Nothing to match afterwards, because nothing was ever split.
| One wallet per currency | One ledger, multiple balances | |
|---|---|---|
| A conversion is… | 3 events across 2 ledgers plus an FX engine | 1 atomic entry with both legs linked |
| The applied rate | Implied — reconstructed from amounts | Recorded on the transaction itself |
| Month-end reconciliation | Cross-matching references between systems | One statement, one reference scheme, in sequence |
| "What's our position right now?" | Sum of separate statements, minus in-flight transfers | One query against one ledger |
Crypto as a balance, not a bolt-on
The design earns its keep when crypto enters the account. On most platforms, crypto is a separate product grafted onto a fiat core — with its own history, its own export format, and a seam between the two systems that the customer reconciles. Here, converting EUR to a stablecoin follows the identical pattern as EUR to USD: one linked entry, one reference, one place it appears in the statement.
That symmetry is quietly connected to why accounts here stay open for crypto-touching businesses. When fiat and crypto share one ledger, transaction monitoring sees the whole flow — collection, conversion, payout — as a single coherent story rather than fragments crossing a system boundary. Coherent stories are auditable; auditable activity is what compliance partners can stand behind. The architecture and the account stability are the same decision viewed from two angles.
What this looks like in practice
The test of an architecture is a boring one: month-end. From a single account, a finance team pulls one statement in which every collection, conversion, and payout appears in sequence — each with its status, its reference, and, for conversions, the executed rate on the line. Per-currency views still exist for accountants who want them, but they are views over one ledger, not exports from separate systems that might disagree.
Nobody chooses a payments platform for its ledger design. But everybody feels it — either as an afternoon of matching transfer IDs, or as a close that ends before lunch. We built for the second outcome, and accepted the engineering bill that came with it.
This article is for general information only and is not financial, legal, or tax advice. Product availability, fees, and features depend on verification, account type, jurisdiction, and applicable regulatory requirements, and may change over time.