How it works

A mirrored stream in. Intelligence out. The institution keeps the controls.

Cenvoriq sits beside the payment path, not in it. Nothing in the current release can hold, block or release a payment.

The pipeline, step by step

01

Financial system

A bank, payment service provider, fintech, telecom wallet or remittance provider keeps processing payments exactly as it does today.

02

Mirrored event stream

The institution pushes tokenised lifecycle events (created, authorised, settled, failed, reversed) over a signed API. Identifiers are pseudonymised by the institution with a key it keeps; Cenvoriq never asks for it.

03

Cenvoriq intelligence layer

The Sentinel Engine scores each event on separate dimensions. IntegrationGuard judges the API client that initiated it. TrustGraph places the parties in the relationship graph. ControlGraph detectors watch privileged actions the institution chooses to feed.

04

Dimensions, graph signals, evidence

Each decision carries its dimensions, reason codes, recommendation and graph context, and is appended to the Evidence Mirror: a hash-chained, signed, verifiable record of what the engine saw and said.

05

Analysts

Cases, candidate investigation clusters, forward traces to cash-out points and tokenised neighbourhoods reach the institution's fraud analysts through the API and reports. Changes to rules, modes and policies need two people.

06

Institution-controlled response

The institution decides what to do. In SHADOW the applied action is always allow, and only the institution's own systems ever hold, block or release a payment.

01 · Event sourcesWhat the institution mirrors
TransactionsIntegrationsAccountsDevicesAgentsMerchantsControlsLabels
02 · Cenvoriq intelligence layerWhat runs
Sentinel EngineIntegrationGuardTrustGraphControlGraphRecipient IntelligenceMule IntelligenceEvidence Mirror
03 · IntelligenceWhat comes back
Risk dimensionsReason codesNetwork signalsIntegration statusRecipient and mule scoresCandidate clustersCasesEvidence
04 · Institution responseWho decides
AnalystsCases and reviewsFour-eyes approvalsInstitution-controlled actionResponseNet (planned)

SHADOW mode

What a SHADOW pilot is

During a SHADOW pilot, transactions continue normally. Cenvoriq receives a mirrored event stream, produces intelligence and recommendations, and allows the institution to measure its value without giving Cenvoriq authority over payment execution.

The engine returns the recommendation it would have made alongside the action it actually applied, which in SHADOW is always allow. The institution compares recommendations against the outcomes it later learns, at the times it learned them, and decides for itself whether the intelligence is worth acting on.

SHADOW MODE observing
Payment authorityNONE
Transaction impactNONE
IntelligenceACTIVE
Evidence recordRECORDING
Recommended · appliedSTEP_UP · ALLOW
event stream · syn_wallet_alice · 14 transfers in 5 minsynthetic
  1. #09transfer to first-time recipient · RAPID_RECIPIENT_DISPERSAL · risk 53STEP_UP
  2. #10transfer to first-time recipient · RAPID_RECIPIENT_DISPERSAL · risk 55STEP_UP
  3. #11transfer to first-time recipient · RAPID_RECIPIENT_DISPERSAL · risk 57STEP_UP
  4. #12transfer to first-time recipient · RAPID_RECIPIENT_DISPERSAL · risk 57STEP_UP
  5. #13transfer to first-time recipient · RAPID_RECIPIENT_DISPERSAL · risk 57STEP_UP
  6. #14transfer to first-time recipient · RAPID_RECIPIENT_DISPERSAL · risk 57STEP_UP
first recommendation above monitor: transfer 92 connected to a confirmed case
01

Historical replay

Your historical tokenised events and labels
Cenvoriq replay engine, label-leakage guard
Measured signal quality and detection: precision, recall, alert rate, lead time, candidate clusters
exit replay engine and data deleted; you keep the report
02

Live SHADOW

Mirrored live event stream over a signed API
Cenvoriq intelligence layer in SHADOW
Recommendations, dimensions, graph signals and a verifiable evidence record for your analysts
while payments continue normally: no hold, block, delay, approval or modification

What a partner brings

Tokenised events, not customer data

  • Tokenised identifiers derived with a key the partner keeps
  • Lifecycle state, timestamp with time zone, amount, currency, rail, channel and assurance levels as categories
  • Optional tokens for device, API client, agent and merchant
  • For evaluation, fraud and non-fraud labels with the time each was learned

Names, phone numbers, national identifiers, account numbers, addresses, dates of birth, PINs, passwords, one-time passcodes and the tokenisation key are never requested and are refused by the import gate. The full boundary is on the security page.

Deliberately not automated

Guard rails that stay manual

  • Any change to a ruleset, decision mode or integration policy needs a second approver
  • Baselines are judged only on history at least 24 hours old, so activity cannot make itself normal while it is happening
  • Large hubs in the graph are never walked through; a busy agent or a popular merchant does not make its neighbours suspicious
  • No machine-learned model is deployed; a challenger would run in shadow and be promoted only if it beats rules on the institution’s own replay
Design-partner programSynthetic demo