Overview

The Lunixi fraud engine is a deterministic, rule- and flow-based decision layer. You send a transaction; the engine runs the flow you published and returns allow / force_3d / review / block together with the list of nodes that produced it.

In two sentences:

You design the decision. The engine runs the rules you publish — it is not a closed scoring box.
Every decision is explainable. Which flow, which node, which rule, which reason code — all of it comes back in the response.

The integration surface is a single call: the Decision API. You do not need our payment orchestrator — your own gateway, POS, or PSP connects to the same endpoint.

How a decision is produced

⚠️

An unconfigured merchant does NOT silently get allow. If no capability bundle, rule group, or flow resolves, the engine returns the configured default decision with code fraud.decision.unconfigured (default: review). "I haven't written rules yet" does not mean "there is no risk".

Resolution — the request is matched against published flows on merchantId · flowType · subjectType · integrationMode · productContext. Details and scope priority: Flows and Resolution.
Execution — the flow runs node by node from its start node. Branching uses if / switch nodes.
Decision — nodes propose decisions; the engine takes the most severe one. The canonical severity order is:
```
allow  <  force_3d  <  review  <  block
```
Once a node says block, a later node cannot pull it back down to allow. If a flow errors, the posture is fail-closed: the decision is raised to at least review, and an existing block is never downgraded.

Nodes you can use in a flow

This is where the engine's power sits. 39 node types run today:

Category	Nodes	What it gives you
Flow control	`start` · `stop` · `subflow` · `parallel` · `merge`	Entry and exit, calling a subflow, running branches concurrently and merging them
Rules and logic	`rule` · `if` · `switch` · `set-var` · `transform` · `safe-transform`	Condition evaluation, branching, intermediate variables
Velocity and patterns	`velocity-check` · `inter-arrival-check` · `event-count-check` · `distinct-count-check` · `history-aggregate-check`	Counts in a time window, gap between transactions, distinct counts, historical aggregates
Lists and screening	`blacklist-lookup` · `sanction-lookup` · `sanction-account-screen` · `sanction-transaction-screen` · `sanction-wallet-screen` · `sanction-indirect-exposure`	Blacklist and sanctions screening, including indirect exposure
Context fetching	`profile-lookup` · `payment-lookup` · `database-lookup` · `redis-get` · `redis-set` · `identity-snapshot-guard`	Customer profile, prior payments, your own database, counter state
External calls	`http-request` · `grpc-call` · `webhook` · `connector-event-source`	Synchronous or asynchronous calls to your services or a third party
Your own code	`script`	Publish your own JavaScript and run it inside the flow — in an isolated V8 context with time and memory ceilings
Control and operations	`idempotency-guard` · `rollout-gate` · `case-open` · `inline-limit-check` · `inline-limit-status` · `action`	Double-call protection, staged rollout, case creation, inline limits

database-lookup reads your database. You register a connection, then query it from inside a flow — so you can feed your own customer history into a fraud decision without shipping the data to us.

The response: decision plus reasoning

A decision call returns not just a label but the trace behind it:

Field	Contents
`decision`	`allow` · `force_3d` · `review` · `block`
`score`	Numeric risk score accumulated by the nodes
`code`	Decision code (e.g. `fraud.decision.unconfigured` for an unconfigured merchant)
`flowPath`	The ordered nodes traversed to reach the decision
`matchedRules` · `matchedRuleGroups`	Names of the rules and groups that matched
`reasonCodes`	Machine-readable reason codes
`tags`	Tags attached by the flow
`actions`	Runtime actions the engine recommends
`explainability`	`summary`, group results, flow explanation

Field-by-field contract with request and response examples: Decision API.

What we do not do

⚠️

The decision endpoint is deterministic. The result of POST /api/v1/fraud/decisions/evaluate is derived from the rules and flow nodes you author — not from a model's probability output. That is a deliberate choice: on a regulated decision path, you must be able to show which rule produced each outcome.

score is not a model's probability output; it is the numeric weight accumulated by nodes.
A separate machine-learning platform does exist (model registry, governance, invocation observability and transaction scoring). Today it is used from the panel surface — to inspect model behaviour and try scenarios. It does not automatically join the decision endpoint's flow; what runs on the decision path is the flow you published.
AI-assisted flow drafting: you describe a policy in text and the system produces a starting flow. You review and publish the draft.
We do not collect behavioural telemetry for you. You measure it and send it on the decision call. See Behavioural Risk Signals.

Where to start

Decision API — the single endpoint, field contract, authentication.
Flows and Resolution — publishing flows, scope priority, which request lands on which flow.
Behavioural Risk Signals — the telemetry field and the silent-drop rule.

Payment Fraud Prevention