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.

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. To manage rules with the API, see Manage policy rules 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. The API procedures need an API credential of type CONTROLS. See Prerequisites.

Complete these prerequisites before you create policies:

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.

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.

   

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.

   

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.

   Non-standard assets

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

   • Travel rule: See Create a Travel Rule policy rule via the console.

   Select Next.

   

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.

   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.

   

   Cross-chain raw signing

   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.

   

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.

  

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

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 for the complete status reference.

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:

See Policy concepts for why policies are immutable.

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.

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.

To create, list, get, and delete policy rules programmatically, see Manage policy rules via the API.

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.

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

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.
• Escalate large transactions. Use 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 policy rules to exchange originator and beneficiary information through Notabene.

For more patterns, see Policy best practices.

• Policies - Understand scope, lifecycle, and evaluation
• Policy reference - Complete reference for limit types, matchers, statuses, permissions, and error codes
• Manage policy rules via the API - Create, list, get, and delete policy rules with the API
• Policy best practices - Recommended patterns and troubleshooting
• Unlock outgoing transactions - Full walkthrough including policy setup