Platform

A decision service for fraud prevention, built to be audited

Rules you can read, decisions that explain themselves, and a record that proves it was never changed. Omnareth runs beside your systems and answers in milliseconds.

Decision model

Event in. Decision out. Reasons attached.

Each event names the entity it concerns: a shipment, a vendor, any record you define. Omnareth evaluates it against that entity's current state, its fraud context and every applicable rule, deterministically: the same inputs always give the same decision.

Any rule denies	DENY the action is blocked
Any rule flags	FLAG allowed, with reasons for review
Nothing fires	ALLOW proceed

Every decision lists each rule evaluated, which fired, its code, severity, message and remediation step.

Rule language

// Deny a handoff whose seal is not the seal applied at origin
{
  "name": "Seal Number Mismatch at Handoff",
  "appliesToEntityType": "Shipment",
  "appliesToEventType": "CUSTODY_HANDOFF",
  "severity": "CRITICAL",
  "condition": {
    "type": "compare",
    "field": "handoff.sealNumber",
    "operator": "!=",
    "valueField": "entity.sealNumber"
  },
  "consequence": {
    "decision": "DENY",
    "code": "SEAL_MISMATCH",
    "remediation": "Hold the container and request an inspection"
  }
}

Conditions combine and, or and not with 15 operators. A comparison can target another field, so what is presented now is checked against what was recorded: the seal at the gate against the seal at origin, the bank account on a payment against the verified one.

Capabilities

What the platform does

Any entity

Your process, your model

Define any entity type with a JSON Schema (a shipment with its seal, vessel and bill of lading, a vendor with its verified accounts) and every write is validated against it.

Rules

Rules you can read

Explicit JSON conditions with a decision, code, message and remediation. Versioned, with draft, active and retired states.

Fail-closed

Missing data means no

Authorization rules deny when a list or field is missing, so a release cannot pass because data was never loaded.

Fraud memory

Recognizes who comes back

Declare which fields identify people, accounts and references; Omnareth tracks them across entities, opens cases on repeat patterns and enforces your watchlist. More

Evidence

Sealed audit records

Entity, event, ruleset and fraud-context snapshots under a SHA-256 hash over canonical JSON, anchored with the decision in a block.

Verification

Proof on demand

One call recomputes a decision's hash and compares it, the decision and its status with the anchored copy.

Integration

One REST API

Your systems send events and act on decisions. When an action is allowed, your system of record updates the entity (a shipment's custodian, a vendor's verified accounts); refused attempts never change it.

Node.js services with PostgreSQL
Docker Compose configuration for the full stack
Optional on-disk persistence for ledger blocks

Endpoint	Purpose
POST /v1/entity-types	Register an entity type (e.g. Shipment, Vendor), its JSON Schema and its fraud identifiers
POST /v1/entities	Create a record: a shipment, a vendor, any entity
GET · PUT /v1/entities/:id	Read or update its state (custodian, holds, verified accounts…)
POST /v1/rules	Create a rule; rules are versioned
POST /v1/events/process	Evaluate an event and return the decision, audit id and anchor receipt
GET /v1/decisions?entityId=…	History: every decision for a shipment, vendor or other entity
GET /v1/decisions/:id	Decision detail with every rule evaluation and its reason
GET /v1/audits/:id	Audit record: entity, event and ruleset snapshots plus integrity hash
GET /v1/audits/:id/verify	Recompute the hash and compare it with the on-chain anchor
GET /v1/fraud/cases	Fraud cases by status and pattern (analyst or admin)
GET · PATCH /v1/fraud/cases/:id	A case with every signal behind it; confirm fraud or mark a false positive
GET · POST · PATCH /v1/fraud/watchlist	Block or watch any identity: a driver, vessel, bank account, domain…

Performance

Fast enough for the moment of decision

Checks only help where the decision is made: at the gate, at the berth, before the payment run. Rule evaluation takes microseconds; a full fraud-checked decision, stored with its audit record, takes milliseconds.

Measurement	Median	p95	p99
Rule evaluation, 34 rules	22 µs	38 µs	71 µs
Decision via API, fraud-checked, stored and audited	75 ms	93 ms	117 ms
The same, waiting for the PACT commit before answering	531 ms	685 ms	687 ms

Measured on 4 vCPU Intel Xeon @ 2.1 GHz, Node.js 22, PostgreSQL 16 and a four-validator PACT network on the same host, production settings (sign-in, field encryption). Rule evaluation sustains ~46,000 decisions per second on one core. One client sending requests in sequence. By default the answer returns before the record commits on PACT; it commits about 0.4 s later at the median. With 8 to 32 concurrent clients, one service process handled 30 to 44 decisions per second.

Pilot program

Prove it on your own operation in 90 days

One lane, facility or process, in shadow mode, with results measured against criteria we agree with you. Qualified companies and organizations can apply.

Apply for the pilot