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

Transaction monitoring your compliance team actually controls.

GoRules is the decisioning engine for AML transaction monitoring: your analysts author the scenarios as decision tables, every change is versioned and approved, and every transaction is evaluated in real time. No vendor ticket, no six-month release cycle, no black box.

From noise to cases,
start to finish.

Watch a Thursday in a financial crime team: 214 open alerts at a 38 percent false positive rate, a delicatessen that trips the structuring scenario every night it banks its takings, a one-cell exclusion for KYC-verified cash-intensive customers, a replay over 12,400 alerts, a signed release - and a structuring ring that stays lit the whole way through.

scroll to play
Thursday, 08:40

The queue opens at 214.

Ninety days of cash movement draw into one link chart. Harbor Deli LLC banks its takings five nights a week, $8,200 to $9,600 a time, and every deposit trips the structuring scenario.

The case file

The fortieth alert on the same account.

Forty alerts in ninety days, forty dispositions, all of them false positive, zero SARs filed. KYC declared the deli cash-intensive and verified it in March. The scenario has never been able to see that.

One cell

The scenario learns who was verified.

The rule that fired opens the live scenario. On a branch, the $8,000 to $9,999 band now excludes customers KYC verified as cash-intensive. The CTR rule at $10,000 does not move.

Proof before production

12,400 alerts, replayed.

Ninety days of alerts re-run against the draft while you watch: 61 percent of the cash noise disappears, every confirmed SAR case still alerts, and the below-the-line sample turns up no missed structuring.

Sign-off

Financial crime approves. v9.3.0 ships.

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

Same morning

214 alerts down to 31.

The amber badges on the deli deposits dissolve one by one and the false positive rate falls from 38 to 9 percent. The five accounts wiring $9,400 to $9,700 into the same beneficiary stay lit, and that alert becomes a case with a SAR draft attached.

The least responsive system
you depend on.

If you run an AML program at a fintech, PSP, or bank, your transaction monitoring software is probably the least responsive system you depend on. Your team identifies a typology, drafts a scenario change, and then waits: on the vendor's professional services queue, on the next quarterly release, or on an engineering backlog where compliance tickets never win. In ComplyAdvantage's survey of 600 senior compliance decision makers, 41% named lack of rule flexibility among the main limitations of their detection programs.

The output side is just as bad. Industry estimates commonly put false positive rates above 90% of alerts, which means analyst teams spend most of their time closing noise while SAR conversion rates stay flat. The usual cause is not mysterious: transaction monitoring solutions shipped with generic rule packs, one threshold applied across every customer segment, and no practical way to backtest a change before it floods the queue or, worse, silently stops catching reportable activity.

Then an examiner asks a simple question: which rule version fired on this transaction last March, who changed that threshold, who approved it, and why? FFIEC examiners expect documented rule rationale and independent testing. NYDFS Part 504 requires New York regulated institutions to certify their transaction monitoring program annually, and a certifying officer signs personally.

If your answer lives in a vendor's opaque config export and a folder of change-request emails, that conversation goes badly.

Scenarios your analysts write.
Governance examiners trust.

The people accountable for the monitoring program should be the people who control the rules it runs on.

01

Compliance authors the rules, in a form regulators can read

In most AML transaction monitoring software the scenarios are configuration only the vendor understands. In GoRules they are visual decision tables and graphs, not code. A BSA analyst can add a velocity rule, tighten a structuring threshold per customer segment, or add a high-risk-jurisdiction condition using spreadsheet-style tables and ZEN expressions. Natural-language rendering turns every rule into plain English, so the same artifact serves the analyst writing it, the MLRO reviewing it, and the examiner reading it.

02

Governance built in: versioning, approvals, environments

Every rule change is captured in git-like version control with author, timestamp, and full diff, protected by approval workflows and role-based access. Changes move through dev, staging, and production explicitly, and any release rolls back in one click. That is the audit trail examiners ask for: you can reproduce exactly which rule version evaluated any historical transaction and show who approved the change that got it there.

03

Real-time evaluation, explainable by design

The open-source ZEN engine (Rust core, MIT licensed) embeds in Node.js, Python, Java, Go, C# or Rust and evaluates rules in under a millisecond, fast enough to sit inline on FedNow, RTP, and SEPA Instant flows where batch monitoring arrives too late to hold a payment. ML anomaly scores, screening results, and KYC risk ratings enter as inputs to rules, so the final decision stays a human-readable rule outcome you can defend, not a black-box score you cannot.

The decisioning layer
of your monitoring stack.

