> ## Documentation Index
> Fetch the complete documentation index at: https://v2.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.

<Note>
  **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.
</Note>

## 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. |
| `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).

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_abc123"], "...": "..." }'
```

<Warning>
  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.
</Warning>

<Note>
  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).
</Note>

## Where to go next

<CardGroup cols={2}>
  <Card title="Receive Crypto" href="/guides/receive-crypto-lifecycle">
    Inbound crypto end to end, including the sender-information gate.
  </Card>

  <Card title="Money Movement" href="/guides/money-movement-lifecycle">
    Fiat funding and payouts end to end.
  </Card>

  <Card title="Non-Custodial Payout" href="/guides/non-custodial-payout-lifecycle">
    Co-signed crypto payouts.
  </Card>

  <Card title="Whitelist Recipients" href="/concepts/whitelist-recipients">
    Registering intercompany recipients.
  </Card>
</CardGroup>