> ## Documentation Index
> Fetch the complete documentation index at: https://docs.anchorage.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Managing rules and policies

> Overview of maintaining and monitoring your approval rules and policy structures.

Managing rules and policies is an ongoing process. This guide covers best practices for keeping your policies effective, monitoring their impact, and updating them as your organization evolves.

## Understanding your current rules

Before managing rules, understand what you have:

<Steps>
  <Step title="Open vault policies">
    Go to **Settings** > **Policies** > **Vault policy**.

    <Frame caption="Vault policy interface">
      <img src="https://mintcdn.com/deployment-4/lSVGGJ7Z6F9zIy7U/knowledge-base/images/screenshots/porto-policies-nav.png?fit=max&auto=format&n=lSVGGJ7Z6F9zIy7U&q=85&s=a0b5408e2d79db2fcc018fd7d4ef7a18" alt="Settings screen with Policies section highlighted" style={{ maxWidth: "280px", height: "auto" }} width="828" height="1792" data-path="knowledge-base/images/screenshots/porto-policies-nav.png" />
    </Frame>
  </Step>

  <Step title="Review all rules">
    You'll see a list of all active rules in priority order (most specific first).
  </Step>

  <Step title="Understand each rule">
    For each rule, note:

    * What conditions trigger it (operation type, amount, address, time, role)
    * Who must approve
    * How many approvers are required
    * Approval timeout
  </Step>

  <Step title="Map to operations">
    Mentally trace where recent operations would match in this rule list.
  </Step>

  <Step title="Identify gaps">
    Are there operations that don't match any rule? (They shouldn't be — default rule must exist)
  </Step>
</Steps>

## Regular rule reviews

Conduct quarterly reviews of your rules:

**Review checklist:**

* [ ] Are any rules never matching? (Consider deleting)
* [ ] Are any rules too broad? (Consider making more specific)
* [ ] Are any rules conflicting? (Overlapping conditions with different requirements)
* [ ] Do team members still understand the rules?
* [ ] Have business conditions changed? (Volume, asset types, counterparties)
* [ ] Are approval times acceptable? (Fast enough but still safe)
* [ ] Do team members know the approval process?

## Monitoring rule effectiveness

### Track approval metrics

Monitor how rules are performing:

* **Approval speed** — How long do approvals typically take?
  * Target: Most approvals \< 2 hours
  * Too slow: Consider reducing approver count or clarifying process

* **Rejection rate** — How often are operations rejected?
  * Target: \< 5%
  * Too high: Consider rules too strict or rejections are due to user errors

* **Escalation rate** — How often do operations require higher-level approval?
  * Target: \< 10-15%
  * Too high: Maybe your tiered thresholds are too conservative

* **Rule hit rate** — Which rules are matching operations?
  * All rules should match something eventually
  * Rarely-matching rules may be redundant

### Generate reports

Most systems allow you to view:

1. **Rule usage report** — Which rules matched how many operations last month?
2. **Approval timeline report** — How long did each operation take to approve?
3. **Rejection report** — What operations were rejected and why?
4. **Audit trail** — Who made changes to rules and when?

Review these monthly or quarterly.

## Identifying problem rules

**Signs of problematic rules:**

| Issue         | Sign                            | Solution                                      |
| :------------ | :------------------------------ | :-------------------------------------------- |
| Too strict    | Approvals taking days           | Reduce approver count or adjust thresholds    |
| Too lenient   | Rejection/incidents             | Increase approver count or tighten conditions |
| Never matches | Rule never applies              | Delete or adjust conditions                   |
| Too specific  | Only applies once/month         | Broaden conditions or merge with similar rule |
| Conflicting   | Operations match multiple rules | Clarify priority or adjust conditions         |
| Unclear       | Users confused about approvals  | Simplify and communicate better               |

## Rule maintenance schedule

Establish a regular maintenance cadence:

| Period        | Activity                                                       |
| :------------ | :------------------------------------------------------------- |
| **Weekly**    | Monitor approval times; catch urgent issues                    |
| **Monthly**   | Review rejection rates and escalations                         |
| **Quarterly** | Full rule review and audit; make updates as needed             |
| **Yearly**    | Comprehensive policy redesign review; document lessons learned |

## Updating rules

When updating rules, follow this process:

1. **Identify the issue** — What's not working about the current rule?
2. **Design the change** — How will you modify the rule?
3. **Announce the change** — Notify stakeholders
4. **Implement** — Make the change and submit for approval
5. **Monitor impact** — Track the new rule's effectiveness
6. **Document** — Record what changed and why

See [Editing rules](/knowledge-base/porto/policies/editing-rules) for detailed editing instructions.

## Policy simplification

Over time, policies can become complex. Simplify when possible:

**Signs of over-complexity:**

* More than 7-8 rules per policy
* Rules with 3+ conditions
* 5+ subquorums with nested logic
* Users confused about how to get approvals

**Simplification strategies:**

1. **Merge similar rules** — Combine rules with nearly identical requirements
2. **Remove duplicates** — If two rules do the same thing, delete one
3. **Consolidate subquorums** — Combine multiple specialized groups into broader categories
4. **Use default rule** — Remove overly specific rules; let broader rule apply
5. **Eliminate time-based rules** — These rarely add value and confuse users

**Example simplification:**

* **Before:** 10 rules covering different asset types, amounts, and times
* **After:** 3 rules: small transactions (1 approver), medium ($X-Y, 2 approvers), large (>$Y, 3 approvers)

