One engine under every decision that moves money.
Nyx, our decision platform, takes your data in and returns an explained verdict. Every model and rule is governed in one place, on open standards, so nothing locks you in.
Six building blocks. Every decision reuses them.
A pack declares the entities, features, models, policies, outcomes and actions a domain needs, so a second domain is configuration rather than a second procurement. See what each pack decides →
dec_EXAMPLE…Agent rails enter the same way: UCP, ACP, AP2, Visa TAP, Mastercard Agent Pay and RFC 9421 signatures, and NPCI’s Unified Agent Protocol once it clears RBI approval, each behind an adapter that never touches the decision core. The first adapter is built with the first design partner.
One decision, whoever starts the payment.
Three ways a payment starts, three kinds of institution that ask, one call to Nyx, and what comes back.
- 1VerifyIN BUILD
The signature the rail presents, and the mandate’s scope, caps and expiry.
- 2Know whoIN BUILD
Binds the agent or mandate to the person behind it.
- 3DecidePILOT READY
Your lists and rules, live behavior and risk models.
- 4AnswerPILOT READY
Inside a deadline you set; a miss returns your fallback.
A person paying goes straight to step 3. Pilot ready: built, and can go into a pilot on your data. In build: being written now with design partners. Partner-led: engine primitives in place, scoped with the first partner who needs it. Nyx is pre-launch; nothing here is a production result.
Heavy AI work never blocks the decision.
One POST call in your transaction flow. A deep-triage agent investigates beside it, never in the authorization path.
One call, a verdict with its reasons.
The response carries the action, score, severity band, the rules that fired and the audit reference. The evidence record the reference points to is in build.
Assembled before an analyst opens the case.
Related cases, device history and ring checks, recommendation-only today and shadow-tested before it ever enforces.
A hard timeout budget and a fallback verdict when it is breached. Fail-open or fail-closed is your policy, set in configuration, not ours.
<100ms† is a design target for the authorization path, validated on your traffic including tail latency. Not an average over a demo.
Deployment footprint, HA and recovery posture and the managed-update model are in the due-diligence pack, on request, before any pilot.
† Design target to validate in the first pilot, not yet independently benchmarked.
Autonomy you set, one rung at a time.
- ShadowRuns on live traffic and acts on nothing. You compare its calls to your team’s.Acts on nothing
- RecommendProposes the action with its evidence. A person decides.A person decides
- ContainReversible actions inside your guardrails: caps, rate limits, auto-pause. Each one opens a human review.Reversible, reviewed
- AutonomousActs within your caps, still bounded to reversible actions. Anything irreversible or adverse stays human.Within your caps
Every action is ledgered and any level rolls back in one click. The synchronous verdict stays in the engine; these agents never enter the authorization path. Designed for automated-decision rules (EU AI Act; GDPR Article 22). The agent path is in build, recommendation-only and shadow-tested today, and the higher rungs are the designed model, to be proven with design partners.
Three ways to run it. One codebase.
The engine, the API, the packs and the evidence record are identical in all three. What changes is who operates the infrastructure and where the data sits.
In every model, models train on your data only, data stays in-country, the decision log stays queryable by you, and the exit path is documented before a pilot starts. Footprint, HA and recovery posture per model are in the due-diligence pack.
Governed AI is the platform, not a feature.
Every AI call, every identity and every decision leaves a trail an examiner can follow.
The evidence record is schema-versioned from day one. SAMA CFF and CBUAE 3057 control mappings are already written; other regimes are mapped with the first partner there.
We hold the code that makes your decisions to the posture we ask you to hold us to for the decisions themselves. Nyx is built with NOX, our own development harness: one ticket in, one reviewed pull request out, with scope planned up front, review and security gates that cannot be skipped, and a recorded trail for every change. NOX is in private beta in the NaxVerse tools library.
Open the NaxVerse tools library ↗What an evaluator asks first.
The architecture answers, without the walkthrough.
How does Nyx sit in the transaction flow?
As one synchronous POST in the authorization path, with a hard timeout budget and a fallback verdict you configure as fail-open or fail-closed. The response carries the action, the score, the severity band, the policies and rules that fired, the model version and an audit reference. Scoring under 100ms is a design target to validate on your own traffic in a pilot, not a benchmarked result.
Where can it run?
Three deployment models on the same codebase and the same API: Nyx-hosted and managed by NaxVerse in the region you choose, inside your own AWS, Azure or GCP account and VPC, or in your data center. Data stays in-country in every model.
What happens to our data?
Models train on your data only. No deployment model requires bulk extraction into a shared black box, the decision log stays queryable by you, and the exit path is documented before a pilot starts.
How do the agent payment protocols get in?
Behind adapters. UCP, ACP, AP2, Visa Trusted Agent Protocol, Mastercard Agent Pay, RFC 9421 signatures and NPCI's Unified Agent Protocol, once it clears RBI approval, normalize into the canonical schema and never touch the decision core. The first adapter is built with the first design partner and the rest follow its contract.
What is it built on?
Open standards end to end: PostgreSQL, Redis, Kafka, Spark, MLflow, KServe, Keycloak and OpenTelemetry, with RBAC and enterprise SSO over OIDC. Models, features and data stay portable.