How privacy-preserving fraud detection works inside TrustGraph

TrustGraph is the first biometric-anchored, privacy-preserving trust network built for the agentic era. It enables institutions to detect repeat fraud and agentic fraud, and to recognize legitimate customers, with signals from across the network, without pooling, exchanging, or exposing customer data. With TrustGraph, when an institution reports fraud, the network can surface a signal if the same face, document, or device appears again at another participating institution. Critically, customer data stays with the institution that holds it.

In this post, I’ll explain how we accomplished this. You will learn what TrustGraph checks on each session, what early access results have shown, how secure multi-party computation keeps customer data private, and how to turn it on in your existing Incode flow.

Why per-session identity checks miss repeat fraud

Per-session identity checks cannot see repeat fraud. Document authenticity, liveness, face match, and government validation all answer one question: does this session look genuine? They cannot answer a second question that matters just as much: has this person, document, or device appeared before during a fraudulent session?

Generative AI has widened that gap, and agentic fraud has made it incredibly costly. Modern fraud is increasingly executed by AI agents end-to-end: they build synthetic identities, forge documents, and retry after every rejection, all across hundreds of companies at once. A fraudster who fails at one institution moves to the next with the same face and a fresh synthetic document. Nothing in a single session carries the history, so the same operator works down a list of banks unchallenged.

Institutions have known about this blind spot, and the obvious fix is to share what each one sees. Yet cross-institution fraud data has stayed locked up for one reason: companies cannot share customer data with each other.

TrustGraph is built to address that issue.

Six signals TrustGraph returns

For every session, TrustGraph returns an explainable signal in each of six categories:

1. Suspected repeat fraudster: Checks the session against Incode's Suspected Fraud List, which Incode builds from historical sessions where fraud was suspected, such as liveness attacks, document tampering, and failed government validation. This check surfaces repeat fraud signals when the same person reappears, even when the previous activity occurred in another session.
2. First-party fraud: Checks for identities associated with fraud reported after verification, including rewards and promotion abuse, account selling, and mule activity. This extends TrustGraph beyond fraud detected at onboarding to activity that may only become known later.
3. Unusual activity: Compares sessions to surface inconsistencies associated with possible fraud, such as one document number linked to several faces, one face presenting several documents, or one device associated with conflicting names. These patterns can help identify synthetic identities and other suspicious activity that may look legitimate in isolation.
4. Velocity and excessiveness: Measures how often the same face, document, or device appears across distinct sessions within a defined time window. This check surfaces patterns associated with activity such as mass account creation and promotion abuse that may look unremarkable one session at a time. Time windows and thresholds are configurable per organization.
5. Fraud ring risk: Links related session attributes within your own data into connected clusters, so investigators can see relationships among sessions that may appear legitimate when viewed individually.
6. Approval boost: Recognizes customers who have successfully verified at other participating institutions and returns a positive trust signal that can lower risk and reduce unnecessary friction. Fraud signals take precedence over trust signals.

Shared or in-branch devices can be whitelisted so they don't trigger device-based checks.

Every category returns a reason code, so an analyst can see what matched and why. TrustGraph includes reason codes across all six signal categories at launch.

TrustGraph adds to your existing identity stack. Document authenticity, liveness, face match, and government validation keep running as they do today. TrustGraph simply adds the context that a single session can never provide on its own.

How Fraud Rings Explorer speeds up fraud ring investigations

Organized fraud causes the largest losses, and it is the hardest thing to see one case at a time. In the Association of Certified Fraud Examiners’ (ACFE) study of workplace fraud, schemes with three or more perpetrators had median losses more than 4x higher than schemes with one. Operators can run dozens or hundreds of applications, each with a real-looking document, a live person on camera, and a working device. Nothing about any single application looks wrong.

But the pattern connecting them gives the operator away: the same device opens many accounts, the same face appears on different documents, and the same template returns under new names. A single-session check cannot see this pattern.

Fraud Rings Explorer within TrustGraph makes that pattern visible within your own data by connecting signals that every verification event already captures. It surfaces suspected rings automatically, so an investigator starts with the network already assembled and skips the manual build. It also lets an analyst act on a confirmed ring's shared infrastructure in one step instead of closing cases one by one.

For many pilot customers, Fraud Rings Explorer shortens investigation timeline from one hour to under five minutes.

Up to 53% more fraud detected in early access

In Incode's early access program, institutions using TrustGraph detected up to 53% more fraud than with their existing models alone.

How secure multi-party computation protects customer data

TrustGraph checks de-identified signals across the network. Customer data stays with the institution that holds it. TrustGraph uses privacy-preserving cryptography to match signals across participating institutions without a central repository. It runs on secure multi-party computation (SMPC): a method that lets several parties compute a joint answer while none of them reveals its inputs.

TrustGraph runs on patented peer-to-peer cryptographic technology, the product of more than a decade of research conducted by Incode and Identiq, a pioneer in cryptographic peer-to-peer identity validation. Incode acquired Identiq in June 2026.

Four privacy protections apply to every query:

• The end user's identity stays protected: TrustGraph de-identifies identifiers before they enter any joint computation, so matching happens on cryptographic shares rather than raw customer data.
• The asking institution stays private: Other participants cannot identify which institution submitted the query.
• The contributing institution stays private. When you receive an answer, you cannot tell who contributed to it.
• Contributing participants do not see the outcome: A participant that helps process a request does not see the result, or whether its own data matched.

Each query uses fresh, one-time cryptographic values, so the same identifier produces a different query each time. This helps prevent any observer, including Incode, from linking queries together.

Add TrustGraph to your existing flow without an integration project

For existing Incode customers, enabling TrustGraph takes a configuration change and no integration project. Incode provisions your tenant, you add the TrustGraph module to a verification flow, and it runs on every session in that flow. Your code and your user journey stay as they are.

A session's outcome changes only when you write rules, and you set enforcement per category. You can fail a session on suspected repeat fraudster, route unusual activity to manual review, or leave a third category in observe mode. Signals arrive inside the standard score response, with per-session detail available for explainability and queue routing.

Then you close the loop. Report confirmed fraud from the dashboard or through the API. TrustGraph de-identifies the contribution and does not reveal your institution as the source, and the signals you receive back sharpen as a result. Reciprocity helps the network improve: the more accurate the fraud that participants report, the more precise the signals everyone gets.

How positive signals can help reduce friction for legitimate customers

TrustGraph also recognizes customers who have successfully verified elsewhere with an approval boost, a positive trust signal that can lower risk and help institutions accept more legitimate customers. Fraud signals take precedence over trust signals, and the institution stays in control of the decision. The result is the other side of network intelligence: recognizing legitimate customers while detecting repeat fraud.

What TrustGraph changes for cross-institution fraud detection

TrustGraph adds the context that single-session verification cannot provide: signals from across participating institutions that help detect repeat fraud and recognize legitimate customers, without pooling, exchanging, or exposing customer data.

The result is a more complete view of risk, while the institution remains in control of every decision.

Ready to see how TrustGraph fits into your existing verification flow? Request a demo today.