Rules and backtesting

A rules engine your compliance team changes and tests itself

Write a fraud or AML rule in Archer Protect, in plain English or in the builder, backtest it on your own history, and put it live the same day. No engineering ticket.

Book a demo How it works

Who owns the risk should own the rules

  • Today Every threshold change is an engineering ticket, and it waits weeks behind product work.

    With Archer Your compliance team changes a rule, tests it, and puts it live the same day.

  • Today Writing a rule means knowing the system, so one person on the team ends up doing all of it.

    With Archer Anyone on the team can describe a rule in plain English, and the assistant builds it.

  • Today New rules go live untested, and you learn what they do in production.

    With Archer Each rule is backtested on your own history first, with the same logic that runs live.

  • Today Nobody can say which rules catch fraud and which only add noise.

    With Archer Each rule shows what it caught, so you keep what works and fix what doesn’t.

How it works

How a rule goes live

  1. Describe it

    Pick from about 120 building blocks, or describe the rule in plain English and the assistant builds it.

  2. Backtest it

    Run it on your own history to see what it would have flagged. The same logic runs live, so what you test is what you get.

  3. Choose what happens

    Open a case in the right queue, alert the team in Slack or by email, or send a decision such as freeze or reject to your system.

  4. Watch it work

    Track each rule’s alerts and outcomes, and retune it when the pattern changes.

Write a rule in plain English

Tell the assistant what you want to catch, for example “hold withdrawals over $2,000 when the customer is using a new device”. It builds the rule from Archer’s building blocks and starts a backtest. Narrow it in the same conversation, or open it in the builder and change any condition yourself.

Describe the rule in plain English. The assistant builds it and starts a backtest.

What a rule can use

Rules draw on about 120 building blocks: transaction amounts and counts over any window, counterparties, account age, devices, connections between accounts, loans, staff, and past alerts. Any event you send can go into a rule too, including chargebacks, refunds, and alerts from your blockchain-analytics tool. A rule can look at a single transaction or at a customer’s whole history.

Transaction monitoring and screening 

Test it on your own history before it goes live

Backtest any rule on your past data and see how many customers and transactions it would have flagged before it touches live traffic. Each change is saved as a new version, and once a rule is live it shows its alerts and outcomes.

See what a rule would have flagged on your own history, before it goes live.

Choose what happens when a rule fires

When a rule fires, it can open a case in the right queue, notify the analyst in Slack or by email, and send a decision such as freeze or reject to your system through a webhook.

Case management and reporting 

One rule can send a decision to your system, open a case, and notify the analyst.

See which rules work

Each rule shows how many alerts it raised and how many of the people it flagged turned out to be real cases. Ask the assistant which rule produces the most false positives and why, then backtest a narrower version on your history before you change anything live.

Each change is saved as a new version, so you can see exactly what a rule looked like when it flagged a given transaction.

Ask which rule makes the most noise, and why.

Customer results

What teams found running Archer

2–3x
the baseline rate of zero-payment defaults found by Numida’s rules in Uganda backtesting
~5.38x
net financial impact relative to subscription cost
< 60 s
to create or change a fraud rule, without engineering
Read the Numida case study 

“Having the ability to test and backtest and see the effect of putting that rule (in production) is really powerful. And it helps you make sure that you’ve got it right.”

Dan Watts Chief Risk Officer, Oxygen X
Read about rule backtesting 

FAQ

Questions compliance teams ask us

What is a fraud rules engine?

A fraud rules engine checks each transaction, login, or account change against conditions your team sets, such as “more than five transfers to new beneficiaries in an hour”, and decides what happens on a match: an alert, a case, or a decision such as hold or reject. In Archer, the same rules cover fraud and AML.

Do we need engineers to change a rule?

No. Your compliance or risk team builds, tests, and publishes rules in the Archer dashboard. Engineers are needed once, to connect your systems to Archer.

Can we test a rule before it goes live?

Yes. Every rule can be backtested on your own history first, and the same logic runs on live events, so what you test is what goes live.

What does the backtest run on?

On your own history: the events you uploaded or sent to Archer, the same kind of events the rule will see live.

Can the assistant put a rule live on its own?

No. The assistant proposes a rule and starts a backtest; a person on your team publishes it. Every published version is kept.

One system

The rest of Archer

See how Archer works on your own data

Book a demo