Transaction Monitoring

Both. A library shipped configured for your sector runs from day one, each scenario pre-parameterized, mapped to FATF and regional guidance, and documented with the reasoning behind its thresholds. From there, you write your own patterns for which nobody has published a typology.

Transaction monitoring answers whether behavior should be reported over days and weeks. Real-time fraud prevention answers whether a payment should be allowed in milliseconds. Both run on the same customer record.

Any rule, new or changed, runs over your own transaction history first. Alert volume, cases it would still have caught, and coverage unique to that rule come back as numbers, shown against the version it replaces.

Performance is measured per rule or customer: alerts raised, cases opened, filings produced, and false-positive rate. A scenario that has never converted is visible as such, and backtesting shows what it would have missed if retired. The decision is recorded with the evidence behind it, which is what makes it defensible rather than political.

Transactions are scored on ingest, so a pattern raises an alert while the activity is still current. Batch delivery by file is supported on the same engine, for firms whose infrastructure works that way.

Partly by scoring against each customer's own baseline, so ordinary behavior for that customer does not fire. Partly by letting you tune from inside the alert that prompted you, and prove the change in history before publishing it.

Typologies confirmed by other institutions arrive as ready scenarios you can backtest and switch on. Only anonymised pattern logic moves across the network. Your customers, transactions, counterparties and thresholds stay in your tenant, and contribution is opt-in per rule.

Every alert shows the rule and version that raised it, the transactions in the window, the counterparties involved and the reason stated in language a reviewer can repeat. Nothing fires on a number alone.

You describe the logic in plain language and Nova lays out the conditions, thresholds and windows on the canvas with its reasoning written alongside each node. Every node stays editable by hand, and the rule still goes through simulation and approval before it runs.

Yes. The narrative is drafted from what the case already contains, in the format the receiving authority expects like goAML, FINCEN, , with supporting transactions attached and the approval chain recorded.

Rules read the customer's rating, segment, and declared expectations, so the same scenario behaves differently for a merchant and a retail savings customer.

It is the largest weight in the Fusion score, so a rising monitoring score pulls a customer into review across the whole program rather than only inside this module.