> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fraudeg.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Configure Risk Rules and Fraud Decision Thresholds
> Build custom fraud rules in FraudEG's no-code rule builder. Set risk score thresholds, signal conditions, and automatic decisions for your business.
Risk rules are configurable conditions that override or augment FraudEG's machine learning risk score to produce a final decision on every transaction or event. Rather than relying solely on the ML model, you define the business logic that matters most to you — blocking high-risk transactions outright, challenging suspicious ones, or flagging edge cases for manual review. This gives you precise control over how fraud prevention behaves across your entire customer base.
## Why custom rules matter
Every business has a different risk profile. A high-volume marketplace tolerates different thresholds than a crypto exchange or a B2B payments platform. Custom rules let you encode your risk tolerance, your knowledge of your customers, and your regulatory obligations directly into FraudEG's decision engine — without writing a single line of code.
Start with FraudEG's recommended baseline rule set, available when you first open the rule builder. These defaults reflect best practices across thousands of businesses and give you a solid starting point to customize from.
## The Risk Rules dashboard
You manage all rules from **Platform → Risk Rules** in the FraudEG dashboard. From here you can create, reorder, enable or disable, and simulate individual rules against historical or synthetic transactions.
***
## Rule anatomy
Every rule has two parts: a set of **conditions** (IF) and a set of **actions** (THEN). When all conditions in a rule are met, FraudEG executes the associated actions and stops evaluating further rules.
### Conditions
You can combine one or more of the following signal types in a single rule:
| Signal type | Examples |
| ------------------ | ----------------------------------------------------------------------- |
| `risk_score` | Range check: `>= 80`, `between 40 and 79` |
| Signal presence | `signal = "ip_proxy_detected"`, `signal = "device_spoofing"` |
| Transaction amount | `amount > 50000`, `amount <= 1000` |
| Payment method | `payment_method.type = "card"`, `payment_method.type = "bank_transfer"` |
| User attributes | `user.is_new = true`, `user.kyc_status = "pending"` |
| Geography | `user.country = "NG"`, `ip.country != user.billing_country` |
| Velocity | `transactions_last_1h > 5`, `failed_attempts_last_24h >= 3` |
### Actions
When conditions are met, choose one or more actions to execute:
| Action | Description |
| ------------------- | ------------------------------------------------------------------------------- |
| **Allow** | Approve the transaction and return a `pass` decision |
| **Challenge** | Return a `challenge` decision — trigger step-up auth or additional verification |
| **Block** | Decline the transaction and return a `block` decision |
| **Flag for review** | Pass the transaction but create a manual review case in the FraudEG dashboard |
| **Send webhook** | Fire a webhook to a URL you specify with the full event payload |
***
## Example rules
The following examples illustrate how to translate common fraud policies into rules:
```text theme={null}
IF risk_score >= 80
THEN block
```
```text theme={null}
IF risk_score >= 50 AND amount > 50000
THEN challenge
```
```text theme={null}
IF signal = "ip_proxy_detected" AND payment_method.type = "card"
THEN challenge
```
```text theme={null}
IF user.is_new = true AND amount > 10000
THEN challenge
```
***
## Rule priority
FraudEG evaluates rules **in the order they appear** in the dashboard. The first rule whose conditions all match is applied, and evaluation stops. Rules that are lower in the list are only evaluated if no earlier rule matched.
Rule conflicts can produce unexpected decisions. Always place more specific rules — those with multiple tightly scoped conditions — above broader, general-purpose rules. A broad rule placed first will shadow every specific rule below it that it matches first.
You can drag and drop rules in **Platform → Risk Rules** to reorder them at any time. Changes take effect immediately for new events after you save.
***
## Create a new rule
Go to **Platform → Risk Rules** and click **New Rule** in the top-right corner.
Give the rule a descriptive name (for example, `Block high-risk score`) and an optional description so your team understands its purpose.
Click **Add Condition** and select a signal type from the dropdown. Set the operator and value. Repeat to add multiple conditions — by default all conditions must be true (AND logic). Toggle to **Match any** if you need OR logic.
Click **Add Action** and select the outcome: **Allow**, **Challenge**, **Block**, **Flag for review**, or **Send webhook**. You can add more than one action to a single rule.
Drag the rule to the correct position in the list. More specific rules should appear above broader ones.
Click **Save Rule**. The rule is saved in a disabled state so you can test it before activating.
***
## Testing rules
Before enabling a new rule in production, validate it in the **sandbox environment** using FraudEG's rule simulation mode.
1. In **Platform → Risk Rules**, click the **Simulate** button next to any saved rule.
2. Enter a sample transaction payload — or load a recent historical event — and click **Run Simulation**.
3. FraudEG shows which rules matched, in what order, and what decision would have been returned.
4. Adjust your conditions or rule order based on the simulation output.
5. Once satisfied, toggle the rule to **Enabled** and promote your configuration to production.
Rules can also be managed programmatically via the FraudEG Rules API (`POST /v1/rules`, `PATCH /v1/rules/{id}`). This is useful for teams that manage configuration as code or need to deploy rule changes through an automated deployment pipeline. See the API Reference for full details.