Airwallex Guide: Multi-Currency Accounts and Local Collection

Airwallex Guide: Multi-Currency Accounts, Local Collection and Trade-offs

Cross-border teams often find their money fragmented: acquiring at one provider, marketplace payouts at another, supplier payments through a third, and currency conversion calculated separately. Founded in Melbourne in 2015, Airwallex targets exactly that problem by putting multi-currency balances, local collection, FX, acquiring, card issuing and spend management into one back office.

One point to be clear about first: this is account infrastructure. It solves how money moves in, out and between currencies, not how to make more buyers complete a purchase. Miss that line and you end up comparing it with an acquirer on conversion rate and drawing conclusions that mean nothing.

1. Onboarding and entity requirements

Airwallex serves legal entities with cross-border operations. Commonly usable jurisdictions include Hong Kong, Singapore, Australia, the UK, Europe and the US; the exact list and required documents, such as business registration, business description, website information and beneficial owner details, should be confirmed on the official site and with the account team.

Mainland China entities generally cannot open accounts directly and need an offshore entity alongside. Onboarding takes longer than a pure SaaS acquirer, so build the timeline into planning: entity registration, onboarding review, first live collection; only after all three is the account genuinely usable. How the entity and its jurisdiction affect account availability is covered in the Cross-Border Seller Entity Structure Guide.

1.1 KYB document checklist

Requirements vary by market but share a common shape. Prepare five groups:

Registration evidence: certificate of incorporation, business registration, articles or memorandum, confirming the entity exists and its ownership can be explained.
Ownership and beneficial owners: shareholder register, identity and address proof for ultimate beneficial owners. The more holding layers, the more look-through documents are needed.
Contracts or trade documents: agreements, orders, invoices and logistics records with buyers and suppliers, showing that funds move for real commercial reasons.
Website and product description: a publicly reachable site, a clear product or service description, and visible pricing and delivery terms.
Refund and privacy policies: pages that match the actual business process rather than boilerplate copied from elsewhere.

1.2 Why trade authenticity dominates the review

Account products are reviewed differently from acquiring. An acquirer asks whether a card transaction carries dispute risk; an account provider asks why the money moves and whether a real trade sits behind it. The first question can be handled with transaction-level risk rules, but the second has to be answered at onboarding.

The reason is that an account can move money on your behalf. An unexplained inflow paired with an unexplained outflow is effectively a conduit, and conduits are exactly what gets abused. That is why reviewers want contracts, invoices and logistics records that connect buyer, you and supplier.

Once that clicks, document preparation has a direction: the goal is not a thicker folder, but a reviewer who can restate your business model and fund path after a few minutes of reading.

1.3 Five common reasons for document requests

Incomplete ownership chain: only direct shareholders were submitted, with no explanation of upstream holding vehicles and ultimate beneficial owners.
Website inconsistent with the declared business: the application says B2B wholesale while the site is a retail landing page, or the site cannot be opened at all.
Documents that do not reconcile with statements: contract, invoice and received amounts differ visibly with no explanation.
Vague purpose of funds: "goods payment" or "service fee" with nothing tying it to a specific trade or counterparty.
Missing refund and dispute descriptions: no page explaining how buyers request refunds, or a description that does not match the real process.

Requests for more documents are not the problem; inconsistent answers are. Keep an internal master document describing the business, and derive every external statement from it, so different people do not tell different stories.

1.4 What determines review time

Review time is not a fixed number. Four things drive it: due diligence requirements in the jurisdiction of registration, whether the business model is in a higher-scrutiny category, whether the documents arrive complete, and whether extra compliance review is required.

The part you can compress is your own: complete documents on the first pass, consistent explanations, and one named contact replying for the company. That cuts down the number of round trips. The part you cannot compress is their process, and pushing hard usually returns a template answer.

2. Six core capabilities

2.1 Multi-currency accounts

Hold balances in multiple currencies, commonly described as more than twenty, within one back office, each with separate bookkeeping. For teams collecting USD, EUR and GBP, this removes the work of shuttling money between banks and platforms.

