# Manage policies via the console

Transaction policies define the rules that govern outgoing transactions from your wallets, so design them to balance operational flexibility with security controls. Without an applicable limit policy for a given asset, Ripple Custody (Wallet) rejects outgoing transfers of that asset. Sweeps, passkey transfers, and some signing actions aren't evaluated against policies. See [Operations that bypass policies](/pt-br/products/wallet/governance-and-controls/policies#operations-that-bypass-policies).

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).

Availability
Travel Rule policies are available in sandbox. They aren't available in production yet.

## 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 you create 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 limit policy for an asset before you can send transfers of that asset. Limit policies apply per asset, so a wallet that sends several assets needs a limit policy for each one. Approval and Travel Rule policies don't satisfy this check. The wallet must also allow outgoing transactions, and the console shows **DEPOSITS ONLY** until it does and the wallet has at least one policy. Even then, sending to an external address fails until the destination has an enabled [address book](/pt-br/products/wallet/governance-and-controls/address-book) entry.

## 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, with two exceptions: they never apply to cross-chain raw signing, and a sign-for transaction needs a policy with a matching **Sign for address**. 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](/assets/policy-stepper-direction.f903d0d8c6f5afd555f74ca9ca8212486825a82460fb714c02707763b5c91af2.9fccc40d.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. For **Inbound**, **Limit** is unavailable and **Approval** isn't listed, so you can select only **Travel rule**. **Approval** also doesn't appear if step-up approvals aren't available for your organization.
![The Rule step with the Limit, Travel rule, and Approval options](/assets/policy-stepper-rule.19b4637a3d683b557eb9fc28cf3484c26e862d3f7e4596cb8235fc9d63851be7.9fccc40d.png)
5. On the **Conditions** step, select the asset the rule applies to. The list shows the assets held in the wallet first, and then your organization's registered assets. To find any other asset in the registry, enter a search.
If the asset you need isn't listed, select **Add asset**. The dialog opens with the wallet's blockchain selected. Enter the **Symbol** and, for a token, the **Contract address**, and optionally a name, decimals, and a CoinGecko ID. Ripple Custody (Wallet) sets the asset's standard from the blockchain, saves the asset to your [registry](/pt-br/products/wallet/vaults-and-wallets/registry/manage-custom-assets), and selects it in the rule. The same dialog is available when you send a transaction and when you configure asset sweeping.
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 under **Apply limit to**. 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. In the console, 1 month is 30 days, so Ripple Custody (Wallet) accepts a custom window of 12 months (360 days).
  - **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 for a Limit rule: XRP selected, a value limit of 1000, and the Rolling limit type](/assets/policy-stepper-limit-conditions.e7e4f6aae93a8e63b6c900b76aeded95876cbec027b18bb76ef67cc8fdd7e3f2.9fccc40d.png)
7. On the **Scope** step, under **To**, select the destinations the rule applies to:
  - **All counterparties and wallets**: Selected by default. This is the broadest option, and it 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.
