Skip to main content
Once a customer is onboarded with a wallet or a Virtual Account, most transactions just work — you call the deposit or payout endpoint and Conduit drives it to settlement. A few need extra information or a document to clear compliance first, and what’s required depends on the transaction. This page is the map: where each flow lives, and what it will ask of you.
Test this flow in sandbox. Drive it end-to-end with simulated money and deterministic controls — start with the sandbox quickstart, then the sandbox overview for this flow, and the cheat sheet for every magic value and simulate endpoint.

​
Pick your flow

The rest of this page covers the requirement gates those flows share. Deposits are submit-and-listen; the gates below are the compliance and documentation requirements a transaction clears before it settles. (Non-custodial crypto payouts have one more ask — your signers co-sign before settlement, via transaction.awaiting_signature; see Non-Custodial Payout. Passkey-mode signers approve on the verify page; a wallet in a programmatic signing mode approves via a signingRequestId instead — see Machine-signer stamping.)

​
Crypto deposits — sender information (Travel Rule)

When crypto arrives from a sender address Conduit doesn’t have registered, the deposit parks instead of settling and fires transaction.awaiting_sender_information (carrying the sourceAddress, the assetAmount, and an expiresAt deadline with daysRemaining). To release it, submit the sender’s (originator’s) details so Conduit can satisfy the Travel Rule:
  • register: false (default) — the details apply to this deposit only.
  • register: true — also saves the address so future deposits from it clear on their own.
Submit before the deadline, or the deposit fails with SENDER_INFO_TIMEOUT. The full deposit walk-through is in Receive Crypto; the originator shape (individual vs business) and the pre-registration path for a wallet the customer owns are in Registered Addresses.

​
Payouts — requirements depend on purpose

Every payout carries a purpose. What the payout needs to clear depends on its value:

​
Intercompany payouts — whitelist the recipient

For purpose: intercompany (first-party / same-group transfers), the recipient must already be registered for the customer — that registration is the compliance evidence, so no per-transaction document is needed. Register it once:
  • Fiat (bank) recipient — POST /v2/customers/{customerId}/whitelist-recipients, then wait for whitelist_recipient.registered (asynchronous review). See Whitelist Recipients.
  • Crypto address, your customer’s own wallet — POST /v2/customers/{customerId}/wallets/registered-addresses as self_custody (synchronous). Send the payout with attestation.custody: "self". See Registered Addresses.
  • Crypto address, another entity in the same group — POST /v2/customers/{customerId}/whitelist-recipients with rail: "crypto", chain, address and relationship: "group_entity", then wait for whitelist_recipient.registered (asynchronous review, same as a bank recipient). Send the payout with attestation.custody: "third_party" plus the third-party identity fields. See Whitelist Recipients.
One intercompany payout needs no registration: a transfer between two wallets of the same customer. Send it with destination: { "type": "wallet", "walletId": "wlt_..." } instead of a recipient. Both wallets must belong to that customer and sit on the asset’s chain. There is no counterparty to register, so the whitelist does not apply. Submit the payout once the recipient is registered. If it isn’t, the payout is rejected at submission with 422 RECIPIENT_NOT_WHITELISTED.

​
Other purposes — attach a supporting document

For any other purpose, the payout needs a supporting document:
  • Attach it upfront — upload the document tagged for transaction support, then pass its doc_* id in documents[]:
  • Attach none — what happens is set per organization. Either the payout is refused with 422 DOCUMENTATION_REQUIRED, or it is accepted and held (stage: "awaiting_customer_action", hasRfi: true) while a request for information asks for the document, due by a stated date. Answer it before the due date to release the payout; miss it, or have the document declined, and the payout fails with failureCode: "compliance_rejected". An organization with no portal user is always refused at create.
See Send a payout for the full request/response shape and the request-for-information walk-through.

​
Where to go next

Receive Crypto

Inbound crypto end to end, including the sender-information gate.

Money Movement

Fiat funding and payouts end to end.

Non-Custodial Payout

Co-signed crypto payouts.

Whitelist Recipients

Registering intercompany recipients.