# Manage policies via the console

Transaction policies define the rules that govern outgoing transactions from your wallets. Without an applicable policy for a given asset, Ripple Custody (Wallet) blocks all outgoing transactions for that asset. Design policies that balance operational flexibility with security controls.

This page explains how to create, change, and delete policy rules in the Ripple Custody (Wallet) console: limit rules, approval rules, and Travel Rule rules. For how the rule kinds work together, see [Policies](/pt-br/products/wallet/governance-and-controls/policies#rule-kinds). To manage rules with the API, see [Manage policy rules via the API](/pt-br/products/wallet/governance-and-controls/policies/manage-policies-api).

## Policy actions

| Action | Console role | Console procedure | API procedure |
|  --- | --- | --- | --- |
| Create a limit, approval, or Travel Rule rule | Owner, Administrator | [Create a policy](#create-a-policy-via-the-console) | [Create a policy rule](/pt-br/products/wallet/governance-and-controls/policies/manage-policies-api#create-a-policy-rule-via-the-api) |
| Check rule status | All except Viewer | [View policy status](#view-policy-status-via-the-console) | [List a wallet's policy rules](/pt-br/products/wallet/governance-and-controls/policies/manage-policies-api#list-a-wallets-policy-rules-via-the-api) |
| Get a policy rule | All except Viewer | Open the wallet's **Policy** tab. | [Get a policy rule](/pt-br/products/wallet/governance-and-controls/policies/manage-policies-api#get-a-policy-rule-via-the-api) |
| Change a rule | Owner, Administrator | [Modify a policy](#modify-a-policy-via-the-console) | [Change a policy rule](/pt-br/products/wallet/governance-and-controls/policies/manage-policies-api#change-a-policy-rule-via-the-api) |
| Delete a rule | Owner, Administrator | [Delete a policy](#delete-a-policy-via-the-console) | [Delete a policy rule](/pt-br/products/wallet/governance-and-controls/policies/manage-policies-api#delete-a-policy-rule-via-the-api) |
| Manage wallet limits | - | - | [Use the wallet limits endpoints](/pt-br/products/wallet/governance-and-controls/policies/manage-policies-api#use-the-wallet-limits-endpoints-via-the-api) |


**Permissions:** In the console, owners and administrators can create and delete policy rules. Owners, administrators, proposers, and approvers can approve them, and every role except viewer can view them. See [User roles and permissions](/pt-br/products/wallet/organization-and-access/users-and-roles#policies). The API procedures need an API credential of type `CONTROLS`. See [Prerequisites](/pt-br/products/wallet/governance-and-controls/policies/manage-policies-api#prerequisites).

## Before you begin

Complete these prerequisites before creating policies:

| Requirement | Description |
|  --- | --- |
| **Vault created** | You need an existing vault. See [Create your first vault](/pt-br/products/wallet/get-started/console/create-your-first-vault). |
| **Wallet created** | You need an existing wallet within the vault. See [Create your first wallet](/pt-br/products/wallet/get-started/console/create-your-first-wallet). |
| **Console access** | You need the Owner or Administrator role to create or delete policy rules. The **Add a new rule** button appears only for these roles. |
| **API credentials (for API usage)** | Credentials with the `policy:create`, `policy:read`, and `policy:delete` permissions for the policy rules API, or `keylimit:create`, `keylimit:read`, and `keylimit:delete` for the older wallet limits endpoints. See [Manage policy rules via the API](/pt-br/products/wallet/governance-and-controls/policies/manage-policies-api#prerequisites). |


Wallets are deposit-only by default
You must create a policy for an asset before you can send outgoing transactions with that asset.

## How policies work

When a user or API credential submits a transaction, the Ripple Custody (Wallet) 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/governance-and-controls/policies#evaluation-order).

## Create a policy via the console

**Required role:** Owner or Administrator.

1. Open the wallet in the Ripple Custody (Wallet) console and go to the **Policy** tab.
2. Select **Add a new rule**.
3. On the **Direction** step, select **Outbound** for transfers from this wallet, or **Inbound** for deposits into this wallet. Only Travel Rule rules support **Inbound**. Select **Next**.
![The Direction step of the Add policy rule form, with the Outbound and Inbound options](../../images/policy-stepper-direction.png)
4. On the **Rule** step, select **Limit**, **Approval**, or **Travel rule**, and then select **Next**. **Travel rule** is unavailable until you connect a Travel Rule provider.
5. On the **Conditions** step, select the asset the rule applies to. The list shows assets currently held in the wallet.
If the asset you need isn't listed, select **Add asset** and enter the asset's blockchain, standard, symbol, and contract address.
6. Set the conditions for the rule:
  - **Limit:** Enter the **Value limit** in the asset's native units (for example, ETH, not wei), and then select the limit type. See [Policy reference](/pt-br/products/wallet/governance-and-controls/policies/policy-reference#limit-types) for details on each limit type.
| Limit type | What it controls | Example |
|  --- | --- | --- |
| **Per transaction** (API: `SINGLE_TX`) | Maximum amount for any single transaction | No single transaction can exceed 10 ETH |
| **Rolling** (API: `ROLLING`) | Maximum amount within a time window | No more than 100 ETH per 24 hours |
| **Max total value** (API: `TOTAL`) | Lifetime cap on total withdrawals | No more than 1,000 ETH can ever leave this wallet |
For **Rolling**, select a **Duration**: 1 hour, 1 day, 1 week, 2 weeks, 1 month, 3 months, 6 months, or 1 year. To enter another window, select **Custom...**, enter a number, and select **Hours**, **Days**, **Weeks**, **Months**, or **Years**. The window must be shorter than one year. The console offers **1 year**, but Ripple Custody (Wallet) rejects a rule with that duration.
  - **Approval:** See [Create a step-up approval rule via the console](/pt-br/products/wallet/governance-and-controls/approvals/step-up-approvals#create-a-step-up-approval-rule-via-the-console).
  - **Travel rule:** See [Create a Travel Rule policy rule via the console](/pt-br/products/wallet/compliance/travel-rule/set-up-travel-rule#create-a-travel-rule-policy-rule-via-the-console).
Select **Next**.
![The Conditions step with a Rolling limit of 1000 XRP over 1 day](../../images/policy-stepper-limit-conditions.png)
7. On the **Scope** step, under **To**, select the destinations the rule applies to:
  - **All counterparties and wallets**: Selected by default. The broadest option, which covers every destination.
  - **All counterparties**: Covers transactions to any counterparty and all its addresses. It doesn't cover transfers to your own wallets. In the API, this is the `ALL_COUNTERPARTIES` matcher.
  - **Selected counterparties**: Covers transactions only to specific counterparties and all addresses on those counterparty records. In the API, this is the `COUNTERPARTY_ID` matcher.
  - **Selected addresses**: Covers transactions only to specific addresses from your address book.
  - **Selected wallets**: Covers transactions only to specific wallets within your organization.
You can also narrow the rule by **Sign for address** and **Transaction types**, and, on an EVM wallet, by **Chain IDs**. To enter a signing address that isn't listed, turn on **Use a custom address**. Leave a field empty to apply the rule to all values. Select **Next**. Approval rules skip the **Scope** and **Advanced** steps, because they don't support matchers.
![The Scope step with destination options, including All counterparties](../../images/policy-stepper-scope.png)
For cross-chain raw signing to an EVM chain that Ripple Custody (Wallet) doesn't natively support, add the target chain ID under **Chain IDs** (the `CHAIN_ID` matcher). Rules without a matching `CHAIN_ID` matcher don't authorize those transactions.
8. On the **Advanced** step, leave **All** selected, or restrict the rule to one **User** or **API credential**. Select **Next**.
Each option in the **Scope** and **Advanced** steps sets a matcher:
| Option | API value | What it controls |
|  --- | --- | --- |
| **Transaction types** | `TRANSACTION_TYPE` | Applies the rule only to selected transaction types (for example, `OfferCreate` only on an XRP Ledger wallet). |
| **User** | `USER` | Applies the rule only to transactions initiated by the selected user. |
| **API credential** | `API_CREDENTIAL` | Applies the rule only to transactions initiated by the selected API credential. |
| **Sign for address** | `SIGN_FOR` | Applies the rule only to transactions signed for selected addresses (multi-signature scenarios). |
| **Selected counterparties** | `COUNTERPARTY_ID` | Applies the rule only to selected counterparties and their registered addresses. |
| **Selected addresses** | `ADDRESS_ID` | Applies the rule only to selected address book entries. |
| **Selected wallets** | `WALLET_ID` | Applies the rule only to selected wallets in your organization. |
| **Chain IDs** | `CHAIN_ID` | Applies the rule only to selected EVM chain IDs for cross-chain raw signing. |
9. On the **Confirm** step, review the rule, and then select **Add policy rule**.
![The Confirm step for a Rolling limit rule](../../images/policy-stepper-limit-confirm.png)


## After you create a policy

What happens next depends on your organization's approval configuration:

- **With approval groups configured:** The policy shows **Inactive | Approval pending**. Designated approvers receive a notification to review the policy, and find the request under **Notifications** > **Approvals**. After the required number of approvers authorize it, the policy shows **Active | Enabled**. If approvers don't respond within the timeout window, or if too many skip, the policy is rejected.
![Notifications showing three pending Policy rule approval requests](../../images/policy-rule-approval-requests.png)
- **Without approval groups configured:** The policy **activates immediately** after creation. You can start using it right away.


Active policies take effect immediately
The policy engine evaluates every outgoing transaction against a policy the moment the policy becomes active. Ripple Custody (Wallet) blocks any transaction that exceeds the limits or targets an unpermitted destination.

Check your approval configuration
Go to **Controls > Approval groups** to see if an approval group exists for Policy rules. See [Configure approval flows](/pt-br/products/wallet/governance-and-controls/approvals/configure-approval-flows#create-an-approval-group-via-the-console) to create one.

## View policy status via the console

Each policy displays its current status in the **Active** column of the **Policy** tab. For example, a policy shows **Inactive | Approval pending** while its creation waits for approval, **Active | Enabled** while it's active, and **Active | Approval pending** while its deletion waits for approval. After a deletion takes effect, the policy no longer appears in the list. See [Rule statuses](/pt-br/products/wallet/governance-and-controls/policies/policy-reference#rule-statuses) for the complete status reference.

![The Policy tab listing Approval, Travel rule, and Limit rules, all Active and Enabled](../../images/policy-rules-list.png)

## Modify a policy via the console

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

1. Create a new policy for the same asset with the updated values.
2. Wait for the new policy to be approved, if your organization requires approval, and become active.
3. Delete the old policy.


![The Policy tab with two Limit rules for XRP, both Active and Enabled](../../images/policy-replace-rule.png)

Avoid protection gaps
Create the new policy before deleting the old one. This ensures continuous protection with no window where no policy applies.

See [Policy concepts](/pt-br/products/wallet/governance-and-controls/policies#policy-immutability) for why policies are immutable.

## Delete a policy via the console

**Required role:** Owner or Administrator.

1. Open the wallet and go to the **Policy** tab.
2. Find the policy in the table.
3. Open the **Actions** menu (three dots) on the policy row and select **Delete**.
4. In the **Delete policy** dialog, select **Submit**.


![The Delete policy dialog with the Cancel and Submit buttons](../../images/policy-delete-dialog.png)

**What happens after deletion:**

- **With approval groups:** The policy shows **Active | Approval pending**. It continues enforcing transactions until approvers authorize the deletion.
- **Without approval groups:** The policy is deleted immediately and stops enforcing.


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.

Cannot delete pending policies
You can't delete a policy that is still pending creation approval. Wait for it to be approved or rejected first.

## Manage policies with the API

To create, list, get, and delete policy rules programmatically, see [Manage policy rules via the API](/pt-br/products/wallet/governance-and-controls/policies/manage-policies-api).

## Multiple policies for the same asset

You can create multiple policies for the same asset in a wallet when:

- The policies have **different limit types** (for example, one per-transaction and one rolling policy)
- The policies have **different filters** (for example, one for all transactions and one for a specific user)


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, Ripple Custody (Wallet) 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.

Policy matching
A policy matches a transaction if the wallet, asset, and all configured filters align with the transaction details. See [Policy concepts](/pt-br/products/wallet/governance-and-controls/policies#policy-evaluation) for how policy evaluation works.

## 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. Scoped policies replace unscoped ones, so repeat each layer with the same matchers.
- **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/governance-and-controls/approvals/configure-approval-flows).
- **Escalate large transactions.** Use [step-up approvals](/pt-br/products/wallet/governance-and-controls/approvals/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/compliance/travel-rule) policy rules to exchange originator and beneficiary information through Notabene.


For more patterns, see [Policy best practices](/pt-br/products/wallet/governance-and-controls/policies/best-practices).

## Related documentation

- [Policies](/pt-br/products/wallet/governance-and-controls/policies) - Understand scope, lifecycle, and evaluation
- [Policy reference](/pt-br/products/wallet/governance-and-controls/policies/policy-reference) - Complete reference for limit types, matchers, statuses, permissions, and error codes
- [Manage policy rules via the API](/pt-br/products/wallet/governance-and-controls/policies/manage-policies-api) - Create, list, get, and delete policy rules with the API
- [Policy best practices](/pt-br/products/wallet/governance-and-controls/policies/best-practices) - Recommended patterns and troubleshooting
- [Unlock outgoing transactions](/pt-br/products/wallet/get-started/console/unlock-outgoing-transactions) - Full walkthrough including policy setup