Nium: cross-border payments, wallets and card infrastructure

Nium is a payment-infrastructure provider, but its currently linked business policy places securities brokers and trading, exchange and wealth-management activities in the prohibited list. That boundary applies before comparing payment features or commercial terms.[2]

Its broader proposition connects collections, multicurrency balances, conversion, payouts and card programmes. The published payout documentation supports business and individual flows, delivered to bank accounts, cards, digital wallets or cash pickup where available. Nium advertises coverage across more than 190 countries; a particular method and corridor still determines the available route.[20]

Under the Pay In/Pay Out terms, a virtual bank account number is a notional reference to the settlement account, not an independently funded end-customer bank account. Stablecoin payin is also specifically structured: a digital-asset partner receives, screens and converts the asset, while Nium credits fiat to the available balance. Nium says it never holds that digital asset. This is a one-way funding service, without asset withdrawal through the same service; correct network and destination details are essential because the on-chain transfer is irreversible.[4]

Production and Sandbox use separate client identifiers and API credentials. Authentication combines the x-api-key header with the client identifier in the request path. Production access is arranged through Nium’s account or support team, and integrations need the documented IP allowlist configuration. These credentials confer payment-system access and belong in controlled server infrastructure.[11]

The payout lifecycle gives useful accounting distinctions. FAILED means rejection by Nium’s internal validation before reaching a bank or clearing system; RETURN means a receiving-bank return. PAID means the partner bank has sent money to the beneficiary bank, not that the final customer has been credited. Status can be retrieved using Nium’s system reference or the client’s externalId. Customer cancellation is normally limited to scheduled payouts that have not begun.[24]

Nium quotes pricing according to the use case, transaction volumes and integration type. Its public sales page does not provide a standard broker tariff. The figures and conditions below come from the named service agreements or technical documentation; they are not a universal price list for every Nium entity.[25]

The separately documented FX Forward service is provided directly by Nium Fintech Limited. It is limited to identifiable goods, services or direct-investment payments, prohibits speculation and standalone FX trading, and is described as outside FCA-regulated investment services and FSCS cover. Payment-account safeguarding remains governed by the underlying payment agreement.[5]

The current version 5 onboarding flow combines corporate, individual and employee onboarding while retaining regional data objects and document requirements. Corporate applications distinguish the business, its authorised applicant and relevant stakeholders. Corporate payroll employees follow individual KYC requirements; spend-management employees have a different documented flow, including jurisdictional exceptions. This creates distinct records and verification paths within a programme.[26]

Nium’s hosted production FAQ describes AWS deployment across availability zones. Its security FAQ says data is encrypted at rest and describes database storage followed by S3 archiving. Customer penetration testing needs specific permission. These public architecture statements do not establish a universal customer-selected residency region or a contractual recovery-time commitment.[31][18]

The role guide is internally inconsistent about viewing API keys: the client-management grid excludes Viewer, while the API-key grid includes every role. That specific entitlement needs confirmation in the deployed configuration; the documented operational and approval distinctions above are consistent.[19]

Card programmes add their own delivery sequence. Physical-card turnaround is agreed with Nium and its personalisation process; receipt and activation precede use. The published issuing functions also cover employee spending, procurement and travel supplier payments, so card issuing should be assessed separately from accepting payment deposits.[29]

The support FAQ refers critical-failure handling to the Master Services Agreement’s SLA without publishing numerical response or restoration targets. The sales page’s one-business-day enquiry response is a commercial-contact promise, not an incident-response commitment.[15][25]

Nium’s status guide separates portal, payout, payin, onboarding, card, FX and reporting components, with incident history and email subscriptions. It expressly excludes the availability of third-party partners. A green Nium component therefore does not describe the complete payment chain; account management or support handles further partner updates.[30]

The June 2024 prohibited-business policy remains linked from Nium’s current legal hub. It names securities brokers and trading/exchange/wealth-management services under prohibition, including investment, stocks, securities, spot and futures. Its separate restricted list allows prior written approval for specified activities such as digital assets. That approval route should not be transferred to the prohibited broker category.[2]

