Rule Management

​

Rule Structure

​

Toggle Active/Inactive

• All rules are enabled by default when you create an audit
• Click the toggle switch next to any rule to disable it
• Disabled rules (grayed out) are skipped during scan execution
• You must have at least 1 active rule to run a scan

• Disable noisy rules that produce too many false positives
• Focus on specific regulatory requirements (e.g., only GDPR encryption rules)
• Test new custom rules in isolation

​

Add Rules from PDF

POST /api/policies/ingest

​

Add Rules from Prebuilt Packs

​

AML / FinCEN (11 rules)

• CTR Aggregation — Currency Transaction Reports for amounts ≥ $10,000
• Structuring Detection — Multiple sub-threshold transactions within time windows
• Velocity Limits — Transaction frequency thresholds
• Dormant Reactivation — Inactive accounts suddenly active
• Round Amount Patterns — Suspicious even-dollar transactions
• Balance Mismatches — oldBalance + amount ≠ newBalance
• High-Risk Rapid Movement — Funds moving quickly through accounts

​

GDPR (14+ categories)

• Consent Management — Explicit consent required for processing
• Data Protection Officer — DPO required for certain processing activities
• Encryption at Rest — Personal data must be encrypted
• Marketing Consent — Separate opt-in for marketing communications
• Privacy Impact Assessments — Required for high-risk processing
• Right of Access — Provide data within 30 days of request
• Right of Erasure — Delete data upon request
• Third-Country Transfers — Adequate safeguards required

​

SOC2 (5 trust principles)

• Security — Logical access controls, MFA, encryption
• Availability — System uptime and disaster recovery
• Confidentiality — Data classification and access restrictions
• Processing Integrity — Data accuracy and completeness
• Privacy — Notice, choice, collection limitation

POST /api/policies/prebuilt
{
  "policy_type": "aml" | "gdpr" | "soc2"
}

​

Understanding Rule Quality Scores

confidence = rule_quality              // Structural quality of the rule
           + signal_specificity_boost  // Bonus for compound AND conditions
           + statistical_anomaly       // How unusual the value is vs. dataset
           + bayesian_precision        // (1 + TP) / (2 + TP + FP)
           + criticality_weight        // CRITICAL > HIGH > MEDIUM

​

Rule Quality Components

• Measures structural quality of the rule definition
• Factors: condition complexity, specificity, threshold sensitivity
• Higher quality = more specific, less prone to noise

• Rules with compound AND conditions get a boost
• Single-threshold rules (e.g., “amount > 10000”) get no boost
• Multi-signal rules (e.g., “amount > 10000 AND type = WIRE AND recipient_country = offshore”) get higher scores

• How unusual is this value compared to the dataset distribution?
• Example: A $1M transaction in a dataset where 99$1K gets a high anomaly score

• Uses historical feedback from your reviews
• Formula: precision = (1 + approved_count) / (2 + approved_count + false_positive_count)
• Rules with many false positives lose confidence over time
• Rules with consistent true positives gain confidence

• CRITICAL violations get the highest weight
• HIGH violations get 0.75x weight
• MEDIUM violations get 0.5x weight

​

Rule Execution Types

​

Single-Transaction Rules

• Type: single_transaction
• Execution: Evaluate conditions per record
• Use Cases: Threshold checks, field validations, cross-field comparisons
• Example: “Transactions over $10K require additional documentation”

​

Windowed Rules

• Types: aggregation, velocity, structuring, dormant_reactivation, round_amount
• Execution: Group records by account, evaluate within time windows
• Use Cases: Velocity limits, structuring detection, dormant account alerts
• Example: “More than 5 transactions in 24 hours triggers a review”

1. Group records by account field
2. For each account, create time windows (e.g., 24-hour rolling windows)
3. Aggregate within each window (sum, count, average)
4. Check if aggregated value exceeds threshold

​

Best Practices

1. Start Broad, Then Narrow
   • Enable all rules for your first scan
   • Disable noisy rules after reviewing results
   • Focus on high-severity, high-confidence violations
2. Review Regularly
   • Approve true positives to boost rule precision
   • Dismiss false positives to reduce noise
   • Your feedback trains the Bayesian model
3. Combine Prebuilt + Custom
   • Start with prebuilt frameworks (AML, GDPR, SOC2)
   • Add custom rules from your internal policies
   • Test new rules on historical data before production
4. Monitor Rule Performance
   • Track precision/recall metrics in the evidence drawer
   • Disable rules with <50% precision
   • Investigate rules with high false positive rates

​

What’s Next?

• Interpreting Violations — Understand severity levels, confidence scores, and evidence grids
• Audit Workflow — Complete end-to-end audit process