Technology
This page describes what the platform is responsible for and how it connects to the systems you already run. It does not describe our detection method — how signals are sequenced, combined and weighted is the part we build, and it stays with us.
Four areas of responsibility. Each is described by what it is accountable for and what it produces, which is what an evaluating institution needs — the internal design is covered under NDA, not on a public page.
Works with the systems you already run.
The platform is designed to read from existing core banking and payment infrastructure through a controlled interface, rather than to sit in the payment path or require anything to be replaced. What is shared is scoped to what detection requires, and agreed with the institution before anything is connected.
Turns events into something comparable.
Transaction records are normalised and set against the account's own history, so behaviour can be assessed in context rather than in isolation. How entities are resolved and features constructed is part of what we build, and is not described here.
Four independent readings of the same event.
Rules, machine learning, anomaly detection and graph analytics each evaluate the transaction. Independence is the point: a signal that survives four different methods is stronger than one that clears a single threshold. How they are sequenced, combined and weighted is our own work and is not published.
Where the decision is made and recorded.
Alerts reach fraud, risk and compliance teams in a workspace built for investigation — the risk position, the evidence behind it and a recommended action — under role-based access, with every action and model version retained as an audit record.
We would rather be clear about the boundary than be vague about everything.
How these are sequenced, combined and weighted is our own work, and is not published. What we do publish is the output — one risk position, the evidence behind it, and a person who decides.
Institutions evaluating the platform receive the technical depth their risk, audit and technology functions need to reach a decision, under agreement. Nothing about that process depends on us describing our method in public.
Where the platform runs is agreed with the institution before anything is connected, against its infrastructure, its data obligations and its internal controls.
Where each part runs is a deployment decision taken with the institution. This is not a claim that customer data leaves, or must remain within, any particular environment.
Detection runs inside the institution's own environment, with customer data remaining under its existing controls.
Dedicated infrastructure provisioned for a single institution, isolated from any shared tenancy.
A controlled interface between bank systems and the detection pipeline, scoped to the attributes detection requires.
Model development and validation supported centrally, with releases moving into the bank environment under institutional approval.
These are architectural options, not statements about where any institution’s data will reside. Data residency, retention and access are decided with the institution and its obligations.
The architecture exists to make one thing possible: an analyst reading an alert that already carries its own explanation.