Fraud decisions that
explain themselves.
The Zarelva Signal Engine is a deterministic decision layer: real-time signals in, an action out — with the triggered signals, the named fraud pattern, and an investigator-ready narrative attached to every decision. Built to hand off cleanly to ZIC for investigation.
Evidence in. Defensible action out.
Most fraud stacks go data → model → score. The Signal Engine goes evidence → signals → rules → decision → investigation → audit trail — because that is how fraud teams actually have to defend their decisions.
ZSIG — Collect
Device, network, behavioral, authentication, account, linkage, and transaction context, computed into a clean signal taxonomy.
ZAIS — Decide
Deterministic rule packs evaluate the fired signals and return one of five actions: approve, step-up, review, cooldown, or block.
ZIC — Investigate
High-risk decisions become analyst-ready cases in the ZIC Investigator Canvas, with linked entities and evidence context attached.
Signals organised the way fraud actually happens.
34 deterministic signals across seven domains — each with a code, a weight, and the event types that can fire it. No black boxes, no embeddings, no unexplainable features.
DEV · Device
Emulators, hooking frameworks (Frida/Xposed), remote-control apps, headless browsers, fingerprint drift.
NET · Network
Datacenter ASNs, proxy/VPN/Tor exits, impossible travel, IP reuse and ASN concentration.
BEH · Behavior
Scripted navigation, rushed movement to sensitive actions, interaction entropy, baseline deviation.
AUTH · Authentication
Failed-login bursts, reset-then-login-on-new-device patterns, MFA and recovery changes.
ACC · Account
Payout rail changes, beneficiary additions, and profile changes that precede cash-out.
LNK · Linkage
Devices tied to many accounts, shared payout clusters, shared infrastructure, graph centrality.
TXN · Transaction
Withdrawal velocity spikes, sudden balance drains, time-to-cashout, unusual post-login actions.
Every decision arrives with its reasoning attached.
A decision is not a number. The engine returns the action, the risk score, the exact signals that fired with their evidence, the named fraud pattern that matched, a plain-language narrative, and the recommended next steps — ready for an analyst, an auditor, or a regulator.
{
"action": "block",
"risk_score": 66.6,
"triggered_signals": [
{ "code": "DEV.EMULATOR_DETECTED", "weight": 0.85, "evidence": { ... } },
{ "code": "DEV.HOOKING_FRAMEWORK", "weight": 0.88, "evidence": { ... } }
],
"top_reasons": [
"DEV.EMULATOR_DETECTED: Emulator / VM detected",
"DEV.HOOKING_FRAMEWORK: Hooking / instrumentation framework detected"
],
"narrative": "Emulator + hooking framework detected on device
attempting sensitive action.",
"recommended_next": [ "Immediately block transaction / session", ... ]
}Explainability is contract-tested, not promised.
The engine ships with 17 behavioral contract tests that lock its guarantees in place. If a change would break any of these, the build fails.
Explanations never contradict decisions
Property-tested across the full signal grid: a block can never carry a “nothing fired” narrative, and an approve can never claim a fraud pattern.
Support events are never fraud by default
A plain password reset — the most common legitimate support event — is contractually guaranteed never to fire the ATO pattern on its own.
No dead rules
Static reachability analysis fails the build if any rule pack references a signal that cannot fire, or sets a threshold its own signals cannot reach.
A working MVP — with honest boundaries.
We would rather you trust the engine than be dazzled by it. Here is exactly where it stands.
- What is real. The decision layer, rule packs, explainability contract, FastAPI surface, lightweight graph linkage, behavioral profiles, and analyst feedback endpoints run as shown — suitable for demos, internal validation, and pilot conversations.
- What is next. The production ZSIG collector (computing signals from raw device and network telemetry), full graph engine, tenant isolation, and model-assisted scoring on top of the deterministic base arrive in Phases 2–3.
- Deliberate ordering. Deterministic before ML. A model you cannot explain to a regulator is a liability, not a feature — ML layers on top of an auditable base, not instead of one.
- Not yet production traffic. This build is not hardened for high-volume production loads. Pilots are scoped accordingly.
Toggle the signals.
Watch the decision explain itself.
The demo runs in your browser as a deterministic simulation of the v0.9.3 rule semantics. Fire an emulator with a hooking framework, or a password reset from a new device, and read exactly why the engine acted.
Launch the Live Demo →- Deterministic, explainable decisioning
- 34 signals · 7 categories · 7 rule packs
- Five graded actions, approve to block
- Investigator-ready narratives
- 17 behavioral contract tests
- FastAPI surface, versioned responses
- Native handoff to ZIC investigation
- Built by an independent fraud practice