Rule Governance and Change Management
How to govern a fraud rule portfolio: inventory fields, materiality tiers, approval paths, documentation, periodic performance review, emergency changes and sunsetting, so rules stay effective and explainable.
Core components
What counts as a "rule"
Govern anything that changes a transaction outcome and isn't already governed as a model:
- Decision rules (decline, hold, step-up, review, limit)
- Thresholds applied to model scores
- Deny-list and allow-list logic (see Negative Lists and Deny Lists)
- Velocity and exposure limits (see Velocity and Exposure Limits)
- Queue routing and prioritization logic
- Hold and funds-availability policies (see Funds Availability Holds)
- Vendor rule configurations
Rule inventory
Start with the inventory. Every production rule gets a record:
| Field | Purpose |
|---|---|
| Rule ID and name | Unique, stable identifier |
| Description (plain language) | What it does, for a non-author |
| Money path and decision point | Where it acts (see Real-Time Decisioning Architecture) |
| Mechanism(s) targeted | Link to taxonomy |
| Action | Decline / hold / step-up / review / limit / flag |
| Owner | Named person, not a team |
| Materiality tier | See below |
| Status | Draft / shadow / live / emergency / retired |
| Created date, author, approver | Audit trail |
| Rationale and evidence | Link to strategy proposal / backtest (see Fraud Strategy Lifecycle) |
| Expected performance | Hit rate, precision, catch, friction at approval |
| Last review date and outcome | Governance hygiene |
| Next review date | Set by tier |
| Expiry date (emergency rules) | Automatic sunset |
| Dependencies | Signals, vendors, lists, other rules |
| Customer-facing reason code and messaging | Explainability, complaints |
| Regulatory relevance | E.g., affects Reg E claims, adverse action, SAR referral |
Materiality tiers (illustrative)
| Tier | Criteria | Approval | Review cadence |
|---|---|---|---|
| Tier 1 | Hard decline or account action on money paths; affects a large share of traffic; regulatory relevance; large dollar exposure | Strategy lead + head of fraud; second-line review where applicable; product consulted on friction | Monthly performance, quarterly deep review |
| Tier 2 | Holds, step-ups, limits; moderate volume | Strategy peer review + strategy lead | Quarterly |
| Tier 3 | Review routing, flags, low-volume rules | Peer review | Semi-annually |
| Emergency | Created under incident authority | Incident commander; logged immediately | Expires in N days unless backfilled and re-approved |
How to build it
Change workflow
Peer review checklist
- Logic matches the stated intent; edge cases considered (nulls, new accounts, currency, time zones)
- Backtest uses matured labels and no look-ahead features
- Incremental value vs existing rules measured
- Good-customer impact estimated by segment (see Friction and Customer Experience Tradeoffs)
- Ops capacity confirmed for review actions (see Alert Review Operations)
- Reason code and customer messaging defined
- Rollback plan and trigger defined
- Dependencies documented (signals, lists, vendors)
- No conflict with other rules (order of evaluation, precedence)
Post-deploy verification
- Hit volume within the expected range
- No unexpected decline-rate shift in unrelated segments
- No errors or latency regressions
- QA spot-check of early hits (see Fraud QA Program)
Periodic performance review
| Measure | Question | Action |
|---|---|---|
| Hit volume vs expectation | Is it firing as designed? | Investigate drift |
| Precision (labels or QA sample) | Are hits still mostly bad? | Retune or retire |
| Incremental catch | Does it catch fraud nothing else catches? | Consolidate if not |
| Friction cost | How many good customers does it affect? | Lighter action, narrower scope |
| Overlap | What share of its hits do other rules also catch? | Consolidate |
| Data health | Are its inputs available and stable? | Fix or add fallback |
| Owner | Is the owner still here and responsible? | Reassign |
Sunsetting
Retire a rule when:
- Incremental catch is below threshold for N reviews
- Precision is below threshold and can't be fixed by tuning
- It's superseded by a model or a broader rule
- The product or flow no longer exists
- It's an emergency rule past expiry without backfill
- It has no owner and nobody will take it
Retire through shadow first: switch the action to log-only for a few weeks and watch the target population before full removal.
Separation of duties
- The author can't be the sole approver for Tier 1–2
- Production rule changes are logged with who, what, when and why. Rules engines should enforce this (see Rules Engine).
- Access to change production rules is restricted and reviewed periodically. Rule access is an Insider Fraud vector: someone who can allow-list an account can launder through it (see Insider Access Controls).
- Emergency changes are reviewed after the fact by someone other than the person who made them
Artifacts and templates
Rule change request (short form)
- Rule ID / new
- Change type: new / modify / retire / emergency
- What and why (2–3 sentences)
- Evidence: backtest link, shadow results
- Expected impact: hits/day, precision, catch $, good customers affected
- Tier and approvers
- Rollout and rollback plan
- Ops and support impact
- Reviewer sign-off
Quarterly rule portfolio review agenda
- Inventory stats: live rules by tier, emergency rules, rules past review date
- Top 10 rules by incremental catch
- Bottom 10 by precision or incremental value: retire or retune?
- Overlap clusters
- Friction leaders: rules affecting the most good customers
- Data dependency issues
- Decisions and owners
Governance health checklist
- Every production rule has an owner, tier, description and review date
- No emergency rules past expiry
- Change log is complete and tamper-evident
- Tier 1 rules reviewed in the last quarter
- Rule edit access reviewed in the last 6 months
- Reason codes mapped for every customer-facing action
- Second-line sampling of rule changes, where applicable (see Three Lines of Defense)
Metrics
| Metric | Target direction |
|---|---|
| Rules without an owner | Zero |
| Rules past review date | Near zero |
| Emergency rules past expiry | Zero |
| Median change lead time (normal path) | Short enough not to be bypassed |
| Rules retired per quarter | Non-zero |
| Share of rules with documented backtest | High |
| Post-deploy rollbacks | Low; investigate causes |
Pitfalls
- Governance so heavy that people bypass it. If a Tier 3 rule change takes two weeks, analysts will ask engineers for "config tweaks" off the books.
- No expiry on emergency rules. This is the main source of sprawl.
- Inventory as a spreadsheet nobody updates. Generate the inventory from the rules engine and add metadata. Don't maintain two sources of truth.
- Measuring rules individually. Overlap hides dead weight.
- Vendor rules out of scope. Vendor-configured rules affect your customers. Govern them the same way.
- No reason codes. When support and complaints teams can't explain a decision, customers escalate, and regulators may ask.
Related
- Fraud Program Overview · Fraud Strategy Lifecycle · Model Risk Management · Experimentation and Champion-Challenger
- Rules Engine · Real-Time Transaction Risk Scoring · Machine Learning Models
- Fraud QA Program · Fraud Incident Response · Three Lines of Defense · Fraud Metrics and KPIs
Sources and further reading
- Federal Reserve SR 26-2, Revised Guidance on Model Risk Management (April 17, 2026): supersedes SR 11-7 and SR 21-8; risk-based tailoring
- Revised Guidance on Model Risk Management, attachment (SR 26-2): model definition excluding deterministic rule-based processes and simple arithmetic
- OCC Bulletin 2026-13, Model Risk Management: Revised Guidance: the OCC issuance and the rescinded OCC guidance
- Lumenova, SR 26-2 model risk management in banking (April 2026): commentary that excluded rule-based tools still need operational controls; calibrated-threshold rules as a gray area
- Abrigo, What SR 26-2 means for financial institutions: rules outside the model definition still need controls when they drive important decisions