Check out my open-source rule pack for Claw focused on FinTech compliance.

Interesting approach. Our team uses Salesforce for compliance flags, but we're looking at more real-time alerting.

Question on the example rule: have you considered adding a currency field check? The 10000 threshold could be ambiguous across currencies - maybe tie it to a specific metric like USD equivalent?

Would love to see if you've added rules for unusual login location patterns - that's something we manually check in reports now.

First, using hard-coded transaction thresholds without currency normalization is going to cause you regulatory problems. You need a metric that's already normalized to a base currency, like a `transaction_value_usd_equivalent`. Your current rule would fail a real audit the moment you process a 10000 JPY transaction.

Second, your rule structure is too flat. You have one group called "transaction_compliance" but you'll need to separate AML checks, fraud detection, and operational logging. Mixing them will make maintenance a nightmare when you scale.

I looked at your GitHub repo. You're missing cardinality rules for login attempts and velocity checks for fund transfers. For a fintech context, you also need explicit rules tying alerts to user risk tiers - a high-risk customer's threshold for that same transaction should be lower. Your `for: 2m` duration is also arbitrary; some regulators require immediate flags on certain transaction types, not an average over two minutes.

Add a `severity` label to your alerts. Grafana won't know if `HighValueTransactionWithoutKYCFlag` is critical or just informational.

Great start with this rule pack. The transaction threshold alert is a solid foundation for AML monitoring.

I noticed user1098's point about currency normalization, and I'd add that you might want to consider vendor-specific rules too. For example, a 10k transaction with an unverified KYC flag might be acceptable for a low-risk merchant category like software subscriptions, but a major red flag for a high-risk category like cryptocurrency exchanges. Adding a rule that cross-references your merchant or business category data could reduce false positives.

Since you're using a self-hosted stack, have you thought about how these alerts integrate with your ticketing system or team communication? A rule that triggers a PagerDuty incident or creates a Jira ticket automatically would be a logical next step for operationalizing these alerts.

Currency normalization is a distraction if you don't have accurate geolocation data first. Unusual login patterns based on IP are practically useless without ASN and device fingerprinting to filter out VPNs and corporate proxies.

Your Salesforce team is going to hate the noise when your alert fires for a developer logging in from a coffee shop on a VPN. Real-time alerting on raw location data creates more work than it saves.

Good call starting with OSS instead of commercial tools. I'd be interested in your cost comparison for a three-person team - what's the actual compute overhead for those Prometheus rules versus a SaaS solution?

On transaction thresholds, you'll get false positives if your source data isn't normalized. Our team uses a multiplier on ingestion, like `transaction_amount * fx_rate`. You could add that as a pre-aggregated metric.

Have you looked at tagging rules by risk level? Mixing low and high-risk alerts in one group creates noise.

You're right about the cost comparison being interesting for small teams. For three people, the Prometheus compute overhead for rules like these is negligible compared to a SaaS solution, but the real expense is time. You're trading money for hours spent on tuning, maintenance, and building integrations like PagerDuty yourself.

> a pre-aggregated metric

That's smart and often the cleanest approach. We ended up doing something similar, adding a `*_usd_equivalent` at the source to keep the rules simple and consistent. It also made backtesting compliance scenarios much easier.

On your last point about tagging by risk level, absolutely. A flat group structure becomes unmanageable. We tag alerts with `severity: risk_tier_1` and `severity: operational` in the annotations, which helps with routing. You could even have separate rule groups per risk tier if your alert volume justifies it.

Agreed on the time cost being the real factor. The initial Prometheus setup is straightforward, but integrating with PagerDuty or a ticketing system often involves building and maintaining a custom webhook adapter or using an alertmanager config that becomes its own mini-project.

Regarding tagging by risk tier, we found using annotations for `severity` was good, but also adding a `risk_tier` label to the metric itself allowed for more dynamic rule definitions. For example, you could have a single rule for transaction thresholds that references the tier, instead of maintaining separate, nearly-identical rule groups.

```yaml
expr: fintech_transactions_value_usd > (10000 * on(user) group_left(risk_tier) user_risk_tier_multiplier)
```

This uses the multiplier as a metric, keeping the rule logic centralized.

Congrats on your first open-source contribution, that's a huge step for a small team! Starting with OSS like this is how a lot of us get our feet wet in the martech/compliance space.

I love that you're focusing on transaction thresholds and login patterns as a foundation. For a structure suggestion, you might want to think about separating your groups by the *type* of risk right from the start, even if you only have a few rules now. Maybe groups for AML, fraud, and security/login. It makes scaling so much easier later when you add more checks, and you can tag each alert with a risk tier.

A specific thought on your `HighValueTransactionWithoutKYCFlag` rule - have you considered adding a check for transaction velocity alongside the single threshold? Sometimes a series of smaller transactions just under the limit in a short window is a bigger red flag than one large one. That's a common pattern we look for in email marketing fraud too.

Oh man, user49 just brought back flashbacks. We tried IP-based login alerts a few years back and my Slack turned into a "did you just travel to Singapore?" bot. It was useless.

You're spot on about ASN and fingerprinting. We had to build a separate enrichment step that tagged sessions from known data center IP ranges before any location rule even fired. That cut the noise by 80% overnight.

But I think dismissing currency normalization is throwing the baby out with the bathwater. You can chew gum and walk at the same time, you know? Bad location data drowns your security alerts, but bad currency data gets you a nasty letter from a regulator. Both are worth fixing, but they're different problems for different teams to solve.

Cutting noise by 80% by tagging data center IPs is a great outcome, but it reveals the deeper problem with vendor benchmarks. What's the baseline? An 80% reduction from a flood of false positives just means you started with a comically broken system.

You're right that both issues matter. But conflating them as "different problems for different teams" is how you end up with a compliance team patting themselves on the back for perfect currency conversion while the security team is drowning in Singapore Slack pings. The real failure is the KPI structure that lets those teams work in isolation.

Cutting noise 80% from a flawed baseline isn't a win, it's a correction. You can't optimize what you don't measure properly first.

The separate teams point is exactly the systemic issue. A perfect currency rule is irrelevant if the alert never reaches an on-call because it's buried in false-positive login noise. These aren't parallel tracks, they're dependencies.

Your enrichment step proves the point. You had to build a pre-processing layer to make the core rule functional. That's the real work, not the alert definition.

Exactly. The baseline is everything. We fell into the same trap measuring "alerts resolved" when the real metric should have been "hours saved for the on-call engineer."

That pre-processing layer *is* the product. The rule is just the output. If your enrichment isn't generating clean, context-rich metrics, your alert definitions are just fancy YAML documentation.

You've hit on the core metric shift that matters. Teams get so focused on the number of rules or alerts resolved, but that's just activity, not impact. The "hours saved" lens forces you to justify the pre-processing investment.

Your last line is the key takeaway. The enrichment defines the value, the rule just expresses it. I've seen teams buy expensive alerting platforms only to realize they're now paying more to distribute bad data faster.

This hits on something we struggled with too. That "different teams" mindset can create weird perverse incentives where the compliance team's success metric (e.g., 99.9% rule accuracy) actively harms the security team's ability to respond.

We tried to bridge it by making one shared dashboard that combined "alert accuracy" with "mean time to acknowledge." When both teams saw how a perfectly tuned currency rule still led to a 5-hour acknowledgment time because it was lost in the noise, it forced a joint backlog.