Part 2 of 3 in our multi-currency accounts series. Read Part 1, by Rana Palit on why receivables are the new battleground for banks — here.
In Part 1 of this series, Rana made the strategic case; the receivables layer is the new battleground in cross-border payments, and the institutions that control transaction flows — not just deposits — are the ones that will lead.
He also laid out the build/buy/partner choice. Institutions choosing to partner, the platforms building net-new, and the AI-native teams shipping their first treasury layer all end up asking the same next question: what does the infrastructure actually let me build?
That’s the question I will answer in this article.
Every cross-border payments vendor will tell you they offer “global accounts, local rails, one API.” However, the conversations I have with the engineering and product teams who are actually responsible for these builds are not about which currencies we support or what the FX spreads look like.
The conversations that matter are about architecture; what the infrastructure lets you compose, how it responds when things go wrong, and whether it stays out of the way when your product evolves twelve months from now. The infrastructure stays invisible and that is the point.
The building blocks of multi-currency account infrastructure
Multi-currency accounts sound like a single product. In practice, they're a set of primitives that different teams have used to build very different things. The same API surface that a bank uses to offer its corporate clients named accounts in five markets is the same one an expense platform uses to give each of its SMB users a wallet, or a marketplace uses to split commissions in real time. And increasingly, it's what an AI platform uses to let its agents move money without a human in the loop.
What makes this more than just account infrastructure is the orchestration layer underneath — the logic that selects rails, sequences multi-step payment flows, handles failures, and retries automatically. That combination of programmable infrastructure and Nium-grade payment orchestration is what I want to walk through here.
It’s worth being clear about what the primitives actually are, because the names can be misleading.
Virtual Account Numbers (VANs)
VANs are unique account identifiers issued per customer, entity, or workflow. What makes them interesting isn't the account itself — it's the assignment model. Static or dynamic? Named to the end customer or shared? Single currency or multi-currency? That first decision shapes everything downstream, including how reconciliation works, what the compliance story looks like, and how much ops overhead you're taking on.
Local rail assignment
Local rail assignment is often what trips teams up. Developers assume they get one account that works everywhere. In reality, PayID in Australia, PayNow in Singapore, Faster Payments in the UK, SEPA in Europe, and Interac in Canada all route differently. More accurately: the infrastructure selects the optimal rail based on payment type, market, and speed requirements — and falls back automatically if the primary rail is unavailable. You configure the rules; the orchestration layer executes them. It sounds like a detail. It isn't — this is what determines whether money actually arrives where it should, at the speed you promised, without your ops team manually investigating every exception.
Sub ledger and wallet management
Sub-ledger and wallet management is where your product logic lives. Balances need to belong to someone, move according to rules, and be accessible to the right people at the right time. Whether you're building a marketplace with per-seller fund segregation or an AI agent with a ring-fenced allocation, the sub-ledger is where that structure sits.
FX and conversion
This is where most platforms eventually realise they've built themselves into a corner. If you treat conversion as a feature you'll add later, you end up with a custom FX layer that's expensive to maintain and hard to audit. Treating it as a policy from the start — when does conversion trigger, at what rate, who bears the cost — is what determines your margin structure long-term.
Webhooks
Webhooks are what make the product feel real-time. Without event-driven notifications on account creation, incoming funds, and FX completion, you're asking your users to refresh a screen and hope.
Before I get into the builds, the marketing team told me that I should explain that every account, every wallet, every flow I describe below sits on Nium’s licensed infrastructure across our regulated entities globally. The reason a bank’s risk team can clear a build on this infrastructure is because the licences, the safeguarding, the audit trail, and the rail relationships sit with us. That is what makes the rest of this article possible.
Four builds on one infrastructure: how teams ship on multi-currency accounts
Build 1 — bank offers corporate clients named local accounts in five markets
A regional bank in Southeast Asia came to us with a straightforward problem. Their corporate clients — exporters, trading companies, professional services firms — were moving to fintechs because the bank couldn't offer them named local accounts in EUR, GBP, USD, and SGD. The bank was losing the relationship, not just the transaction. They wanted to fix that without building banking infrastructure across four new jurisdictions.
What they built is a white-label collections product. Clients log into the bank's portal and see accounts that look like the bank's own product. Each corporate gets a named local account in their own legal name — not a shared pooled account with a reference number to track.
At the API level, the bank creates a static, customer-named VAN per currency per corporate client via Nium API. The response includes:
- the issued virtual account in the corporate's legal name
- the BIC
- the assigned rail
When a payment arrives, the WALLET_FUNDED webhook fires, the bank's system reconciles it to the right customer, and the balance updates. The client never sees Nium.
The thing I want to flag here is the named vs. pooled distinction, because it's where a lot of implementations quietly go wrong. A shared account with a payment reference works fine when volumes are low and your ops team is manually matching. At scale:
- references get entered incorrectly
- payments arrive with nothing at all
- you end up with a reconciliation backlog
Customer-named accounts eliminate the matching problem entirely — the account itself is the identifier. It's also what correspondent banks and compliance teams expect when they're reviewing an audit trail.
On failures: if a payment arrives with no matching reference, the webhook still fires with the full sender detail. The bank decides what to do — auto-return, hold for ops review, reconcile manually. The infrastructure holds the funds safely until instructed.
Build 2 — expense platform gives every SMB user a named multi-currency wallet
This one came from a team building expense management for SMBs in Australia and the US. Their users were asking for a way to receive EUR and GBP from European clients without maintaining separate bank accounts in Europe. The platform wanted to offer it natively — not a redirect to a third-party product that breaks the experience and confuses the user.
Every SMB user who onboards gets their own virtual accounts in the currencies they enable. Balances, incoming transactions, conversion options — all in the platform's UI, all built on Nium, all invisible as Nium.
On user creation, the platform provisions a multi-currency wallet. For each currency activated, a dedicated VAN is issued. An auto-conversion rule can be set at the wallet level — a target currency and a threshold — so when an inbound EUR payment exceeds the equivalent of, say, AUD 500, conversion triggers automatically and the webhook fires. No custom FX logic to build or maintain. Balance reads across all currencies are available via a single API call in real time.
The thing that surprised this team was the time-to-first-funding improvement. They'd built on other infrastructure before that required per-user wire whitelisting, so they were expecting days. With per-user dedicated accounts, a new user can receive funds within 24 hours of activation. That changed their onboarding funnel in ways that no UX change had managed to.
If conversion fails — rate feed down, quote expired — funds stay in the source currency and the webhook fires with a retry timestamp. The platform can retry automatically or surface a manual option to the user. It's not glamorous, but predictable failure handling is what makes a product trustworthy to the SMB waiting on that EUR payment.
Build 3 — marketplace splits commissions and pays sellers the day funds arrive
The pattern here is familiar to anyone who's worked on marketplace payments: buyers pay, the platform takes a cut, sellers wait. The waiting is what kills the product. One marketplace came to us with:
- sellers waiting 10+ days for payouts
- FX costs eating into take-home
- no real-time visibility into where funds were sitting.
Their sellers were threatening to list elsewhere.
The fix was a two-tier fund flow. Buyers pay into a single collection wallet. When the WALLET_FUNDED webhook fires, the platform calls the transfer API to split the funds in the same handler — specifying the platform fee, the seller's wallet, and the payout destination. Nium handles the FX, the fund movement, and rail selection. Each seller has their own sub-ledger wallet. Per-seller statements via a single API call. Compliance audit trail built in, no custom ledger to maintain.
The rail selection piece is worth unpacking, because this is where the orchestration layer does real work. When the marketplace triggers a payout to a seller in Germany, the system evaluates the payment against available rails — SEPA Credit for standard clearing, SWIFT as the international fallback — and routes accordingly based on destination, speed, and cost. If the primary rail is temporarily unavailable, it retries on the next eligible rail before surfacing a failure event. The marketplace doesn't write that routing logic or maintain it. It configures the payout once; the orchestration handles the decision-making at execution time.
The design choice that unlocked everything else was the two-tier ledger — platform funds and seller funds segregated at the infrastructure level, not tracked in a spreadsheet or reconstructed at month-end. This is the difference between a product that regulators accept and one they start asking questions about. It also meant sellers could see their own balance in real time, which turned out to matter more to them than payout speed.
When payouts fail — invalid account details, beneficiary bank offline — a rejected transaction event fires and the funds return to the seller's sub-ledger. Not lost, not sitting in a suspense account. The marketplace retries with corrected details or surfaces the error to the seller. Idempotency keys on every transfer call mean double-processing is not something you're managing in your application logic.
Build 4 — AI platform lets its agents move money
This is the build I find most interesting right now, partly because it's genuinely new territory and partly because the API interaction is so different from the others.
An AI-native platform building autonomous procurement agents had a problem that's going to sound familiar to a lot of teams: the agents could make decisions, but every payment still required a human to log into a banking portal. They were automating the thinking and manually executing the action. That bottleneck gets worse as agent workflows scale.
What they built is an agentic treasury layer. Each agent workflow gets its own sub-wallet provisioned under the platform's master wallet, with spend limits and an allowed counterparty list configured at setup. When the agent needs to pay a supplier, it fetches a rate via the exchange rates API, then initiates a payout against the locked quote. The platform handles the rules:
- what the agent is allowed to do
- who it can pay
- when it needs to escalate
Nium handles the rails.
That sequence — check rate, lock quote, initiate payout, confirm status — is orchestration in the most literal sense. The agent isn't making a single API call; it's coordinating a multi-step financial workflow with conditional logic at each step. If the rate quote expires between steps, it refetches. If the payout fails, it evaluates whether to retry on a different rail or trigger the human escalation path. If the spend limit is breached, the call fails synchronously and the agent handles it in-flow. The platform defines the decision tree; the infrastructure executes each step reliably and gives the agent a clear signal at every point.
For teams building on LLM frameworks, the API surface maps cleanly to tool-use schemas. An agent equipped with the following has a complete treasury capability without a custom financial layer underneath:
- check_balance
- get_fx_rate
- initiate_payout
- get_transaction_status
The sub-wallet-per-workflow model is what makes this manageable in practice. Ring-fenced allocations limit blast radius if something goes wrong. Reconciliation is clean at the workflow level. The finance team gets per-workflow spending visibility without needing a custom accounting layer.
What the four builds have in common
Four different products, four different customer types. But the same infrastructure, the same API surface, and the same underlying principle: whoever builds on this owns the customer relationship. The infrastructure stays invisible.
What I've seen working across these patterns is that the teams who get the most out of the infrastructure are the ones who make the architecture decisions early — static vs. dynamic accounts, named vs. pooled, per-user vs. shared sub-ledger. Those decisions are hard to unwind. The teams who defer them tend to rebuild.
None of the four customers above needed to rebuild their infrastructure to keep growing:
- the bank from Build 1 is now expanding from EUR and GBP to AUD and SGD — same API, new corridors.
- the expense platform added inward direct debit for recurring collections on top of their wallet product
- the marketplace is processing MEA corridors that weren't in scope at launch
- the AI platform went from one agent workflow to dozens. None of them needed to rebuild their infrastructure to do it.
If you're the one who has to ship this, the question worth asking isn't whether we support the currencies you need today. It's whether the architecture can support what you'll need to build in 12 months — when your product has evolved, your volume has grown, and the corridors you didn't know you needed are suddenly the ones you do. That is the test of infrastructure versus an API.
The four patterns above are all live in production today on Nium infrastructure. If you're working on something similar and want to talk through the architecture before committing to an integration, reach out.
Coming next in this series: a deployment playbook for banks that have decided to partner — the five decisions you make in week one, the six weeks to your first live corridor, and what "good" looks like at twelve months. Followed by the platforms and marketplaces equivalent: the funds-flow architecture decisions, the deployment pattern, and the benchmarks for teams building at scale.
API reference and sandbox access: Nium Documentation
To get started: Contact your Nium solutions engineer or email [email protected]
