--- title: "TrustGraph" url: "https://developer.incode.com/features-and-modules/trust-graph-overview/" section: "features-and-modules" group: "Feature Deep Dive" version: "v1.1" status: "live" --- # 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](/dashboard-platform-administration/trust-graph-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](/dashboard-platform-administration/trust-graph-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](/dashboard-platform-administration/trust-graph-fraud-ring-explorer) to learn how these configurations show in the ring exploration and investigation workflow. For the full list of reason codes emitted by each category, see [TrustGraph reason codes](/general-reference/trust-graph-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](/dashboard-platform-administration/single-session-view/#trust-graph) to see these details. To verify TrustGraph is active on a flow, run one session and inspect the response: ```bash 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](/dashboard-platform-administration/trust-graph-module-configuration/#add-conditions) 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](/dashboard-platform-administration/flows-1) or [Workflow](/dashboard-platform-administration/workflows-20/) Builder, [add the TrustGraph module](/dashboard-platform-administration/trust-graph-module-configuration) 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**. ## Related pages - [TrustGraph module overview](/features-and-modules/trust-graph): Module summary with platform availability and links to per-SDK configuration. - [TrustGraph module configuration](/dashboard-platform-administration/trust-graph-module-configuration): How to add TrustGraph to a Flow or Workflow, and the settings available in the module configuration panel. - [TrustGraph reason codes](/general-reference/trust-graph-reason-codes): Full list of reason codes emitted by each category, with meanings. - [Fraud Ring Explorer](/dashboard-platform-administration/trust-graph-fraud-ring-explorer): The Dashboard investigation surface for fraud rings discovered in your history. - [Single Session View, TrustGraph tab](/dashboard-platform-administration/single-session-view/#trust-graph): Reading TrustGraph results for an individual session in Dashboard.