DocumentationAPI Reference
Features and modules, Feature Deep Dive

TrustGraph

TrustGraph is Incode's privacy-preserving trust network for helping institutions detect repeat fraud and giving them real-time signals to boost conversion. It is a layered set of categories, each analyzing a different fraud vector, and it runs in real time during session execution.

TrustGraph sits on top of your per-session identity stack to add context that a single session can never see on its own. Document authenticity, liveness, face match, and government validation checks answer whether a single session looks genuine; TrustGraph answers a different question: have these data attributes shown up before, in your own history or across the network, in a way you should worry about?

How it works

Steps 1 through 3 happen automatically and in real time whenever TrustGraph is enabled on a flow. Step 4 is the investigation and feedback loop that compounds the product's value over time.

Step 1: Verify. A user completes an identity verification in your Incode-powered flow: onboarding, authentication, or any other journey.

Step 2: Query the network. Incode normalizes and de-identifies the relevant identifiers (for example face, face on ID, device hash, document number, personal number, voter number) and checks them against TrustGraph, for the categories you enabled on that flow and with the thresholds you configured.

Step 3: Return signals. TrustGraph returns a per-category signal, an overall status, and an explainable list of reason codes describing what matched and why, delivered inside the standard score response. You can add rules for decisioning as needed.

Step 4: Review, investigate, and contribute. Your team reviews sessions and investigates connected sessions in Fraud Ring Explorer. When you confirm a fraud outcome, you can report it back. That signal protects every other TrustGraph participant and sharpens the signals you receive in return.

Note

A defining property of the network: no participant ever learns which institution contributed a signal, or even whether its own data matched a given query. You receive a status and an explainable breakdown, never another institution's records.

Categories

Each category has its own signals, fraud vectors, and reason codes. For every category, you use the TrustGraph module configuration to determine which checks are run and the thresholds to use. Your Incode team will work with you to help optimize the configurations. Refer to Fraud Ring Explorer to learn how these configurations show in the ring exploration and investigation workflow.

Category What it detects
Suspected Repeat Fraudster — SUSPECTED_REPEAT_FRAUDSTER Identities, devices, or documents that have been previously labelled fraudulent. Example signals: liveness attacks, face-recognition attacks, document tampering, failed government validation. Checked against the Suspected Fraud List.
First-Party Fraud — FIRST_PARTY_FRAUD Users who act anomalously, as reported by an institution. Incode uses this data as a possible indication of account compromise or identity theft, not of credit-worthiness. Example signals: rewards abuse, account selling, mule and circular trading patterns.
Unusual Activity — UNUSUAL_ACTIVITY Inconsistencies across sessions, drawn from both passing and failing sessions. Example signals: one document with several faces, one face with several documents, one device tied to conflicting identities.
Velocity — VELOCITY_CHECKS The same attribute used to onboard abnormally often within a configured time window. Tracked attributes include face, face on ID, document number, personal number, voter number, and device.
Fraud Rings The current session's link to discovered fraud clusters, returned as a real-time risk signal. Clusters are formed on shared attributes such as name, face, IP address, and device hash.

For the full list of reason codes emitted by each category, see TrustGraph reason codes.

Result structure

TrustGraph returns signals, not decisions or numbers to threshold. Each enabled category returns OK, AT_RISK, or NOT_EXECUTED, along with an explainable list of matches and reason codes. The overall TrustGraph status is OK or FAIL; FAIL if at least one enabled category is AT_RISK.

Incode does not decision on your behalf: you decide whether a signal fails a session, routes it to manual review, or follows another path. Branch on the matches and reason codes rather than the status alone, and treat both statuses and reason codes as an open set that can grow over time.

Reading TrustGraph in your integration

TrustGraph fires automatically on every session in a flow that has it enabled. No SDK or client code changes are required to start receiving signals.

Two reads cover almost every integration:

  • For the summary signals, read trustGraph.riskResults.overall.status and the per-category statuses in reasonCategoryScores from the score response.
  • For the detailed explanation, call the TrustGraph result endpoint and read the matches on each category. Every match carries a reason (why it fired) and a checkType (the attribute that matched). Those two fields are what you route queues on and what you show an analyst.

The same results are visible without writing any code in the Dashboard single Session view. Open the session and go to the TrustGraph tab to see these details.

To verify TrustGraph is active on a flow, run one session and inspect the response:

curl --silent --location \
  --url 'https://demo-api.incodesmile.com/omni/get/score?id=INTERVIEW_ID' \
  --header 'api-version: 1.0' \
  --header 'api-key: API_KEY' \
  --header 'Content-Type: application/json' \
  --header 'X-Incode-Hardware-Id: SESSION_TOKEN' \
  | jq '.trustGraph.riskResults.reasonCategoryScores'

An enabled category returns OK or AT_RISK. A disabled category returns NOT_EXECUTED. On a clean test session, a healthy integration returns OK for the categories you enabled and NOT_EXECUTED for the rest. If every category comes back NOT_EXECUTED, TrustGraph is not active on the flow: confirm both that the tenant is provisioned and in scope, and that the TrustGraph module is attached to the flow the session ran through.

Warning

Handle unknown values gracefully. Treat statuses and reason codes as an open set: new values are added over time. Branch on the values you know and default anything unrecognized to review rather than assuming a fixed enum.

Decisioning with rules

Note

The rule patterns below describe the Rules Engine, which applies to Flows. If you're using Workflows, configure a Condition after the TrustGraph module in your Workflow to act on signals instead. The patterns and the fields you branch on are the same; only the surface differs.