GoRules pairs with your data pipeline, screening provider, ML models, and case management - it does not replace them.

01

Model your scenarios

Recreate the rule set from your current transaction monitoring system as decision tables: single-transaction rules, aggregate and velocity rules over time windows, behavioral deviation rules, and risk-pattern typologies like structuring or rapid in-out movement. Start from the financial services templates and set thresholds per customer risk segment instead of one global value.

02

Connect your inputs

Each evaluation receives the transaction plus whatever context your rules need: the customer's KYC/CDD risk rating, sanctions and watchlist screening results from your screening provider, account history aggregates from your data pipeline, and ML risk scores if you run models. Feature platforms such as Chalk or Tecton are natural companions here: they compute the velocity aggregates and risk signals in real time, and GoRules decides on them.

03

Test, approve, promote

Run proposed changes against historical transaction samples to see alert volume impact before anyone in production feels it, the same way ATL/BTL tuning exercises probe thresholds above and below current settings. When the numbers look right, the change goes through approval and is promoted from staging to production with the full trail recorded.

04

Evaluate in real time and route alerts

Embed the engine in your payment path for sub-millisecond decisions, or call the REST API from your core system. Rule outcomes carry severity and reason fields your case management system consumes for triage, and your team keeps tuning: review alert dispositions, adjust thresholds per segment, watch SAR conversion rather than raw alert count.

Built for production,
not proof of concept.

  • Sub-millisecond rule evaluation with the embedded open-source ZEN engine (Rust core), suitable for inline monitoring on instant payment rails
  • Full audit trail: every rule change versioned with author and diff, approval workflows with role-based access, one-click rollback
  • Reproducibility: pin and retrieve the exact rule version that evaluated any historical transaction
  • Deploy anywhere: self-hosted via Docker or Kubernetes for data residency and vendor risk requirements, or GoRules Cloud; SSO, RBAC, SOC 2
  • Rules stay explainable with ML in the loop: model scores are inputs, decisions are readable rules rendered in natural language

Questions, answered.

What is transaction monitoring?

Transaction monitoring is the ongoing analysis of customer transactions to detect activity that may indicate money laundering, terrorist financing, or fraud. Transaction monitoring software evaluates each transaction, or batches of them, against rules and scenarios, generates alerts for suspicious patterns, and feeds investigations that can end in a SAR filing. It is a core obligation under BSA/FinCEN requirements in the US and Article 26 of the EU's AMLR (Regulation 2024/1624, applying from 10 July 2027), and the FATF risk-based approach expects monitoring intensity to match customer and product risk.

What is the difference between transaction screening and transaction monitoring?

Screening matches the parties to a transaction against sanctions, PEP, and watchlists before or as it executes. Monitoring analyzes transaction behavior over time to find suspicious patterns. AML screening and monitoring are separate controls that work together, and in GoRules your screening provider's match results simply arrive as inputs your monitoring rules can act on.

What are examples of AML transaction monitoring rules?

Common scenarios include structuring (multiple cash deposits just under the $10,000 CTR threshold within 72 hours), velocity rules (transaction count or volume in 24 hours far above the customer's segment baseline), rapid in-out movement (withdrawal of 90%+ of a deposit within a day), transfers involving high-risk jurisdictions combined with amount deviation, and dormant accounts reactivating with large transfers. In GoRules each of these is a decision table your compliance team can read and edit, with thresholds set per customer risk segment.

How does real-time transaction monitoring work for instant payments?

On rails like FedNow, RTP, and SEPA Instant, settlement happens in seconds, so monitoring must run inline in the payment path before funds move, not in an overnight batch. The embedded ZEN engine evaluates rules in under a millisecond per decision, which leaves your latency budget for data lookups and screening calls. The same rule set can serve as the decision core of a payment monitoring system across cards, ACH, and instant rails.

Is GoRules a complete AML compliance platform?

No, and that is deliberate. GoRules is the rules engine and rule governance layer: scenario authoring, testing, versioning, approvals, and real-time evaluation. You pair it with your data pipeline, a screening data provider, your ML models if you use them, and case management for investigations. It supports the audit trail and change governance regulators expect, but compliance is a property of your program, not of any software.

The same engine,
next door.

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

Credit DecisioningPolicy above your ML modelsLoan DecisioningApplication to priced decisionFinancial ServicesTemplates and industry solutions

Your scenarios. Your thresholds.
Your audit trail.

Put transaction monitoring rules in the hands of the team accountable for them, with the governance to prove every change.

Get started Book a demo