Create Policy
Set up a new policy for your organization.Each policy must include a rule. When the policy is evaluated, the rule configuration determines whether the policy triggers for a given activity.Dfns policies support approval workflows through configurable approvalGroups. Unlike some competitors, Dfns does not expose a separate “admin quorum” concept; instead, quorum requirements are defined within the policy engine for flexibility.
- HTTP request
- POST /v2/policies
- Authorization requirements
-
Organization User (CustomerEmployee)
Delegated User (EndUser)
Service Account
- Required Permission
-
Policies:Create(always required) - Headers
-
-
Authorization(string, header, required): Bearer token used to authenticate API requests. -
X-DFNS-USERACTION(string, header, required): User action signature used to sign change-inducing requests.
-
- Request body
-
curl --request POST \ --url https://api.dfns.io/v2/policies \ --header 'Authorization: Bearer <token>' \ --header 'Content-Type: application/json' \ --header 'X-DFNS-USERACTION: <api-key>' \ --data ' { "name": "chainalysis prescreening policy", "activityKind": "Wallets:Sign", "rule": { "kind": "ChainalysisTransactionPrescreening", "configuration": { "alerts": { "alertLevel": "LOW", "categoryIds": [] }, "exposures": { "direct": { "categoryIds": [] } }, "addresses": { "alertLevel": "LOW", "categoryIds": [] }, "fallbackBehaviours": { "skipUnscreenableTransaction": false, "skipUnsupportedNetwork": false, "skipUnsupportedAsset": false, "skipChainalysisFailure": false } } }, "action": { "kind": "Block" }, "filters": { "walletId": { "in": [ "wa-4sql3-a6ct4-8j2q8ih86d853rgg", "wa-j9btt-5s9o8-i3r8373ddg0usn3" ] } } } ' - Response
-
Example response:
{ "id": "<string>", "name": "<string>", "status": "Active", "activityKind": "Registry:Addresses:Modify", "rule": { "kind": "AlwaysTrigger", "configuration": {} }, "action": { "kind": "RequestApproval", "approvalGroups": [ { "quorum": 2, "approvers": { "userId": { "in": [ "<string>" ] } }, "name": "<string>", "initiatorCanApprove": true } ], "autoRejectTimeout": 2 }, "dateCreated": "<string>", "dateUpdated": "<string>", "filters": {} }
Things to remember
Misconfigured approval rules can prevent any user from approving an action. By default, users cannot approve an activity that they initiated, even if they are members of the approval group. To allow self-approval, set initiatorCanApprove to true. Improper configuration can prevent any user from completing the approval process.
- Single approver scenario
-
A policy requires approval from one specific admin user, for example, the CEO:
- Quorum: 1
- Approver: CEO
initiatorCanApproveis not enabled
If the CEO initiates a transfer:
- The CEO cannot approve the request.
- No other user is available to approve it.
- The transaction remains pending indefinitely.
Result:The transaction cannot be completed because no valid approver exists.
Resolution EnableinitiatorCanApproveor add additional approvers to the group.
- Full quorum requirement
-
A policy requires approval from all users in the organization:
- Total users: 3
- Quorum: 3
initiatorCanApproveis not enabled
If any user initiates a policy modification:
- That user cannot approve the request.
- Only two users remain available to approve.
- The quorum of three approvals cannot be reached.
Result The system is effectively locked, and the policy cannot be modified.
Resolution Either:
- Reduce the quorum (for example, 2 out of 3), or
- Enable
initiatorCanApprove
If the configuration is already active and blocking changes, you must:
- Add a new user with approval permissions to meet the quorum, or
- Contact support for administrative intervention