# Policy concepts

Transaction policies are the security rules that control what funds can leave your wallets. Every wallet in Wallet-as-a-Service (Palisade) is **deposit-only by default**. You must create at least one policy for an asset before you can send that asset from the wallet.

Think of policies as programmable spending limits. They automatically evaluate every outgoing transaction and block any that would exceed your configured limits. This protects your assets even if someone gains unauthorized access to your API credentials or user accounts.

**Policies answer these questions:**

- How much can leave in a single transaction?
- How much can leave over a period of time?
- What is the maximum that can ever leave?
- Who can initiate transactions, and to where?


This page explains the core concepts you need to understand before creating and managing policies.

## Policy scope

Policies operate at the **wallet level only**. Each policy applies to a single wallet and controls transactions for a specific asset within that wallet.

No vault-level or organization-level policies
You cannot create a policy that applies to multiple wallets simultaneously. If you need the same limit across ten wallets, you must create ten separate policies—one for each wallet.

Multi-chain EVM wallets
If your organization uses separate wallets for different EVM chains (for example, one Ethereum wallet and one Arbitrum wallet), policies on one wallet do **not** apply to the other—even if both wallets hold the same asset (ETH). You must create policies independently on each wallet.

## Limit types

Wallet-as-a-Service (Palisade) supports three limit types:

- **Per transaction (`PER_TX`)** – Maximum amount for any single transaction
- **Rolling duration (`ROLLING_DURATION`)** – Maximum cumulative amount within a sliding time window
- **Max total value (`CONSTANT`)** – Lifetime cap on total withdrawals


You can combine multiple limit types on the same wallet for layered protection.

How rolling windows work
When you attempt a transaction, the system calculates how much has already left the wallet within the current window. If your new transaction would push the total over the limit, the system rejects it immediately. As older transactions "roll off" the window, capacity becomes available again.

