v2.0

GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here!

Watch the launch videoWatch
gorules
Book a demoGet started

Fraud detection software.
The score flags it, your rules decide.

GoRules is the decision layer above your fraud scores: velocity rules, allow, deny, and review thresholds, and step-up triggers in visual decision tables your fraud team edits directly. Tune a false-positive problem the same afternoon you find it, without retraining a model or waiting on an engineering release.

From held to cleared,
start to finish.

Watch a Monday in a fraud team: 214 good transactions stuck behind a rule tightened during a card-testing attack, a one-cell exemption for trusted devices, a replay over 4,180 held transactions, a signed release - and a false positive rate that drops from 38 to 9 percent.

scroll to play
Monday, 09:06

The queue never emptied.

A checkout declines: an $84 reorder, risk score 0.12, device trusted since last spring. It is the 214th payment held since Thursday, when the velocity rule was tightened against a card-testing attack.

The case file

Nothing here looks like fraud.

Three years on the account, 14 prior orders, zero disputes, the same device for 11 months. One counter tripped: 4 card attempts in 10 minutes, one over the limit set during the attack.

One cell

The velocity rule learns about devices.

The rule that held it opens the live policy. On a branch, the 10-minute hold now applies to untrusted devices only. The score block at 0.85 and the confirmed-fraud block stay exactly as they are.

Proof before production

48 hours of holds, replayed.

4,180 held transactions re-run against the draft while you watch: 2,548 release, all 37 confirmed-fraud cases are still caught, chargeback exposure unchanged.

Sign-off

Fraud approves. v7.1.0 ships.

Priya Shah signs the release, it promotes through staging to production with the full trail recorded. Rollback stays one click away.

Within the hour

The queue drains. The blocks hold.

The retry goes through without a human touching it. Review queue 214 to 31, false positive rate 38 to 9 percent, and the new-device attempt scoring 0.91 stays blocked.

The rule that stops fraud
also stops your customers.

Fraud detection software is judged on the fraud it stops and paid for with the customers it stops alongside it. Merchant Risk Council survey data puts the average fraud-suspicion decline rate at 2.6% of orders, rising to roughly 3.1% once the basket clears $100, and industry analyses consistently find false declines cost more revenue than the fraud they prevent. Every one of those declines traces back to a threshold somebody picked, often a year ago, for a customer mix that no longer exists.

Ask a fraud team where the policy actually lives and you get three answers at once: score cutoffs hard-coded in the checkout or authorization service, a vendor console whose logic nobody outside the vendor can inspect, and a spreadsheet of per-segment thresholds the risk analysts maintain by hand. The people accountable for the fraud rate and the approval rate are the people who cannot change either one without a ticket.

The feedback loop makes it worse. Chargebacks land weeks after the transaction, so the labels that prove a threshold was wrong arrive long after the revenue is gone. Nobody can answer the question that matters before shipping: if we move the deny cutoff from 720 to 760 for returning customers, how many of last month's declines become approvals, and how much confirmed fraud comes through with them?

The pressure is external too. Visa's Acquirer Monitoring Program folded fraud and dispute ratios into one number, flagging portfolios above standard at 50 bps and excessive at 70 bps, and under the PSD2 RTS your transaction risk analysis exemptions only survive while the reference fraud rate stays inside the 0.13%, 0.06%, and 0.01% bands. When a dispute, an acquirer review, or an angry customer asks why a specific transaction was blocked in March, "the score was high" is not an answer, and neither is a config export nobody can diff.

The rules layer
above your fraud score.

Your model estimates how risky the transaction is. GoRules decides what happens next - allow, challenge, review, or deny - in tables the fraud team owns.

01

Fraud policy as decision tables, not vendor config

Fraud policy is naturally a matrix: score band by velocity counter by customer segment, resolving to an action and a reason code. GoRules decision tables are that matrix, spreadsheet-style, edited by fraud analysts and rendered in natural language for review. Hard blocks such as confirmed-fraud devices, blocked BIN ranges, and disposable email domains are modeled with Policies, ordered blocks evaluated in sequence, so they fire before the score is ever consulted. Velocity conditions like cards per device in 24 hours, attempts per BIN, or orders per shipping address sit in the same table as the score bands, and ZEN expressions handle derived values such as deviation from the customer's own baseline. Start from the fraud detection templates instead of a blank table.

02

Tune false positives without touching the model

Branch the live policy with git-like version control, raise the deny cutoff for returning customers, and replay a labelled sample of historical transactions through both branches as test cases: which orders swap from deny to allow, which confirmed-fraud cases now get through. GoRules AI can draft the rule change, run the tests, and explain the resulting decisions while you iterate. When the numbers work, promote through dev, staging, and production as a versioned release with required approvals, and roll back in one click if the fraud rate disagrees.

03

Every decline explains itself

Each evaluation returns the action plus the exact rules that fired: which hard block matched, which score band applied, which velocity counter tripped. That trace is what a dispute analyst attaches to representment evidence, what a support agent reads back when a good customer calls, and what an acquirer review consumes when it asks how your controls actually work. Behind it sits the governance record: full audit logs, commit history, approval workflows, SSO, and role-based access control.

Keep your models.
Own the decision.

