Policies

A policy acts as a gate for a specific activity within IBM Digital Asset Haven. Before an activity is executed, the policy engine evaluates all applicable policies. Depending on the policy configuration, the activity can be blocked or routed through an approval workflow.

Note: Default behavior:

If no policies are configured, all actions are allowed. Policies add restrictions on top of this default allow‑all behavior. They do not act as an allowlist.

Warning: Delegated wallets bypass policies.

Policies apply only to organization-managed wallets. Delegated wallets bypass the policy engine entirely because the end user holds full signing authority. The organization cannot enforce policy controls on delegated wallet transactions.

Note: All applicable policies are evaluated.

When an activity occurs, every matching policy is evaluated. Policies do not override one another. If any policy issues a Block action, the activity is blocked. If multiple policies issue Request approval, approvals from all triggered policies are required before the activity proceeds.

Policies are commonly used to support risk management, information security, compliance, and governance requirements.

Policy configuration example

The policy engine allows you to define conditions that trigger approval requirements and specify who must approve an action.For example, assume the following compliance requirements:

Transactions over USD 100,000 require approval from a Vice President.
Transactions over USD 250,000 require approval from both a Vice President and a Managing Director.

To implement these requirements, create two policies:Large payment

Rule: TransactionAmountLimit with a threshold of USD 100,000
Action: Request approval from the Vice Presidents approval group

Very large payment

Rule: TransactionAmountLimit with a threshold of USD 250,000
Action: Request approval from the Managing Directors approval group

When a policy is triggered, IBM Digital Asset Haven creates an approval request. The request must be approved or rejected by users in the associated approval group before the activity can proceed.

Available rules

Rule	Trigger condition
`AlwaysTrigger`	Every signing request requires approval or is blocked
`TransactionAmountLimit`	Transaction amount exceeds a defined USD threshold
`TransactionAmountVelocity`	Total transferred value exceeds a limit within a time window
`TransactionCountVelocity`	Number of transactions exceeds a limit within a time window
`TransactionRecipientWhitelist`	Recipient address is not on the approved list
`ChainalysisTransactionPrescreening`	Outbound transaction flagged by Chainalysis KYT
`ChainalysisTransactionScreening`	Incoming transaction flagged by Chainalysis KYT
`GlobalLedgerTransactionPrescreening`	Outbound transaction flagged by Global Ledger KYT
`TravelRuleTransactionPrescreening`	Transfer requires travel rule compliance through Notabene

When triggered, a policy either blocks the activity or requires explicit approval.

Approval process

When a policy triggers with the Request approval action, the transaction is paused until the required approvals are received. Approval requirements are defined using approval groups and quorums.

Approval group: A set of users authorized to approve an action. You can specify individual users or allow any user in the organization.
Quorum: The minimum number of approvals required from an approval group, for example, two out of five approvers.

A transaction can require approval from multiple groups. For example, you could require approval from both a compliance team and a finance team. The transaction proceeds only after all groups meet their quorum requirements.If any approver rejects the request, the transaction is rejected. You can optionally configure an automatic rejection timeout to prevent approval requests from remaining pending indefinitely.

Note: By default, the transaction initiator cannot approve their own request. Set initiatorCanApprove to true if self-approval is required.

Service account approvers

Service accounts can participate as approvers when the approval group is configured with serviceAccountsCanApprove set to true. This enables automated approval workflows in which service accounts participate alongside human approvers.

Note: This feature requires activation by IBM support for your organization.

When enabled:

Service accounts must be explicitly listed in the approval group. Wildcards are not supported.
Service account approvals count toward the quorum.
A service account rejection denies the request.
Approval groups can include both human and service account approvers.

Automating with service accounts

For automated workflows such as scheduled payouts, certain wallets might need to bypass approval requirements.

Using wallet tags

You can scope policies by using wallet tags:

Tag wallets that require approval, for example, requires-approval.
Configure policies to apply only to wallets with that tag.

Example policy configuration:

{
  "name": "Large Payment Approval",
  "activityKind": "Wallets:Sign",
  "rule": {
    "kind": "TransactionAmountLimit",
    "configuration": {
      "limit": "100000",
      "currency": "USD"
    }
  },
  "action": {
    "kind": "RequestApproval",
    "approvalGroups": [...]
  },
  "filters": {
    "walletTags": {
      "hasAny": ["requires-approval"]
    }
  }
}

This policy enforces approval only for wallets tagged with requires-approval. Automated wallets that are not tagged bypass the policy.

Tip: You can also target individual wallets using the walletId filter, but wallet tags provide greater flexibility when managing groups of wallets.