Multi-Currency Treasury Architecture for Payment Operators

Most payment operators have a currency mismatch they are solving by not thinking about it. Revenue arrives in multiple currencies — GBP from UK card settlement, EUR from European volume, USD from global platform payouts, PHP from Southeast Asian marketplaces — and the default behaviour is PSP auto-conversion: each settlement batch converts everything to the operator’s functional currency at the embedded rate. The FX cost is not shown as a line item. It sits inside the conversion rate.

For operators with under $500,000 in annual cross-currency settlement, the gap between PSP default conversion and an optimised treasury approach is typically $5,000–$15,000 per year — unlikely to justify the operational overhead of multi-currency treasury management. At $2M in cross-currency volume, that gap reaches $30,000–$45,000. At $10M, it is over $100,000. At that point, conversion efficiency is a meaningful budget line.

This article is a decision framework, not a platform ranking. The question it answers is: given your operating profile and currency exposure, what architecture should you use for holding balances, converting currencies, and managing forward exposure — and where do specialist treasury platforms, virtual IBANs, and stablecoins fit?

Map Your Exposure Before Choosing Architecture

Treasury architecture decisions start with a clear picture of the exposure, not with a platform choice. Three categories of currency exposure affect payment operators:

Settlement exposure — currencies in which your PSP settles. Stripe and Adyen both support multi-currency settlement configurations — check your account setup, as default behaviour varies by account and product, and many PSP defaults convert at the transaction level if multi-currency settlement is not explicitly enabled. Your settlement report tells you the actual currency breakdown.

Payables exposure — currencies in which you have costs. Supplier invoices in MXN, staff payroll in PHP, SaaS subscriptions billed in GBP. Where payables and revenue are in the same currency, you have a natural hedge and conversion is not necessary. Where they differ, you have conversion exposure on both sides.

Reserve currency exposure — rolling reserves held by your PSP are often denominated in USD regardless of the underlying transaction currency. A EUR-heavy European merchant may find their reserve held in USD, creating an implicit long-USD position that has not been explicitly chosen. Check your PSP contract for reserve currency denomination.

The natural hedge principle runs through all three categories: where revenue and costs are in the same currency, holding that currency eliminates the conversion cost on both legs. A UK operator with GBP revenue and GBP costs — payroll, suppliers, hosting — has no structural need to convert anything.

Treasury Architecture Options

Four structural approaches, roughly ordered by operational complexity:

Default PSP auto-conversion — the baseline. Every settlement converts to your functional currency at the PSP’s embedded rate, typically 1.5–3.0% above mid-market for default pricing (this is not a disclosed fee; it is embedded in the conversion rate applied). Acceptable at low cross-currency volume. Does not require any new infrastructure. The cost is implicit and often untracked.

Multi-currency PSP settlement with bank FX — configure PSP settlement in multiple currencies, receive GBP in a GBP bank account, EUR in a EUR account. Convert accumulated balances through your bank’s FX desk on your schedule rather than at every settlement. Bank FX spreads for corporate accounts depend heavily on relationship and volume — bank FX pricing is not publicly disclosed in standardised form. As an operator estimate based on market observation, well-established corporate accounts with material recurring FX volumes (commonly above $5M per quarter, though this varies by bank) may access spreads in the 0.3–0.8% range; smaller accounts typically pay closer to PSP default rates. Batch conversion reduces the number of conversions and allows timing flexibility. Confirm the actual spreads available with your bank’s treasury desk.

Specialist treasury platform — platforms like Airwallex and Wise Business combine multi-currency account holding, local payment rail access, and FX conversion at published rates. Airwallex publishes 0.5% above interbank for major currencies (AUD, USD, HKD, CNY, EUR, GBP, SGD) and 1% for other currencies, with local transfers to 120+ countries included. Wise Business converts at mid-market rate and charges a separate per-transfer conversion fee rather than embedding a spread, with 22 receivable currencies (verify current scope at Wise’s published pricing). Nium covers 190+ countries and 60+ currencies per its product page, with real-time settlement available on 100+ specific corridors; pricing is not publicly disclosed and requires sales engagement. These platforms can materially reduce FX cost versus PSP default for operators in the approximate $500K–$50M annual cross-currency range, and they centralise multi-currency cash management that would otherwise require separate bank accounts in multiple jurisdictions. Specific savings depend on currency mix, volume tier, and platform pricing at the time of contracting — model the comparison against your own settlement data.

Multi-currency with targeted stablecoin corridors — for operators with EM-heavy payout needs or specific cross-border B2B flows, stablecoin rails offer an additional layer where traditional and specialist platform economics do not compete. This is an extension of the specialist platform tier, not a replacement for it. Covered separately in the stablecoin section below.

Decision Matrix by Operating Profile

Volume thresholds are indicative. Adjust based on your currency mix: an operator with 80% of revenue in a single non-functional currency hits the architecture inflection point earlier than one with diffuse cross-currency exposure.

