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.

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.

A pending request does not set funds aside. The source account’s balance is checked when the request completes, after the final approval, not when the request is created. If the funds have moved in the meantime (a trade, another withdrawal, a transfer), the request fails at completion and needs to be resubmitted.

For most teams this never comes up. Where it can: an active trading account that also processes withdrawals, or several fund-movement requests drawing on the same balance at once. Until reserved funds arrive (see below), two habits keep approvals smooth:

• Treat a submitted request as spoken-for balance, avoid trading or moving the amount while approvals are in flight.
• When several requests draw on one account, approve them in the order that matches the available balance.

Reserving funds at request creation is planned: once it ships, submitting a request will set the amount aside, and an approved request will never fail because the balance moved during review.

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.

The source account’s balance no longer covered the amount when the request completed. Balances are checked at completion, not at creation, and a pending request does not set funds aside, so activity on the account during review can leave too little behind. Confirm the funds are back on the source account and submit a new request. See “Keep the funds available until approval.”