See [Policy reference](/products/wallet/user-interface/policies/policies-reference#limit-types) for complete limit type documentation, duration values, and examples.

## Policy uniqueness

Each policy must be unique within its wallet. The system identifies a policy by four attributes:

| Attribute | Description |
|  --- | --- |
| Wallet ID | The wallet the policy belongs to |
| Limit type | `PER_TX`, `ROLLING_DURATION`, or `CONSTANT` |
| Symbol | The asset symbol (for example, `ETH`, `BTC`, `USDC`) |
| Matchers | Optional filters that narrow when the policy applies |


You can create multiple policies with the same limit type and symbol **if they have different matchers**. For example:

- `PER_TX` + `ETH` + no matchers → Applies to all ETH transactions
- `PER_TX` + `ETH` + `TRANSACTION_TYPE: WITHDRAWAL` → Applies only to ETH withdrawals


Both policies can coexist because their matcher configurations differ.

Duplicate policy error
If you try to create a policy that matches an existing policy's wallet, limit type, symbol, and matchers, the API returns error `PAL006.023: limit policy already exists`.

## Policy immutability

Policies are immutable. You cannot edit an existing policy's limit amount, duration, or matchers.

**To modify a policy:**

1. Delete the existing policy (see [Manage policies](/products/wallet/user-interface/policies/policies-manage#delete-a-policy)).
2. Create a new policy with the updated values.


Why policies are immutable
Immutability provides a clear audit trail. Every policy change creates a new record with its own approval history, making it easy to track who authorized what and when.

## Policy lifecycle

Every policy moves through a series of states from creation to deletion.


```mermaid
stateDiagram-v2
    direction TB

    [*] --> LIMIT_CREATION_APPROVAL_PENDING: Create policy

    LIMIT_CREATION_APPROVAL_PENDING --> LIMIT_ENABLED: Approved
    LIMIT_CREATION_APPROVAL_PENDING --> LIMIT_REJECTED: Rejected

    LIMIT_ENABLED --> LIMIT_DELETION_APPROVAL_PENDING: Request deletion

    LIMIT_DELETION_APPROVAL_PENDING --> LIMIT_DELETED: Approved

    LIMIT_REJECTED --> [*]
    LIMIT_DELETED --> [*]

    note right of LIMIT_ENABLED: active: true
    note right of LIMIT_DELETION_APPROVAL_PENDING: Still enforcing
    note right of LIMIT_REJECTED: Terminal state
    note right of LIMIT_DELETED: Terminal state
```

Policies move through five statuses: pending approval, enabled, rejected, pending deletion, and deleted. A policy in `LIMIT_DELETION_APPROVAL_PENDING` status continues to enforce transactions until the deletion is approved—this prevents gaps in protection.

See [Policy reference](/products/wallet/user-interface/policies/policies-reference#policy-statuses) for the complete status reference.

## Approval requirements

Whether a policy requires approval depends on your organization's approval group configuration.

### With approval groups configured

If your organization has an approval group for **Policy rules**, new policies enter `LIMIT_CREATION_APPROVAL_PENDING` status. Designated approvers must authorize the policy before it takes effect.

The policy activates after the required number of approvers authorize it (for example, 2 of 3 approvers). If the approval threshold becomes mathematically impossible to reach (for example, too many approvers skip), the policy moves to `LIMIT_REJECTED`.

### Without approval groups configured

If no approval group exists for Policy rules, the policy **automatically activates** immediately after creation. It transitions directly to `LIMIT_ENABLED` with `active: true`.

Security consideration
Without approval groups, anyone with API credentials that include `keylimit:create` scope can instantly enable policies. Consider configuring approval groups to add human oversight.

See [Approvals](/products/wallet/user-interface/security-controls/approvals) to configure approval groups for your organization.

## Policy evaluation

When you submit a transaction, the policy engine evaluates it against all active policies for that wallet and asset. Policy checks are one stage in the full transaction pipeline.

### Where policies fit in the transaction pipeline

Policy evaluation is the first check after a transaction is created. The full pipeline is:


```mermaid
flowchart TD
    TX[Transaction created] --> PC[Policy check]
    PC -->|Pass| AP{Approvals required?}
    PC -->|Fail| REJ[Transaction rejected]
    AP -->|Yes| AG[Approval group review]
    AP -->|No| SIG[MPC signing]
    AG -->|Approved| SIG
    AG -->|Rejected| REJ
    SIG --> BC[Blockchain submission]
    BC --> CONF[Confirmed]

    style REJ fill:#ffcccc
    style CONF fill:#ccffcc
```

1. **Policy check** – The engine evaluates the transaction against all matching policies. If any policy rejects, the transaction is rejected immediately and never reaches approvers.
2. **Approval check** – If approval groups are configured for transactions, designated approvers must authorize the transaction.
3. **MPC signing** – The transaction is signed by the wallet's MPC quorum.
4. **Blockchain submission** – The signed transaction is published to the network.


See [Signing & approvals overview](/products/wallet/user-interface/security-controls/security-controls-overview) for details on approvals and MPC quorums.

### Evaluation order


```mermaid
flowchart TD
    A[Transaction submitted] --> B{Find matching policies}
    B --> C[Policy 1: Check limit]
    B --> D[Policy 2: Check limit]
    B --> E[Policy N: Check limit]

    C --> F{All policies pass?}
    D --> F
    E --> F

    F -->|Yes| G[Proceed to approvals/signing]
    F -->|No| H[Transaction rejected]

    style H fill:#ffcccc
    style G fill:#ccffcc
```

1. The engine finds all `LIMIT_ENABLED` policies that match the transaction's wallet, asset, and attributes.
2. For each matching policy, the engine checks whether the transaction would exceed the limit.
3. If **any** policy rejects the transaction, the entire transaction fails.
4. If **all** matching policies pass, the transaction proceeds to the next stage (approvals or signing).


### Network fees and policy limits

Policy limits are checked against the **transaction amount only**. Network fees (gas on EVM chains, transaction fees on XRP Ledger) are **not** included in the limit calculation. For example, if you have a PER_TX limit of 10 ETH and send exactly 10 ETH, the policy check passes — the gas cost does not push the transaction over the limit.

### Operations that bypass policies

Not all outgoing fund movements are subject to policy checks. **Asset sweeping bypasses policies entirely.** A wallet does not need any policies in place to be swept, and sweep transactions are not evaluated against existing policies.

This means policies alone do not prevent all fund movement from a wallet. If you need to restrict sweeping, manage sweep configurations separately through **Settings > Workflows**. Only owners and administrators can configure sweeping operations.

See [Asset sweeping](/products/wallet/user-interface/wallets/asset-sweeping) for details on sweep configuration.

Transaction freeze is separate from policies
[Transaction freeze controls](/products/wallet/user-interface/transactions/manage-transactions#freeze-and-unfreeze-transactions) apply to **inbound** transactions only (holding incoming funds for compliance review). Policies apply to **outbound** transactions only. These two controls operate on different transaction directions and do not interact with each other.

### Matcher evaluation

Matchers filter which transactions a policy applies to. A transaction must match **all** matchers on a policy for that policy to apply. If a policy has no matchers, it applies to **all** transactions for that asset.

Matcher types include: `TRANSACTION_TYPE`, `USER`, `API_CREDENTIAL`, `ADDRESS_ID`, `COUNTERPARTY_ID`, `WALLET_ID`, and `SIGN_FOR`.

See [Policy reference](/products/wallet/user-interface/policies/policies-reference#matchers) for detailed matcher documentation and examples.

## Monitoring policy checks with webhooks

If you have webhooks configured for the **TRANSACTION** domain, you receive notifications as transactions move through the policy check stage. The relevant statuses are:

| Status | Description |
|  --- | --- |
| `POLICY_CHECK_PENDING` | Transaction is being evaluated against policies |
| `POLICY_CHECK_PASSED` | Transaction passed all policy checks |
| `REJECTED` | Transaction was rejected (by policy or approval) |


These webhooks allow you to build automated monitoring for policy enforcement — for example, alerting on rejected transactions or tracking policy check latency.

No policy lifecycle webhooks
Webhook notifications cover **transaction** status changes only. There are no webhook events for policy creation, approval, or deletion. To track policy lifecycle changes, use the [Approval domain](/products/wallet/user-interface/integrations/overview#approval-domain) webhooks, which notify when approval requests for policy rules are created or resolved.

See [Webhooks overview](/products/wallet/user-interface/integrations/overview) for setup instructions and payload format.

## What to read next

- [Policy reference](/products/wallet/user-interface/policies/policies-reference) – Complete reference for all limit types, matchers, and configuration options
- [Manage policies](/products/wallet/user-interface/policies/policies-manage) – Step-by-step guide to create, modify, and delete policies
- [Policy best practices](/products/wallet/user-interface/policies/policies-best-practices) – Recommended patterns and common configurations