Executive summary: what this guide covers
Search for "global finance" and you'll mostly find macroeconomics — capital flows, exchange-rate regimes, the architecture of international markets. That's a legitimate field, and it's not what most people typing this phrase into a search bar need. Businesses looking for global finance accounts are asking something much more operational: how do I hold money in several currencies, get paid by customers in their local currency, pay suppliers and contractors abroad, and control card spend across countries — without bleeding value on FX and wire fees at every hop?
This guide answers that question at the account level. It explains the anatomy of a multi-currency business account, the meaningful difference between a genuine local account and a virtual collection account, how correspondent banking and local payment rails determine what you pay and how long you wait, and a five-step framework for structuring accounts by legal entity, currency, and payment corridor.
Who this guide is for
Founders, finance leads, controllers, and operations people at companies that touch more than one currency. That includes SaaS businesses billing in USD, EUR, and GBP; marketplaces paying contractors across a dozen countries; ecommerce brands selling into multiple regions; and digital-first or decentralized organisations — including DAOs — that need fiat operations alongside an on-chain treasury.
It is also useful to anyone who has been told "just open a global business bank account" and discovered that phrase describes at least four different products with very different mechanics.
The 60-second version
- A global finance account, in business practice, is a multi-currency business account — one relationship that holds balances in several currencies, provides account details for receiving funds in key markets, sends outbound payments over local or international rails, and usually issues cards.
- The two structural questions that matter most are: what account details do I actually get in each market (real local account vs. virtual collection details vs. neither), and what rail does an outbound payment travel on (local scheme vs. SWIFT correspondent chain).
- Your total cost is rarely the headline fee. It is the fee plus the FX spread over the interbank rate, plus intermediary deductions, plus the cost of failed or delayed payments and the reconciliation work they create.
- Provider coverage, limits, pricing, and eligibility vary enormously and change often. Verify them directly with each provider and in their terms — including anything you read here.
What is the difference between 'global finance' as an economic system and a global finance account for a business?
Meaning one: the system. Global finance as a field of study — cross-border capital markets, central bank policy, international settlement infrastructure, institutions like the BIS, IMF, and World Bank. If you're writing a paper or studying capital flows, that's your lane, and the rest of this guide will only be tangentially useful.
Meaning two: the account. A commercial banking or e-money product that lets a company operate financially in more than one country and currency. Everything below is about this.
The two are connected — the account you open sits on top of the system, and the system's plumbing (correspondent banking, settlement windows, sanctions regimes) is exactly why your Tuesday-afternoon payment to Manila takes three days. Understanding the plumbing makes you a better buyer of the product.
What is a global finance account and how does it differ from a normal business bank account?
Plain-language definition
A global finance account is a business account that lets you hold, receive, convert, and send money in multiple currencies from a single platform, with account details or payment capability in more than one country.
A normal domestic business bank account, by contrast, holds one currency, gives you account details in one country, and converts anything arriving in a foreign currency on receipt at whatever rate the bank applies. The difference is not the ability to send money abroad — most domestic accounts can wire internationally — but the ability to hold several currencies without forced conversion and to be paid locally in more than one market.
In the market you'll see it sold under several names: multi-currency account, global account, foreign currency account, global collection account, borderless account. The label is marketing; the mechanics are what differ. A useful mental model is that any such account is a bundle of four capabilities, and providers implement each one differently:
- Receive — the account details customers pay into, per currency and per market.
- Hold — segregated or on-balance-sheet balances in each currency, without forced conversion.
- Convert — FX between held balances, at some rate, with some spread.
- Send — outbound payments over local rails, SWIFT, or (increasingly) blockchain rails.
Cards, invoicing, expense management, and approval workflows sit on top as software layers.
What a global finance account lets a business actually do
Concretely, a well-configured setup means:
- A German customer pays a euro invoice by SEPA transfer to euro account details — no international wire on their side, no correspondent deduction, no "your bank charged me €18" support ticket.
- A US customer pays by ACH into USD details, and the funds land as USD, not as a converted euro balance stripped of 1–2%.
- You hold that USD until you actually need euros, so you're choosing when to convert rather than being converted at settlement.
- You pay a contractor in Poland in złoty and a supplier in Singapore in SGD from the same dashboard, with an audit trail.
- Your team spends on corporate cards denominated in the currency they're spending in, so a EUR-region hire's SaaS subscriptions don't attract a conversion fee on every charge.
That's the value proposition of cross-border payments for businesses done properly: fewer conversions, fewer intermediaries, fewer surprises.
Scope: what it is not (investment account, PSP, treasury system)
Three distinctions worth nailing down early, because conflating them causes bad purchasing decisions.
It is not an investment or brokerage account. A global finance account is for operational money movement. It typically does not offer securities, managed FX hedging products, or interest-bearing investment sleeves (some providers offer yield features; treat those as separate products with separate risk).
It is not a payment service provider (PSP). A PSP or merchant acquirer — Stripe, Adyen, PayPal and similar — processes card and checkout payments from your customers. It collects, then pays out to a bank account. A global finance account is where that payout lands and where your outbound money movement happens. Most businesses need both, and they solve different problems.
It is not a treasury management system (TMS). A TMS is software for cash forecasting, liquidity planning, hedging, and multi-bank aggregation. A global account is a place money sits. Larger companies operate both; smaller ones often use the reporting layer of their account provider as a lightweight substitute until complexity forces the upgrade. If you're heading in that direction, global treasury management is the discipline to read up on next.
Core concepts and commonly confused terms
Multi-currency account vs. multiple single-currency accounts
Multiple single-currency accounts means separate accounts, often at separate institutions, each holding one currency. Five currencies means five logins, five sets of statements, five compliance relationships, and manual wires between them when you need to rebalance.
A multi-currency account consolidates balances under one relationship and one interface. You see all currencies in a single ledger view, convert between them internally, and pay out from whichever balance makes sense. As Stripe's overview of how multicurrency bank accounts work explains, the practical benefit is avoiding automatic conversion on every inbound and outbound transaction — you decide when currency risk crystallises.
The tradeoff: consolidation concentrates counterparty and operational risk. If one provider freezes an account during a compliance review, everything freezes. Mature finance teams deliberately keep a secondary relationship for this reason.
How does a multi-currency account actually hold and convert currencies?
Holding. In most implementations, each currency balance you see is a ledger position on the provider's books. Behind it, the provider holds funds in that currency in its own accounts — at a partner bank, a local correspondent, or a safeguarding account, depending on its licence. So a "EUR balance" and a "USD balance" are not two bank accounts you own; they are two entries in one ledger, each backed by real funds held in the corresponding currency. The practical consequence is that nothing is converted on receipt: euros arriving stay euros until you instruct otherwise.
Converting. A conversion is a trade, not a transfer. The provider quotes you a rate sourced from its liquidity providers or interbank pricing, then debits the source-currency balance and credits the target-currency balance on the same ledger. No money crosses a border and no payment rail is involved — the currency change happens internally, usually instantly. Rails and correspondent chains only come into play when funds leave the platform.
Two implications worth holding onto:
- Because conversion and payment are separate events, you can decouple them: convert when the rate or your cash-flow calendar suits you, pay when the invoice is due.
- Because the provider sets the rate, the spread it applies is the real price of the conversion — see the mid-market discussion below.
What is the difference between a local account and a virtual collection account?
This is the single most misunderstood distinction in the category, and it directly affects whether customers can pay you cheaply.
A true local account is an account held at an institution in that jurisdiction, in your company's name, with local account details and full access to that country's domestic payment schemes. It typically requires a local entity or, at minimum, a local presence and a full onboarding process there.
A virtual collection account (often marketed as a virtual IBAN account, virtual account, or global account) gives you local-format details — an IBAN, a US routing and account number, a UK sort code and account number — that route inbound funds into your balance with a provider that may be domiciled elsewhere. Providers like Airwallex describe these as global accounts precisely because the details are local while the underlying relationship is not.
Why the difference matters in practice:
- Payer experience. Both usually let a domestic customer pay by local transfer, which is the main win.
- Name matching. Some virtual accounts are issued in the provider's name with a reference, not yours. Certain payers — government agencies, large enterprises with strict beneficiary-name checks, some payroll systems — will reject that. Ask explicitly whether the details are in your legal entity's name.
- Direct debits. Collecting by SEPA Direct Debit or ACH debit often requires capabilities a virtual account may not support.
- Scheme membership and deposit treatment. A local bank account may carry deposit insurance in that jurisdiction; e-money balances are usually safeguarded instead (see below). Different protection, different mechanics.
- Regulatory and tax optics. Where an account is legally held can matter for local licensing requirements, banking references, and audit questions.
SWIFT sits apart from both: it's a messaging network for international transfers between institutions, not a local scheme. A "SWIFT account" isn't a product type — it means your account can send and receive international wires identified by BIC and, usually, IBAN.
Neo-banking vs. traditional bank vs. EMI vs. payment processor
| Type | What it is | Typical strengths | Typical constraints |
|---|---|---|---|
| Traditional/global bank | Licensed deposit-taking institution | Broad country coverage, credit, deposit insurance, institutional credibility | Slow onboarding, conservative risk appetite, dated UX, opaque FX |
| EMI / payment institution | Licensed to issue e-money and process payments, not to take deposits or lend | Fast onboarding, strong multi-currency and FX UX, modern APIs | No lending, safeguarding rather than deposit insurance, coverage gaps |
| Neo-banking platform | A software-first provider delivering banking-like services, often on partner bank or EMI licences | Consolidated multi-currency, cards, payments, reporting in one product; appetite for digital-native sectors | Depends on underlying partners; product breadth narrower than a full bank |
| PSP / processor | Merchant acquiring and checkout | Card acceptance, subscriptions, fraud tooling | Not a place to hold or send treasury funds |
The word "bank" gets used loosely across all four. What matters legally is the licence behind the product and who holds your money — which the provider must be able to state clearly, in writing.
Settlement, FX conversion, and the mid-market rate
Settlement is the moment funds irrevocably move between institutions. A payment can be "sent" in your dashboard and not yet settled at the receiving bank; the gap is where cut-off times, currency holidays, and correspondent processing live.
FX conversion is a trade. There is a reference rate — commonly called the mid-market or interbank rate, the midpoint between bid and ask in the wholesale market — and there is the rate you're offered. The difference is the spread or markup, and it is a fee whether or not it's labelled one.
Read pricing as two components: explicit fee (a fixed amount or percentage) and implicit spread (bps over reference rate). A provider advertising "zero-fee transfers" with a 1.5% spread is more expensive on a $50,000 payment than one charging a $15 fee with a 0.3% spread. Do the arithmetic on your actual volumes and ticket sizes, not on a generic comparison. A quick way to sanity-check a quoted rate is to compare it against a live reference using a currency converter before you confirm the trade.
Safeguarding, segregation, and where your money actually sits
If your provider is an EMI or payment institution rather than a bank, your balance is generally not a deposit. It's typically safeguarded — held in segregated accounts at credit institutions or in qualifying liquid assets, ring-fenced from the provider's own funds so that in an insolvency it should be returned to customers ahead of general creditors.
This is a genuinely different protection model from deposit insurance schemes like FDIC or EU deposit guarantee schemes. Neither is universally "safer" — they fail differently. What you need to know, per provider:
- Which entity and licence holds your funds, in which jurisdiction?
- Are funds safeguarded, insured as deposits, or held via a partner bank arrangement (and if so, which bank)?
- Does the answer differ by currency or by market?
Ask, and get the answer in the terms and conditions rather than from a salesperson.
How do cross-border payments move through correspondent banking and local rails?
Correspondent banking and the SWIFT chain
Banks don't have accounts everywhere. To move money into a currency and country where it has no presence, a bank uses a correspondent — an institution that holds an account relationship (nostro/vostro) in that market.
A typical international wire looks like this:
Your bank → its correspondent → (possibly a second correspondent)
→ beneficiary's bank → beneficiary account
Each hop is an institution that: applies its own cut-off times, runs its own compliance screening, may deduct a fee from the principal, and may re-key or truncate payment reference data. Three hops means three chances for delay, deduction, or a data-loss-induced failure. The BIS has documented a long-term decline in the number of active correspondent relationships globally, which means fewer, longer chains on some corridors — one structural reason why certain routes remain slow and expensive.
Fee conventions matter here too. On SWIFT, charges are typically OUR (sender pays all), SHA (shared), or BEN (beneficiary pays). If you send SHA or BEN, your supplier receives less than the invoice amount and someone has to reconcile the shortfall.
Local rails: SEPA, ACH, Faster Payments, and regional equivalents
Domestic schemes are cheaper and faster because they skip the correspondent chain entirely:
- SEPA Credit Transfer / SEPA Instant — euro payments across the SEPA area.
- ACH — US batch payments; economical, not instant. Fedwire for same-day high-value; RTP and FedNow for instant.
- Faster Payments / CHAPS / Bacs — UK instant, high-value, and batch respectively.
- Regional equivalents: PIX (Brazil), UPI (India), NPP (Australia), Interac (Canada), FPS (Hong Kong), and many more.
The strategic point: a provider's real value is how many of these rails it can reach locally for both collections and payouts. A payment that starts as a card charge in Brazil and lands as a local PIX payout has never touched SWIFT. That's where the cost and speed advantage comes from — not from magic FX.
Why do international transfers cost more or take longer than domestic ones?
Because they involve more institutions, a currency trade, more compliance checks, and no shared operating calendar. Concretely, here is where the money and the days go, in rough order of how often they bite:
- FX spread — usually the largest cost and the least visible.
- Intermediary deductions — correspondent banks taking a cut mid-flight.
- Cut-off times and value dates — miss a 3pm cut-off and you've added a day; hit a currency holiday in either country and you've added more.
- Compliance holds — a screening hit on a name, country, or payment purpose. Legitimate, and slow.
- Bad beneficiary data — wrong IBAN, missing intermediary BIC, missing purpose code (required for several APAC and Middle East corridors), name mismatch. Repairs cost fees and days.
- Currency/country restrictions — some currencies are non-deliverable or require documentation; some corridors require in-country licensed partners.
Most "the bank is ripping us off" incidents are actually one of items 3–6 combined with item 1.
How stablecoin and blockchain rails change the picture
Blockchain settlement introduces a fourth rail type alongside local schemes, SWIFT, and card networks. Its structural properties: near-continuous operation (no cut-offs, no weekends), settlement finality measured in seconds to minutes, and no correspondent chain.
What it doesn't remove:
- The on/off ramp. Someone still has to convert fiat to stablecoin and back, and that conversion has a spread and a compliance process. The ramp is where the cost and the friction now live.
- Compliance obligations. Sanctions screening, KYC/KYB, and transaction monitoring apply. Blockchain analytics add wallet-level screening on top.
- Counterparty and issuer risk. A stablecoin is a claim on an issuer, and reserve quality, redemption terms, and applicable regulation vary by token and jurisdiction.
- Accounting complexity. Digital asset treatment, revaluation, and disclosure need deliberate policy. Talk to your auditor before, not after.
For organisations already operating on-chain, the interesting architecture is a hybrid: an on-chain treasury for reserves and protocol activity, and fiat accounts for payroll, vendors, and tax — with a controlled, documented bridge between them. Our guide to banking for Web3 goes deeper on how those two halves connect, and crypto banking as a category covers where the rails are heading.
A simple flow diagram: from customer invoice to settled balance
INBOUND
Customer (Germany)
└─ pays EUR invoice via SEPA
└─ your EUR collection details (local-format IBAN)
└─ EUR balance in your global account [no FX, no correspondent]
Customer (USA)
└─ pays via ACH ──► USD details ──► USD balance [no FX]
Customer (card)
└─ PSP settles ──► payout to your USD/EUR details ──► balance
TREASURY DECISION
Hold, or convert at a rate you choose (reference rate + spread)
OUTBOUND
EUR balance ──► SEPA ──► EU vendor [local rail]
USD balance ──► ACH/Fedwire ──► US vendor [local rail]
USD balance ──► FX to PHP ──► local payout ──► contractor (PH)
USD balance ──► SWIFT ──► correspondent(s) ──► exotic-currency vendor
Any balance ──► corporate card spend, in-currency
REPORTING
Single ledger ──► accounting system ──► reconciliation ──► close
The design goal, visible in the diagram: minimise conversions and minimise hops. Every arrow that involves an FX trade or a correspondent is a place where value and time leak out.
Should a business use one global platform, several local accounts, or a hybrid?
Incumbent global bank: coverage vs. onboarding friction
Best when you need credit facilities, in-country presence in markets neo-providers don't reach, deposit-insured balances, or the institutional credibility that certain counterparties and tenders demand. PNC, for instance, positions multicurrency accounts as part of a broader corporate and institutional services relationship — which is exactly the point: you're buying a relationship, not a product.
Costs: onboarding measured in weeks or months, per-country repetition, conservative risk appetite (digital-asset exposure is frequently a hard stop), and FX pricing that is often relationship-negotiated rather than transparent.
Neo-banking platform: speed and consolidation vs. product breadth
Best when your priority is fast setup, consolidated multi-currency operations, transparent FX, modern APIs, and card issuing — and when your business model sits in a sector traditional banks treat as high-risk.
Costs: no lending, safeguarding rather than deposit insurance, coverage that is broad but not universal, and dependency on underlying partner institutions whose changes can affect your service. Diligence the licence stack, not just the interface.
Local in-country accounts: authenticity vs. administrative load
Best when a market genuinely requires it: local direct debit collection, local payroll and tax remittance, government or enterprise counterparties with strict beneficiary-name checks, or regulatory requirements tied to a local entity.
Costs: an entity or presence, separate onboarding, separate mandates and signatories, separate statements, and the reconciliation burden of another silo. Open these deliberately, per requirement, not speculatively.
Hybrid setups and when they make sense
The common mature pattern:
- One primary multi-currency platform as the operational hub — collections in major currencies, most payables, cards, reporting.
- Local accounts in one to three "deep" markets where regulation, payroll, or counterparty requirements demand it.
- One backup relationship at a second institution holding enough liquidity to run payroll and critical vendors for a defined period if the primary is unavailable.
This survives provider outages and compliance reviews, which single-provider setups do not.
Tradeoff table: control, cost, speed, compliance, and effort
| Dimension | Incumbent global bank | Neo-banking platform | Local in-country accounts | Hybrid |
|---|---|---|---|---|
| Country/currency coverage | Broadest, uneven by bank | Broad in major corridors, gaps in exotics | Deep in one market only | Best achievable |
| Onboarding speed | Slowest | Fastest | Slow, repeated per market | Mixed |
| FX transparency | Often negotiated/opaque | Usually published spreads | Varies, often poor | Mixed |
| Local rail access | Strong where present | Strong in supported markets | Full in that market | Strong |
| Deposit protection | Deposit insurance typical | Safeguarding typical | Local scheme | Mixed |
| Credit and lending | Available | Rarely | Sometimes | Available via bank leg |
| Digital-asset friendliness | Often restrictive | Varies; some specialise | Usually restrictive | Depends on legs |
| Consolidated reporting | Weak across countries | Strong within platform | Weak | Needs deliberate design |
| Admin/ops effort | High | Low | Highest | Medium |
| Concentration risk | Medium | High if sole provider | Low | Lowest |
Weight these against your own flows. A business with 90% of volume in EUR and USD should optimise differently from one paying contractors across fifteen currencies.
Compliance, risk, and regulatory realities
What documents and checks are required to open a global business account?
Every regulated provider must verify who you are and who ultimately controls you. Expect to supply, in some combination:
- Certificate of incorporation, registration extract, and articles/bylaws
- Proof of registered and operating address
- Ownership structure chart, down to ultimate beneficial owners (commonly anyone at or above 20–25%, though thresholds vary by regime and provider)
- ID and proof of address for directors, authorised signatories, and UBOs
- Description of business activity, expected volumes, currencies, and counterparty countries
- Source-of-funds and source-of-wealth evidence
- Financial statements or bank statements, for established entities
- Licences where the activity is regulated
Alongside the documents, expect checks: KYB verification of the entity against registries, identity verification of individuals, sanctions and PEP screening, adverse-media checks, and a risk assessment of your sector and corridors.
Nested holding structures, nominee arrangements, and offshore layers all extend timelines. Prepare a clean structure chart and a one-page business description up front — it materially shortens onboarding.
Sanctions screening and high-risk corridors
Every payment is screened against sanctions and watchlists at each institution it touches. Screening produces false positives, and false positives produce holds. You will reduce friction by:
- Using full, exact legal names for beneficiaries
- Including clear, specific payment purposes and invoice references
- Providing purpose codes where the corridor requires them
- Notifying your provider in advance of unusual large or first-time payments to sensitive jurisdictions
Some corridors are structurally slow regardless of provider, because the correspondent options are limited and the compliance burden is high. No platform "solves" this; some route around it better than others.
Tax, residency, and reporting considerations to raise with an advisor
This guide is not tax or legal advice, and the right answers are entity- and jurisdiction-specific. Raise at least these with a qualified advisor:
- Where accounts are held and whether that creates local reporting or filing obligations
- Foreign account reporting regimes applicable to your jurisdiction and owners
- Functional currency election and how FX gains/losses are recognised
- Transfer pricing when entities in a group lend to or fund each other
- Withholding tax on cross-border payments, especially services and royalties
- VAT/GST treatment of cross-border invoicing
- Substance and permanent-establishment risk if operations follow the account
The order matters: decide your legal and tax structure first, then build the account architecture to serve it. Doing it the other way round is how businesses end up unwinding accounts.
Can decentralized organisations or DAOs open global finance accounts?
In practice, yes — but almost always through a legal wrapper rather than as an unincorporated on-chain collective, and with more diligence than a comparable non-crypto business.
Crypto-native organisations face a real onboarding constraint: many institutions decline the sector outright, and those that don't apply enhanced diligence. Expect questions about token flows, on-chain source of funds, wallet controls, and governance.
The specific challenge for a DAO is legal personhood. A provider needs an entity to contract with and identifiable individuals to hold accountable. Most functioning setups use a wrapper — a foundation, association, LLC, or similar — with documented authority delegating operational control from token-holder governance to named signatories. Without that layer, KYB simply cannot complete. Providers offering financial services for DAOs generally expect this structure to exist, or to be created as part of onboarding.
Implementation framework: a five-step rollout
Step 1: map your currency and corridor exposure
Before evaluating any provider, produce one table from twelve months of actuals:
| Direction | Currency | Corridor | Annual volume | Transaction count | Avg ticket | Current cost (fees + est. spread) | Pain point |
|---|---|---|---|---|---|---|---|
| Inbound | EUR | DE/FR/NL → you | Customers charged wire fees | ||||
| Inbound | USD | US → you | Auto-converted on receipt | ||||
| Outbound | PHP | you → PH contractors | 3-day delays, deductions |
Estimate spreads by comparing executed rates in your statements against historical reference rates on the same dates. This is tedious and it is the highest-leverage hour of the whole project — it converts "FX feels expensive" into a number.
Then rank corridors by volume and by pain. The top three of each define your requirements. Everything else is nice-to-have.
Step 2: How should a company structure accounts across multiple entities and currencies?
Design on two axes.
By entity. Every legal entity needs its own accounts. Do not commingle — it destroys the corporate veil argument, breaks intercompany accounting, and creates audit problems. Map: entity → jurisdiction → currencies needed → functions.
By function. Within an entity, separate accounts (or sub-accounts/virtual accounts) by purpose:
- Collections — one per major currency, so inbound reconciliation is clean
- Operating — the account that pays vendors and general expenses
- Payroll/contractors — separated for access control and confidentiality
- Card funding — a bounded balance limits exposure from card compromise
- Reserve/buffer — tax provisions and runway, deliberately harder to touch
A useful three-entity sketch:
GROUP HOLDCO (Delaware)
├── USD operating account — intercompany funding, investor capital
│
├── US OPCO
│ ├── USD collections (ACH + wire details)
│ ├── USD operating + payroll
│ └── USD card funding ──► corporate cards (US team)
│
└── EU OPCO (Ireland)
├── EUR collections (SEPA, local-name IBAN)
├── GBP collections (Faster Payments details)
├── EUR operating + payroll
└── EUR/GBP card funding ──► corporate cards (EU/UK team)
Step 3: shortlist and evaluate providers against a scorecard
Score each candidate 1–5 and weight by what your Step 1 map says matters:
| Criterion | Weight | What to verify |
|---|---|---|
| Currencies held (not just convertible) | Explicit list; held vs. convert-and-send | |
| Local collection details per market | Are details in your entity's name? | |
| Local payout rails per corridor | Which corridors are local vs. SWIFT? | |
| FX pricing structure | Reference rate used, spread in bps, tiering, weekend/off-hours pricing | |
| Explicit fees | Inbound, outbound, FX, card, account, dormancy, chargeback | |
| Limits | Per-transaction, daily, monthly; how increases are approved | |
| Card programme | Currencies, virtual/physical, limits, controls, spend categories | |
| Licence and safeguarding | Which entity, which regulator, which partner bank | |
| Eligibility fit | Your sector, jurisdiction, and ownership structure | |
| Onboarding | Documents, realistic timeline, named contact | |
| API and integrations | Accounting system, payroll, ERP; webhook quality | |
| Support model | Named contact vs. ticket queue; hours vs. your timezone | |
| Multi-user controls | Roles, approval thresholds, segregation of duties, audit log | |
| Track record | Public incidents, outage history, references in your sector |
Run a corridor test: give each shortlisted provider three real payments from your map and ask for an all-in quote — rail used, expected settlement time, total received by beneficiary. Vague answers are informative.
Compare published spread structures across the market — resources like OFX's explainer on how multi-currency business accounts work and Wise's multi-currency account pages are useful for seeing how differently pricing gets presented — then normalise everything to bps on your actual volumes.
Step 4: migrate payables, receivables, and card spend
Sequence to avoid breaking cash flow:
- Open and fund the new accounts; keep the old ones live in parallel.
- Test small. One low-value payment per corridor. Confirm timing, amount received, and reference data integrity end to end.
- Move payables first. You control these. Update vendor records in batches; get written confirmation of new details.
- Move receivables second, in waves. New customer details go out with invoices, not as a standalone email — and never change bank details by email alone without out-of-band confirmation, in either direction. Invoice redirection fraud thrives on exactly this moment.
- Roll out cards by team with limits and merchant controls set from day one, not retrofitted.
- Wind down old accounts only after two full close cycles run clean. Keep one dormant if it costs nothing — it's cheap optionality.
Budget more time than feels necessary for receivables. Enterprise customers' vendor-master update processes can take a full quarter.
Step 5: instrument reporting, reconciliation, and controls
The accounts are the easy part. Sustainable operations require:
- Direct feed to your accounting system, per currency, with FX revaluation policy documented
- A unique reference per invoice so inbound payments auto-match
- Documented FX policy: who may convert, at what size, within what tolerance, and whether you hold natural currency positions
- Approval thresholds and dual authorisation above a defined amount
- Beneficiary allowlists for recurring payees, with a defined change-control process
- Monthly reconciliation of every currency balance, not quarterly and certainly not annually
- A quarterly FX cost review comparing executed rates against reference rates — the only way to catch spread drift
Worked examples of account architectures
These are illustrative architectures, not case studies. No customer data or outcomes are represented.
SaaS company collecting in USD, EUR, and GBP
Situation. Delaware parent, Irish EU entity. Card payments via a PSP; enterprise customers pay by invoice and bank transfer.
Architecture.
- US entity: USD collections (ACH + wire), USD operating, USD card funding.
- Irish entity: EUR and GBP collection details in the entity's name; EUR operating; GBP held, not auto-converted.
- PSP settles USD to the US entity, EUR/GBP to the Irish entity — avoiding a conversion on every settlement batch.
- FX policy: convert GBP→EUR monthly to cover EUR-denominated costs; hold the rest as a natural hedge against GBP-denominated spend.
Why. Enterprise invoice payers want to pay domestically. GBP details in the entity's name pass strict beneficiary-name checks that a provider-named virtual account may not. See multi-currency business accounts for how the collections layer is typically packaged.
Marketplace paying contractors in many currencies
Situation. Single operating entity, revenue mostly USD, payouts to contractors in 14 countries, twice monthly.
Architecture.
- USD collections and USD operating account as the hub.
- Payout via a platform with local rails into the top corridors by volume; SWIFT reserved for the long tail.
- Contractor onboarding captures full legal name, local account details in local format, tax documentation, and purpose codes where required — at signup, not at first payment.
- Batch payment runs on a fixed calendar, converted in a single FX trade per currency per run rather than per contractor (better pricing tier, one rate to reconcile).
- Fee convention set to sender-pays so contractors receive the full invoiced amount.
Why. For high-count, low-ticket payouts, per-transaction fees and repair fees dominate cost, and batching plus data quality attack both. Paying international contractors is largely a data-hygiene problem dressed as a payments problem.
A DAO or decentralized community bridging on-chain treasury and fiat operations
Situation. Protocol treasury on-chain; obligations include contributor compensation, audits, legal fees, cloud infrastructure, and conference spend — all fiat-denominated.
Architecture.
- Legal wrapper (foundation or LLC) as the contracting entity for fiat accounts, with a governance-approved delegation of operational authority to named signatories.
- On-chain treasury remains under multisig, governed by proposals; policy defines what may be moved to fiat and by whom.
- Bridge layer: a documented process converting a governance-approved amount from treasury assets to fiat, into the wrapper's operating account, on a schedule — with the on-chain transaction h