The September Platform Services Agreement specifically describes a platform client transmitting end-customer payment information rather than itself holding the stated payment-services licences. The contracting Nium entity is fixed by the Fee Schedule. That agreement model is distinct from the provider’s broader financial-institution marketing.[3]

The August DPA treats Nium and its client as independent controllers for the ordinary service relationship. Its processor appendix instead concerns a client processing Nium data under outsourcing; it should not be read as making Nium the client’s processor for all payment data. The controller provisions require incident notice without undue delay after awareness, rather than a general fixed 72-hour customer-notification promise.[6]

Founded in 2014 by Prajit Nanu and Michael Bermingham, the business began as Instarem and adopted Nium in 2019. It remains privately held and co-headquartered in Singapore and San Francisco. Its stated investors include Vertex, BOND, Visa, NewView Capital and Temasek; investor participation does not make Nium a Visa operating business.[1]

Nium announced its acquisition of Cypher on 8 July 2026. The acquired company built a non-custodial crypto wallet and issuing business; its founder and engineering team joined Nium. The announcement links that expertise to Nium’s existing stablecoin-backed issuing and fiat/on-chain infrastructure, rather than presenting the acquisition as a new brokerage licence.[28]

The current Lithuanian register also preserves enforcement history: a EUR 40,000 fine dated 10 September 2024 for AML-law infringements and a EUR 10,000 fine dated 5 July 2022 concerning inaccurate balance and safeguarded-funds information. These historical actions appear alongside the current entity’s authorization record.[9]

Operator

Nium group; contracting entity specified by service and jurisdiction

Service scope

Payment, wallet, FX and card infrastructure; current-linked policy prohibits securities brokers and trading.

Customer types

Banks; Financial institutions; Fintechs; Enterprises; Payment platforms

Delivery

Hosted; API

Pricing publication

Quote only

Headquarters

Singapore and San Francisco

Platforms

Nium Portal; Nium Connect

Integrations

REST APIs; SWIFT MT; ISO 20022; Webhooks; SFTP reports; Sandbox MCP tools

Pricing scope

Commercial quote depends on use case, transaction volume and integration type.

Implementation

API, portal or SWIFT integration with regional onboarding and configured payment corridors.

Support

Account management, service support and component-status notifications; contractual incident targets depend on the agreement.

Permissions and regulatory scope

Regional payment permissions do not establish broker eligibility. Securities brokers and trading are prohibited by the linked business policy.

Provider metadata checked 20 Oct 2026Source 1Source 10Source 2Source 20Source 25Source 15Source 30Source 17Source 16

The Nium MCP Server can help an AI assistant find API and corridor information and make supported requests. Its write tools can create customers, beneficiaries and test payouts, fund wallets and submit KYC data in Sandbox. The documented live API interaction scope currently covers Payout APIs; other API coverage is described as forthcoming. These tools provide test-environment action authority, not a documented grant to move production funds autonomously.[16]

The portal supports transaction RFIs without a separate API implementation. Submitted material returns to pending review, with subsequent status changes communicated through events. Scheduled reports can use daily, weekly, monthly or trailing-twelve-month frequencies and optional SFTP delivery with a PGP key. Monthly statements are downloadable PDFs. These exports support reconciliation alongside the distinct transaction and remittance status fields.[17]

Privacy retention is purpose- and law-dependent: Nium says it deletes or de-identifies data when no longer needed, while legal obligations and technical constraints can limit immediate deletion. The notice describes international transfers and access/copy, portability and deletion rights subject to applicable conditions; end customers may need their platform provider’s assistance.[7]

Under the Platform Services Agreement, annual renewals follow the initial term; either party can ordinarily terminate on 30 days’ notice, subject to applicable early fees. Exit requires disabling the integration. Nium termination for cause can accelerate remaining minimum commitments. Disputed platform entries should be reported within 60 days after entry, subject to longer legal periods.[3]

The Pay In/Pay Out supplement requires the client to retain instruction records for at least eight years after termination, or longer where law requires. Closing the integration therefore does not end the client’s recordkeeping duty.[4]