By default, TrustGraph signals do not affect the session decision. They are surfaced as an independent set of signals so you can watch them before they affect outcomes. You make them impact decisions by adding rules, which can act on the overall TrustGraph signal, on any individual category, or on both.

The three patterns below are illustrative shapes, not a literal rule syntax. Express them in your own rules configuration.

Single-field. The simplest possible adoption: one condition on the overall status.

IF trustGraph.riskResults.overall.status = FAIL
THEN route the session to manual review

Per-category routing. Different categories mean different things, so send them to different places.

IF SUSPECTED_REPEAT_FRAUDSTER = AT_RISK  THEN hard block
IF FIRST_PARTY_FRAUD          = AT_RISK  THEN route to the investigations queue
IF UNUSUAL_ACTIVITY           = AT_RISK  THEN route to manual review
IF VELOCITY_CHECKS            = AT_RISK  THEN route to the velocity review queue

Composite decisioning. Combine the TrustGraph signal with what the per-session checks already told you.

IF SUSPECTED_REPEAT_FRAUDSTER = AT_RISK
   AND a per-session check (liveness, document authenticity, government
       validation) already failed
THEN fail the session

IF SUSPECTED_REPEAT_FRAUDSTER = AT_RISK
   AND every per-session check passed
THEN route to manual review with the TrustGraph matches attached

In all three, the final decision stays on the session's top-level status. TrustGraph complements the per-session checks; it never replaces them and it never decides on your behalf.

Tip

TrustGraph returns a signal status, not a numeric score, so there are no thresholds to hard-code in your backend. Thresholds live in the configuration your Incode team applies, and your rules branch on the resulting statuses.

Deployment scopes

TrustGraph runs in one of two deployment scopes, set per tenant. The scope determines two things at once: what your institution contributes, and what your checks can search against. Both scopes include the same categories, but in the Local scope TrustGraph can only tell you about fraud you have already seen, while in the Global scope it draws on the whole network. Global is recommended by default to leverage the full product value; region-specific exclusions may apply, as advised by your Incode team.

Reciprocity. The network is strongest when participation is mutual. The more accurate fraud you contribute to the Global scope, the more precise the signals you get back.

Scope What you contribute What your checks search
Local Everything you store stays scoped to your own organization family. Only data belonging to your own organization family.
Global Your data contributes to the network through the privacy-preserving query layer, with zero knowledge sharing. Network-contributed signals plus your own organization family's data.

Privacy

Fraud operations do not stop at one company's boundary, but privacy and regulatory constraints have historically blocked institutions from comparing notes: pooling customer data is never an option. TrustGraph's privacy architecture is what removes that blocker.

TrustGraph lets institutions jointly validate identity signals without sharing any private data with each other or with Incode. The Global layer is a privacy-preserving query layer, implemented with proprietary Secure Multi-Party Computation (SMPC). It is explicitly not a centralized data store and does not pool records.

How a query executes:

  • Normalize locally. The local node standardizes identifiers (capitalization, whitespace, phone and postal formats) so they are comparable across institutions.
  • De-identify irreversibly. Hashing and truncation strip PII before any value leaves the local node.
  • Build fresh cryptographic material per request. The same identifier produces a different on-the-wire query every time, so no observer, including Incode, can correlate queries. Routing across participating nodes also mitigates scraping and brute force.
  • Compute jointly on shares. Each node runs SMPC against its own data, operating only on cryptographic shares. No participant sees another's inputs in plaintext, hashed, or encrypted form, and nodes return contributions without learning the outcome of their own participation.
  • Return an aggregate signal. The aggregation layer combines contributions and applies scoring without ever seeing raw or hashed user data. You get a status and an explainable breakdown: no records, no per-source detail. Transient query data is destroyed when the session ends and the cryptographic material is not reusable.

Data handling

TrustGraph is a component of the Incode platform and follows the same platform machinery and the retention policy you configure. Whatever policy you set applies to TrustGraph too: there is no separate or divergent retention schedule. Deletion requests submitted on platform propagate across data stores, including those used by TrustGraph.

Control layers

Every layer of control is yours. Some layers you set yourself in Dashboard, while tenant-level layers are set by your Incode team based on what you decide.

Layer You decide Governs
Tenant enablement and scope Whether TrustGraph runs at all, and whether your tenant is Local or Global. Your Incode team applies it. Whether any category can run, which insights your checks reach, which sub-features are available.
Named configuration Which categories your team can toggle in Flow Builder, which granular checks run inside each category, and the thresholds and time windows they use. Your definition of risk: for example, how many times one device may appear across identities before it counts as a signal.
Flow Builder Which categories run in which user journey, and which named configuration applies. Per-flow behavior.
Decisioning rules Whether a TrustGraph signal affects the session outcome at all, and how. Fail, manual review, queue routing, or observe-only, per category or on the overall status.

Get started

  1. Incode provisions your tenant and scope. TrustGraph is opt-in at the tenant level and no category runs until it is provisioned. Your Incode team applies it and can help calibrate velocity windows and thresholds in your configuration.
  2. Add the TrustGraph module to a flow. In the Flow or Workflow Builder, add the TrustGraph module and toggle categories per flow. TrustGraph then fires automatically on every session in that flow: no change to your code or user-journey integration is required to start receiving signals.
  3. Run and observe. By default, TrustGraph does not alter session decisioning: statuses appear on every session with zero decision impact. Run a representative period and evaluate decisioning strategy.
  4. Enforce with rules and close the loop. Add rules on the overall TrustGraph status and/or per category, route queues on the returned reason codes, and turn on Report Fraud.

Was this page helpful?