> ## 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.

# Why FinWatch?

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:

```shellscript lines theme={null}
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:

```shellscript lines theme={null}
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.