Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.finwatch.finance/llms.txt

Use this file to discover all available pages before exploring further.

For decades, the backbone of many fraud detection systems has been a familiar, powerful, yet increasingly brittle tool: the regular expression. Combined with simple ‘if-then’ logic, regex has been the go-to for flagging suspicious transactions. If a payment description contains a risky keyword, block. If a transaction is over a static limit, review.  This approach was fine when the world of financial crime was simpler. But today, it’s like trying to build a skyscraper with a hammer and nails. Modern fraudsters don’t operate in simple, stateless patterns; they use sophisticated, coordinated strategies that unfold over time. Your defence mechanism needs to be just as dynamic. It’s time to move beyond regex and embrace a language built for the problem: a Domain-Specific Language (DSL).

​
The Old Way: A System Held Together by Regex and Hope

Traditional rule engines force you to think in isolated, stateless events. This leads to critical limitations:
  • They Lack Context: A simple rule can’t easily answer questions like, “How many times has this user tried to do this in the last hour?” or “Is this transaction unusual for this specific user?”
  • They Are Brittle: A rule like description regex "(?i)crypto" is easily bypassed. What if the user writes ‘c-r-y-p-t-o’? Or uses a different term? You’re stuck in a never-ending game of cat-and-mouse, adding ever-more-complex regex patterns that are a nightmare to maintain.
  • They Are Slow to Change: Because the logic is often buried in application code or managed through clunky UIs, deploying a new rule is a slow, developer-dependent process. By the time the rule is live, the fraudsters have moved on.
Consider a classic fraud pattern: structuring (or “smurfing”), where a user makes multiple small deposits to stay under a reporting threshold. How would you detect this with a traditional system? It’s nearly impossible. You can’t do it with a single regex, and it requires keeping state, something most basic rule engines aren’t built for.

​
A Better Way: Thinking in Patterns with FinFlows

A DSL like FinFlows allows you to describe the behaviour of fraud, not just the superficial attributes of a single transaction. It provides the vocabulary to express complex, time-based patterns in a way that is both powerful and readable.
Two features, in particular, are game-changers:
1. Time-Window Aggregates: The End of Stateless Rules Instead of looking at one transaction, FinFlows allows you to analyse a stream of activity over a defined period. This is how you defeat patterns like structuring. Look how elegantly this rule describes the problem: 
rule StructuringDetection {
    description "Detect multiple small deposits intended to evade limits"
    when amount < 10000
    and count(where source == $current.source, "PT24H") >= 3
    and sum(amount where source == $current.source, "PT24H") > 25000
    then review
         score   0.8
         reason  "Possible structuring"
  }
In plain English, this says: “If a transaction is under 10,000, but the same user has made at least 3 transactions in the last 24 hours that total more than 25,000, flag it for review.” This is impossible with regex alone. With FinFlows, it’s a few lines of clear, declarative logic. 2. Dynamic References: Personalised, Context-Aware Rules Static rules treat all users the same. A 5,000,000 transaction might be normal for one customer but highly suspicious for another. Dynamic references, like ‘$current.source’, let you create rules that are relative to the actor’s own behaviour.  Consider a velocity check: 
rule HighVelocitySpending {
    description "Detect rapid spending from a single account"
    when sum(amount where source == $current.source, "PT1H") > 5000000
    then review
         score   0.7
         reason  "Spending velocity exceeded"
}
This rule isn’t checking a single transaction. It’s asking, “Has the total amount from this specific source account exceeded 5,000,000 in the last hour?” It automatically personalises the monitoring to each user, dramatically increasing accuracy and reducing false positives. 

​
The Future is a Fluent Conversation About Risk

By adopting a DSL like FinFlows, you are fundamentally changing how you fight fraud. You move from a slow, reactive, and rigid process to one that is:
  • Fast: Your fraud analysts—the domain experts—can write and deploy rules in minutes, not weeks.
  • Intelligent: You can detect sophisticated, stateful fraud patterns that were previously invisible.
  • Clear: Your rules become self-documenting, readable, and easy to audit.
 The future of fraud detection isn’t about writing a better regex. It’s about having a more intelligent conversation about risk. FinFlows provides the language to do it.