Release-bound rules
A logic change waits weeks for engineering time.
Platform · Detection logic
Rules Engine, detection logic without a release cycle
Build, test and ship detection rules yourself, replay them against real history before they go live, so a new scenario does not wait for the next deployment.
No-code
Rule builder
Backtested
Against real history
Versioned
Every rule, every change
Minutes
From idea to live rule
Why this matters
The rule you need is stuck behind a deployment
A new typology appears, and the fix is obvious, but changing the logic means a ticket, a sprint and a release. By the time the rule ships, the pattern has moved on. Complead puts the rule builder in the compliance team’s hands, with backtesting so nobody ships a rule blind.
Blind changes
A new rule goes live without anyone knowing how many alerts it will raise.
No version history
When a rule misfires, nobody can say what changed or when.
How it works
Scroll to advance
Four steps, from idea to live rule
-
Step 01
Build the rule
Compose conditions in a no-code editor: fields, thresholds and score effects.
-
Step 02
Backtest on history
Replay the rule against real past data to see how many alerts it would have raised.
-
Step 03
Tune the threshold
Adjust and re-run until the alert volume and hit rate are where you want them.
-
Step 04
Publish and version
Publish the rule with a version. Roll back to any prior version at any time.
complead / build
IF txn_count_1h > 12 AND avg_amount > 5000 THEN score +30.
complead / backtest
- Backtest30d
- alerts214
- would clear89%
- true positives3
complead / tune
- Threshold 12 →16
- alerts 214 →96
- true positivesheld
complead / publish
- Publishedv3
- live
- rollback to v2available
Build
Backtest
Tune
Publish
Capabilities
What the product actually does
No-code builder
Conditions, thresholds and score effects without writing code.
Backtesting
Replay any rule against real history before it goes live.
Versioning
Every rule and every change kept, with rollback.
Segmentation
Rules scoped per product, segment or jurisdiction.
Score contribution
Rules add to the Fusion score, not just a binary flag.
Change audit
Who changed what, when and why.
Product tour
Three screens your team lives in
Logic you can read
Conditions in plain terms, with the score effect shown as you build.
- Fields and operators from a picker
- Score effect previewed
- Scope by segment or jurisdiction
complead / editor
- velocity spikev3
- IF txn_count_1h > 12 AND avg_amount > 5000 THEN+30
Know before you ship
Replay against history and read the alert volume, clearance rate and true positives.
- 30, 60 or 90 day windows
- Alerts and clearance rate shown
- True positives highlighted
complead / backtest
- 30d
- alerts214
- clear89%
- confirmed3
Retune?
Every change on the record
The full version history of a rule, with a one-click rollback.
- Diff between versions
- Author and reason per change
- Rollback to any version
complead / versions
- v3live
- v2archived
- v1archived
- diffavailable
What it acts on
Which signals a rule can use, and how current they are
Rules read from screening results, transaction data, device signals and Fusion scores, all live.
Field reference
Screening
Match scores, list origin, entity type
Transactions
Amount, velocity, counterparty, geography
Device
Fingerprint and behaviour signals
Freshness
Live, evaluated as events arrive
Runs on Fusion
Rules feed the Fusion score, they do not replace it
A rule adds to the single customer risk score alongside screening and behaviour. You tune the logic, the engine keeps the score explainable.
This product
Rules Engine
Custom detection logic, backtested and versioned
Feeds into
Fusion engine
Rule contributions to the risk score
You get
One risk score
Yours to shape, still explainable
Integration
Manage rules by hand or over the API
Build in the editor, or create and publish rules programmatically for automated pipelines.
// create a rule
POST /v1/rules "name": "velocity_spike", "when": "txn_count_1h > 12 && avg_amount > 5000", "then": "score += 30"
201 Created · v3 · draft
// backtest before publishing
POST /v1/rules/velocity_spike/backtest "window": "30d"
200 OK · 214 alerts · clear_rate 0.89
FAQ
Before you ask us
Do we need engineering to change a rule?
No. The builder is no-code, so the compliance team owns the logic. Engineering can still automate rule management over the API if wanted.
Can we test a rule before it goes live?
Yes. Backtest any rule against 30, 60 or 90 days of real history and read the alert volume and hit rate.
What if a new rule misfires?
Every rule is versioned. Roll back to a prior version in one click.
Can rules differ by segment?
Yes. Scope a rule per product, segment or jurisdiction.
Do rules replace the risk score?
No. Rules contribute to the single Fusion score, which stays explainable.
Where is our data stored?
You choose the region: EU, UK or Türkiye.
Testimonials
All case studies
What compliance teams say
We went from checking customers one by one to a single platform that screens more than 3,000 of them around the clock, so our analysts can finally focus on real risk.
We moved from screening customers one by one to a unified platform where our analysts can focus on what actually matters.
We focus on real risks, not false positives, meeting our AML obligations and our customers' expectations.