On **Inbound** Travel Rule rules, the counterparty, address, and wallet scopes match the sender of the deposit instead of the destination, although the console still labels the field **To**. The counterparty, address, wallet, and **All counterparties** scopes don't match transactions that a dApp submits through WalletConnect, even when the destination is in your address book. Limit policies still evaluate them, and they still need transaction approvers. See [Matchers](/pt-br/products/wallet/governance-and-controls/policies/policy-reference#matchers).
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**. If you leave a field empty, the rule doesn't filter on it. A rule with no filters at all is an unscoped rule: it applies only when no scoped rule matches the transaction, and it never applies to cross-chain raw signing. Approval rules skip the **Scope** and **Advanced** steps, because they don't support matchers. Select **Next**.
![The Scope step with the destination options, All counterparties and wallets selected](/assets/policy-stepper-scope.8e8146c67d2b649af5334a12311831cd7fe86eb356c70dd98d65c6c152b6325c.9fccc40d.png)
For cross-chain raw signing to an EVM chain that Ripple Custody (Wallet) doesn't natively support, rules without matchers never apply. A rule with matchers applies when all of its matchers match the transaction, whether or not the rule includes a `CHAIN_ID` matcher. To scope a rule to a target chain, add the chain ID under **Chain IDs** (the `CHAIN_ID` matcher).
8. On the **Advanced** step, leave **All** selected, or restrict the rule to one or more **Users** or **API credentials**. Select **Next**.
Each option in the **Scope** and **Advanced** steps sets a matcher, except the defaults **All counterparties and wallets** and **All** initiators, which set none:
| 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 per-transaction limit rule, with an Edit link for each section](/assets/policy-stepper-limit-confirm.3fb03c9c99e3a7142cb331a54b8b926e37a39a5842753d4f455015988bcd612e.9fccc40d.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**. A policy rule request has a **View** button there instead of inline approval buttons. Select **View**, and then act on the request on the rule's page. 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, Ripple Custody (Wallet) rejects the policy.
![Notifications showing three pending Policy rule approval requests](/assets/policy-rule-approval-requests.e7404b86b6e2737369099a11a14b64d941d18f282b0f2bfa65713488d6e3fdf0.9fccc40d.png)
- **Without approval groups configured:** Ripple Custody (Wallet) approves the policy automatically. The policy shows **Inactive | Approval pending** for a moment, and then **Active | Enabled**. You don't need to take any action.


Active policies take effect immediately
The policy engine starts evaluating transactions against a policy the moment the policy becomes active. Ripple Custody (Wallet) blocks a transaction that exceeds the limits of the policies that apply to it, or that no policy covers. Sweeps, passkey transfers, and some signing actions aren't evaluated against policies. See [Operations that bypass policies](/pt-br/products/wallet/governance-and-controls/policies#operations-that-bypass-policies).

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](/assets/policy-rules-list.2199fd0f166e36eb7b0e211a125cc62798b2bef6bc71498767b7cb2f950e3255.9fccc40d.png)

## Modify a policy via the console

Policies are immutable, so you can't edit an existing policy. To change a policy:

1. Delete the old policy.
2. Wait until the deletion completes. If your organization requires approval, approvers must approve the deletion first.
3. Create a new policy for the same asset with the updated values.


Two policies for the same asset can be active together when they differ in limit type or scope. For example, a per-transaction limit, and a rolling daily limit that applies to one scope:

![The Policy tab with two active Limit rules for XRP: 1 XRP per transaction with no scope, and 200 XRP per day with one scope](/assets/policy-replace-rule.ff1af70397a7afd5a17c55f3a1ff2fd111c38123fec55c8c9c2b7b1d184c98bd.9fccc40d.png)

Plan for a gap
A new policy that differs from the old one only in amount or window counts as a duplicate, so you can't create it until you delete the old policy. Until the new policy takes effect, Ripple Custody (Wallet) rejects transfers of that asset that no other policy covers, with `PAL006.005`. You can create the new policy first only if it differs in limit type or matchers.

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**. The menu appears only if you have permission to delete policies and the policy isn't waiting on a compliance check, creation approval, or deletion approval.
4. In the **Delete policy** dialog, select **Submit**. For a policy with status **Rejected**, the button reads **Delete**, because that deletion doesn't need approval.


![The Delete policy dialog with the Cancel and Submit buttons](/assets/policy-delete-dialog.c309a3bf75b1185aeedb7da2be002cd7ca35f68bd5c2ec9f22c14ff615707c69.9fccc40d.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:** Ripple Custody (Wallet) deletes the policy immediately, and the policy stops enforcing.


Removing the last policy blocks all sends
If you delete the only policy for an asset, the wallet can no longer send transfers of that asset until you create a new policy. Sweeps and passkey transfers aren't affected.

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)


Policies that differ only in amount or window are duplicates, and you can have only one rolling policy for each scope. See [Policy uniqueness](/pt-br/products/wallet/governance-and-controls/policies#policy-uniqueness).

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. This also means a scoped policy can loosen a base limit, even if the base limit is lower, and a wallet-wide cap needs a matching scoped policy as well. The **Confirm** step warns you when a rule overrides matching rules.

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 to prevent 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