> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.crisscross.money/exchange-funding/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.crisscross.money/_mcp/server.

# Funding

The Funding endpoints cover the full lifecycle of moving money in and out of CrissCross: viewing balances, depositing funds, registering beneficiaries, and withdrawing to your own bank account or crypto wallet.

A typical first run looks like **get deposit details → send the payment in → check your balance → register a beneficiary → withdraw**.

## Balances

Your balance in each currency is split into the portion that's available to spend and the portion that's reserved against in-flight activity, like pending withdrawals and accepted-but-unfilled orders. When you accept a quote or create a withdrawal, funds move from available to reserved synchronously, then become a final debit once the order fills or the withdrawal is dispatched. [Get balances](/api-reference/exchange/balances/get-balances) returns one entry per provisioned currency, including zeroes.

For a chronological audit trail of everything that's hit a currency (deposits in, trades, withdrawals out, fees, adjustments), use [Get balance statement](/api-reference/exchange/balances/get-balance-statement). This is the source of truth for reconciliation. Reservations don't appear here; they're not yet final movements. Statements only record settled events.

## Deposits

Funding your account is a pay-in flow: CrissCross gives you a unique identifier to send funds to (a bank account or reference for fiat, or a wallet address for crypto), and we credit your balance once the payment arrives.

Use [Get deposit account details](/api-reference/exchange/deposits/get-deposit-account-details) to retrieve the destination details for the currency you want to fund. The response includes the beneficiary name and address to put on the payment, the account or wallet details, and the routing information appropriate to the rail. It also returns a unique reference that attributes the payment to your account. The reference is stable per currency, so you can safely cache it. Always include it on the payment. Without it, the deposit can't be auto-attributed, and crediting will be delayed while we work it out manually.

You can monitor incoming payments with [List deposits](/api-reference/exchange/deposits/list-deposits) or [Get deposit](/api-reference/exchange/deposits/get-deposit). A deposit starts as pending while we wait for it to clear, and either becomes credited (funds available) or rejected (returned, e.g. because compliance review failed). Each deposit records when we first detected the payment and when it actually landed in your balance.

## Beneficiaries

Before you can withdraw to a destination, you need to register it as a beneficiary. Beneficiaries are allowlisted destinations: bank accounts or crypto wallets you've approved for outbound payments. Each beneficiary is tied to a single currency.

[Create a beneficiary](/api-reference/exchange/beneficiaries/create-beneficiary) by submitting the destination's name, address, currency, and routing details. We recommend sending an idempotency key on the request so retries are safe; it's optional, but if you skip it you accept the risk of accidentally creating duplicates.

USD beneficiaries use a wire payment type: `international_wire` for cross-border transfers or `domestic_wire` for transfers within the US. Each takes a `wireDetails` object alongside the routing details: international wire needs the beneficiary bank's `bic`, `abaRoutingNumber`, `bankName`, and `bankAddress`, while domestic wire needs `abaRoutingNumber` and `bankName`. `swift` is deprecated: beneficiaries created with it before this change keep working, but a new USD beneficiary created with `swift` is rejected.

New beneficiaries are created in a pending state and run through async compliance validation. Poll [Get beneficiary](/api-reference/exchange/beneficiaries/get-beneficiary) until the status becomes active before referencing it in a withdrawal. Some don't make it through and end up rejected. Existing ones can also be disabled later if needed.

## Withdrawals

Withdrawals move funds from your CrissCross balance to one of your own registered beneficiaries.

> **Withdrawals vs Payouts.** Use **withdrawals** to move *your own* funds to *your own* destinations. Use the [Payouts API](/payout-getting-started) when sending to third-party recipients (suppliers, customers, employees). Both draw from your Exchange balances; the difference is the destination.

[Create a withdrawal](/api-reference/exchange/withdrawals/create-withdrawal) by referencing an active beneficiary and the amount to send. You also provide a reference that will appear on the recipient's statement, and optionally a client reference for your own internal tracking. As soon as the withdrawal is created, the amount is reserved on your balance. Your available balance drops immediately, even though the actual debit only happens once the funds are dispatched. As with beneficiaries, send an idempotency key to make retries safe.

A withdrawal sits in a pending state while it waits to be dispatched, which is the only window where you can [cancel](/api-reference/exchange/withdrawals/cancel-a-withdrawal) it. Once it's been handed to the rail it's processing, and shortly after that it completes, at which point the reservation becomes a final debit. Cancellations release the reservation back to your available balance. So do failures (rejected before dispatch) and returns (sent but bounced back by the receiving bank).

You can check on any withdrawal with [Get withdrawal](/api-reference/exchange/withdrawals/get-withdrawal) or browse history with [List withdrawals](/api-reference/exchange/withdrawals/list-withdrawals).