GoRules does not replace your scoring model, your device intelligence provider, or your case management system. It is the layer that turns their signals into an action.

01

Wire it into the authorization path

Call GoRules over REST from your checkout, payment, or onboarding service, or embed the MIT-licensed open-source ZEN Engine with SDKs for Node.js, Python, Java, Go, C#, and Rust. The payload carries the transaction, your model's fraud score, device fingerprint and reputation signals, velocity counters from your feature store or cache, BIN and AVS/CVV results, and the customer's account history.

02

Model the policy

Build the decision graph: hard blocks first as Policies, then velocity tables for card testing and enumeration, then score bands per segment, channel, and MCC. It ends in one structured outcome - allow, challenge with a 3DS step-up, route to manual review, or deny - each carrying a reason code your downstream systems can act on.

03

Replay, then compare

Run a labelled window of historical transactions through the current policy and a challenger branch in the simulator. Compare decline rate, challenge rate, review queue volume, and caught fraud side by side, let stakeholders read the rules in natural language, and take the change through approval before it touches live traffic.

04

Operate and keep tuning

Evaluate inline in under a millisecond, feed reason codes into case management and your dispute workflow, and close the loop weekly: review chargeback labels and analyst dispositions, adjust thresholds per segment, and watch approval rate next to fraud rate rather than either one alone.

Built for production,
not proof of concept.

  • Sub-millisecond evaluation with the open-source ZEN engine (Rust core), fast enough to sit inline in the authorization path without spending your latency budget
  • Git-like version control on every fraud policy: branches, commit history, approval workflows, one-click rollback when a threshold change misbehaves
  • Self-host with Docker or Kubernetes so cardholder, device, and behavioral data never leave your infrastructure, or run on GoRules Cloud
  • Complete audit trail: every decision links to the rules that fired, every rule change records who changed what and when. SSO, role-based access, SOC 2
  • No lock-in: the core engine is open source under MIT with a Rust core, and 70+ industry templates give your team a working starting point instead of a blank table

Questions, answered.

What is fraud detection software?

Fraud detection software evaluates a transaction, login, or account-opening attempt against risk signals and rules, then returns an action in real time: allow it, challenge it with step-up authentication, send it to a human reviewer, or deny it. Modern stacks are layered, with device intelligence and behavioral data feeding a scoring model and a rules layer turning that score plus hard policy into the actual decision. The scoring part estimates risk; the rules part is where your risk appetite, your segments, and your reason codes live. GoRules provides that rules layer as visual decision tables and graphs your fraud team edits directly.

What is a fraud rules engine, and does it replace machine learning?

A fraud rules engine executes explicit, human-authored logic: velocity checks, score cutoffs, allowlists, hard blocks, and segment-specific thresholds. It does not replace machine learning, and the two are not competing. A model generalizes to patterns nobody wrote down, while rules encode the decisions you must be able to explain and change today. The production pattern is a hybrid: the model emits a score, the rules engine applies deterministic overrides and maps that score to an action. Keeping them separate means a threshold change is an afternoon of work rather than a retraining and revalidation cycle.

What is fraud scoring and how do thresholds map to allow, deny, and review?

Fraud scoring condenses signals about a transaction into a single number, typically 0 to 100 or 0 to 1000, where higher means riskier. Teams then band that score: auto-approve below a low cutoff, deny above a high one, and route the middle to a manual review queue or a 3DS step-up challenge. The bands are the whole game, and they should not be global, because a returning customer with a three-year history and a first-time buyer on a prepaid BIN deserve different cutoffs. In GoRules each band is a row in a decision table, set per segment, channel, and product, and changed without an engineering release.

How do we reduce false positives without letting more fraud through?

Replace one global cutoff with per-segment bands, add a challenge tier so borderline cases get a 3DS step-up instead of a hard decline, and test every change against labelled history before it ships. GoRules lets you branch the live policy, replay a window of past transactions through both versions, and compare decline rate, challenge rate, review volume, and caught fraud before anyone in production feels it. Because velocity counters, device signals, and model scores all enter as inputs to readable rules, you can see which condition produces the false positives instead of guessing at a score. Then tune weekly rather than quarterly, because the change no longer waits on a release window.

Can we self-host, and does GoRules help with audits and scheme monitoring programs?

Yes to self-hosting: deploy with Docker or Kubernetes inside your own network, or embed the MIT-licensed open-source ZEN engine directly in your services, so transaction, cardholder, and device data never crosses a vendor boundary. SSO and role-based access control govern who can view or change rules, and GoRules Cloud is available when managed hosting suits you better. For audits, disputes, and acquirer reviews you can retrieve the exact rule version that evaluated any historical transaction along with the approval that put it into production, which is the evidence teams need when documenting controls behind PSD2 transaction risk analysis exemptions or a scheme monitoring remediation plan. GoRules supplies the traceability; the obligations remain yours.

The same engine,
next door.

One decision layer serves the whole institution - these use cases run on the same tables, versioning, and audit trail.

Transaction MonitoringAML rules on the same engineCredit DecisioningPolicy above your ML modelsDecision EngineThe layer under every decision

Stop the fraud.
Keep the customer.

Rebuild your current rule set as decision tables this week, replay last month's transactions against it, and find out what your thresholds are actually costing before you change a line of code.

Get started Book a demo