The clear need is a business with buyers in several currency zones and suppliers in several currency zones that does not want a conversion on every receipt and payment. The balances then act as an internal pool: money comes in, stays put, and conversion happens when there is an actual payment to make.

The equally clear non-need is a single market, single currency business that settles immediately and pays domestic suppliers. There, multi-currency balances are one more hop with one more reconciliation routine.

2.2 Local collection

Collect through local clearing networks in multiple markets, so the account details your customer sees are local. This removes intermediaries and cost from cross-border transfers and makes payment easier for the payer.

The need is sharpest in B2B. Corporate buyers pay locally as a matter of habit: a cross-border wire means correspondent details, intermediary banks and unpredictable arrival, and many procurement processes simply will not accept it. Handing over local account details removes that friction entirely.

The case where it adds little is a pure marketplace seller. If all your revenue arrives as scheduled platform payouts, your counterparty is the platform rather than the end buyer, and local account details do much less. For a comparison of collection routes, see the Cross-Border Collection Comparison.

2.3 FX and cross-border payments

Conversion and payment happen in one flow, with currency and delivery form selectable. Batch payments help when settling suppliers or distributed teams on a schedule.

The need is a team whose money already sits in the account and must go out in several currencies: ad spend in USD, suppliers in RMB, salaries across markets. Routing each direction through a bank turns filing and reconciliation into a full-time chore, and batch payments compress the repetition into one submission.

Where it adds little: few payments, large amounts, fixed counterparties. Bank wires are not expensive in that shape, and their documentation and audit trail often suit finance better.

2.4 Online acquiring

Website and API acquiring can be connected to the account, so collected funds land directly in multi-currency balances instead of first arriving in a single-currency bank account.

Be precise about the boundary. It does acquire, but acquiring capability depends on the markets actually enabled, the settlement currencies and card scheme coverage, and local acquiring is not equally good in every market. Card acquiring is usually more developed in mature markets, while local payment method coverage in longer-tail markets has to be confirmed one by one.

So the fair expectation is "a landing point for funds plus acquiring in the main markets", not "one global local-acquiring solution". Buyer-side payment method experience, 3DS strategy and chargeback handling still need per-market validation, and markets with strong local method preferences usually need a dedicated local acquirer alongside.

2.5 Cards and spend management

Virtual and physical cards cover ad spend, subscriptions and travel. Bringing these into one system gives far better limit control, categorisation and reconciliation than a drawer of personal cards.

The need is a team spending heavily on ads and SaaS: issue a card per project or channel, set a limit, freeze it on demand. That controls budget and reduces exposure if card details leak.

Where it adds little: small spend across one or two company cards. The value comes from managing many cards, projects and currencies; without that complexity it is just a nicer interface on an expense process.

2.6 API and embedded finance

Platform businesses can embed accounts, FX and card issuing into their own products. This requires engineering capacity, but lets a platform offer cross-border money movement without building a licensing stack itself.

The need is a platform hosting many small sellers or service providers: it wants collection, pre-split fund aggregation and supplier payments abroad inside its own interface, without asking users to open an offshore bank account.

Where it adds little: a single-entity business. With nobody else's money involved, embedded capability has a poor return, and direct back-office automation through the API is enough.

3. Fund paths and account structure

The feature list tells you little on its own; the fund path decides the experience. The same set of features can produce very different reconciliation effort and FX cost depending on how money is routed.

3.1 Local collection accounts versus a global multi-currency account

The two get conflated. A local collection account is an entry point for receiving in the local currency through the local clearing network, and its focus is the payer's experience. A global multi-currency account is a place to hold balances in many currencies, and its focus is your own treasury.

The first answers how others pay you; the second answers where the money sits afterwards. They are usually used together, but when budget and attention are limited the order matters: confirm first that key markets offer local account details, then look at how many currencies the balances actually need to cover. For the wider strategy, see the Multi-Currency Payment Account Guide.

