Transfers and Withdrawals

Every withdrawal and transfer resolves through the same three checks. Keeping them apart is the key to configuring, and debugging, fund movement in your Organization.

Check 1 - Account permission (which accounts?). The Member must hold the fund-movement permission on the accounts involved:

• Withdrawal: the Withdraw permission on the source account.
• Transfer: the Transfer permission on both the source and the destination account.

Check 2 - Workflow level (can they start?). The Member’s Workflow Profile must hold Initiate (or Execute) on the relevant workflow, Withdrawal Request or Transfer Request.

Check 3 - Policy (how does it complete?). The workflow’s policy takes over. If the Member holds Execute and “Always require approval” is OFF, the request completes immediately. Otherwise it waits for the required number of approvals from other Members.

Checks 1 and 2 are independent grants, and moving funds always takes both. A Member with Withdraw on an account but no Initiate on Withdrawal Request cannot withdraw a thing; neither can a Member who can start requests but holds Withdraw nowhere.

The checks live in different places by design. Account permissions come from the Member’s Account Roles and answer the where; the Workflow Profile answers the whether; the policy answers the how. You can adjust any one without touching the other two, narrow which accounts a trader can withdraw from without changing approval rules, or tighten approvals without touching anyone’s account access.

Worked example

An Organization has three accounts, A, B, and C. Priya, one of its Members, holds:

• An Account Role granting Read and Transfer on accounts A and B, and Withdraw on account A.
• A Workflow Profile with Initiate on Withdrawal Request and Transfer Request.
• Policies: Withdrawal Request requires 2 approvals; Transfer Request requires 1.

What Priya can do:

Withdrawals go exclusively to addresses on your Organization’s whitelist, which is managed under the separate Manage Addresses workflow. A withdrawal request specifies the source account, the asset and amount, and a whitelisted destination.

Because withdrawals move funds out of the Organization, the Withdrawal Request policy is typically the first one tightened and locked. Most Organizations require at least one independent approval for every withdrawal, including the Owner’s. See Rolling out governance.

The address whitelist

Adding or deleting a whitelisted address is a governed operation under Manage Addresses, with its own policy. Addresses cannot be edited, to change one, delete it and add the replacement.

• Withdrawal requests can only target addresses that are on the whitelist when the request completes.
• A profile with Initiate or Execute on Withdrawal Request also needs View on Manage Addresses. This lets the Member review the Organization’s withdrawal-address whitelist before selecting a destination.
• View on Manage Addresses does not permit address changes. Starting an address change requires Initiate (or Execute) on Manage Addresses, and approving one requires Approve on that workflow.

Transfers move funds between two of your Organization’s accounts, rebalancing between desks, funding a new account, consolidating profits. Funds never leave the Organization, but transfers change which team can reach them, which is why they are governed with the same care as withdrawals.

The both-sides rule deserves emphasis: the Transfer permission is required on both the source and the destination account. A Member cannot drain an account they control into one they do not, and cannot pull funds into their accounts from elsewhere in the Organization. Both ends of every transfer are under explicit grant.

Both workflows can be started from two places, with identical checks and outcomes either way:

• From the page-level button. Select Withdraw or Transfer from the main navigation. You choose the source account explicitly in the flow (and, for transfers, the destination). Only accounts your permissions cover are offered.
• From an account row. In the Accounts list, each account’s row offers the same actions with that account preselected as the source. The preselected source stays visible through review and submission. Transfers still ask for an explicit destination. See Working across many accounts for how the interface keeps account context unambiguous.

• Track it in Requests. Every withdrawal and transfer request shows its status, the approvals collected so far, and who has reviewed it.
• Approvers review the full detail. Source (and destination), asset, amount, and the initiator, approvers see everything before deciding. Any single approver can reject.
• Completion is recorded. When a request completes, the movement is recorded as a security event linked to the request and its approval trail, giving you an audit path from decision to funds.

Submitting a withdrawal or transfer request locks the amount on the source account straight away, before any approval is collected. The funds stop being available for trading or other fund movements at that point, and they leave the account only when the request is approved and settles.

Two practical effects:

• Your available balance drops at submission, not at completion. An account with requests in flight shows less available balance than its total. Reconciliation and trading automation should read the available figure.
• A request that does not complete releases the lock. Rejected, expired, and canceled requests return the amount to the available balance.

Because the amount is held from the start, an approved request no longer fails for want of balance. You do not need to keep the funds clear manually while approvals are in flight.

Check 2 is failing: their Workflow Profile does not hold Initiate on the Withdrawal Request workflow. The Withdraw account permission only selects accounts, the profile decides whether they can start requests. The effective access preview on their Member page shows exactly this resolution.

Withdraw and Transfer are separate permissions, and Transfer must be held on both the source and destination. Check their Account Roles for the Transfer permission on both accounts involved, and their profile for Initiate on Transfer Request.

You hold the Transfer permission on the source but not on that destination. Both ends of a transfer must be covered by your permissions. Ask an administrator to extend your Account Role to the destination account.

The initiator holds Execute on Withdrawal Request and the policy’s “Always require approval” is OFF. That combination completes requests immediately by design. To require review for everyone, turn “Always require approval” ON, see Policies, approvals, and governance.

Not enough eligible approvers have acted. Check who holds Approve on Transfer Request, excluding yourself, since you cannot approve your own request, and confirm they are active. If an approver was deactivated after you submitted, the request holds to the approval count from when it was created; grant Approve to another Member to unblock it.

Check the Requests page for withdrawal or transfer requests still awaiting approval. The amount on each one is locked at submission and stays locked until the request completes or is rejected, so an account with requests in flight shows less available balance than its total. See “Funds are locked when you submit.”

The call created a request, and the request is waiting for approval. A refid confirms the request exists, not that the withdrawal completed. Track the request using the approval_request_id returned alongside it, or find it on the Requests page. See Governance and API keys.