Convert Now vs Hold vs Hedge

These are three distinct decisions that often get conflated. The logic for each is different.

Convert now

Convert at settlement when:

• You have no costs in that currency and no natural hedge exists. Holding JPY you cannot spend in JPY provides no benefit unless you expect JPY appreciation.
• The currency is volatile relative to your functional currency and the holding period adds risk without reducing conversion cost.
• PSP settlement is already netting conversion cost at a negotiated rate that compares favourably to your alternatives.

Convert now is the default and is correct for most operators most of the time. The question is whether you are converting at the PSP’s embedded rate or on your own terms.

Hold

Hold the currency when:

• You have matching costs in that currency. EUR revenue against EUR payroll and EUR supplier invoices is a natural hedge. You will need to spend EUR regardless; converting it to USD and then back to EUR for the next invoice is unnecessary cost.
• You are accumulating for a near-term batch conversion. Holding GBP for three to five business days to batch-convert weekly rather than converting at each settlement reduces the number of conversions and allows you to pick timing.
• Settlement is imminent and conversion adds no value. A payout to a GBP supplier due this week does not need to convert via USD and back.

Hold has limits: holding volatile EM currencies for speculative benefit is not treasury management, it is FX trading. The hold decision should be driven by cost reduction and natural hedge logic, not currency speculation.

Hedge

Forward hedging is appropriate when:

• You have a confirmed, scheduled liability in a specific foreign currency — a signed supplier contract, an annual software licence, a payroll commitment.
• The payment is more than approximately 30 days forward, giving enough time for exchange rate movement to matter.
• You have an existing banking relationship with a treasury desk, or access to a specialist FX hedging service. Forward contracts and options are not standard features of every business bank account.
• The notional size justifies the hedging overhead. As a practical guide (confirm with your bank), corporate FX desks typically engage on individual forward contracts above approximately $500K equivalent. Smaller amounts can sometimes be accommodated through specialist platforms.

Most payment operators should not be running forward hedging on routine transaction flow. For major currency pairs (USD, EUR, GBP, JPY, AUD, CHF), the volatility window between accepting a payment and converting it within a few business days is typically narrow enough that the expected FX movement does not warrant a hedge premium. EM-currency exposure with longer hold windows or large concentrated balances deserves more deliberate attention. The correct trigger for forward hedging is a large, confirmed, dated liability — not ongoing revenue flow.

Local Accounts and Virtual IBANs

Local accounts become relevant in two specific operating scenarios.

Receiving B2B payments locally. When corporate buyers want to pay via domestic bank transfer — avoiding SWIFT fees and remittance truncation — a local bank account or virtual IBAN in their country makes payment operationally simple for the payer and avoids the issues documented in cross-border B2B AR. A German buyer can send a SEPA SCT to your virtual German IBAN rather than constructing an international SWIFT wire.

Paying local suppliers without correspondent banking cost. For operators with meaningful supplier payables in a specific market — Philippines, Mexico, India — a funded local account allows payouts on domestic rails (InstaPay, SPEI, UPI) rather than via SWIFT correspondent chain. The cost and timing advantage is material for EM payables.

Virtual IBANs from specialist platforms abstract the complexity of opening local bank accounts. Airwallex, Nium, and comparable providers issue virtual IBANs in multiple jurisdictions as part of their platform — the operator holds a single account relationship with the platform, and the platform routes payments to and from local rails. This is operationally significantly lighter than opening legal entities and bank accounts in each currency jurisdiction.

Important: distinguish between platforms that actually hold local licences and process payments locally versus those that use correspondent arrangements to reach local rails. The former provides cleaner settlement and more reliable timing. Due diligence on regulatory standing — not just coverage — is warranted before routing material volume through any virtual IBAN provider.

The SWIFT ISO 20022 migration, which reached mandatory cutover on 22 November 2025 (per the SWIFT-published cross-border payments timeline), has improved remittance data quality for operators staying on SWIFT — though many institutions still rely on in-flow translation rather than native MX processing during the post-cutover adjustment period. For EM corridors where SWIFT correspondent banking adds material cost, virtual IBAN infrastructure on local rails remains the more efficient choice.

When Stablecoins Are Relevant

Stablecoins serve a specific, bounded role in multi-currency treasury. They are not a general substitute for bank accounts and are not relevant for most domestic or developed-market treasury operations. They are relevant in three scenarios.

EM payout corridors where SWIFT economics are weak. Cross-border B2B payment costs on SWIFT for EM corridors typically include $25–45 in wire fees plus 0.8–1.5% FX spread on the conversion (operator estimate; see linked corridor analysis), with additional correspondent banking deductions that vary significantly by corridor and are often not transparent at the time of sending. For operators with material supplier payables in Mexico, South and Southeast Asia, or parts of MENA, stablecoin settlement rails can reduce total round-trip cost and settlement time materially. The economics are corridor-specific and depend on on/off-ramp provider coverage and cost — the detailed corridor analysis is in Stablecoins for B2B Settlement: Where They Actually Work and the ramp cost mechanics in Stablecoin On/Off-Ramp Operations.