## Approval process communication

Ensure users understand the process:

1. **Document the policy** — Create a simple guide showing rules and approval requirements
2. **Training** — New users should understand their approval responsibilities
3. **Visual flowchart** — Create a diagram showing decision tree for approvals
4. **FAQ** — Answer common questions about why certain operations require certain approvals
5. **Examples** — Show concrete examples of different operation types

**Example documentation:**

```
VAULT: Treasury

Simple operations (to trusted destinations): 1 approver needed
- Approver: Any of \{Treasurer, Assistant Treasurer\}
- Expected approval time: < 1 hour

Regular operations (to pre-approved addresses): 2 approvers needed
- Approvers: 2 of \{Treasurer, Assistant Treasurer, CFO\}
- Expected approval time: 2-4 hours

Large operations (> $500k or to new addresses): 3 approvers needed
- Approvers: All of \{Treasurer, CFO, CEO\}
- Expected approval time: 4-8 hours
```

## Handling policy exceptions

Sometimes operations need expedited or special approval:

1. **Escalation procedure** — How can someone request expedited approval?
2. **Emergency override** — What's the process if normal approvers aren't available?
3. **Temporary exceptions** — Can you temporarily change a rule for unusual situations?
4. **Appeal process** — What if someone disputes an approval decision?

Document these procedures so users know options.

## Policy evolution tracking

As rules change over time, maintain a changelog:

| Date     | Rule                 | Change                                   | Reason                       | Approved by |
| :------- | :------------------- | :--------------------------------------- | :--------------------------- | :---------- |
| Jan 2026 | Large transactions   | Threshold raised $200k → $500k           | Increased transaction volume | CFO         |
| Dec 2025 | All operations       | Added time-window exception for weekends | Speed end-of-week operations | CEO         |
| Nov 2025 | Trusted destinations | Reduced from 2 to 1 approver             | Streamline common operations | Board       |

This history helps with compliance, auditing, and understanding why rules are structured as they are.

## Common policy scenarios

### Growing organization

As you grow, your approval structure should evolve:

1. **Stage 1 (startup):** 1-2 approvers for everything
2. **Stage 2 (20+ people):** Different approval tiers (small/medium/large)
3. **Stage 3 (100+ people):** Role-based approvals, department-specific rules
4. **Stage 4 (500+ people):** Complex subquorum structures with specialized functions

Each stage requires policy updates.

### High-compliance industry

If you're in a regulated industry (banking, healthcare, financial services):

* **Annual compliance audit** — Rules must be reviewed against compliance requirements
* **Regulatory alignment** — Ensure rules support compliance needs
* **Documentation** — Keep detailed records of policy changes and approvals
* **Training** — Users must understand policy and compliance implications

### Multi-geography organization

If you operate in multiple countries/regions:

* **Regional policies** — Different rules for different jurisdictions
* **Central oversight** — Corporate-level policies for cross-border operations
* **Local expertise** — Regional managers set policies for their area
* **Compliance** — Policies must meet all applicable regulations

### Multiple currencies or asset types

If you work with diverse assets:

* **Asset-specific rules** — Different approval requirements by asset type
* **Amount rules** — USD value thresholds vs. crypto amount thresholds
* **Custody** — Rules for custody assets vs. trading assets
* **Bridges and derivatives** — Special rules for higher-risk operations

## Getting stakeholder buy-in

When proposing policy changes:

1. **Document the rationale** — Why is the change needed?
2. **Show impact** — How will approvals change? Speed? Security?
3. **Get feedback** — Ask stakeholders (users, approvers, compliance, legal)
4. **Pilot if possible** — Test the change with a subset first
5. **Implement gradually** — Phase in major changes rather than big bang
6. **Monitor closely** — Watch the impact; adjust if needed

## Policy documentation template

Create a standard format for documenting policies:

```
POLICY NAME: [Name]
VAULT/ORGANIZATION: [Where it applies]
EFFECTIVE DATE: [When it starts]
LAST REVIEWED: [Date]
OWNER: [Person responsible]

PURPOSE:
[Why this policy exists; what risk it addresses]

RULES:
[List each rule with conditions and approval requirements]

SUBQUORUMS:
[If applicable, define each group and its quorum]

EXAMPLES:
[Show 2-3 example operations and their approval flows]

ESCALATION:
[How to handle exceptions or emergencies]

CHANGES FROM PREVIOUS VERSION:
[What was different; why it changed]
```

## Tools and automation

Some organizations use tools to help manage policies:

* **Policy management software** — Visualize rules, test impact
* **Approval workflow tools** — Automate routing and notifications
* **Audit logging** — Automatically track all rule changes
* **Analytics dashboards** — Monitor approval metrics
* **Template libraries** — Pre-built policies for common scenarios

Ask your administrator what tools are available.

## Best practices summary

* **Regular reviews** — Quarterly policy audits catch problems early
* **Clear documentation** — Users should understand why rules exist
* **Simplify over time** — Reduce complexity as you learn what works
* **Monitor metrics** — Track approval speed, rejection rates, escalations
* **Communicate changes** — Users should know about policy updates
* **Keep history** — Document why rules changed; helps with future decisions
* **One change at a time** — Don't modify multiple rules simultaneously
* **Involve stakeholders** — Get buy-in from approvers, compliance, users
* **Test before finalizing** — Simulate how new rules will affect operations
* **Maintain fallback** — Always have a default rule; never leave operations without an approval path