> ## Documentation Index
> Fetch the complete documentation index at: https://apidocs.finrock.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Enable Ad-Hoc Addresses for One-Time Withdrawals

> Allow withdrawals to non-whitelisted addresses for use cases like exchange payouts. Enable per sub-account with spending rule controls.

By default, Finrock restricts outbound transactions to addresses that have been explicitly whitelisted in your workspace. Ad-hoc addresses lift that restriction for specific sub-accounts, allowing withdrawals to any address provided at transaction time — without pre-registering it. This capability is essential for products like crypto exchanges, where end-users supply their own withdrawal destination on demand.

<Note>
  Ad-hoc addresses are **disabled by default** on all sub-accounts. You must explicitly enable the feature on each sub-account where it is needed, and the change requires Owner approval before it takes effect.
</Note>

## When to Use Ad-Hoc Addresses

Whitelisted addresses are the right approach for recurring, known counterparties — treasury wallets, exchange accounts, and partner addresses that your team has vetted. Ad-hoc addresses are appropriate when:

* Your application allows end-users to specify their own withdrawal destination at runtime (for example, a crypto exchange or a payment processor).
* You need to send a one-time payment to a new counterparty without going through the whitelist approval workflow.
* You are building a high-volume consumer product where pre-registering every recipient address is impractical.

<Warning>
  Enabling ad-hoc addresses opens up outbound transfers to **any** on-chain address from the affected sub-account. Only enable this feature on sub-accounts that genuinely require it, and always pair it with Spending Rules to cap the maximum USD value per transaction and require manual approval above your threshold.
</Warning>

## How to Enable Ad-Hoc Addresses

Enabling ad-hoc addresses is a dashboard operation that requires Owner approval. Follow these steps:

<Steps>
  ### Log In to Your Finrock Account

  Open `https://finrock.io` and sign in with your credentials.

  ### Open the Settings Page

  Click the **Settings** icon in the left menu — it is the second-last icon from the bottom. This opens your workspace settings.

  ### Select Ad-Hoc Addresses

  In the left pane of the Settings page, click **Ad-hoc addresses**. You will see a list of all sub-accounts in your workspace along with the current state of the ad-hoc address feature for each — either **Enabled** or **Disabled**.

  ### Toggle the Sub-Account

  Find the sub-account you want to configure and click its toggle button to switch from **Disabled** to **Enabled**. The state immediately changes to **Pending Approval**.

  ### Get Owner Approval

  Finrock notifies the workspace Owner that a change is pending. Contact your Owner and ask them to review and approve the request. Once approved, the state changes to **Enabled** and ad-hoc withdrawals become active for that sub-account.
</Steps>

## Add a Spending Rule for Ad-Hoc Addresses

Enabling ad-hoc addresses alone is not sufficient to authorise transactions — you also need a **Spending Rule** that defines the maximum USD notional value allowed per outbound transaction and whether manual approval is required above a certain threshold. The same Spending Rules system applies to both whitelisted and ad-hoc address destinations.

<Steps>
  ### Open the Spending Rules Page

  Navigate to the **Spending Rules** section in your Finrock dashboard.

  ### Add a New Rule

  Click **Add new rule** to open the rule configuration form.

  ### Select EXTERNAL as the Destination

  Choose **EXTERNAL** as the destination type. This covers both whitelisted addresses and ad-hoc addresses for outbound transactions.

  ### Configure the Rule Parameters

  Set the maximum USD notional value for a single transaction. Optionally, require manual approval for transactions above a sub-threshold. Save the rule once configured.
</Steps>

<Info>
  Spending Rules for ad-hoc addresses work identically to Spending Rules for whitelisted addresses. If you already have an EXTERNAL Spending Rule in place, it will govern ad-hoc withdrawals from that sub-account automatically — you may not need to create a new one.
</Info>

## Security Best Practices

<CardGroup cols={2}>
  <Card title="Limit to Necessary Sub-Accounts" icon="lock">
    Enable ad-hoc addresses only on the specific sub-accounts that your application requires. Keep treasury and cold-storage sub-accounts restricted to whitelisted addresses at all times.
  </Card>

  <Card title="Always Pair with Spending Rules" icon="shield">
    Set a maximum USD notional limit and require manual approval above your risk threshold. This gives you a human checkpoint for large ad-hoc withdrawals.
  </Card>

  <Card title="Enable AML Screening" icon="magnifying-glass">
    When using ad-hoc addresses, enable AML screening so every new counterparty address is checked against Chainalysis before funds move. See the AML Compliance guide.
  </Card>

  <Card title="Use sequence_id for Idempotency" icon="fingerprint">
    Always pass a unique `sequence_id` on ad-hoc withdrawal requests to prevent double-spend if your application retries a failed request.
  </Card>
</CardGroup>