ML Models
AntifraudAI’s ML models are trained on fraud patterns observed across the entire platform — spanning industries, geographies, and fraud typologies. This shared learning means that even a brand-new AntifraudAI customer benefits from fraud signal accumulated across the network. Key characteristics of the ML layer:- Continuously updated. Models retrain automatically as new labeled fraud data arrives, keeping detection current against evolving attack patterns.
- Multi-signal. Each model ingests dozens of enriched signals — device, behavioral, network, and transactional — rather than relying on any single indicator.
- Transparent outputs. The model’s contribution to the score is surfaced through the
signalsarray in the API response, so you can always see which indicators drove a given result. - Not directly configurable. Customers do not control model weights or feature engineering. This is intentional: shared model integrity is what makes the platform-wide learning valuable.
Rules
Rules are customer-defined logical conditions evaluated after ML scoring. Each rule consists of a condition (what to match) and an action (what to do when matched). Rules give you four types of control:- Score adjustment — Increase or decrease the ML score by a fixed number of points. Use this to amplify or dampen the model’s assessment for cases your business understands well.
- Forced decision — Override the score entirely and force an
allow,review, orblockdecision. Useful when the answer is categorical: you always block a specific country, or you always allow a verified internal service account. - Attribute blocking — Deny specific IP addresses, IP ranges, countries, user IDs, card BINs, or device fingerprints that you know are malicious.
- Trusted allowlisting — Exempt VIP users, internal test accounts, or partner integrations from standard screening so they never trigger false positives.
Rule Priority
Rules are evaluated in priority order: the list is processed top-to-bottom, and the first rule whose condition matches wins. Subsequent rules are not evaluated for that event. This means rule ordering matters significantly:- Rules at the top of the list act as hard overrides — if a rule matches, the pipeline stops.
- Rules lower in the list are only reached if no earlier rule matched.
- A catch-all rule at the bottom of the list (condition:
always) acts as a default fallback.
priority field via the API.
Rule Syntax
Rules are expressed as JSON objects with acondition block and an action block. Here is an example rule that blocks traffic from high-risk countries:
eq (equals), neq (not equals), in (list membership), gt (greater than), lt (less than), contains, and regex.

