# Configure transaction policies

Transaction policies define the rules that govern outgoing transactions from your wallets. Without a matching policy for a given asset, Wallet-as-a-Service blocks all outgoing transactions for that asset. As an owner or administrator, you design policies that balance operational flexibility with security controls.

## How policies work

When a user or API credential submits a transaction, the Wallet-as-a-Service policy engine automatically evaluates it against the wallet's active policies. The engine checks:

1. Does a policy exist for this asset?
2. Does the transaction amount fall within the policy's limit?
3. Is the destination permitted by the policy?
4. Is the initiator permitted by the policy (if restricted)?
5. Do any other policy matchers, such as transaction type, signing address, or chain ID, match the transaction?


If a policy with matchers matches the transaction, only the matching policies with matchers apply. Otherwise, the policies without matchers apply. The transaction must satisfy **every** applicable policy. If no policy applies, or the transaction exceeds any applicable policy, the platform blocks it. See [Policy evaluation](/pt-br/products/wallet/user-interface/policies/policies-concepts#evaluation-order).

## Create a policy rule

1. Open the wallet and go to the **Policy** tab.
2. Select **Add a new rule**.
3. Select the **asset** the policy applies to. The dropdown lists assets currently held in the wallet.


Non-standard assets
If the asset you need isn't listed, select **switch to non-standard asset** and enter the blockchain, contract address, and symbol manually.

1. Select a **rule type**:


| Rule type | What it controls | Example |
|  --- | --- | --- |
| **Per transaction** | Maximum amount for any single transaction | No single transaction can exceed 10 ETH |
| **Rolling** | Maximum amount within a time window | No more than 100 ETH per 24 hours |
| **Max total value** (API: `CONSTANT`) | Lifetime cap on total withdrawals | No more than 1,000 ETH can ever leave this wallet |


1. Set the **value limit**.
2. Under **Apply this rule to**, select the allowed destinations:
  - **All counterparties and wallets** - the broadest option. Permits transactions to any registered address or internal wallet.
  - **Selected counterparties** - permits transactions only to specific counterparties and all addresses on those counterparty records. In the API, use `COUNTERPARTY_ID` instead of the older `COUNTERPARTY` matcher.
  - **Selected addresses** - permits transactions only to specific addresses from your address book.
  - **Selected wallets** - permits transactions only to specific wallets within your organization.
3. Add any other matchers that the policy needs:


| Matcher | API value | What it controls |
|  --- | --- | --- |
| **Transaction type** | `TRANSACTION_TYPE` | Applies the rule only to selected transaction types. |
| **User** | `USER` | Applies the rule only to transactions initiated by selected users. |
| **API credential** | `API_CREDENTIAL` | Applies the rule only to transactions initiated by selected API credentials. |
| **Sign for** | `SIGN_FOR` | Applies the rule only to transactions signed for selected addresses. |
| **Counterparty** | `COUNTERPARTY_ID` | Applies the rule only to selected counterparties and their registered addresses. |
| **Address** | `ADDRESS_ID` | Applies the rule only to selected address book entries. |
| **Wallet** | `WALLET_ID` | Applies the rule only to selected wallets in your organization. |
| **Chain ID** | `CHAIN_ID` | Applies the rule only to a selected EVM chain ID for cross-chain raw signing. |


Cross-chain raw signing requires Chain ID
For cross-chain raw signing to an EVM chain that Wallet-as-a-Service doesn't natively support, add a `CHAIN_ID` matcher for the target chain ID. Policies without a matching `CHAIN_ID` matcher don't authorize those transactions.

1. Select **Add a new rule**.


Policies take effect immediately
The policy engine evaluates every outgoing transaction against active policies the moment you create them. Wallet-as-a-Service blocks any transaction that exceeds the limits or targets an unpermitted destination.

## Multiple policies

You can create multiple policies for the same asset in a wallet. When a user or API credential submits a transaction, the transaction must pass every applicable policy.

This lets you create layered policies. For example:

- A **per transaction** policy limiting individual sends to 10 ETH
- A **rolling** policy limiting total sends to 100 ETH per 24 hours


Scoped policies replace unscoped ones
When a policy with matchers applies to a transaction, policies without matchers don't apply to it. For example, if you add a 5 ETH policy for one API credential, Wallet-as-a-Service checks that credential's transactions against the 5 ETH policy only, not against the 10 ETH or 100 ETH policies. To keep a rolling cap for that credential, add a rolling policy with the same matcher.

## Edit a policy rule

You can't edit a policy. To change an existing policy:

1. Create a new policy for the same asset with the updated conditions.
2. After the new policy is active, delete the old policy.


## Delete a policy rule

1. Open the wallet and go to the **Policy** tab.
2. Find the policy in the table.
3. Open the **Actions** menu and select **Delete**.


Removing the last policy blocks all sends
If you delete the only policy for an asset, the wallet can no longer send that asset until you create a new policy.

## Design effective policies

Consider these strategies when designing your policy structure:

- **Layer multiple rule types.** Combine per-transaction limits with rolling limits and lifetime caps for defense in depth.
- **Restrict destinations.** Use selected counterparties or addresses instead of "all" to limit where funds can go.
- **Restrict initiators.** Assign specific policies to specific users or API credentials. This prevents unauthorized users from initiating high-value transactions.
- **Start conservative.** Begin with low limits in sandbox, validate your operations, then adjust limits upward as needed.
- **Pair with approval groups.** Policies control allowed actions; approval groups add human oversight. Use both together. See [Configure approval flows](/pt-br/products/wallet/admin-guide/configure-approval-flows).
- **Escalate large transactions.** With Policy Engine v2, use [step-up approvals](/pt-br/products/wallet/user-interface/policies/step-up-approvals) to require specific approvers for transactions of more than an amount, instead of blocking them.
- **Meet Travel Rule obligations.** If your organization is a regulated VASP, use [Travel Rule](/pt-br/products/wallet/user-interface/travel-rule/travel-rule-overview) policy rules to exchange originator and beneficiary information through Notabene.


## Related guides

- [Policies overview](/pt-br/products/wallet/user-interface/policies/policies-overview) — Conceptual overview
- [Manage policies](/pt-br/products/wallet/user-interface/policies/policies-manage) — Reference documentation
- [Unlock outgoing transactions](/pt-br/products/wallet/getting-started/unlock-outgoing-transactions) — Full walkthrough including policy setup