USD-equivalent treasury buffer during settlement. An operator receiving USD and waiting to convert to their functional currency may hold USDC rather than USD in a bank account if they lack a US bank account or need settlement to arrive faster than ACH banking allows. USDC preserves USD value, can be held and transferred in hours, and off-ramped to fiat when needed. The key requirement: custody must be established before using USDC as an operational buffer. For the custody decision, see Stablecoin Treasury Operations: Custody, Keys, and Multisig.

Settlement float between confirmed receipt and bank credit. Some operators hold stablecoin for 24–72 hours between receiving funds on-chain and off-ramping to fiat — maintaining USD value without triggering an immediate conversion. This is a narrow use case but avoids conversion timing risk when bank settlement windows are inconvenient.

Stablecoins are not relevant as a yield instrument for operating treasury, as a primary operating account, or for developed-market corridors where modern SWIFT gpi provides competitive economics and strong remittance data.

Common Treasury Mistakes

Treating PSP auto-conversion as free. The FX spread is not zero because it is not disclosed as a fee. At scale, the embedded spread is often the largest variable cost on cross-border volume, exceeding the disclosed acquirer margin. FX Markup Economics measures this.

Confusing hold with hedge. Holding EUR in a EUR account because you will spend EUR next month is sensible treasury. Holding MXN for three months because you expect MXN appreciation is FX speculation dressed as treasury management. The decision rule for holding should be cost reduction and natural hedge, not exchange rate views.

Running forward hedges below meaningful thresholds. Forward contracts on amounts below $500K (indicative; confirm with your bank) often cost more in admin overhead and minimum fees than the hedging benefit. Natural hedges and batch conversion timing are more practical at smaller scale.

Opening local accounts before automating reconciliation. A local EUR account that receives EUR bank transfers is operationally efficient only if your AR system can match those transfers to invoices. The cross-border B2B AR problem applies here: a virtual IBAN that receives funds without structured remittance data still requires manual reconciliation. Get the reconciliation infrastructure right before expanding local account coverage.

Modelling stablecoin corridors on gas fees alone. The on-chain transfer costs cents. The on-ramp and off-ramp at each end of the corridor are where the real cost accumulates — typically 10–150 basis points each, depending on corridor and provider. The round-trip cost is the sum of both ramps plus gas, not just the chain fee.

Not monitoring PSP reserve currency. Rolling reserves held by your PSP are often denominated in USD even when your revenue is EUR-heavy. If the USD strengthens significantly against your functional currency while a substantial reserve balance is held, the mismatch creates an implicit FX loss on funds you thought were stable. Check your PSP agreement for reserve currency denomination and whether conversion applies at release.

Ignoring the working capital layer. Reserve and settlement float represent capital trapped outside your operational accounts. On a 10% reserve rate with a 90-day hold for $2M monthly volume, the reserve alone locks up roughly $600,000. Add T+3 settlement float (about $200,000 continuously) and total inaccessible capital approaches $800,000. At a 6% cost of capital, this is roughly $48,000 per year in implicit working capital cost — before any FX consideration. The interaction between settlement architecture and treasury architecture matters. See Working Capital Cost of Payments for the full methodology.

What to Read Next

The FX and working capital foundation this framework sits on:

FX Markup Economics: How Cross-Currency Acceptance Quietly Eats Margin — how PSP FX spreads are structured, how to measure yours, and when bulk conversion starts making sense.

Working Capital Cost of Payments: Reserves, Settlement Timing, Float — the capital your PSP holds as reserves and settlement float, how to calculate its real cost, and which contract terms move it.

The cross-border infrastructure layer:

Why Cross-Border B2B Payments Are Still Broken — the structural problems in SWIFT correspondent banking that drive the case for alternative rails and multi-currency treasury.

SWIFT gpi vs Local Rail Interconnects — which cross-border settlement infrastructure to use for which corridor.

Cross-Border B2B AR: The Infrastructure Problem — the receivables side: virtual IBANs, remittance data, and reconciliation for B2B collection.

When stablecoins enter the treasury stack:

Stablecoins for B2B Settlement: Where They Actually Work — corridor-by-corridor analysis of where stablecoin rails beat SWIFT economics.

Stablecoin On/Off-Ramp Operations: Where the Cost Advantage Gets Eaten — ramp provider landscape, cost structure, and round-trip economics.

Stablecoin Treasury Operations: Custody, Keys, and Multisig — custody, key architecture, and operational security for operators holding stablecoin balances.

The full cross-border reading list — from structural problems through rails, FX mechanics, corridor analysis, and stablecoin settlement — is at the Cross-Border Payments Reading List.