Skip to main content
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.
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.

​
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.
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.

​
How to Enable Ad-Hoc Addresses

Enabling ad-hoc addresses is a dashboard operation that requires Owner approval. Follow these 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.
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.

​
Security Best Practices

Limit to Necessary Sub-Accounts

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.

Always Pair with Spending Rules

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.

Enable AML Screening

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.

Use sequence_id for Idempotency

Always pass a unique sequence_id on ad-hoc withdrawal requests to prevent double-spend if your application retries a failed request.