Deleting rules

You can delete rules that are no longer necessary or that aren’t being used. When you delete a rule, operations that would have matched that rule now match the next most-specific rule.

​

When to delete rules

Consider deleting rules when:

• Never used — A rule hasn’t matched any operations in months
• Obsolete — Business practice has changed and the rule no longer applies
• Redundant — Another rule covers the same scenario
• Too complex — A rule is causing confusion without clear benefit
• Org restructure — After staffing changes, a rule may no longer make sense

​

Before deleting a rule

Before deleting, verify:

1. Check recent operations — Did this rule apply to any recent transactions?
2. Confirm redundancy — Is another rule covering the same scenarios?
3. Impact analysis — What operations will be affected by deleting this rule?
4. Approval path — Will deleting this rule speed up or slow down approvals?
5. Compliance — Does your compliance requirement depend on this rule?

​

Delete a rule

​

What happens when you delete a rule

Before deletion:

• Withdrawal $150,000 to new address
• Rule “Large withdrawals to new addresses” = 2 approvers
• Result: 2 approvers required

After deleting that rule:

• Same withdrawal $150,000 to new address
• No longer matches the specific rule
• Now matches rule “Large withdrawals (any address)” = 1 approver
• Result: 1 approver required (faster approval)

Operations move to the next-most-specific matching rule. Every operation must match some rule — if you delete the last rule, a default rule must exist.

​

Safe deletion practices

​

Method 1: Replace, don’t delete

Instead of deleting a rule, edit it to be less strict:

• Before: “Withdrawals > $100k to new addresses” = 2 approvers (never used)
• After: Delete this rule
• Better: Edit rule to “Withdrawals > $500k to new addresses” = 2 approvers (might capture some operations)

​

Method 2: Stage the deletion

For important rules, delete in stages:

1. Week 1: Remove rule but keep it in draft state (visible but inactive)
2. Week 2: Monitor operations — do they route to other rules correctly?
3. Week 3: If no issues, permanently delete the rule
4. Week 4: Document the deletion

​

Method 3: Create fallback rule first

Before deleting a specific rule, ensure a more general rule exists:

• To delete: “Withdrawals to untrusted counterparties” = 2 approvers
• Fallback needed: “All withdrawals” = 1 approver (catches what specific rule would have)
• Then: Delete the specific rule

​

Common deletions

​

Delete duplicate rules

You might have created rules that overlap: Duplicate rules:

• Rule A: “Withdrawals > $100k” = 2 approvers
• Rule B: “Large withdrawals” = 2 approvers (same threshold, same requirement)

Action: Delete one of them (keep the more specific one if conditions differ).

​

Delete overly specific rules

Rules with very narrow conditions might never match: Example overly specific rule:

• “Withdrawal of exactly $73,452.50 on Tuesdays between 2 PM and 2:15 PM”
• (Probably never matches; delete it)

​

Delete obsolete organization rules

After team restructuring, old rules might reference people who no longer work there: Obsolete rule:

• “Requires approval from Bob and Alice”
• (Bob and Alice left; no one can approve; delete it)

​

Fallback rule necessity

Every policy must have a default/fallback rule with no conditions. Before deleting any rule:

1. Check if this is the default rule — If yes, don’t delete it unless replacing it
2. Verify another rule will match — Ensure operations won’t fall through the cracks
3. Test mentally — Think through what rule would match if this one is deleted

​

Testing before deletion

If possible, test the impact:

1. Review recent operations — See which rule each matched
2. Simulate deletion — Mentally trace operations through remaining rules
3. Check no gaps — Ensure every possible operation matches some rule
4. Audit trail — Review the history of what operations matched this rule

​

Approval for rule deletion

Deleting rules requires the same approval process as policy changes:

• Submitter: The person proposing rule deletion
• Approvers: Usually the same policy that governs vault operations
• Timing: Deletion takes effect only after approval
• Audit trail: Deletion is recorded showing who approved it and when

​

Recovering deleted rules

If you accidentally delete a rule:

1. Check version history — Some systems keep policy versions; you can roll back
2. Recreate the rule — If no backup, manually recreate it with the same conditions
3. Request recovery — Contact your administrator or Porto support for help

Keep documented copies of important rules in case you need to recreate them.

​

Communication around deletions

When deleting an important rule, notify users:

1. What’s being deleted — Name and purpose of the rule
2. Why — Business reason for the deletion
3. Effective date — When the deletion takes effect
4. Impact — How will this affect approvals? Faster or slower?
5. Examples — Show examples of operations affected

Example notification:

• “We’re deleting the ‘Small deposit’ rule (1 approver for deposits under $5k) because we’ll require 1 approver for all deposits going forward.”
• “Effective: Jan 15”
• “Impact: Small deposits will now match the default rule (1 approver), so no change.”

​

Audit trail of deletions

All rule deletions are recorded:

• Who deleted it — The user who made the deletion
• When — Exact time and date
• Which rule — All conditions and requirements of the deleted rule
• Approval — Who approved the deletion
• Reason — If provided, why the rule was deleted

This trail allows auditors to understand policy evolution.

​

Rule deletion checklist

Before deleting a rule, verify:

• This rule hasn’t been used recently
• Another rule covers similar scenarios
• No compliance requirement depends on this rule
• Users have been notified of the planned deletion
• A fallback rule exists to catch affected operations
• The deletion has been approved
• Audit trail shows the deletion