> ## Documentation Index
> Fetch the complete documentation index at: https://docs.conduit.financial/llms.txt
> Use this file to discover all available pages before exploring further.
# Transact
> What each transaction needs to clear: Travel Rule sender info on crypto deposits, recipient whitelisting for intercompany payouts, and supporting documents for everything else
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](/sandbox/quickstart), then [the sandbox overview](/sandbox/overview) for this flow, and the [cheat sheet](/sandbox/cheat-sheet) for every magic value and simulate endpoint.
## Pick your flow
| You want to | Asset | Guide |
| ------------- | ---------- | -------------------------------------------------------------- |
| Receive funds | Crypto | [Receive Crypto](/guides/receive-crypto-lifecycle) |
| Receive funds | Fiat (USD) | [Money Movement](/guides/money-movement-lifecycle) |
| Send a payout | Crypto | [Non-Custodial Payout](/guides/non-custodial-payout-lifecycle) |
| Send a payout | Fiat | [Money Movement](/guides/money-movement-lifecycle) |
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](/guides/non-custodial-payout-lifecycle). Passkey-mode signers approve on the verify page; a wallet in a programmatic signing mode approves via a `signingRequestId` instead — see [Machine-signer stamping](/guides/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:
```bash theme={null}
curl https://api.conduit.financial/v2/transactions/{id}/sender-information \
-X POST \
-H "x-api-key: YOUR_API_KEY" \
-H "content-type: application/json" \
-H "idempotency-key: $(uuidgen)" \
-d '{ "originator": { "...": "..." }, "register": true }'
```
* `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](/guides/receive-crypto-lifecycle); the `originator` shape (individual vs business) and the pre-registration path for a wallet the customer owns are in [Registered Addresses](/concepts/registered-addresses).
## Payouts — requirements depend on `purpose`
Every payout carries a `purpose`. What the payout needs to clear depends on its value:
| `purpose` | What it requires |
| --------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `intercompany` | A **pre-registered (whitelisted) recipient**. No per-transaction document. A transfer to another of the same customer's own Conduit wallets is the exception — it needs neither. |
| `treasury_management` · `payment_for_goods_or_services` · `payroll` · `investments` · `other` | A **supporting document** attached to the payout. |
### 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](/concepts/whitelist-recipients).
* **Crypto (address) recipient** — `POST /v2/customers/{customerId}/wallets/registered-addresses` (synchronous). See [Registered Addresses](/concepts/registered-addresses).
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`](/errors/recipient-not-whitelisted).
### Other purposes — attach a supporting document
For any other `purpose`, the payout needs a supporting document, and the system tells you so by **rejecting and asking you to retry** with the document attached:
1. Submit the payout. With no document, it's rejected at submission with [`422 DOCUMENTATION_REQUIRED`](/errors/documentation-required) — **no payout is created**.
2. Upload the document, tagged for transaction support:
```bash theme={null}
curl https://api.conduit.financial/v2/documents \
-X POST \
-H "x-api-key: YOUR_API_KEY" \
-F "file=@invoice.pdf;type=application/pdf" \
-F "purpose=transaction_support"
```
3. Resubmit the payout with the returned `doc_*` id in `documents[]` and a **new `idempotency-key`** — attaching the document changes the request body, and the original key is already bound to the no-document attempt, so reusing it returns `409 IDEMPOTENCY_KEY_CONFLICT`:
```bash theme={null}
curl https://api.conduit.financial/v2/payouts \
-X POST \
-H "x-api-key: YOUR_API_KEY" \
-H "idempotency-key: $(uuidgen)" \
-H "content-type: application/json" \
-d '{ "purpose": "treasury_management", "documents": ["doc_034A0gCCW6w2ubcipmRoY8"], "...": "..." }'
```
Keep that **new** key for any further retries of the corrected payout — don't mint another one each time. Reusing the corrected request's key means a lost response replays the one payout that was accepted instead of creating a second one.
A document accepted at submission can still be reviewed afterward; if it's found inadequate the payout fails with `failureCode: compliance_rejected`. The full payout request shape lives in [Money Movement](/guides/money-movement-lifecycle) (fiat) and [Non-Custodial Payout](/guides/non-custodial-payout-lifecycle) (crypto).
## Where to go next
Inbound crypto end to end, including the sender-information gate.
Fiat funding and payouts end to end.
Co-signed crypto payouts.
Registering intercompany recipients.