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
Last updated: 17 August 2026
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:
Members cannot approve their own requests, so count approvers from the point of view of whoever starts a request. An approver who never starts requests counts for everyone; an approver who also starts requests cannot count toward their own. Two approvals are met by two approvers who only approve, but not by two approvers who also start requests. The system blocks a configuration no one could satisfy, and the policy editor shows your available approvers alongside the number you are asking for.
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 you should confirm the unlock route before locking, as described under “Safeguards” below. Nothing in the product stops you from locking a policy into a state no one can change. See Rolling out governance for when to take this step.
Confirm the unlock can still happen before you lock. Unlocking is a Manage Policies request against a locked policy, so Execute cannot shortcut it. You need a Member who can start a Manage Policies request, plus as many other Members holding Approve on Manage Policies as that workflow requires, all of them verified and active. The system does not check this for you, and a locked policy with no route to an approved change needs Kraken support to recover.
Lockout prevention. A change is refused when it would leave a workflow with no one able to complete the requests started on it. Because Members cannot approve their own requests, this happens as soon as the required count exceeds what any single initiator can reach on their own requests. The check runs on both sides: when you edit a policy, and when you change a Member’s Workflow Profile or an Account Role.
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. Only Members who have accepted their invitation and completed verification count toward approvals: an invited Member does not count until both are done, even though they appear in your team list. 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.
Check your Workflow Profile: locking requires Initiate or Execute on the Manage Policies workflow. If the lock request was created but nothing changed, it is waiting for approval rather than refused, see the entry above.
The product does not refuse a lock for want of an independent approver, so confirm the unlock route yourself before locking: a Member who can start a Manage Policies request, plus as many other Members holding Approve on Manage Policies as that workflow requires.
The required approvals exceed what some Member who starts requests could gather, since nobody can approve their own request. The policy editor names the cause: one or more Members hold both Initiate and Approve, so each of them faces one fewer approver than the total. Lower the required approvals, or grant Approve to another Member who does not start requests on this workflow.