All
Filter by:
How do I deposit cash into my account?
I need help with account verification
Why can't I access my account?
Are there any crypto withdrawal fees?
I need help signing into my account
Policies, approvals, and governance
Policies decide how governed operations complete: immediately, or after review by other Members. Each workflow carries one policy, set once for the whole Organization. This article explains the request lifecycle, the policy settings, and locking. For who can start and approve requests, see Roles, profiles, and permissions.
Note:
Policies belong to workflows, never to accounts. There is one Withdrawal Request policy for the Organization, not one per account. To vary who can withdraw from which account, use fund-movement permissions in Account Roles; to vary how strictly withdrawals are reviewed, you have a single dial for the whole workflow.
Every governed operation follows the same path, whether it moves funds or changes the Organization’s own configuration:
1 - Initiation. A Member whose Workflow Profile holds Initiate (or Execute) on the workflow starts a request. For withdrawals and transfers, they also need the matching fund-movement permission on the accounts involved.
2 - Immediate completion check. If the Member holds Execute and the workflow’s “Always require approval” setting is OFF, the request completes on the spot. Done. One exception: a request that changes a locked policy always waits for approval, whatever the requester holds, see “Locking policies” below.
3 - Approval queue. Otherwise the request waits for review. Members with Approve on that workflow see it in their queue.
4 - Resolution. When the required number of independent approvals is reached, the request completes and takes effect. Any single approver can instead reject it, which ends the request without effect.
Completed requests are recorded as security events, linked back to the request and its approval trail.
A Member cannot approve their own request. The system enforces this on every workflow, and no permission, profile, or policy configuration overrides it.
The only way a single Member completes a governed operation alone is Execute, and only while the workflow’s policy permits immediate completion.
Each workflow’s policy has two settings:
Setting | What it does |
|---|---|
Required approvals | How many distinct Members must approve before a request completes. Approvers come from the Members holding Approve on that workflow; the initiator is always excluded for their own request. |
Always require approval | When ON, every request goes through the approval queue, including requests from Members with Execute. When OFF, Members with Execute complete requests immediately. |
The interaction between Execute and “Always require approval”:
Member’s profile on the workflow | Always require approval | Outcome |
|---|---|---|
Initiate, without Execute | OFF or ON | Request waits for approval |
Initiate + Execute | OFF | Request completes immediately |
Initiate + Execute | ON | Request waits for approval, Execute is dormant |
Execute is never removed by a policy, it stays on the profile, visibly flagged as dormant while “Always require approval” is ON, and resumes working if the setting is later turned OFF.
- Go to Policies and select the workflow (for example, Withdrawal Request).
- Set the required number of approvals.
- Choose whether Always require approval is ON or OFF.
- Review who currently holds each level on this workflow, the policy editor shows the team’s levels alongside the settings, so you can verify the configuration is satisfiable before saving.
- Confirm.
Policy changes are themselves governed operations under the Manage Policies workflow. If that workflow requires approval, your change waits in the queue like any other request.
Every policy also keeps its own change history: each update, lock, and unlock is listed there with the approval request that carried it, so you can always see what changed, who requested it, and who signed off. Completed changes are recorded as security events as well.
Important:
Before raising the required approval count, confirm enough Members hold Approve on the target workflow to meet it. The system blocks configurations that could never be satisfied.
Locking is the commitment step of governance. It requires independent approval for every future change to that workflow’s policy, including changing its approval count, changing “Always require approval,” or unlocking it.
Every policy change runs as a Manage Policies request whether the target policy is locked or not, the lock does not change where a change goes, only how it completes:
- A change to an unlocked policy follows the normal request lifecycle. A Member holding Execute on Manage Policies completes it immediately while that workflow’s “Always require approval” setting is OFF.
- A change to a locked policy, the approval count, the “Always require approval” setting, or unlocking, always waits for review by Members holding Approve on Manage Policies. The lock overrides Execute for that one policy, and it applies to everyone equally: the Owner’s changes go through the same review as anyone else’s.
Once locked, no single person can weaken the workflow’s governance alone. Changes remain routine, any Member whose Workflow Profile grants approval on Manage Policies can review and approve them, but they always take at least two people.
Locking is per workflow. Locking Withdrawal Request says nothing about Transfer Request or any other workflow, you tighten one workflow at a time, at your own pace. See Rolling out governance for the recommended progression.
Lock and unlock are requests too
Three kinds of requests run under the Manage Policies workflow. You will see them named in the approval queue, in each policy’s change history, and in security events:
Request | What it does |
|---|---|
Policy update | Changes a policy’s settings, the approval count or “Always require approval” |
Policy lock | Locks a policy |
Policy unlock | Unlocks a locked policy |
Locking is not exempt from its own rules: a lock request follows the same lifecycle as any other Manage Policies request. If you hold Execute on Manage Policies and its “Always require approval” setting is OFF, the lock takes effect immediately; otherwise it waits in the queue, and the policy stays unlocked until the request is approved.
How a policy change completes
Putting the pieces together, the outcome of any Manage Policies request:
Target policy | Requester’s level on Manage Policies | “Always require approval” on Manage Policies | Outcome |
|---|---|---|---|
Locked | Any, including Execute | ON or OFF | Waits for approval, the lock decides |
Unlocked | Initiate, without Execute | ON or OFF | Waits for approval |
Unlocked | Execute | ON | Waits for approval, Execute is dormant |
Unlocked | Execute | OFF | Completes immediately |
Two ways to govern policy changes
Control | Scope | Effect |
|---|---|---|
Policy lock | One workflow’s policy | Changes to that policy require independent approval; other workflows are untouched. |
“Always require approval” on Manage Policies | All policies | Every policy change, on every workflow, goes through approval. A bulk governance switch. |
The two controls are complementary and never conflict: wherever either one applies, the change waits for approval, and setting both changes nothing further. Use the lock for incremental tightening; use the Manage Policies setting when you want all policy changes reviewed at once.
Locking Manage Policies itself
Manage Policies is a workflow like any other: it has its own policy, and that policy has its own lock. Locking it is the final commitment of a governance rollout. Once the Manage Policies policy is locked, every change to the rules anywhere in the Organization, including unlocking any policy, and unlocking Manage Policies itself, requires independent approval. From that point, no single person can loosen governance again through the product.
This is also why the independent-approver safeguard below exists: the system will not let you lock a policy into a state that no one could ever change. See Rolling out governance for when to take this step.
- Independent approver required for locking. A policy cannot be locked unless at least one Member other than the person locking holds Approve on the Manage Policies workflow. Otherwise the lock could never be undone through the product.
- Lockout prevention. The system blocks saving a policy where the only Member holding Approve on a workflow is also its only initiator with a required count of one, their own requests would have no eligible approver.
- Deactivation warning. Verify approver coverage before deactivating a Member who holds Approve. Deactivation proceeds even if it drops a workflow below its required approval count, and pending requests hold to the threshold that applied when they were created.
Once policies make sense, Rolling out governance walks through introducing them safely: configure, validate, then lock, one workflow at a time, with worked examples.
Troubleshooting
“Always require approval” is ON for that workflow. Execute is dormant while the setting is ON; every request queues for independent approval. To restore immediate completion, turn the setting OFF in Policies, noting that this is a Manage Policies action and may itself require approval.
If the request in question is a policy change, also check the target policy: changes to a locked policy always wait for approval, regardless of Execute. That is the lock working as designed.
Locking is itself a Manage Policies request. If “Always require approval” is ON for Manage Policies, or your Workflow Profile does not hold Execute on it, the lock waits for independent approval like any other request. The policy stays unlocked until the lock request is approved, you will find it in the approval queue, and in the policy’s change history once it completes.
Count the active Members holding Approve on that workflow, excluding yourself. If an approver was deactivated after the request was created, the remaining approvers may no longer reach the required count, a pending request holds to the threshold from when it was created, even if the policy has since changed. Reactivate the Member or grant Approve to another active Member to unblock it.
At least one other Member must hold Approve on the Manage Policies workflow before any policy can be locked. Without an independent approver, a locked policy could never be changed again. Assign Approve on Manage Policies to another Member and retry.
The configuration would create requests nobody can approve, typically a single Member holding both Initiate and the only Approve on the workflow, with a required count of one. Grant Approve to at least one more Member, or give the initiating Member Execute so their requests can complete without review while the policy allows it.