Entrust Identity Verification (Onfido) vs Sumsub

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Sumsub
   Entrust Identity Verification (Onfido)✓fullprobed8/10

   An llms.txt file exists at documentation.identity.entrust.com/llms.txt and is directly probed returning HTTP 200 with structured content describing the API/SDK platform, confirming an agent can be pointed at it. Missing for 10: no evidence of broader agent-oriented doc formats (e.g., markdown-only mirrors, sitemap of llms-full.txt) or third-party confirmation that agents successfully consume it.

   • [probe] “PROBE llms.txt: HTTP 200 at https://documentation.identity.entrust.com/llms.txt # Entrust Identity Verification Documentation > Entrust Ide…”
   • [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”

   proof ↗⚑ flag

   Sumsub✓fullprobed9/10

   A live probe confirms llms.txt exists at docs.sumsub.com/llms.txt (HTTP 200) with explicit guidance that any doc page can be appended with .md for markdown, and docs pages are indeed served as .md variants throughout the evidence pack, directly enabling agent-oriented consumption. Missing for 10: no independent third-party confirmation of an agent actually consuming this successfully.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.sumsub.com/llms.txt # Sumsub Documentation > Documentation for Sumsub Append .md to any documenta…”
   • [claimed-docs] “Tailor colors, styles, and step instructions to match your brand across Web and Mobile SDKs.”
   • [claimed-docs] “Grant your team members access to your Sumsub account.”
   • [claimed-docs] “Generate a security key or use biometric options to reduce the risk of account compromise.”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Sumsub
   Entrust Identity Verification (Onfido)~partialclaimed5/10

   The product exposes a full REST API (create applicant, create workflow run, webhooks, OAuth client-credentials tokens) that could be scripted headlessly in CI, and webhook/polling patterns support automation without UI interaction. However, the primary workflow-building tool is explicitly no-code/drag-and-drop, and there is no evidence of a CLI, SDK for CI pipelines, or documented headless/automation-testing use case. missing for 10: explicit CI/headless automation examples, CLI tooling, documented non-interactive test/staging workflows, and confirmation that Workflow Studio config can be version-controlled or scripted rather than GUI-only.

   • [claimed-docs] “Obtaining SDK tokens – SDK tokens are essential for authenticating and initializing the Entrust IDV SDKs”
   • [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
   • [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”
   • [claimed-docs] “Entrust recommends generating short-lived OAuth access tokens for API authentication using client credentials grant.”
   • [claimed-docs] “It's a no-code, drag and drop interface that allows you to build, maintain and update workflows seamlessly without the need for developer in…”

   proof ↗⚑ flag

   Sumsub~partialclaimed6/10

   Sumsub exposes a RESTful API, sandbox mode for testing integrations, and webhooks for event-driven automation—these together enable headless/CI-style usage without a UI. However, there is no explicit CI/CD tooling, CLI, or documented automation pipeline examples confirming actual CI usage. missing for 10: explicit CI/CD integration examples, official CLI, automated test/build pipeline documentation.

   • [claimed-docs] “With the Sumsub API, you can process the applicant data and documents submitted for verification through simple RESTful APIs.”
   • [claimed-docs] “Use Sandbox mode to test your integration before going live.”
   • [claimed-docs] “Sumsub’s Webhooks is a tool that allows you to automatically receive notifications for various events and changes related to your applicants…”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Sumsub
   Entrust Identity Verification (Onfido)—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Sumsub✓fullprobed8/10

   Sumsub explicitly documents an official MCP server that lets AI agents perform Sumsub operations under existing role permissions, corroborated by a probe confirming the doc page exists. missing for 10: independent/hands-on third-party confirmation of the MCP server working in practice, and details on setup/authentication scope.

   • [claimed-docs] “Use the MCP server to let AI agents perform Sumsub operations on your behalf, while keeping access controlled by your existing Sumsub role p…”
   • [probe] “official MCP server documented at https://docs.sumsub.com/docs/mcp-server”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Entrust Identity Verification (Onfido)—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Sumsub—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round to Sumsub
   Entrust Identity Verification (Onfido)✓fullprobed7/10

   Entrust provides a well-documented public API/SDK flow (applicant creation, workflow run, SDK token, webhook or polling for results) plus OAuth client-credentials authentication and webhook signature verification, all confirmed by a live llms.txt probe describing it as 'a comprehensive API and SDK platform'. missing for 10: independent/community corroboration of real-world API integration, and a direct link to a full API reference/OpenAPI spec beyond the docs snippets.

   • [claimed-docs] “Obtaining SDK tokens – SDK tokens are essential for authenticating and initializing the Entrust IDV SDKs”
   • [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
   • [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”
   • [claimed-docs] “You can get the expected signature of the webhook by computing the HMAC of the event request body using the SHA256 algorithm, using the webh…”
   • [claimed-docs] “Entrust recommends generating short-lived OAuth access tokens for API authentication using client credentials grant.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://documentation.identity.entrust.com/llms.txt # Entrust Identity Verification Documentation > Entrust Ide…”

   proof ↗⚑ flag

   Sumsub✓fullprobed8/10

   Sumsub documents a public RESTful API for verification workflows, webhooks for events, sandbox testing, and even an official MCP server enabling AI agents to perform operations via the API. This directly satisfies the AI-native driving-via-API story. Missing for 10: a discoverable formal OpenAPI/Swagger spec (probe found 404s), and independent third-party corroboration of API usage.

   • [claimed-docs] “With the Sumsub API, you can process the applicant data and documents submitted for verification through simple RESTful APIs.”
   • [claimed-docs] “Use Sandbox mode to test your integration before going live.”
   • [claimed-docs] “Sumsub’s Webhooks is a tool that allows you to automatically receive notifications for various events and changes related to your applicants…”
   • [claimed-docs] “Use the MCP server to let AI agents perform Sumsub operations on your behalf, while keeping access controlled by your existing Sumsub role p…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.sumsub.com/openapi.json, https://docs.sumsub.com/swagger.json, https://docs.sumsub.com/…”
   • [probe] “official MCP server documented at https://docs.sumsub.com/docs/mcp-server”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Sumsub
   Entrust Identity Verification (Onfido)~partialclaimed4/10

   The docs show OAuth client-credentials grant for short-lived tokens and separate SDK tokens for capture flows, which provides some credential separation, but there is no explicit mention of scoped/least-privilege roles, permission granularity, or agent-specific credential issuance. missing for 10: explicit least-privilege/scoped role definitions, documentation of granting narrower API scopes per use-case or agent, and any AI-agent-specific credential workflow.

   • [claimed-docs] “Entrust recommends generating short-lived OAuth access tokens for API authentication using client credentials grant.”
   • [claimed-docs] “Obtaining SDK tokens – SDK tokens are essential for authenticating and initializing the Entrust IDV SDKs”

   proof ↗⚑ flag

   Sumsub~partialprobed5/10

   Sumsub's MCP server docs state that AI agent access is controlled by existing Sumsub role permissions, implying some scoping via role-based access control, and separate docs confirm team member access management exists. However, there's no explicit documentation of issuing distinct, least-privilege API credentials/tokens scoped specifically to an agent (e.g., token-level scopes, expiring keys, or granular per-agent permission sets). Missing for 10: dedicated API-key/token scoping mechanism, documented permission granularity for agent-specific credentials, and independent confirmation of least-privilege enforcement in practice.

   • [claimed-docs] “Use the MCP server to let AI agents perform Sumsub operations on your behalf, while keeping access controlled by your existing Sumsub role p…”
   • [claimed-docs] “Grant your team members access to your Sumsub account.”
   • [probe] “official MCP server documented at https://docs.sumsub.com/docs/mcp-server”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Entrust Identity Verification (Onfido)
   Entrust Identity Verification (Onfido)~partialclaimed6/10

   Evidence confirms official SDKs exist (mobile/web SDKs, SDK tokens, migration guide from Smart Capture SDKs to new IDV SDKs) with documented API/webhook/auth flows, showing developers can build against them. However, there's no evidence of language-specific SDK repos, open-source code samples, versioning/release notes, or independent developer corroboration of build experience. Missing for 10: public SDK repository/language coverage details, code samples, independent developer testimonials, changelog/versioning transparency.

   • [claimed-docs] “Obtaining SDK tokens – SDK tokens are essential for authenticating and initializing the Entrust IDV SDKs”
   • [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
   • [claimed-docs] “Entrust recommends generating short-lived OAuth access tokens for API authentication using client credentials grant.”
   • [claimed-docs] “NFC is **only available for integration via the Entrust Identity Verification mobile SDKs**.”
   • [claimed-docs] “migration guide to support migrations from the latest Smart Capture SDKs to the new Entrust IDV SDKs and highlight all new features”

   proof ↗⚑ flag

   Sumsub~partialprobed5/10

   Docs confirm Web and Mobile SDKs plus a RESTful API and sandbox for integration testing, and even an MCP server for agentic use, but there is no evidence of broader official language SDKs (e.g., server-side Python/Node/Java), GitHub repos, or independent developer corroboration. missing for 10: list of official server-side/language SDKs, GitHub repo links, independent developer confirmation of SDK quality.

   • [claimed-docs] “With the Sumsub API, you can process the applicant data and documents submitted for verification through simple RESTful APIs.”
   • [claimed-docs] “Use Sandbox mode to test your integration before going live.”
   • [claimed-docs] “Tailor colors, styles, and step instructions to match your brand across Web and Mobile SDKs.”
   • [claimed-docs] “Use the MCP server to let AI agents perform Sumsub operations on your behalf, while keeping access controlled by your existing Sumsub role p…”
   • [probe] “official MCP server documented at https://docs.sumsub.com/docs/mcp-server”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Sumsub
   Entrust Identity Verification (Onfido)✓fullclaimed7/10

   Docs clearly document configurable webhook events to notify on workflow status changes, including signature verification via HMAC-SHA256, showing a supported webhook subscription mechanism. missing for 10: no documentation of event type granularity/catalog, no independent/hands-on corroboration, and no explicit mention of self-serve webhook management UI or retry/delivery guarantees.

   • [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”
   • [claimed-docs] “You can get the expected signature of the webhook by computing the HMAC of the event request body using the SHA256 algorithm, using the webh…”
   • [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”

   proof ↗⚑ flag

   Sumsub✓fullclaimed8/10

   Sumsub's documented Webhooks feature explicitly allows automatic subscription to applicant verification events and status changes, directly matching the story. Missing for 10: independent/hands-on corroboration of webhook reliability and detailed payload/event-type documentation in the evidence pack.

   • [claimed-docs] “Sumsub’s Webhooks is a tool that allows you to automatically receive notifications for various events and changes related to your applicants…”

   proof ↗⚑ flag

Agentic features

1. ai-native userSet up automations that run autonomously in the background

   weight 2 · round drawn
   Entrust Identity Verification (Onfido)~partialclaimed5/10

   Workflow Studio provides no-code, drag-and-drop automation of verification workflows, and webhooks/polling allow asynchronous, background monitoring of workflow status rather than requiring active user polling — evidence of some autonomous background operation. However, this is workflow automation for identity checks, not an AI-native agentic automation framework (no mention of AI agent orchestration, scheduling, or LLM-driven decisioning). Missing for 10: evidence of AI-agent-specific automation setup, autonomous decision-making beyond fixed verification steps, and integration with agent frameworks.

   • [claimed-docs] “It's a no-code, drag and drop interface that allows you to build, maintain and update workflows seamlessly without the need for developer in…”
   • [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”
   • [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”

   proof ↗⚑ flag

   Sumsub~partialprobed5/10

   Sumsub supports background automation implicitly via webhooks (automatic event notifications), verification levels (automated multi-step verification sequences), and AML screening configuration that runs automatically — plus an MCP server letting AI agents perform operations autonomously under role permissions. However, there's no dedicated workflow/rules builder or scheduler described as enabling arbitrary user-defined 'set and forget' automations beyond the verification pipeline itself. Missing for 10: an explicit automation/workflow orchestration feature, scheduling capability, and independent evidence of autonomous background runs beyond webhook triggers.

   • [claimed-docs] “Sumsub’s Webhooks is a tool that allows you to automatically receive notifications for various events and changes related to your applicants…”
   • [claimed-docs] “A level is a sequence of steps that your applicants have to take to verify their identity. Each level may include document-based or selfie-b…”
   • [claimed-docs] “Configure your AML screening settings to suit your needs by screening against targeted lists and categories that are relevant to your busine…”
   • [claimed-docs] “Use the MCP server to let AI agents perform Sumsub operations on your behalf, while keeping access controlled by your existing Sumsub role p…”
   • [probe] “official MCP server documented at https://docs.sumsub.com/docs/mcp-server”

   proof ↗⚑ flag

2. ai-native userOperate the product with natural-language commands

   weight 2 · round to Sumsub
   Entrust Identity Verification (Onfido)—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Sumsub~partialprobed6/10

   Sumsub documents an official MCP server that lets AI agents perform Sumsub operations on the user's behalf under role-based permissions, which enables natural-language/agentic control via an AI agent interface rather than the product itself exposing an NL command layer. Missing for 10: direct evidence of a native natural-language command interface within Sumsub's own UI/API, and independent/hands-on confirmation of the MCP server's real-world usability.

   • [claimed-docs] “Use the MCP server to let AI agents perform Sumsub operations on your behalf, while keeping access controlled by your existing Sumsub role p…”
   • [probe] “official MCP server documented at https://docs.sumsub.com/docs/mcp-server”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   Entrust Identity Verification (Onfido)—none0/10

   The evidence pack shows conventional API/SDK documentation (auth, webhooks, workflow setup) but no mention of an interactive API reference, API explorer, or runnable code examples anywhere in the docs.

   ⚑ flag

   Sumsub—none0/10

   There's mention of a REST API and docs, but no evidence of an interactive API reference with runnable examples (e.g., try-it-out console, embedded code sandbox); the OpenAPI/Swagger probe returned 404s, suggesting no interactive spec is publicly exposed.

   • [claimed-docs] “With the Sumsub API, you can process the applicant data and documents submitted for verification through simple RESTful APIs.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.sumsub.com/openapi.json, https://docs.sumsub.com/swagger.json, https://docs.sumsub.com/…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Entrust Identity Verification (Onfido)—none0/10

   The evidence pack shows extensive API/webhook documentation but no mention of a downloadable OpenAPI/Swagger spec or other machine-readable API definition file. As an API-driven platform, this axis is applicable, but no evidence supports it.

   ⚑ flag

   Sumsub—none0/10

   Sumsub documents a RESTful API and provides llms.txt for markdown docs, but direct probes for OpenAPI/Swagger spec files all returned 404, and no evidence pack item points to a downloadable machine-readable API spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.sumsub.com/openapi.json, https://docs.sumsub.com/swagger.json, https://docs.sumsub.com/…”
   • [claimed-docs] “With the Sumsub API, you can process the applicant data and documents submitted for verification through simple RESTful APIs.”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Sumsub
   Entrust Identity Verification (Onfido)—none0/10

   The evidence pack covers SDK tokens, webhooks, OAuth, and workflow tools but contains no mention of a sandbox/test environment separate from production for API or SDK testing. This is a fair axis for an API/SDK platform, but no evidence supports it.

   ⚑ flag

   Sumsub✓fullclaimed8/10

   Sumsub explicitly documents a Sandbox mode for testing integrations before going live without touching production data, directly matching the story. Missing for 10: independent/hands-on corroboration beyond vendor docs, and details on how sandbox data isolation is guaranteed.

   • [claimed-docs] “Use Sandbox mode to test your integration before going live.”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round to Entrust Identity Verification (Onfido)
   Entrust Identity Verification (Onfido)~partialclaimed3/10

   The docs reference an 'api/latest' version and a migration guide for moving from Smart Capture SDKs to new IDV SDKs, implying some versioning and change management, but there is no explicit documented deprecation policy, version support timeline, or sunset schedule for APIs. missing for 10: explicit versioned API scheme (e.g., v1/v2 endpoints), a published deprecation/sunset policy, and timelines for backward compatibility.

   • [claimed-docs] “Obtaining SDK tokens – SDK tokens are essential for authenticating and initializing the Entrust IDV SDKs”
   • [claimed-docs] “migration guide to support migrations from the latest Smart Capture SDKs to the new Entrust IDV SDKs and highlight all new features”

   proof ↗⚑ flag

   Sumsub—none0/10

   No evidence of API versioning scheme or a documented deprecation policy; OpenAPI spec probes returned 404s and docs only describe general REST usage, sandbox testing, and webhooks without mentioning version lifecycle or deprecation timelines.

   • [claimed-docs] “With the Sumsub API, you can process the applicant data and documents submitted for verification through simple RESTful APIs.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.sumsub.com/openapi.json, https://docs.sumsub.com/swagger.json, https://docs.sumsub.com/…”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round drawn
   Entrust Identity Verification (Onfido)—none0/10

   The evidence describes single-applicant workflows (create applicant → workflow run → SDK token → webhook) and no batch/bulk API endpoints, CSV bulk upload, or multi-item processing tools are documented. Bulk operations are a plausible axis for an identity verification API but no supporting evidence exists.

   • [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
   • [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”

   proof ↗⚑ flag

   Sumsub—none0/10

   Evidence shows a RESTful API, webhooks, and an MCP server for automating individual applicant verification workflows, but nothing documents batch/bulk endpoints or bulk-processing capabilities across many applicants or items at once.

   • [claimed-docs] “With the Sumsub API, you can process the applicant data and documents submitted for verification through simple RESTful APIs.”
   • [claimed-docs] “Sumsub’s Webhooks is a tool that allows you to automatically receive notifications for various events and changes related to your applicants…”
   • [claimed-docs] “Use the MCP server to let AI agents perform Sumsub operations on your behalf, while keeping access controlled by your existing Sumsub role p…”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Entrust Identity Verification (Onfido)
   Entrust Identity Verification (Onfido)✓fullclaimed7/10

   Workflow Studio provides a no-code, drag-and-drop rule builder for defining identity verification workflows, and webhooks let users trigger downstream actions automatically on workflow status change events, satisfying the event-driven automation story within the IDV domain. Missing for 10: detailed documentation of conditional/branching rule logic within Workflow Studio and independent/hands-on corroboration of the rule engine's flexibility.

   • [claimed-docs] “It's a no-code, drag and drop interface that allows you to build, maintain and update workflows seamlessly without the need for developer in…”
   • [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”
   • [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”

   proof ↗⚑ flag

   Sumsub~partialclaimed5/10

   Sumsub's webhook system lets applicants' verification events (e.g., status changes) automatically trigger outbound notifications, which can drive downstream actions, and AML/verification level configuration lets you set some conditional check rules — but there's no documented rules engine for defining custom 'if event X then action Y' automation beyond webhooks and level configuration. Missing for 10: a dedicated rules/automation engine, conditional branching logic, and evidence of user-defined trigger-action workflows beyond webhook notifications.

   • [claimed-docs] “Sumsub’s Webhooks is a tool that allows you to automatically receive notifications for various events and changes related to your applicants…”
   • [claimed-docs] “A level is a sequence of steps that your applicants have to take to verify their identity. Each level may include document-based or selfie-b…”
   • [claimed-docs] “Configure your AML screening settings to suit your needs by screening against targeted lists and categories that are relevant to your busine…”

   proof ↗⚑ flag

3. ai-native userVersion, review, and roll back my automations

   weight 1 · round drawn
   Entrust Identity Verification (Onfido)—none0/10

   No evidence of version history, review workflows, or rollback capabilities for Workflow Studio automations; documentation focuses on building workflows via no-code interface but omits versioning/rollback features entirely.

   ⚑ flag

   Sumsub—none0/10

   Sumsub's evidence covers verification levels, AML screening, webhooks, and an MCP server for agent operations, but nothing addresses versioning, reviewing, or rolling back automations/workflows (e.g., verification level configs or rule changes). No changelog, version history, or rollback mechanism is documented anywhere in the pack.

   ⚑ flag

Deepfake defense

1. risk analystThe vendor documents specific defenses against AI-generated faces, deepfakes, and camera-injection attacks — named detection capabilities, not just a marketing mention of fraud

   weight 2 · round to Sumsub
   Entrust Identity Verification (Onfido)—none0/10

   Evidence documents general liveness via head-motion challenges (Motion feature) and repeat-face fraud alerts, but nothing names specific defenses against AI-generated faces, deepfakes, or camera-injection attacks as the story requires. Missing for 10: named deepfake detection capability, AI-generated/synthetic face detection, and camera/virtual-camera injection attack prevention documentation.

   • [claimed-docs] “Motion also assesses liveness by asking users to complete either a simple head turn pattern in both directions or four randomized head movem…”
   • [claimed-docs] “The alerts you to faces which have already been through your identity verification flow, highlighting potential repeat identity fraud attemp…”

   proof ↗⚑ flag

   Sumsub~partialclaimed6/10

   Sumsub's liveness docs explicitly name defenses against deepfakes, AI-generated images, paper masks, photos of screens, and dolls, going beyond generic marketing language (sumsub-docs-12) and includes a review workflow for liveness results (sumsub-docs-13). However, there is no explicit mention of 'camera injection' attacks or deeper technical detail on how each attack vector is detected. missing for 10: explicit camera-injection attack defenses, technical/algorithmic detail on detection methods, independent validation of these claims.

   • [claimed-docs] “In under a second, it confirms the applicant is a real, live person (not a deepfake, AI-generated image, paper mask, photo of a screen, or d…”
   • [claimed-docs] “Open the Applicants page and select an applicant who passed the Liveness check. In the profile, navigate to the Liveness section and review …”

   proof ↗⚑ flag

Duplicate detection

1. risk analystThe platform detects repeat and duplicate identities across verifications — the same face or document resurfacing under different names is flagged automatically

   weight 2 · round to Entrust Identity Verification (Onfido)
   Entrust Identity Verification (Onfido)~partialclaimed6/10

   Docs explicitly describe a facial deduplication feature that flags faces already seen in prior verification flows, directly addressing repeat-identity detection under different names. However, evidence lacks detail on document-level duplicate detection, how matches are surfaced/scored to a risk analyst, or independent/hands-on validation of accuracy. Missing for 10: document dedup evidence, analyst-facing reporting/UI detail, independent corroboration of detection accuracy.

   • [claimed-docs] “The alerts you to faces which have already been through your identity verification flow, highlighting potential repeat identity fraud attemp…”

   proof ↗⚑ flag

   Sumsub—none0/10

   The evidence covers liveness detection, document verification, AML screening, and reusable KYC, but none of it describes cross-applicant duplicate/repeat identity detection (e.g., flagging the same face or document reused under a different name). This is a plausible and common KYC capability, but no evidence pack item documents it for Sumsub.

   ⚑ flag

Liveness

1. risk analystSelfie checks match the live user to the document portrait with liveness detection — documented defenses against printed photos, screens, and replayed video

   weight 3 · round to Sumsub
   Entrust Identity Verification (Onfido)~partialclaimed5/10

   Docs confirm a facial similarity/liveness check using motion challenges (head turns, randomized movements) to match selfie to document portrait, but there is no explicit documentation describing specific defenses against printed photos, screen replays, or video replay attacks. Missing for 10: explicit anti-spoofing detail (printed photo, screen, deepfake/video replay countermeasures), independent testing/accuracy corroboration.

   • [claimed-docs] “Motion also assesses liveness by asking users to complete either a simple head turn pattern in both directions or four randomized head movem…”

   proof ↗⚑ flag

   Sumsub✓fullclaimed8/10

   Sumsub's docs explicitly describe liveness detection that confirms the applicant is a real, live person and not a deepfake, AI-generated image, paper mask, or photo of a screen, and matches them to the account/document on file, plus a review workflow for liveness results and a broader Liveness & Face match check within verification levels. Missing for 10: independent/hands-on corroboration of anti-spoofing efficacy (e.g., third-party pentest or lab results) and explicit mention of replayed-video defenses beyond screen-photo detection.

   • [claimed-docs] “In under a second, it confirms the applicant is a real, live person (not a deepfake, AI-generated image, paper mask, photo of a screen, or d…”
   • [claimed-docs] “Open the Applicants page and select an applicant who passed the Liveness check. In the profile, navigate to the Liveness section and review …”
   • [claimed-docs] “A level is a sequence of steps that your applicants have to take to verify their identity. Each level may include document-based or selfie-b…”

   proof ↗⚑ flag

Db checks

1. developerVerify identity against authoritative databases without documents — SSN, national registries, or credit-header data — for lower-friction flows where a doc scan is overkill

   weight 2 · round drawn
   Entrust Identity Verification (Onfido)—none0/10

   The evidence pack covers document verification, biometric/facial checks, watchlist/PEP/sanctions screening, webhooks, and SDK auth flows, but contains no mention of document-free identity verification against SSN, national ID registries, or credit-header databases. Since this is a plausible capability for an IDV platform, absence of evidence means 'none' rather than 'na'.

   ⚑ flag

   Sumsub—none0/10

   The evidence pack covers document verification, liveness, AML screening, and reusable KYC, but contains no mention of no-document database verification methods such as SSN checks, national registry lookups, or credit-header data — the specific capability the story asks about.

   ⚑ flag

Kyb

1. ops leadVerify businesses, not just people — registry lookups, UBO identification, and documented KYB flows that chain into KYC on the owners

   weight 2 · round drawn
   Entrust Identity Verification (Onfido)—none0/10

   All evidence focuses on individual identity verification (document capture, facial similarity, watchlist/PEP checks on applicants, workflow studio for KYC flows) — there is no mention of business/registry lookups, UBO (ultimate beneficial owner) identification, or documented KYB (know-your-business) workflows chaining into KYC on owners.

   ⚑ flag

   Sumsub—none0/10

   The evidence pack covers individual KYC flows (document/liveness checks, verification levels, AML screening, reusable KYC) but contains no mention of business/KYB verification, company registry lookups, or UBO identification chaining into KYC. Since none of the provided evidence addresses business verification specifically, this applicable axis is unsupported.

   ⚑ flag

Risk signals

1. developerEnrich verifications with phone, email, and device risk signals — carrier checks, address history, device fingerprint — as additional documented check types

   weight 2 · round drawn
   Entrust Identity Verification (Onfido)—none0/10

   The evidence pack documents document reports, facial similarity/liveness, watchlist/PEP/sanctions checks, and duplicate-face detection, but contains no mention of phone, email, carrier, address history, or device fingerprint risk signals as check types. missing for 10: phone risk check docs, email risk check docs, carrier/device fingerprint check docs, address history check docs.

   • [claimed-docs] “In your Dashboard, you can configure which documents you want to accept in your verification workflow, filtering according to issuing countr…”
   • [claimed-docs] “Watchlist reports verify an applicant's records against a range of global watchlists, including: Sanctions... Politically Exposed Persons (P…”
   • [claimed-docs] “The alerts you to faces which have already been through your identity verification flow, highlighting potential repeat identity fraud attemp…”
   • [claimed-docs] “Motion also assesses liveness by asking users to complete either a simple head turn pattern in both directions or four randomized head movem…”

   proof ↗⚑ flag

   Sumsub—none0/10

   The evidence pack covers document verification, liveness, AML screening, verification levels, and reusable KYC, but contains no mention of phone/carrier checks, email risk scoring, address history validation, or device fingerprinting as check types.

   ⚑ flag

Doc types

1. ops leadThe platform verifies government IDs from a documented breadth of countries and document types — passports, national IDs, driver licenses, residence permits — with the supported list published

   weight 3 · round to Sumsub
   Entrust Identity Verification (Onfido)~partialclaimed4/10

   Docs confirm the platform lets ops configure accepted documents by issuing country and document type (docs-8), implying broad multi-country/document-type support, but no published list enumerating supported countries or specific document types (passports, national IDs, licenses, residence permits) is provided in the evidence. Missing for 10: a published country/document-type coverage list, explicit mention of all four document categories, and any breadth metric (e.g., number of countries/documents supported).

   • [claimed-docs] “In your Dashboard, you can configure which documents you want to accept in your verification workflow, filtering according to issuing countr…”
   • [claimed-docs] “NFC is **only available for integration via the Entrust Identity Verification mobile SDKs**.”

   proof ↗⚑ flag

   Sumsub~partialclaimed6/10

   Sumsub publishes a broad claim of covering '14,000+ document types from 220+ countries and territories' and describes verification levels including document-based checks, but the evidence pack lacks a documented published list/breakdown by specific document type (passports, national IDs, driver licenses, residence permits) per country. missing for 10: a searchable/published per-country per-document-type coverage list, independent verification of the 14,000+ document claim.

   • [claimed-docs] “Instantly verify 14,000+ document types from 220+ countries and territories.”
   • [claimed-docs] “A level is a sequence of steps that your applicants have to take to verify their identity. Each level may include document-based or selfie-b…”

   proof ↗⚑ flag

Extraction

1. developerVerified sessions return the extracted document fields as structured data — name, date of birth, document number, address, expiry — retrievable via the API, not just a pass/fail flag

   weight 2 · round drawn
   Entrust Identity Verification (Onfido)—none0/10

   The evidence describes workflow results retrievable via webhook or polling and a 'document report' concept, but nothing explicitly confirms that structured fields (name, DOB, document number, address, expiry) are returned as retrievable API data rather than a report/pass-fail outcome. Missing for 10: explicit API/webhook payload schema or docs showing per-field extracted data (name, DOB, doc number, address, expiry) returned to developers.

   • [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
   • [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”
   • [claimed-docs] “In your Dashboard, you can configure which documents you want to accept in your verification workflow, filtering according to issuing countr…”

   proof ↗⚑ flag

   Sumsub—none0/10

   The evidence pack shows Sumsub exposes applicant data via RESTful APIs and covers document verification broadly, but none of the cited docs mention retrieving structured extracted fields (name, DOB, document number, address, expiry) via API rather than a pass/fail result. missing for 10: explicit API/field reference docs showing extracted document data payload, sample response schema, or field-level API endpoint.

   • [claimed-docs] “With the Sumsub API, you can process the applicant data and documents submitted for verification through simple RESTful APIs.”
   • [claimed-docs] “Instantly verify 14,000+ document types from 220+ countries and territories.”

   proof ↗⚑ flag

Agent decisions

1. ai-native userVerification outcomes come back structured enough for an agent to decide on — machine-readable check results, risk signals, and failure reasons an automated onboarding flow can branch on

   weight 2 · round drawn
   Entrust Identity Verification (Onfido)~partialclaimed6/10

   Docs show a structured, API-driven flow (workflow run → SDK token → webhook/polling → reports) with distinct report types (document, watchlist/PEP/sanctions/adverse media, facial similarity, repeat-fraud alerts) that provide machine-consumable results an automation could branch on. However, there is no explicit evidence of a documented schema for risk scores, standardized failure-reason codes, or example JSON payloads that an agent would parse to make branching decisions. Missing for 10: explicit result schema/field reference, enumerated failure/rejection reason codes, and sample structured payloads showing risk signal granularity.

   • [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
   • [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”
   • [claimed-docs] “In your Dashboard, you can configure which documents you want to accept in your verification workflow, filtering according to issuing countr…”
   • [claimed-docs] “Watchlist reports verify an applicant's records against a range of global watchlists, including: Sanctions... Politically Exposed Persons (P…”
   • [claimed-docs] “The alerts you to faces which have already been through your identity verification flow, highlighting potential repeat identity fraud attemp…”
   • [claimed-docs] “You can get the expected signature of the webhook by computing the HMAC of the event request body using the SHA256 algorithm, using the webh…”

   proof ↗⚑ flag

   Sumsub~partialprobed6/10

   Sumsub's REST API and webhook system (sumsub-docs-1, sumsub-docs-3) provide machine-readable verification events, and verification levels/AML screening (sumsub-docs-5, sumsub-docs-6) imply structured check results and risk categorization that an automated flow could branch on; the MCP server (sumsub-docs-4, sumsub-probe-3) further supports agent-driven access. However, the evidence never shows the actual JSON schema, specific risk-score fields, or enumerated failure-reason codes, and no OpenAPI spec is discoverable (sumsub-probe-2), so it's unclear how granular/structured the failure reasons truly are. Missing for 10: explicit schema/examples of check-result payloads, documented risk-signal taxonomy, and enumerated failure-reason codes for automated branching.

   • [claimed-docs] “With the Sumsub API, you can process the applicant data and documents submitted for verification through simple RESTful APIs.”
   • [claimed-docs] “Sumsub’s Webhooks is a tool that allows you to automatically receive notifications for various events and changes related to your applicants…”
   • [claimed-docs] “A level is a sequence of steps that your applicants have to take to verify their identity. Each level may include document-based or selfie-b…”
   • [claimed-docs] “Configure your AML screening settings to suit your needs by screening against targeted lists and categories that are relevant to your busine…”
   • [claimed-docs] “Use the MCP server to let AI agents perform Sumsub operations on your behalf, while keeping access controlled by your existing Sumsub role p…”
   • [probe] “official MCP server documented at https://docs.sumsub.com/docs/mcp-server”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.sumsub.com/openapi.json, https://docs.sumsub.com/swagger.json, https://docs.sumsub.com/…”

   proof ↗⚑ flag

Agent operations

1. ai-native userAn agent can operate the verification pipeline — create sessions, poll outcomes, retrieve extracted data, and trigger re-checks through the API or an MCP surface with scoped credentials

   weight 3 · round to Sumsub
   Entrust Identity Verification (Onfido)~partialclaimed5/10

   The API supports the core pipeline: create applicant/workflow run, obtain SDK/OAuth tokens with scoped client-credentials grants, and retrieve results via webhook or polling (docs-2,3,4,6). However there is no evidence of an MCP surface for agent access, and no explicit documentation of a 're-check' trigger endpoint distinct from creating a new workflow run. missing for 10: MCP server/tool surface for agentic access, explicit re-check/re-verification API, and any agent-oriented orchestration examples.

   • [claimed-docs] “Obtaining SDK tokens – SDK tokens are essential for authenticating and initializing the Entrust IDV SDKs”
   • [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
   • [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”
   • [claimed-docs] “Entrust recommends generating short-lived OAuth access tokens for API authentication using client credentials grant.”

   proof ↗⚑ flag

   Sumsub~partialprobed6/10

   Sumsub has a documented REST API and an official MCP server explicitly described for letting AI agents perform Sumsub operations under scoped role-based permissions (sumsub-docs-4, sumsub-probe-3), plus webhooks for outcome notification (sumsub-docs-3). However, evidence doesn't confirm specifics like polling outcomes, retrieving extracted data, or triggering re-checks explicitly through the MCP surface, nor is there an OpenAPI spec confirming full API surface (sumsub-probe-2 shows 404s). Missing for 10: explicit documentation of session creation/polling/re-check operations via MCP, confirmation of scoped credential granularity within MCP, and independent/hands-on validation of the MCP server's agent workflows.

   • [claimed-docs] “Use the MCP server to let AI agents perform Sumsub operations on your behalf, while keeping access controlled by your existing Sumsub role p…”
   • [probe] “official MCP server documented at https://docs.sumsub.com/docs/mcp-server”
   • [claimed-docs] “Sumsub’s Webhooks is a tool that allows you to automatically receive notifications for various events and changes related to your applicants…”
   • [claimed-docs] “With the Sumsub API, you can process the applicant data and documents submitted for verification through simple RESTful APIs.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.sumsub.com/openapi.json, https://docs.sumsub.com/swagger.json, https://docs.sumsub.com/…”

   proof ↗⚑ flag

Sandbox

1. developerA sandbox lets me exercise every outcome before going live — documented test documents, personas, or magic values that deterministically produce pass, fail, and review results

   weight 3 · round to Sumsub
   Entrust Identity Verification (Onfido)—none0/10

   No evidence of a sandbox environment with documented test documents, personas, or magic values that deterministically produce pass/fail/review outcomes; the pack only covers workflow setup, SDK tokens, webhooks, and report types. missing for 10: sandbox/test-mode documentation, sample test documents or personas, deterministic magic-value test data for triggering specific verification outcomes.

   ⚑ flag

   Sumsub~partialclaimed4/10

   Sumsub documents a Sandbox mode for testing integrations before going live (sumsub-docs-2), but the evidence pack contains no specifics on documented test documents, personas, or magic values that deterministically trigger pass/fail/review outcomes. Missing for 10: documented deterministic test data/personas, explicit mapping of test inputs to pass/fail/review results, and any hands-on confirmation of sandbox behavior.

   • [claimed-docs] “Use Sandbox mode to test your integration before going live.”

   proof ↗⚑ flag

Session api

1. developerThe whole verification lifecycle is drivable through the API — create a session, get its status, retrieve results and captured media, and cancel or redact it — with every step documented

   weight 3 · round to Entrust Identity Verification (Onfido)
   Entrust Identity Verification (Onfido)~partialclaimed6/10

   Docs confirm core lifecycle steps — create applicant, create workflow run, obtain SDK token, retrieve results via webhook or polling — plus authentication (OAuth) and webhook signature verification are documented. However, explicit API-level documentation for retrieving captured media, and for cancel/redact operations, is not shown in the evidence pack. missing for 10: documented endpoint/example for retrieving captured media via API, documented cancel operation, documented redact/delete operation, and independent confirmation these work end-to-end.

   • [claimed-docs] “Obtaining SDK tokens – SDK tokens are essential for authenticating and initializing the Entrust IDV SDKs”
   • [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
   • [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”
   • [claimed-docs] “You can get the expected signature of the webhook by computing the HMAC of the event request body using the SHA256 algorithm, using the webh…”
   • [claimed-docs] “Entrust recommends generating short-lived OAuth access tokens for API authentication using client credentials grant.”

   proof ↗⚑ flag

   Sumsub~partialprobed5/10

   Sumsub confirms a RESTful API, sandbox testing, and webhooks for applicant verification events, implying core lifecycle operations exist, but the evidence pack never documents explicit endpoints for session status polling, retrieving captured media, or cancel/redact actions, and probes for an OpenAPI/swagger spec all 404. Missing for 10: documented endpoints for status retrieval, media/result retrieval, and cancel/redact operations, plus a discoverable API reference (OpenAPI) confirming full lifecycle coverage.

   • [claimed-docs] “With the Sumsub API, you can process the applicant data and documents submitted for verification through simple RESTful APIs.”
   • [claimed-docs] “Use Sandbox mode to test your integration before going live.”
   • [claimed-docs] “Sumsub’s Webhooks is a tool that allows you to automatically receive notifications for various events and changes related to your applicants…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.sumsub.com/openapi.json, https://docs.sumsub.com/swagger.json, https://docs.sumsub.com/…”

   proof ↗⚑ flag

Webhooks

1. developerVerification lifecycle events arrive as signed webhooks — created, processing, verified, requires-input — so my system reacts to outcomes without polling

   weight 2 · round to Entrust Identity Verification (Onfido)
   Entrust Identity Verification (Onfido)~partialclaimed7/10

   Docs confirm webhooks can be configured to asynchronously notify status changes on workflow runs, with signed payloads verified via HMAC-SHA256, letting developers avoid polling. However, the pack never enumerates the specific lifecycle states (created, processing, verified, requires-input) claimed in the story, so exact event coverage is unconfirmed. missing for 10: explicit list of webhook event types/payload schema, independent confirmation of event granularity.

   • [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”
   • [claimed-docs] “You can get the expected signature of the webhook by computing the HMAC of the event request body using the SHA256 algorithm, using the webh…”
   • [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”

   proof ↗⚑ flag

   Sumsub~partialclaimed5/10

   Sumsub docs confirm a webhooks system that automatically notifies of applicant verification status changes, satisfying the core 'react without polling' need, but the evidence pack never documents webhook signing/signature verification or enumerates specific lifecycle event types like created/processing/verified/requires-input. missing for 10: signature verification mechanism details, explicit list of lifecycle event payload types, independent/hands-on confirmation of webhook reliability.

   • [claimed-docs] “Sumsub’s Webhooks is a tool that allows you to automatically receive notifications for various events and changes related to your applicants…”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round drawn
   Entrust Identity Verification (Onfido)~partialclaimed5/10

   Core verification actions (create applicant, start workflow run, obtain SDK token, retrieve results via webhook/polling) are documented as API operations, but Workflow Studio (workflow building) and Dashboard-based document-acceptance configuration are explicitly positioned as no-code/low-code UI tools 'without the need for developer involvement,' with no documented API equivalent for authoring or editing workflows/rules themselves. Missing for 10: API/SDK endpoints for programmatically creating or editing workflows and document-acceptance rules equivalent to what Workflow Studio and the Dashboard provide, and confirmation that NFC or other SDK-only features are reachable via pure API calls.

   • [claimed-docs] “It's a no-code, drag and drop interface that allows you to build, maintain and update workflows seamlessly without the need for developer in…”
   • [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
   • [claimed-docs] “Smart Capture Link is a low- to no-code frontend solution complementing Workflow Studio, allowing you to verify individuals with or without …”
   • [claimed-docs] “In your Dashboard, you can configure which documents you want to accept in your verification workflow, filtering according to issuing countr…”
   • [claimed-docs] “NFC is **only available for integration via the Entrust Identity Verification mobile SDKs**.”

   proof ↗⚑ flag

   Sumsub~partialprobed5/10

   Sumsub exposes a REST API for core verification flows (processing applicants/documents, webhooks, AML screening) and even an MCP server for agent-driven operations, showing strong API coverage of the verification workflow. However, several UI-configured capabilities (team member access management, branding/styles, security-key/biometric account settings) are documented only as console actions with no evidence of equivalent API endpoints, and no public OpenAPI/swagger spec was found (probe returned 404s), so full UI-API parity isn't demonstrated. Missing for 10: API/CLI equivalents for team access management, branding customization, and security settings; a public API reference confirming full endpoint coverage.

   • [claimed-docs] “With the Sumsub API, you can process the applicant data and documents submitted for verification through simple RESTful APIs.”
   • [claimed-docs] “Sumsub’s Webhooks is a tool that allows you to automatically receive notifications for various events and changes related to your applicants…”
   • [claimed-docs] “Use the MCP server to let AI agents perform Sumsub operations on your behalf, while keeping access controlled by your existing Sumsub role p…”
   • [claimed-docs] “Configure your AML screening settings to suit your needs by screening against targeted lists and categories that are relevant to your busine…”
   • [claimed-docs] “Tailor colors, styles, and step instructions to match your brand across Web and Mobile SDKs.”
   • [claimed-docs] “Grant your team members access to your Sumsub account.”
   • [claimed-docs] “Generate a security key or use biometric options to reduce the risk of account compromise.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.sumsub.com/openapi.json, https://docs.sumsub.com/swagger.json, https://docs.sumsub.com/…”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   Entrust Identity Verification (Onfido)—none0/10

   No evidence in the pack mentions data residency, regional storage options, or data localization controls for Entrust Identity Verification; the docs cover workflow building, SDK tokens, webhooks, and verification reports but say nothing about where data is stored or user choice of region.

   ⚑ flag

   Sumsub—none0/10

   No evidence in the pack mentions data residency options, regional data storage, or the ability to choose a storage location; nothing addresses this axis at all.

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Entrust Identity Verification (Onfido)—none0/10

   The evidence pack covers workflow building, SDK/API auth, webhooks, document/watchlist checks, and fraud detection, but contains no mention of data retention policies, deletion controls, or user-facing privacy/data lifecycle management. No documentation excerpt addresses how users or AI-native integrators can configure retention periods or trigger deletion of collected identity data.

   ⚑ flag

   Sumsub—none0/10

   No evidence in the pack addresses data retention policies, deletion controls, or data lifecycle management for applicant data; the docs cover verification, AML, MCP, and API features but nothing on retention/deletion mechanisms.

   ⚑ flag

Consent

1. founderThe vendor documents how biometric data is handled lawfully — GDPR bases, US biometric statutes like BIPA, and the consent language my flow needs — so legal review has something to review

   weight 2 · round drawn
   Entrust Identity Verification (Onfido)—none0/10

   The evidence pack covers technical integration (SDKs, webhooks, workflow studio, watchlist/document reports) but contains no documentation addressing GDPR legal bases, BIPA or other US biometric statutes, or consent language guidance for biometric data handling.

   ⚑ flag

   Sumsub—none0/10

   The evidence pack shows Sumsub does biometric liveness/face-match checks, but contains no documentation of legal bases (GDPR), US biometric statutes like BIPA, or consent language guidance for legal review — missing for 10: GDPR lawful-basis documentation, BIPA/state biometric statute references, consent language templates or legal review materials.

   ⚑ flag

Redaction

1. ops leadControl what happens to collected identity data — documented retention windows and a redaction or deletion API that scrubs PII on demand

   weight 2 · round drawn
   Entrust Identity Verification (Onfido)—none0/10

   None of the evidence mentions documented data retention windows or a redaction/deletion API for PII; the docs cover workflow building, SDK tokens, webhooks, watchlist reports, and biometric features but nothing about data lifecycle controls. missing for 10: retention policy documentation, deletion/redaction API endpoints, and any mention of PII scrubbing on demand.

   ⚑ flag

   Sumsub—none0/10

   No evidence pack item documents retention windows, PII redaction, or a deletion/scrubbing API — the pack covers verification levels, AML, liveness, webhooks, and MCP, none of which address data retention or deletion controls.

   ⚑ flag

Hosted flows

1. developerLaunch a complete document-plus-selfie verification with a hosted or drop-in flow — create a session server-side, redirect or embed, and read the result — without building capture UI myself

   weight 3 · round drawn
   Entrust Identity Verification (Onfido)✓fullclaimed7/10

   Docs describe the full server-side flow: create applicant, create workflow run (returns SDK token), collect document+selfie captures via drop-in/hosted SDK, and retrieve results via webhook or polling — exactly the no-build-your-own-capture-UI flow described in the story. Also supports Smart Capture Link as a hosted no-code option and webhook signature verification for secure result reads. missing for 10: no independent/hands-on developer corroboration (blog posts, sample repos, or third-party integration reports) confirming the drop-in/hosted redirect flow works end-to-end in practice.

   • [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
   • [claimed-docs] “Obtaining SDK tokens – SDK tokens are essential for authenticating and initializing the Entrust IDV SDKs”
   • [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”
   • [claimed-docs] “You can get the expected signature of the webhook by computing the HMAC of the event request body using the SHA256 algorithm, using the webh…”
   • [claimed-docs] “Smart Capture Link is a low- to no-code frontend solution complementing Workflow Studio, allowing you to verify individuals with or without …”

   proof ↗⚑ flag

   Sumsub✓fullclaimed7/10

   Docs show server-side REST API for creating verification sessions, prebuilt Web/Mobile SDKs for drop-in capture UI (document+selfie, liveness), webhooks to read verification results, and sandbox testing — covering the full story without requiring custom capture UI. Missing for 10: explicit documentation of the hosted redirect flow vs embedded SDK distinction, an explicit 'create applicant/session' API code sample, and independent/hands-on corroboration beyond first-party docs.

   • [claimed-docs] “With the Sumsub API, you can process the applicant data and documents submitted for verification through simple RESTful APIs.”
   • [claimed-docs] “A level is a sequence of steps that your applicants have to take to verify their identity. Each level may include document-based or selfie-b…”
   • [claimed-docs] “Tailor colors, styles, and step instructions to match your brand across Web and Mobile SDKs.”
   • [claimed-docs] “In under a second, it confirms the applicant is a real, live person (not a deepfake, AI-generated image, paper mask, photo of a screen, or d…”
   • [claimed-docs] “Sumsub’s Webhooks is a tool that allows you to automatically receive notifications for various events and changes related to your applicants…”
   • [claimed-docs] “Use Sandbox mode to test your integration before going live.”

   proof ↗⚑ flag

Native sdks

1. developerI get native iOS, Android, and web SDKs with guided camera capture — glare, blur, and edge detection coaching the user to a usable document photo on the first try

   weight 2 · round to Entrust Identity Verification (Onfido)
   Entrust Identity Verification (Onfido)~partialclaimed4/10

   Evidence confirms native mobile SDKs (with NFC only via mobile SDK) and an SDK-token based capture flow, and the product name 'Smart Capture' implies guided capture, but there is no explicit documentation of glare/blur/edge-detection coaching or confirmation of iOS, Android, and web SDK parity. missing for 10: explicit glare/blur/edge-detection coaching documentation, confirmation of web SDK support, first-try capture UX detail.

   • [claimed-docs] “Obtaining SDK tokens – SDK tokens are essential for authenticating and initializing the Entrust IDV SDKs”
   • [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
   • [claimed-docs] “NFC is **only available for integration via the Entrust Identity Verification mobile SDKs**.”
   • [claimed-docs] “migration guide to support migrations from the latest Smart Capture SDKs to the new Entrust IDV SDKs and highlight all new features”
   • [claimed-docs] “Smart Capture Link is a low- to no-code frontend solution complementing Workflow Studio, allowing you to verify individuals with or without …”

   proof ↗⚑ flag

   Sumsub—none0/10

   Evidence confirms Sumsub offers Web and Mobile SDKs with brand/style customization and document verification across many types, but there is no evidence describing native iOS/Android capture guidance features like glare, blur, or edge detection coaching during document photo capture. Missing for 10: explicit documentation of guided camera capture UX, glare/blur detection, and edge-detection coaching in the SDKs.

   • [claimed-docs] “Tailor colors, styles, and step instructions to match your brand across Web and Mobile SDKs.”
   • [claimed-docs] “Instantly verify 14,000+ document types from 220+ countries and territories.”

   proof ↗⚑ flag

No code

1. ops leadSend a verification to someone with a no-code link or QR code — no engineering ticket to verify a one-off customer, contractor, or seller

   weight 2 · round to Entrust Identity Verification (Onfido)
   Entrust Identity Verification (Onfido)~partialclaimed6/10

   Smart Capture Link is documented as a low-/no-code frontend that lets ops verify individuals without engineering effort, aligning with the no-code link concept, and Workflow Studio supports drag-and-drop workflow setup without developers. However, there is no explicit mention of a shareable QR code option or a simple 'send a one-off link' flow from a dashboard for ad-hoc individuals like contractors or sellers. missing for 10: explicit QR code generation/sharing feature, documentation of an ops-friendly one-off invite/send flow, independent or hands-on confirmation of ease-of-use for non-technical ops staff.

   • [claimed-docs] “Smart Capture Link is a low- to no-code frontend solution complementing Workflow Studio, allowing you to verify individuals with or without …”
   • [claimed-docs] “It's a no-code, drag and drop interface that allows you to build, maintain and update workflows seamlessly without the need for developer in…”

   proof ↗⚑ flag

   Sumsub—none0/10

   The evidence pack covers APIs, SDKs, webhooks, verification levels, AML screening, and an MCP server, but contains no mention of a no-code shareable verification link or QR code that an ops person could generate and send without engineering involvement.

   ⚑ flag

Reuse

1. developerA person verified once can be recognized and reused across sessions or products — documented re-verification and reuse of a prior passed check instead of forcing a full re-run

   weight 2 · round to Sumsub
   Entrust Identity Verification (Onfido)—none0/10

   The docs describe repeat-face detection for fraud purposes (flagging faces that already went through verification) but this is a fraud-detection alert, not a documented mechanism for reusing a prior passed check to skip re-verification across sessions or products. No evidence of a 'reusable identity' or portable verification token/credential feature.

   • [claimed-docs] “The alerts you to faces which have already been through your identity verification flow, highlighting potential repeat identity fraud attemp…”

   proof ↗⚑ flag

   Sumsub✓fullclaimed8/10

   Sumsub explicitly documents Reusable KYC, letting clients share verification data via agreement with other Sumsub clients so applicants can reuse a prior passed check instead of re-running full verification. This directly matches the story's theme of recognizing and reusing a verified identity across products/sessions. Missing for 10: no independent/hands-on corroboration of reuse working across separate live products, and no detail on cross-session recognition mechanics (e.g., token/session persistence) beyond the Reusable KYC agreement model.

   • [claimed-docs] “With Reusable KYC, you can conclude an agreement with other Sumsub clients to share verification data, and enable applicant data reuse to co…”

   proof ↗⚑ flag

Analytics

1. founderSee verification funnel analytics — pass rates, drop-off points, completion time by country and document type — to know what verification is costing me in signups

   weight 2 · round drawn
   Entrust Identity Verification (Onfido)—none0/10

   Evidence covers workflow configuration, SDK/webhook integration, document/watchlist checks, and fraud detection, but nothing about a dashboard or reporting feature showing pass rates, drop-off funnels, or completion time broken down by country/document type. No analytics or reporting evidence exists to support this founder-facing metrics story.

   ⚑ flag

   Sumsub—none0/10

   The evidence pack covers API, webhooks, verification levels, AML, liveness, MCP server, and account management, but contains no mention of analytics dashboards, funnel/pass-rate reporting, drop-off analysis, or completion time breakdowns by country/document type.

   ⚑ flag

Review

1. ops leadBorderline verifications land in a manual review queue with the full evidence — document images, extracted fields, check results — and reviewer decisions feed back into the record

   weight 2 · round to Sumsub
   Entrust Identity Verification (Onfido)—none0/10

   The evidence pack documents workflow orchestration, SDKs, webhooks, watchlist/document reports, and dashboard configuration, but nowhere describes a manual review queue that surfaces document images, extracted fields, and check results together, nor a feedback loop where reviewer decisions update the record. Missing for 10: explicit manual review queue documentation, evidence bundling for reviewers, and reviewer decision feedback into the applicant record.

   ⚑ flag

   Sumsub~partialclaimed4/10

   Sumsub's docs show applicant profiles where reviewers can inspect check results (e.g., liveness section) and levels aggregate document/selfie/liveness checks, implying some review workflow, but there is no explicit documentation of a dedicated manual review queue for borderline cases or of how reviewer decisions are written back into the applicant record. missing for 10: explicit manual review queue feature docs, description of extracted-field/document display in review UI, evidence that reviewer decisions feed back into verification status/record.

   • [claimed-docs] “Open the Applicants page and select an applicant who passed the Liveness check. In the profile, navigate to the Liveness section and review …”
   • [claimed-docs] “A level is a sequence of steps that your applicants have to take to verify their identity. Each level may include document-based or selfie-b…”

   proof ↗⚑ flag

Workflows

1. ops leadConfigure verification logic without code — conditional steps, risk-based routing, country-specific requirements, and template changes that don't need an engineering deploy

   weight 3 · round to Entrust Identity Verification (Onfido)
   Entrust Identity Verification (Onfido)~partialclaimed7/10

   Workflow Studio is explicitly documented as a no-code, drag-and-drop tool for building/maintaining/updating workflows without developer involvement, and the Dashboard lets ops filter accepted documents by issuing country — both directly support code-free verification-logic configuration. However, the evidence never explicitly confirms conditional branching or risk-based routing logic within Workflow Studio, only general workflow building and document/country filtering. Missing for 10: explicit documentation of conditional-step/risk-based routing configuration, and independent/hands-on confirmation that template changes deploy live without engineering involvement.

   • [claimed-docs] “It's a no-code, drag and drop interface that allows you to build, maintain and update workflows seamlessly without the need for developer in…”
   • [claimed-docs] “Smart Capture Link is a low- to no-code frontend solution complementing Workflow Studio, allowing you to verify individuals with or without …”
   • [claimed-docs] “In your Dashboard, you can configure which documents you want to accept in your verification workflow, filtering according to issuing countr…”

   proof ↗⚑ flag

   Sumsub~partialclaimed5/10

   Docs confirm verification 'levels' as configurable sequences of steps with many check types and adjustable AML screening settings, implying dashboard-based configuration rather than code changes (sumsub-docs-5, sumsub-docs-6). However, there is no explicit evidence of conditional branching logic, risk-based routing rules, or country-specific requirement templates being configurable without an engineering deploy. Missing for 10: explicit no-code workflow/conditional-logic builder documentation, evidence of risk-based routing configuration, and country-specific rule templates managed purely via UI without deploys.

   • [claimed-docs] “A level is a sequence of steps that your applicants have to take to verify their identity. Each level may include document-based or selfie-b…”
   • [claimed-docs] “Configure your AML screening settings to suit your needs by screening against targeted lists and categories that are relevant to your busine…”
   • [claimed-docs] “Instantly verify 14,000+ document types from 220+ countries and territories.”

   proof ↗⚑ flag

Monitoring

1. ops leadScreening is not one-shot — previously verified users are continuously re-screened against watchlist updates, and changes raise events I can act on

   weight 2 · round to Sumsub
   Entrust Identity Verification (Onfido)—none0/10

   Evidence documents one-time Watchlist Reports (sanctions, PEP, monitored lists, adverse media) run during a verification workflow, plus webhooks that notify on workflow status changes — but nothing describes ongoing/continuous re-screening of previously verified applicants against watchlist updates or dedicated 'watchlist changed' events after the initial check.

   • [claimed-docs] “Watchlist reports verify an applicant's records against a range of global watchlists, including: Sanctions... Politically Exposed Persons (P…”
   • [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”

   proof ↗⚑ flag

   Sumsub~partialclaimed5/10

   Sumsub documents configurable AML/watchlist screening (sumsub-docs-6) and a generic webhook system for verification-related events and changes (sumsub-docs-3), which together imply an ops lead could be notified of screening changes, but the evidence never explicitly confirms ongoing/continuous re-screening of already-approved applicants against watchlist updates or that such updates specifically fire webhook events. Missing for 10: explicit documentation of automated periodic re-screening post-approval, and confirmation that watchlist-update hits generate a distinct actionable event/webhook type.

   • [claimed-docs] “Configure your AML screening settings to suit your needs by screening against targeted lists and categories that are relevant to your busine…”
   • [claimed-docs] “Sumsub’s Webhooks is a tool that allows you to automatically receive notifications for various events and changes related to your applicants…”

   proof ↗⚑ flag

Screening

1. ops leadScreen verified users against sanctions, PEP, and adverse-media watchlists as part of the same verification — one vendor, one API, one review surface

   weight 2 · round drawn
   Entrust Identity Verification (Onfido)✓fullclaimed8/10

   Docs explicitly describe Watchlist reports covering Sanctions, PEPs, Monitored Lists, and Adverse Media, integrated into the same workflow/API/dashboard used for identity verification (single vendor, single API, unified webhook/review surface). missing for 10: no independent/hands-on corroboration of the unified review UI or case-management workflow for screening hits.

   • [claimed-docs] “Watchlist reports verify an applicant's records against a range of global watchlists, including: Sanctions... Politically Exposed Persons (P…”
   • [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
   • [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”

   proof ↗⚑ flag

   Sumsub✓fullclaimed8/10

   Sumsub documents configurable AML screening (sanctions, PEP, adverse media implied by 'categories') integrated into the same verification flow/API and reviewable via the applicant profile alongside other checks, all under one platform. Missing for 10: explicit mention of adverse-media list coverage and independent/hands-on corroboration of screening accuracy or review UI beyond docs.

   • [claimed-docs] “Configure your AML screening settings to suit your needs by screening against targeted lists and categories that are relevant to your busine…”
   • [claimed-docs] “A level is a sequence of steps that your applicants have to take to verify their identity. Each level may include document-based or selfie-b…”
   • [claimed-docs] “Open the Applicants page and select an applicant who passed the Liveness check. In the profile, navigate to the Liveness section and review …”
   • [claimed-docs] “With the Sumsub API, you can process the applicant data and documents submitted for verification through simple RESTful APIs.”

   proof ↗⚑ flag