Skip to main content
POST
/
v2
/
policies
Create Policy
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"
      ]
    }
  }
}
'
{
  "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": {}
}

​
Authentication

✅ Organization User (CustomerEmployee)
❌ Delegated User (EndUser)
✅ Service Account

​
Required Permissions

Policies:Create: Always required.

Authorizations

​
Authorization
string
header
required

Bearer Token: Used to authenticate API requests. More details how to generate the token: Authentication flows

​
X-DFNS-USERACTION
string
header
required

User Action Signature: Used to sign the change-inducing API requests. More details how to generate the token: User Action Signing flows

Body

application/json
  • Registry:Addresses:Modify
  • Permissions:Assign
  • Permissions:Modify
  • Policies:Modify
  • Registry:ContractSchemas:Modify
  • Wallets:Sign
  • Wallets:IncomingTransaction
​
name
string
required
​
activityKind
enum<string>
required
Available options:
Registry:Addresses:Modify
​
rule
AlwaysTrigger · object
required

This rule will always be triggered, meaning that if this rule is defined on a policy, the policy will always trigger the policy action, regardless of the activity details.

​
action
RequestApproval · object
required

This action means that activity will first require an Approval process to be completed before it can be executed (or be aborted if someone rejects it during the approval process).

One or several groups of approvers need to be specified. These groups define who is allowed to approve / reject an activity.

The activity will only be executed if all approver groups reach their "quorum" of approvals. Otherwise, if any one user within any approver group rejects, then the activity is aborted and the call is not executed.

The example below shows a RequestApproval action, configured with one approval group requiring 2 approvals amongst three specific users.

{
  "action": {
    "kind": "RequestApproval",
    "autoRejectTimeout": 60, // minutes
    "approvalGroups": [
      {
        "name": "Admins",
        "quorum": 2, // only 2 approvers required in that group 
        "approvers": {
          "userId": {
            "in": ["us-...1", "us-...2", "us-...3"],
          }
        }
      }
    ],

  }
}

Don't lock yourself up

By default, users cannot approve an activity they initiated themselves, even if they are in an approval group. To allow this, you must set initiatorCanApprove: true.

Example 1: For any wallet transfer, a policy is setup to require approval from 1 specific admin user (eg. the CEO). initiatorCanApprove was not set to true. If the CEO himself initiates a transfer, no-one can approve his transfer and it's stuck.

Example 2: Company has only 3 users. A policy is setup to require approval from any 3 users (quorum: 3) for any modification of a policy. initiatorCanApprove was not set to true. In this case, they are locked, and the policy cannot be modified: whoever requests a modification cannot approve, and the policy is therefore always missing one approver. To unlock, they would need to invite a new user and give him the rights to approve as well.

  • RequestApproval
  • Block
​
filters
object

Response

200 - application/json

Success

  • Registry:Addresses:Modify
  • Permissions:Assign
  • Permissions:Modify
  • Policies:Modify
  • Registry:ContractSchemas:Modify
  • Wallets:Sign
  • Wallets:IncomingTransaction
​
id
string
required
​
name
string
required
​
status
enum<string>
required
Available options:
Active,
Archived
​
activityKind
enum<string>
required
Available options:
Registry:Addresses:Modify
​
rule
AlwaysTrigger · object
required

This rule will always be triggered, meaning that if this rule is defined on a policy, the policy will always trigger the policy action, regardless of the activity details.

​
action
RequestApproval · object
required

This action means that activity will first require an Approval process to be completed before it can be executed (or be aborted if someone rejects it during the approval process).

One or several groups of approvers need to be specified. These groups define who is allowed to approve / reject an activity.

The activity will only be executed if all approver groups reach their "quorum" of approvals. Otherwise, if any one user within any approver group rejects, then the activity is aborted and the call is not executed.

The example below shows a RequestApproval action, configured with one approval group requiring 2 approvals amongst three specific users.

{
  "action": {
    "kind": "RequestApproval",
    "autoRejectTimeout": 60, // minutes
    "approvalGroups": [
      {
        "name": "Admins",
        "quorum": 2, // only 2 approvers required in that group 
        "approvers": {
          "userId": {
            "in": ["us-...1", "us-...2", "us-...3"],
          }
        }
      }
    ],

  }
}

Don't lock yourself up

By default, users cannot approve an activity they initiated themselves, even if they are in an approval group. To allow this, you must set initiatorCanApprove: true.

Example 1: For any wallet transfer, a policy is setup to require approval from 1 specific admin user (eg. the CEO). initiatorCanApprove was not set to true. If the CEO himself initiates a transfer, no-one can approve his transfer and it's stuck.

Example 2: Company has only 3 users. A policy is setup to require approval from any 3 users (quorum: 3) for any modification of a policy. initiatorCanApprove was not set to true. In this case, they are locked, and the policy cannot be modified: whoever requests a modification cannot approve, and the policy is therefore always missing one approver. To unlock, they would need to invite a new user and give him the rights to approve as well.

  • RequestApproval
  • Block
​
dateCreated
string
​
dateUpdated
string
​
filters
object