Skip to main content
Build a treasury product for corporate customers that need to hold working capital across multiple currencies, sweep funds between related entities, and execute FX conversions on demand. Balances are centralized in stablecoin in each entity’s wallet, and converted to local fiat only when needed.

Step 1: Generate your API key

Head over to dashboard.lumx.io. Once logged in, generate a new API key and store it securely. See Authentication for details.

Step 2: Onboard the corporate with multi-currency accounts

Create a business customer for the entity that will hold the treasury. Provision the fiat accounts they need so incoming deposits are converted to stablecoin and consolidated in the customer’s wallet automatically. See Coverage for supported currencies and rails.
Request
Before the corporate can transact, they must accept Lumx’s terms of service (POST /customers/{id}/tos) and complete KYB. See Business verification for the full onboarding flow.

Step 3: Fund the corporate’s wallet

Once each account is ACTIVE, create an autoconversion rule for it, using the account’s id as accountId. You do this once per account: the response’s sourceDepositInfo carries the deposit details for that currency. Share them with the corporate’s treasury team, and every deposit that lands is converted to stablecoin and consolidated in the customer’s wallet, whatever the amount.
Request
Each deposit must be worth at least 50 USD in the account’s currency. A USD, EUR, or GBP account holds one active rule at a time. All deposits land as stablecoin in the same wallet. The corporate doesn’t hold separate per-currency balances. If the corporate already holds stablecoin on-chain, they can also transfer it directly to the wallet returned at customer creation, no conversion needed. Subscribe to the onramp.success webhook to know the moment the wallet is credited and balances are ready to be moved or converted. For the response, the deposit details per currency, and when to create a one-off on-ramp instead, see Global accounts.

Step 4: Onboard subsidiaries and counterparty destinations

How you model the corporate group depends on whether each entity needs its own wallet. Multi-entity (each subsidiary holds its own balance): onboard each subsidiary as its own business customer. Each gets a dedicated wallet, and you can move funds between them with internal transfers. Single-entity (parent holds all balances): register each related external destination under the parent customer with the appropriate holder.relationship so transfers out are correctly categorized. The taxId format varies by jurisdiction; see Tax IDs by country for the expected value per country.
Register a subsidiary's destination under the parent
See Destinations for all supported rails and the full holder schema.

Step 5: Move funds between entities

When subsidiaries are onboarded as separate customers, move stablecoin between their wallets without going through fiat. Transfers settle in seconds and don’t incur FX cost.
Request
Response

Step 6: Convert balances to fiat on demand

When the corporate needs to settle in fiat (paying a supplier, repatriating profits, funding a subsidiary’s local account), create an off-ramp transaction debiting the wallet. Use the purpose code that matches the move: See Purpose codes for the full list and rules.
Request
For predictable FX (budgeting, monthly settlements, locked supplier quotes), fetch a locked exchange rate first and pass its id as exchangeRateId on the off-ramp request. See Exchange Rates.

Step 7: Track and reconcile

Subscribe to offramp.success, offramp.failed, transfer.success, and account.active webhooks to keep balances, transfers, and conversion status in sync inside your product. See Webhooks.

Global accounts

Provision multi-currency virtual accounts.

Exchange Rates

Lock FX rates for predictable conversions.

Destinations

Holder relationships for inter-company moves.

Transactions

Transfer, off-ramp lifecycle and purpose codes.