3.2 How funds move between balances

Three actions cover most of it: inflow, internal conversion and payout. Inflows land in the matching currency balance; internal conversion exchanges between balances; payouts leave in the target currency along the chosen route.

Avoid pointless conversions. A common waste is converting everything into one currency on receipt and then converting back to pay a supplier, paying a spread at each step. Keeping the original currency and converting only when a payment is due is usually cheaper.

A second, easily missed point is balance layers: which balances are freely available and which are restricted by pending settlement or review must be tracked separately. Blended together, they overstate available cash.

3.3 FX spread and fees are two different costs

Conversion cost has two parts: an explicit fee and a spread embedded in the rate. The first is visible on a statement, the second hides in the gap between the quoted rate and the mid-market rate.

That is why "free conversion" misleads: the fee can be waived, the spread cannot. The workable comparison is to take the executed rate at a given moment, align it with the public mid-market rate and compute the gap, rather than comparing who advertises zero fees. Treasury design and multi-currency position management are covered in the Platform Treasury Architecture Guide.

3.4 Choosing a payout route

There are usually two: local payment and cross-border wire. The choice is not driven by a rate card but by three things: whether the counterparty can receive a local transfer, the amount and frequency, and the documentation required.

Local payment fits counterparties with local accounts, frequent payments and smaller amounts. Wires fit large amounts, counterparties that only accept them, and finance teams that need bank-issued confirmation. When both are in use, record route, currency and fee in one table, or month-end reconciliation becomes painful.

4. What it does not solve

Drawing the boundary is more useful than listing features. Three things should not be expected from the account layer.

First, buyer-side payment experience is not its job. Which cards buyers use, whether 3DS challenges fire, and how disputes are decided and represented all depend on the acquirer and card scheme rules you connect. The account layer handles what happens to the money after it arrives; it does not move checkout conversion.

Second, collecting on behalf of customers cannot be replaced by an account layer. Holding client funds involves ownership, splitting and licensing questions, and the account layer supplies tools, not permissions. That road needs a licensed split-settlement arrangement or a merchant-of-record model; the architectural differences are in the Independent Store Payment Architecture Guide.

Third, a multi-currency account is not multi-currency pricing. Pricing currency is a commercial decision: which currency you quote in a market shapes price perception and determines who carries FX risk, and none of that depends on how many currencies the account supports. Being able to collect euros does not mean you should price in euros.

5. Fee structure

Airwallex costs typically split across accounts and collection (some scenarios have no account fee; collection is charged per item or as a percentage), FX (quoted as a spread, competitive with or better than bank rates depending on the day), cross-border payments (per item), acquiring (percentage plus fixed fee) and cards (possible issuance and annual fees).

The right way to judge is the whole chain: collection cost plus FX spread plus payment fees plus acquiring rate. Compare that chain with the traditional route of marketplace payout into a collection account and then domestic settlement; the difference usually shows up in the FX spread.

5.1 Explicit rates

Explicit items are the ones you can read off a rate card: per-item or percentage collection fees, per-item cross-border payment fees, percentage plus fixed fee for acquiring, and card issuance or annual fees. These are easy to compare, and easy to mistake for the whole picture. Actual figures follow the official documentation and your contract.

5.2 Hidden costs

Hidden items rarely appear on the front page of a rate card: FX spread, off-hours rate quotes, withdrawal or transfer-out fees, and the cost of returned payments. Individually they look small, but in high-frequency, multi-currency operations they compound into a meaningful share.

The hardest to quantify is timing. Quotes are live while finance processes paperwork by the day or week, and the rate movement in between is a real cost that appears on no invoice.

5.3 When total cost runs past expectations

Many payments of small value, where per-item pricing gets amplified and the fixed component takes over.
Currency round trips, where each conversion adds a spread that never shows up as an error in the business.
Using balances for short-term working capital, where funds sit in several places and the cost of moving and reconciling them is underestimated.
Comparing rate cards instead of the whole chain, where cheap acquiring masks expensive FX, or the reverse, and either view alone leads to the wrong conclusion.

