Platform · 02 Detect
Catch the pattern. Not just the latest event.
A payment can look ordinary until you connect it to the account, the device and what happened before. SENTR combines configurable rules with customer-specific anomaly detection—so your team can inspect the risk, not just receive a number.
- Event-scoped rules and industry presets
- Customer-specific anomaly scoring
- Findings you can inspect and explain
The SENTR scoring engine
Evaluate every event. Keep every contribution inspectable.
Scoring is a core engine—not just a label attached to a rule match. SENTR evaluates events using the mapped signals and available context, including events where no rule fires.
Read the diagram
An illustrative event space sits beside selected rule contributions: device velocity adds 18 and a first-seen IP adds 12. These sample contributions are not the full score. Customer-model findings are evaluated separately; the radar shape does not imply a graph-learning model.
Know what changed the score
Inspect per-rule attribution: the matched check, severity and exact positive or negative score contribution. Direct-decision rules express a different effect from adding score; the workbench makes that choice explicit.
Keep independent findings separate
The customer model produces its own risk score and contributing signals once its data requirements are met. The model does not learn from rule outputs. Decision policies consume the relevant findings; generated prose explains them.
Open the complete custom-rule workbench → · Explore the customer model
The patterns you know. The activity you need to question.
Rules express known concerns. Anomaly detection adds a different question: how unusual is this activity for your business?
Current activity · history · linked accounts, devices, sessions, IPs and payment methods
01 / Configured controls
What matches your rules?
Global and industry presets, event-scoped conditions, lists and scoring profiles express the patterns and sensitivities your operation chooses.
Direct decisions where a rule specifies one
02 / Customer-specific model
What departs from your normal?
The anomaly model learns from suitable signals—not rule outputs. Once enough clean data is available, it can flag unusual behaviour even without a rule match.
Contributing signals and confidence
Next: apply your decision policy. Keep the two findings inspectable. Set the response and configured actions in the decision layer.
Inspect the policy controls →Mechanism illustration of rule and anomaly evaluation—not a claim that scores are simply added together. Additional AI scoring is also available. We agree the applicable scoring configuration, direct-rule interactions and policy controls for your deployment.
Inspect the finding
Open the score.
See what moved it.
The real product view shows a matched rule, its impact and its recorded contribution. Model findings have their own score breakdown; a rule match is not evidence that the model found the same thing.
AI turns relevant recorded findings into readable language. The underlying attribution stays available to inspect. The language model does not decide whether to approve or block.
Explore decision explanations →
Enlarge view The matched rule, its impact and the recorded reason—together on the event.
The explanation has something concrete behind it: the matched check and its contribution.
Make your knowledge operational.
Start with global and industry presets from a library of 300+ rules across event types. Refine the controls around the events, signals and risk appetite that matter to your business.
- Protect the business moment
- A registration, payment attempt, withdrawal or bonus claim can use different event-scoped checks. Custom event types extend the same approach to your own activity.
- Look beyond the current event
- Evaluate mapped fields alongside available history and linked entities. Repeated claims, instrument reuse and velocity checks depend on the context you actually supply.
- Choose the effect of a match
- Rules can add or subtract score, including decimal contributions, or return a direct decision. Lists have configurable influence; a match is not universally a block or an exemption.
- Adjust the right threshold
- Scoring profiles change numeric thresholds inside applicable rules. Decision policies separately determine when findings lead to review or block.
Customer-specific learning
Learn what normal means for your business.
An unusual pattern does not need an authored rule to deserve attention. The customer model learns from clean signals independently of rule outputs.
Learning and evaluation are different jobs.
- Establish the context. Supply sufficient suitable data and relevant history. The model does not start with a complete understanding of a new customer.
- Train on a schedule. Customer-model training runs overnight once its data requirements are met—not after every click or reviewer correction.
- Evaluate new activity. Inspect the separate model score and contributing signals alongside the rule findings.
- Review the outcomes. Validated judgements and corroborating evidence inform the feedback process; a human override is not automatically training truth.
Illustrative bonus-abuse pattern
One shared device is a clue. The wider pattern matters.
The question worth asking
Several accounts claim a promotion through the same device. Examine claim timing, prior activity and other available links. Repeated coordinated behaviour may justify review under the configured controls.
The alternative worth checking
A household may legitimately share a device or network. A connection alone is not proof of abuse. Inspect the evidence before treating every linked account as fraudulent.
Entity context supports detection. Connection Ring helps a person investigate the relationships; it is not a claim of a separate graph-learning model.
See the iGaming workflow → · Explore complex-fraud detection · Explore false-positive reduction
Clear about the AI. Clear about what comes next.
AI scoring and the AI rule builder are available alongside customer-specific anomaly detection and AI explanations. The ML pipeline and automatic feature engineering also support the platform. Sector and global model aggregation remain a separate availability question—not an assumed consequence of these capabilities.
That distinction matters: neither a roadmap nor an algorithm count proves better fraud outcomes. For a qualified SENTR.Citadel evaluation, free, read-only Shadow Mode lets you inspect findings alongside your current controls. It is optional—not a prerequisite for every customer.
ML pipeline & automatic feature engineering
Build the inputs behind the intelligence.
The ML pipeline and automatic feature engineering are available alongside the scoring engine. They support model learning and the development of input features—not just the final score shown on an event.
Automatic feature engineering develops signal variations for machine learning. Your data quality, available history and validation process still matter. We work through the applicable feature and training controls during technical discovery.
This is distinct from instant retraining after every override, autonomous policy publication or cross-customer model aggregation. Discuss the model and data workflow →
Keep the work connected
What happens next?
- What comes in
- The current event, available history and linked-entity signals.
- What moves forward
- Inspectable rule contributions and separate customer-model findings.
Next, decide what those findings should mean for your business.
Continue to DecideThe detection foundation is shared. SENTR.Citadel gives operators direct control of the workbench; SENTR.Tower uses guided presets and simpler configuration.
Compare the exact controls ↗Before you decide
The questions worth asking.
How do rules, machine learning and AI scoring work together?
SENTR combines configurable rules with customer-specific anomaly detection and additional AI scoring. Rule contributions and model signals remain inspectable rather than being described as one unexplained score. Confirm the score interactions, applicable settings and decision policies for your deployment.
Separate scoring from policy →Does SENTR learn from other customers automatically?
Customer-specific learning is available. Sector and global model tiers are also available where agreed for your deployment. Broader-data participation requires governance; it is not an automatic consequence of using SENTR.
Inspect current availability →Bring the pattern your current controls struggle with.
A missed attack, a noisy rule or activity that is hard to explain. We will work through the data, controls and evidence needed for a useful evaluation.