Overview

You don't sell Chase dollars to buy Wells Fargo dollars. You transfer them at par through a clearinghouse.

Stablecoins don't work this way today. Moving between stablecoins looks like an FX trade — parties buy and sell at spot prices, with slippage, through trading desks, despite both sides being dollars.

The TBMC clearinghouse fixes that. Any supported stablecoin or deposit token, fungible with any other, across any supported chain, at par. Movement between stablecoins becomes a transfer, not a trade.

This API is how you wire your product into the clearinghouse.

What you can build

• Accept pay-ins in any supported stablecoin or chain and consolidate into the one you prefer.
• Pay out in any supported stablecoin or chain without holding inventory in each.
• Integrate your custom stablecoin into stablecoin products with 1:1 fungibility.
• Integrate once for every member asset and chain. No per-issuer relationships required.
• Track every payment's lifecycle in the TBMC developer console — full status history, no extra integration.

How a payment order moves

A payment order is the unit of work. You declare "send X of asset Y to address Z on chain C," and TBMC handles the rest. Orders settle one of two ways.

Standard settlement

Funded orders are batched into a netting window and cleared at par:

1. Funding wallet exposed. TBMC returns the inbound funding wallet for the asset/chain you want to pay in.
2. Transfer observed. Once the inbound transfer lands on-chain, the order moves from AWAITING_FUNDS → FUNDED.
3. Netting window locks. Funded orders are batched into the next netting window. Opposing flows are offset: where one client sends a stablecoin and another requests it, the flows net and no further action is required.
4. Imbalance settled at par. For any remaining imbalance, TBMC redeems surplus stablecoins with the issuer (fiat returns to TBMC's bank account) and mints deficit stablecoins by transferring fiat to the minting issuer.
5. Distribution. TBMC delivers the requested outbound asset to the designated recipient on the requested chain.

Settlement times are predictable, independent of chain finality or liquidity conditions. Pricing is a fixed fee — not slippage.

Instant settlement

When you need funds delivered immediately, instant settlement pays out from prefunded liquidity within seconds — bypassing the netting window:

1. Funding wallet exposed. TBMC returns the inbound funding wallet for the asset/chain you want to pay in.
2. Transfer observed. Once the inbound transfer lands on-chain, the order is funded.
3. Instant payout. TBMC immediately delivers the requested outbound asset to the recipient from a prefunded pool, without waiting for a netting window. A small per-transaction fee applies.

Get set up

Before your first payment, you'll need to:

1. Onboard your account — complete KYB in the developer console. Calls are rejected until your account is ACTIVE and KYB APPROVED.
2. Create an API key in the developer console.
3. Register your users and their wallets — both the wallets you send from and the wallets you pay to.
4. Have TBMC activate your recipient wallets so they can receive funds.

The Getting Started guide walks through each step in full.

Concept map

• Account → many users → many wallets (address + chain). The account holds KYB status; users are the parties on whose behalf your account moves money.
• Payment order — the workflow entity. Lifecycle: AWAITING_FUNDS → FUNDED → ... → DISTRIBUTED.
• Epoch — the netting window that batches funded orders for settlement.

Supported coverage

Supported assets include USDC, USDG, PYUSD, SBC, CASH, mUSD, frxUSD, RLUSD, SOFID across Ethereum and Solana. Member ecosystems include Paxos, Bridge, Brale, MoonPay, Anchorage, BitGo. Coverage is expanding.

Always check GET /supported-assets for the live canonical list.

Authentication

Every request requires an API key minted from the developer console. Each key is scoped to a single account.

Subaccounts

An account can have subaccounts — separate accounts you own, one level deep, each with its own users, custody wallet, and payment orders. Your parent account's API key can act on them through the scoped operations below. Webhook management is the exception: use the subaccount's own API key for its endpoints and delivery log.

Two optional parameters control the scope of a request. Reads take them as query parameters; writes take them as body fields.

Parameter	Effect
subaccountId	Act on this subaccount instead of your account. Must be a direct child of your account.
includeSubaccounts	On list endpoints, span your account and its subaccounts.

Rules worth knowing before you build:

• Neither parameter means your own account. Existing integrations keep working unchanged when you add a subaccount.
• includeSubaccounts=true cannot be combined with subaccountId. Sending both returns 400. Sending includeSubaccounts=false alongside subaccountId is fine — it means the same as omitting it.
• Rolled-up rows identify their accounts. Users carry accountId, so duplicate labels remain attributable. Payment orders carry senderAccountId for the sending side and receiverAccountIds for every receiving account in your scope. A side owned by another customer is omitted rather than exposing its account id.
• A subaccount id you do not own returns 403. So does one belonging to a sibling subaccount.
• A paused subaccount is read-only. Reads remain available when the child is suspended or under KYB review. Writes require the child to be active and fully approved. Archived children remain outside every scope.
• Limits are shared. Ceilings belong to the parent account and usage counts every subaccount, so subaccountId changes which account GET /account/limits names, not the numbers it reports.
• Each subaccount has its own custody wallet. GET /deposit-addresses returns that subaccount's addresses, and returns 412 if its wallet is not provisioned yet.
• Instant orders inherit their account from their quote. Pass subaccountId to POST /quotes; the order citing that quote takes none, and sending one on an instant body returns 400.
• Webhooks are not scoped. A subaccount's events go to that subaccount's endpoints. Use its own API key to manage those endpoints and the delivery log. Neither parameter has any effect on a /webhooks operation.

Subaccounts are created by TBMC on request, not through this API.