Questions, answered plainly

It checks each high-risk action (a cargo release, a bank-detail change, a claim payout, a sign-in, an onboarding) before your system carries it out. It checks the action against the record it affects, your rules and its memory of who has been refused before, answers ALLOW, ALLOW_WITH_FLAGS or DENY with the reasons, and seals the decision so it can be proven later.

No. Decisions come from explicit rules you can read, version and change. Scores from other systems, such as a face-match score from your identity verification provider, can be inputs to those rules.

11 reference solutions ship today: cargo by road, cargo by sea, payments, insurance claims, e-commerce refunds, lending, healthcare claims, telecom, government benefits, cybersecurity, identity verification. Any approval process can be modeled the same way: define the record, the events and the fields that identify people, devices, accounts and documents.

Each record type declares which event fields identify whom. Omnareth remembers identities implicated in refusals, opens a case when one value appears behind refusals on several records or when a single-use value (a document, a session token, a police report) turns up on a second one, and refuses identities an analyst has confirmed. Only the identities a rule names are held responsible; the genuine customer named in a fraud attempt is not.

Through a JSON REST API: one call per action, before the action happens. Your system mirrors the records it wants checked and acts on the answer. The integration guide shows a real request and response.

In our measurements, a fraud-checked, stored and audited decision took 75 ms at the median and 93 ms at the 95th percentile through the API. Rule evaluation alone takes 22 µs at the median for 34 cargo rules. 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).

It depends on how the rule is written. A rule written as a requirement ("the password must be valid", "the account must be verified for this vendor") fails when the field is missing, so the action is refused. A rule written as a prohibition ("deny if the document is expired") only fires when the field says so. Write the checks that must never be skipped as requirements; the reference sets do this for authorization checks.

Yes. Every change creates a new rule version, each decision records the exact version it used, and a rule that has made decisions can be deactivated but not deleted.

As Node.js services with PostgreSQL, plus the Omnareth chain for anchoring, with a Docker Compose file for the full stack.

The record as it stood, the event as received, every rule evaluated with its exact version, and the fraud context computed for each identity in the event. The audit record is sealed with a SHA-256 hash, and the hash is anchored in a block.

They can change the row, but verification reports it: the record no longer matches its own hash or the anchored copy. In our tests, all 3 kinds of direct database edit were detected. How tamper evidence works.

It is the consensus methodology of PACT Protocol, the blockchain consensus technology developed by Habify Labs that powers Omnareth. The Omnareth chain uses it to establish accepted records: every decision's integrity hash is recorded on the chain, and verification compares the record with that copy. The technology behind Omnareth.

No. The Omnareth chain uses PACT Protocol consensus, holds hashes rather than your data, and involves no cryptocurrency. Anchoring proves the decision database was not edited after the fact; to hold up against the operator itself, include independent parties in the network.

No. Watchlists and fraud history stay in your deployment and cover the records Omnareth sees there.

Every reference scenario ends with one: an insider edits the record so the fraudster passes every rule. A confirmed fraudster is still refused on the watchlist, and the audit record shows the block Omnareth acted on.

90 days on one lane, facility or process: discover & model (days 1–15), connect (days 16–30), shadow run (days 31–75), review & decide (days 76–90). During the shadow run, decisions are recorded but not enforced, so your operation carries on unchanged.

Yes. 11 reference scenarios run end to end with one command each, 100 decisions in all, every one checked against its expected outcome and verified on chain. Run them.

Organizations with a process exposed to fraud and the event data to run it through Omnareth. Eligibility and the application form.