A full self-audit method is in the Payment Fee Audit Guide.

6. Advantages and limitations

Advantages

Multi-currency balances and local collection together, so both how to collect and where the money sits are handled in one place.
Conversion and payment in one flow, cutting the number of hops between banks and platforms and shortening the cash cycle.
Acquiring funds land directly in multi-currency balances rather than arriving in a single-currency account first.
Cards and spend management cover the outbound side, so ad and subscription spend can be controlled per project.
API capability supports platform scenarios, letting a platform offer cross-border money movement without building its own licensing stack.

Limitations

Onboarding thresholds and review time exceed pure acquirers, so leaving that time out of the plan delays launch.
Entity requirements exclude many mainland China teams; without an offshore entity there is little to discuss.
As account infrastructure it does not improve buyer-side conversion, since local payment method experience still depends on the acquiring layer.
The product line is broad: accounts, FX, acquiring and cards each carry their own process and reconciliation rules, and it takes time to run them smoothly.
Concentrated accounts mean concentrated risk. With balances in one place, a compliance review that restricts funds affects every currency, so documents and transaction context should be kept current as a routine.

7. Who it fits

Good fit: teams selling across countries, needing multi-currency balances and local collection, with cross-border supplier payments and centralised control of ad and subscription spend; platform businesses evaluating embedded payment capabilities.

Weaker fit: single-market teams collecting one currency; independent developers who only need a checkout button and have no fund movement problem.

The more useful judgement sits between those two. If your pain is money scattered across providers and conversion costs nobody can explain, it is worth evaluating. If your pain is a low-converting checkout page, what you need is an acquirer and payment method coverage, not an account layer.

8. Launch checklist

Entity and documents first: confirm the jurisdiction works and complete KYB in one pass, rather than fixing the entity after launch.
First live collection: run a small real transaction through inflow, balance and payout to prove the chain works.
Align the currency list: put buyer currency, balance currency and supplier payment currency in one table and check for gaps.
Record FX rates: confirm the executed rate and timestamp of every conversion can be exported, or reconciliation cannot close.
Verify collection details: check the local account format market by market and whether payers can recognise it, and prepare payment instructions if needed.
Permissions and approvals: split operator rights by role and require approval for payouts, so no single login can move the whole balance.
One reconciliation standard: fix statement download frequency, field definitions and the mapping into your accounting system.
Change regression: when entity, business model or collection markets change, assess early whether a new review is required.

9. How it splits work with Adyen, Stripe and PingPong

The roles differ: Adyen and Stripe solve acquiring and approval rates, Airwallex and PingPong focus on fund aggregation and movement, and PayPal is a buyer-side wallet option. A cleaner split has three layers:

Acquiring layer: Adyen, Stripe, Checkout.com and similar, handling authorisation, 3DS, disputes and payment method coverage at the moment of payment.
Fund layer: account services such as Airwallex, WorldFirst and PingPong, handling multi-currency balances, local collection, FX and batch payouts.
Wallet layer: buyer-side accounts such as PayPal, present as a payment method that changes buyer choice rather than your fund structure.

The three layers do not conflict, and one company can use all of them. The acquiring layer decides conversion, the fund layer decides capital efficiency, and the wallet layer decides whether some buyers pay at all. The common setup is acquiring through Stripe or Adyen, aggregation through a multi-currency account, and a wallet shown alongside. Differences against account services such as PingPong come down to available markets, collection options and supporting features, and deserve a line-by-line comparison against your own market mix.

The full role map is in the Cross-Border Payment Selection Matrix. On sequence: settle the acquiring layer first, then the fund layer, and only then decide whether the wallet layer is worth adding. Do it the other way round and you will build an awkward fund structure around a preference for one payment method.

Source: 16IDC original. Capabilities, eligibility and pricing follow https://www.airwallex.com official documentation and contract terms.