InackGuardTest a rule before it raises one alert.
Eight rule types for payment firms and money-service businesses. Backtest each over the past 90 days, see what it would have flagged, then switch it on, with a reason and approver for every threshold change.
What is transaction monitoring software?
Transaction monitoring software watches payments for patterns that a compliance policy says to look at: amounts just under a reporting threshold, a quiet account that suddenly moves money, payments to high-risk countries, a first large payment to a new beneficiary. Each pattern is a rule with thresholds. The hard part is setting thresholds that catch risk without burying analysts, which is why a backtest over your own past activity matters more than a long rule library. InackGuard runs the test first, records who approved the threshold, and only then raises alerts.
Guessed thresholds bury analysts or miss risk.
Set a threshold too low and alerts pile up; too high and real activity slips through. A backtest on your own past activity shows the workload and the cases before you commit.
How it works
- STEP 1Upload transactions or connect by API
- STEP 2Choose rules and draft thresholds
- STEP 3Backtest over the past 90 days
- STEP 4Approve, switch on and review monthly
What it does
Six capabilities, each one visible in the report it produces.
Eight rule types
Structuring, velocity, pass-through, dormant activation, high-risk country, new large beneficiary, cash threshold and activity above expectation. Each has a short explanation of what it detects, the parameters it takes and the regulatory reference it serves.
- Each type documented with an example and a reference
- Parameters validated before a rule can be saved
- Start a rule from the typology catalogue with the type preset
RECORDEDThe rule type, version and parameters of every rule, past and present.
90-day backtest
A backtest runs a draft rule over the last ninety days of your own transactions and reports how many customers it would have flagged, how many cases it would have opened and a sample of them. Nothing is created; the result is recorded in the audit trail.
- Customers flagged, cases it would open, a sample of both
- Nothing written: no alerts, no cases
- Every backtest kept in the audit trail with its parameters
RECORDEDThe backtest, its parameters, window and counts.
Governed changes
A threshold change needs a reason and an approver who is not the person proposing it. The old value, the new value, both names and the reason stay on the rule's history, so an examiner sees why a rule was tuned and who agreed.
- Reason required on every change
- Approver must differ from the proposer
- Full history per rule, exportable
RECORDEDEvery version of every rule with reason, proposer and approver.
Risk profiles
Each customer carries an expected activity profile: monthly amount, monthly count, a tier. Rules such as activity above expectation read it, so the same payment can be normal for one customer and an alert for another.
- Expected monthly amount and count per customer
- Tier feeds rule sensitivity
- Profiles editable with a reason, like rules
RECORDEDThe profile values used by each alert at the time it was raised.
Recorded tests
Backtests, dry runs and real runs all land in the same audit trail with the same shape: who, when, which rule version, which window, what came out. A tuning decision months ago can be reconstructed from it.
- Backtests and live runs in one trail
- Rule version and window on every entry
- Exportable with the case bundle
RECORDEDEach run, the rule version it used and its counts.
Fast evaluation
Rules run over the whole book in one scheduled run, and one transaction at a time through the scoring endpoint, so a payment can be checked as it is booked and the answer comes back in the same request, with its latency reported.
- Scheduled runs over the whole book
- One-transaction scoring with latency reported
- No transaction is held by the platform; the answer is for a person
RECORDEDThe run or the scoring request, its latency and what fired.
Specifications
- DATA
- Transactions with customer, amount, direction, counterparty country and time
- RULES
- Eight types, configurable thresholds
- TESTING
- 90-day backtest; nothing is created during a test
- GOVERNANCE
- Reason and approver on every change; review records
- OUTPUT
- Alerts, cases and an audit trail
Guides that go with it
Written from the product, kept with it.
Reports built on it
Each one shows its price before it runs.
Questions
Do backtests create alerts?+
No. They show what would have been flagged and are recorded in the audit trail.
Can we write custom rules?+
Today you configure the eight rule types; custom rules are on the roadmap.
Who should approve threshold changes?+
Someone other than the person proposing them, as your policy sets.
See transaction rules on your own names.
Free preview, no card.