Skip to main content
Accounts are the financial infrastructure layer in Infinite. They represent where funds are held and how they move — whether through traditional banking rails or blockchain networks.

Overview

Infinite uses a typed account system where each account serves a specific purpose. Accounts are always linked to a customer and have distinct creation endpoints. Think in roles, not just type names. The same INFINITE_WALLET (inw_) type is used for a deposit mailbox and for a treasury vault.

Infinite Wallets (INFINITE_WALLET, inw_)

Blockchain wallets managed by Infinite on behalf of your customers. There is no public create endpoint for treasury wallets — they are provisioned automatically when a customer is approved. List them with GET /v1/accounts?type=INFINITE_WALLET. Three jobs share this type:
  • Treasury (vault) — holds balances; source for withdrawals and payouts
  • Transaction — system-controlled address used while a one-off transfer is in flight
  • Deposit mailbox (walletType: VIRTUAL) — created by crypto fixed routes. Unique receive address that auto-sweeps to a bank or wallet
Do not treat a treasury inw_ as something you can sandbox-fund. Account fund-in only accepts funding-method ids (vba_, vwa_, pba_). To credit a vault in sandbox, pick a fixed route whose sweep target is that vault, then simulate a deposit with the route’s source account id (vba_… or mailbox inw_…). Funds land on the destination, not the source mailbox. Then create a transfer from the vault. You cannot attach a third-party key as a co-signer on an Infinite wallet. If you need a customer-controlled address (a guard, guardian, or self-custodial destination), create an external wallet. Supported address types: EVM, SOLANA, TRON, BITCOIN

External Bank Accounts

Bank accounts owned by your customers at external institutions. Used as payout destinations for fiat transfers.
Required fields vary by payment rail. See the API reference for full details.

External Wallets

Third-party blockchain wallets owned by your customers. Infinite does not hold the keys. Use them as payout destinations, fixed-route sweep targets, or a customer-controlled guard address.
The response id is ewa_…. Status starts IN_REVIEW and becomes ACTIVE after screening. See Create an external wallet.

Virtual Bank Accounts

Fiat bank accounts provisioned within Infinite’s banking partners. Used for receiving fiat deposits via ACH, wire, SEPA, SWIFT, and similar rails. These are typically created as part of a fixed route (POST /v1/fixed-routes/virtual-bank-accounts) rather than standalone. Each route gets its own account number, so the deposit identifies itself — no memo required. A USD balance account is also a vba_ that holds funds instead of sweeping. A separate fixed route can use that balance account as its sweep target, so deposits to a dedicated account number credit the balance with no conversion.

Virtual wallets (vwa_) vs crypto deposit wallets

The vwa_ prefix is a funding-method virtual wallet used in some products (for example card funding). It is not what POST /v1/fixed-routes/virtual-wallets returns. That endpoint creates an INFINITE_WALLET (inw_) with walletType: VIRTUAL — a dedicated crypto mailbox. Sandbox fund-in on vwa_ will not credit that mailbox. To test the route, simulate-deposit with the mailbox (source) account id; the sweep credits the route destination.

ID Prefixes

Each account type has a distinct ID prefix:

Account Status

Account status is read-only. Once an external bank or proxy account is ACTIVE, you can permanently close it with POST /v1/external-bank-accounts/{id}/close. Accounts still IN_REVIEW cannot be closed. Closed accounts cannot be used as transfer or FX destinations, and fixed routes that sweep to them are disabled.

Retrieving Accounts

List accounts for a customer

Get an account by ID

Next Steps

Once accounts are set up, you can create transfers to move funds between them.

Transfers

Move funds between accounts across fiat and crypto rails

API Reference

Full API reference for account endpoints