The rule engine behind DetectX® monitoring, scoring, filtering and digital identity. Your team writes each rule in the Rule Designer from fields your data already holds, checks them against lists it keeps itself, and sets every threshold to its own policy, with no coding. Every change is tested in staging before it goes live, and every version keeps its date and its owner, so you can always see what ran, when, and why.
Alerts raised under a published rule land in that module's queue, here Transaction Monitoring.
Where your rules run
One rule engine. Five solutions, each acting its own way.
A business rule is a condition your institution writes: a threshold, a list check or a time window. The same Rule Designer writes the rules for five DetectX® solutions, and what happens when a rule fires depends on the solution it runs in. Select a solution to see one of its rules and that rule’s version history.
Just publishedAwaiting confirmation14.10.2026 · e.marti
v3
ActiveConfirmed and running02.06.2026 · j.feldmann
v2
Earlier version11.01.2026 · e.marti
v1
First published18.08.2025 · j.feldmann
Next review of v3: 02.12.2026
The owner is notified when the review falls due. A version not revised in time is blocked until it is.
Illustrative. Example rules and version history, not a client configuration.
How a rule is built
Four parts. Each one does a single job.
A DetectX® business rule is assembled from data your systems already hold. The base model supplies the fields, dictionaries supply the lists, rules hold the conditions, and rulesets decide what runs. Your team owns the rules and dictionaries; Prospero sets up the base model and rulesets.
Base model
Rules see the fields your data already supplies.
The base model links your core system to the fields a rule can use. Fields come from the data mart, the REST interface or the payment message, or are calculated in the base model. It is set up by Prospero at implementation and changed through a patch.
A dictionary is a table your team uploads and maintains, such as your country or industry risk ratings. Any rule can test a field against it, and a change to the list applies to every rule that uses it. Changing a dictionary’s structure, such as adding a column, needs Prospero.
dict.country_riskCountry risk dictionary
Country
FATF status
Your rating
Country A
Call for action
High
Country B
Increased monitoring
High
Country C
Not listed
Medium
Country D
Not listed
Low
Also used by the standard rules: industry risk, reported clients, suspicious clients
Set here
The lists, and what goes in them
Owned by
Your team
Rules
Conditions you can read, line by line.
Each condition compares a field with a value or a dictionary, using operators such as equal to or greater than. Conditions join with AND or OR and are checked from top to bottom. You start from a standard rule and set the values to your own policy.
20 000 Values your team sets. Shown with the documented example values.
Set here
Every condition and threshold
Owned by
Your team
Rulesets
A rule runs once its ruleset is active.
Rules are grouped into rulesets and activated together, alongside the settings for monitoring and scoring. Each installation arrives with the standard rules already in place, ready for your team to set its values. The ruleset is set up at implementation and rarely changes after that.
Written from years of running rules in production.
A rule template is a ready-written rule with the values left for you to set. DetectX® ships a set for each industry it serves, built from the patterns of risk we have seen at banks, insurers and other institutions. Your team picks the set for its industry, enters its own thresholds and starts monitoring, then adds its own rules alongside.
Your team owns its business rules. This is the route one requirement takes, from the wording in your policy to a rule running in DetectX®.
Your policy · section 4.2
“Transactions of politically exposed persons1 are reviewed when a single payment reaches 20 0002, or when more than five3 payments within ten days4 together reach 20 0002.”
1Who
2Amount
3Count
4Window
In DetectX®
Standard rules · Transaction MonitoringTM 01 · PEP transactions
Standard rule
TM 01PEP transactionsMatches the requirementSelected
TM 02Sum of transactionsAvailable
TM 03Abnormally high transactionAvailable
TM 04Inflow and outflow comparisonAvailable
Standard rules shown for Transaction Monitoring.
Rule Designer · from the standard ruleTM 01 · PEP transactions
Draft
IFclient.pep_status = PEP or PEP-related1
ANDany of:
payment.amount ≥ 20 0002
ORcount(payments, 10d4) > 53
ANDsum(amount, 10d4) ≥ 20 0002
THENraise alert
Only the values were set. Documented example values.
Staging · test cases for TM 014 of 4 behave as expected
Passed
Case 1PEP, one payment of 25 000Expected alertAlert
Case 2PEP, six payments, 21 400 in ten daysExpected alertAlert
Case 3PEP, 18 000 in ten daysExpected no alertNo alert
Case 4Non-PEP, one payment of 40 000Expected no alertNo alert
Example test cases. All data synthetic.
Rule package · TM 01Staging to production
Active
1Export from stagingAs one rule packageDone
2Import into productionWith the import and export utilityDone
3ActivateThe ruleset picks the rule upRunning
Deployment steps as documented for business rules.
Example policy wording and documented example values. Test cases synthetic.
Tested before it goes live
See what a rule will do before it touches production.
One rule change, from its test result to production. Every step is yours to drive: nothing goes live on its own.
Rules › Transaction Monitoring › Test casese.marti
No. Rules are created, changed and removed in the Rule Designer, with no coding. Your team builds each rule from conditions on fields your data already supplies.
Your team owns the rules and the dictionaries: every condition, threshold and list entry. Admin users decide who can edit them, for the whole Rule Designer or rule by rule. Prospero sets up the base model and the rulesets, and delivers any change to them as a patch.
Every change runs in a staging environment against test cases built for each rule, and every case has to pass. The tested rules then move to production as one package, so nothing is edited by hand in production.
Yes. Every version of a rule keeps its date and owner. If a change doesn’t behave as expected, an earlier version can be set active again.
No. Both run on the same core. Rules carry the policy you have already written, and the models reach activity no rule describes.
