Every Nexiel Screen customer can configure their own supplementary rules on top of the core matching engine's classification, from the dashboard at /policies. A rule can tag or escalate a decision for your own review workflow. It cannot clear, downgrade, or otherwise weaken a POSSIBLE_MATCH or CONFIRMED_MATCH result the core engine already produced. That is not a UI restriction. It is enforced in the data model and the evaluation code itself, and this page explains exactly how.
This is a dashboard feature today, not a public API endpoint. There is no POST /v1/policy-rules route in the Screen API yet. Programmatic access is on our roadmap. Contact us if you need it sooner.
Nexiel's own platform rule is unambiguous: never auto-clear a POSSIBLE_MATCHresult, and always require human review. The EU AI Act's human-in-the-loop requirement for AI-assisted decisions applies the same way. A configurable rule builder could otherwise become a way to soften that guarantee, deliberately or not. Nexiel's answer is to make it structurally impossible rather than policy-dependent:
CLEAR result to POSSIBLE_MATCH, forcing the review it did not previously require). There is no third action type. There has never been a clear or downgrade action in the underlying type system for any rule builder to expose, so the dashboard cannot offer one and a direct API call could not construct one either.These are the same three layers Nexiel's own platform-wide rules run through. Your rule and Nexiel's platform-wide rules share the same evaluation and safety code.
A rule you configure is scoped to your account from the moment it is created. Backtesting and Shadow evaluation only ever read your own historical screening decisions, never another customer's, even when another customer's decision would obviously match your rule's conditions. You cannot view, edit, or run another customer's rule, and a rule id that belongs to a different account behaves exactly like one that does not exist.
A new rule starts as a Draft. Before it can run against real, ongoing decisions, you run a backtest against your own historical screening decisions, so you can see exactly how often it would have matched and what it would have done, using real historical numbers rather than a fabricated or extrapolated estimate. Once backtested, a rule can move to Shadow: it is evaluated against your real decisions and the outcome it would produce is recorded for you to review, but it never changes an actual classification or API response.
Promoting a rule to influence a live decision is on our roadmap. Every rule lands at Shadow at most today. If a live-influencing tier ships, that will be a deliberate, explicitly announced change.
The same fields Nexiel's own reviewers use: the decision's classification, wallet-screening classification, highest candidate score, candidate count, whether any candidate is a PEP, whether human review was required, which matching layers fired, which entity types and list sources appeared, and the matching engine version. Every field genuinely persists in Nexiel's audit log, so a backtest against it reflects real data.