Entrust Identity Verification (Onfido) vs Veriff

Agent access

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

   weight 2 · round drawn
   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

   Veriff✓fullprobed8/10

   Veriff hosts a live llms.txt at devdocs.veriff.com/llms.txt (confirmed HTTP 200 via probe) that indexes structured dev docs, directly enabling an AI agent to be pointed at agent-oriented documentation. Missing for 10: no OpenAPI/machine-readable spec (openapi.json 404s) and no explicit vendor messaging about AI-agent consumption of the docs.

   • [probe] “PROBE llms.txt: HTTP 200 at https://devdocs.veriff.com/llms.txt # Veriff Dev Documentation > Knowledge base documentation for Veriff Dev Do…”
   • [claimed-docs] “Learn how to manually review and manage verification sessions in the Veriff Customer Portal.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://devdocs.veriff.com/openapi.json, https://devdocs.veriff.com/swagger.json, https://devdocs.ve…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Veriff~partialclaimed5/10

   Veriff exposes a REST API (create session, poll decision, webhooks) and dedicated test integrations where decisions can be triggered programmatically without paid usage, which supports scripted/CI-style testing of the integration logic. However, the core verification itself requires an end-user completing an SDK-driven capture flow, so full headless automation of real verifications is not documented. missing for 10: explicit CI/automation guide, example of running full flow with no human/SDK interaction, and any mention of CI pipelines or automation frameworks.

   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [claimed-docs] “Any verification session done in the test integrations **do not count towards paid usage**.”
   • [claimed-docs] “You can trigger decisions for test integration sessions.”
   • [claimed-docs] “Batch upload tests are **sometimes** agreed with Veriff onboarding team and are **very use case specific**.”

   proof ↗⚑ flag

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

   weight 3 · 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

   Veriff—none0/10

   Veriff is an identity verification SaaS with a REST API, SDKs, and webhooks, but no evidence of an official MCP server for agent connectivity; this is a fair axis for a SaaS API product, so absence of evidence yields none.

   • [claimed-docs] “Pass end-user data via API and check out endpoint behavior”
   • [claimed-docs] “Bring the end-user to verification flow using web or native SDKs”
   • [claimed-docs] “Set up webhooks to get responses from Veriff”
   • [probe] “PROBE openapi: all candidate paths 404 (https://devdocs.veriff.com/openapi.json, https://devdocs.veriff.com/swagger.json, https://devdocs.ve…”

   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

   Veriff—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 Veriff
   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

   Veriff✓fullprobed8/10

   Veriff exposes a documented REST API (session creation, decision polling, HMAC-signed webhooks, authentication) with dedicated devdocs, matching an AI-native user's need to drive the product programmatically. Missing for 10: a discoverable OpenAPI/Swagger spec (probe found only 404s) and independent third-party confirmation of API usage.

   • [claimed-docs] “Pass end-user data via API and check out endpoint behavior”
   • [claimed-docs] “the shared secret key, used to create the X-HMAC-SIGNATURE header”
   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [claimed-docs] “Veriff uses the HMAC-SIGNATURES (as `x-hmac-signature` header or `VRF-HMAC-SIGNATURE` header) and allowed IP lists and ranges for that purpo…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://devdocs.veriff.com/openapi.json, https://devdocs.veriff.com/swagger.json, https://devdocs.ve…”

   proof ↗⚑ flag

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

   weight 2 · round to Entrust Identity Verification (Onfido)
   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

   Veriff—none0/10

   Veriff's API auth model is a single shared-secret HMAC key (X-HMAC-SIGNATURE) plus optional IP allowlisting, not a scoped/least-privilege credential system with per-agent roles or permissions. No evidence of API key scoping, granular roles, or credential issuance tailored to individual agents.

   • [claimed-docs] “the shared secret key, used to create the X-HMAC-SIGNATURE header”
   • [claimed-docs] “Veriff uses the HMAC-SIGNATURES (as `x-hmac-signature` header or `VRF-HMAC-SIGNATURE` header) and allowed IP lists and ranges for that purpo…”

   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

   Veriff~partialprobed5/10

   Veriff docs reference web and native SDKs plus a REST API with webhooks and HMAC auth, giving developers official building blocks, but there is no OpenAPI/swagger spec (probe found 404s) and no evidence of language-specific SDK repos, versioning, or AI-agent-friendly machine-readable schemas. Missing for 10: OpenAPI/machine-readable spec, list of concrete SDK languages/repos, independent developer corroboration.

   • [claimed-docs] “Bring the end-user to verification flow using web or native SDKs”
   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Veriff uses the HMAC-SIGNATURES (as `x-hmac-signature` header or `VRF-HMAC-SIGNATURE` header) and allowed IP lists and ranges for that purpo…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://devdocs.veriff.com/openapi.json, https://devdocs.veriff.com/swagger.json, https://devdocs.ve…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Veriff
   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

   Veriff✓fullclaimed8/10

   Veriff has documented webhook support with HMAC-signed payloads for verification decisions, including setup docs and security details (X-HMAC-SIGNATURE, IP allowlisting), which allows event-driven/agentic integration rather than only polling. Missing for 10: no independent/hands-on corroboration of webhook reliability or payload schema details, and no explicit mention of event types beyond decision webhooks.

   • [claimed-docs] “Set up webhooks to get responses from Veriff”
   • [claimed-docs] “the shared secret key, used to create the X-HMAC-SIGNATURE header”
   • [claimed-docs] “Veriff uses the HMAC-SIGNATURES (as `x-hmac-signature` header or `VRF-HMAC-SIGNATURE` header) and allowed IP lists and ranges for that purpo…”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”

   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

   Veriff~partialclaimed5/10

   Veriff's API supports asynchronous background processing via webhooks and decision polling (create a session, then get notified via webhook when a decision is ready), which enables automations that run without direct user interaction. However, there is no evidence of AI-agent-specific orchestration, scheduling, or autonomous multi-step workflow tooling beyond basic webhook/polling patterns. Missing for 10: explicit support for autonomous agent orchestration, scheduled/triggered workflows beyond single verification sessions, and any AI-native automation framework or SDK.

   • [claimed-docs] “Set up webhooks to get responses from Veriff”
   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [claimed-docs] “You can trigger decisions for test integration sessions.”

   proof ↗⚑ flag

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

   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

   Veriff—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

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

   Veriff—none0/10

   Veriff's devdocs describe API endpoints (sessions, webhooks, HMAC auth) but there is no evidence of an interactive reference with runnable/try-it examples; a probe for OpenAPI/Swagger specs at devdocs.veriff.com returned 404s, indicating no machine-readable spec backing an interactive console.

   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [probe] “PROBE openapi: all candidate paths 404 (https://devdocs.veriff.com/openapi.json, https://devdocs.veriff.com/swagger.json, https://devdocs.ve…”

   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

   Veriff—none0/10

   Explicit probe evidence shows all common OpenAPI/Swagger spec paths return 404, and no documented download link for a machine-readable spec exists anywhere in the docs pack.

   • [probe] “PROBE openapi: all candidate paths 404 (https://devdocs.veriff.com/openapi.json, https://devdocs.veriff.com/swagger.json, https://devdocs.ve…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://devdocs.veriff.com/llms.txt # Veriff Dev Documentation > Knowledge base documentation for Veriff Dev Do…”

   proof ↗⚑ flag

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

   weight 1 · round to Veriff
   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

   Veriff✓fullclaimed7/10

   Veriff explicitly documents test integrations where sessions 'do not count towards paid usage' and decisions can be manually triggered without real verification data, effectively serving as a sandbox for API testing. missing for 10: no explicit mention of full data isolation guarantees, no independent/hands-on confirmation of sandbox fidelity, and OpenAPI spec probes returned 404 suggesting limited machine-readable API test tooling.

   • [claimed-docs] “Any verification session done in the test integrations **do not count towards paid usage**.”
   • [claimed-docs] “You can trigger decisions for test integration sessions.”
   • [claimed-docs] “Batch upload tests are **sometimes** agreed with Veriff onboarding team and are **very use case specific**.”

   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

   Veriff—none0/10

   Evidence shows Veriff's API uses versioned paths (e.g. /v1/sessions) but there is no documentation of a versioning scheme, deprecation policy, changelog, or sunset timeline; OpenAPI spec probes returned 404. Missing for 10: documented API versioning/deprecation policy, changelog or migration guides, and any explicit commitment to backward compatibility.

   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [probe] “PROBE openapi: all candidate paths 404 (https://devdocs.veriff.com/openapi.json, https://devdocs.veriff.com/swagger.json, https://devdocs.ve…”

   proof ↗⚑ flag

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

   weight 2 · round to Veriff
   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

   Veriff~partialclaimed2/10

   Veriff's API is built around creating and polling individual verification sessions (docs-6, docs-7), with no documented bulk/batch API endpoint for processing many items in one call. The only mention of batch capability is 'Batch upload tests' that are ad-hoc, negotiated with the onboarding team, and 'very use case specific' rather than a standard bulk feature. Missing for 10: a documented bulk/batch API endpoint, SDK support for multi-item submission, and evidence of automated large-scale batch processing.

   • [claimed-docs] “Batch upload tests are **sometimes** agreed with Veriff onboarding team and are **very use case specific**.”
   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”

   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

   Veriff~partialclaimed3/10

   Veriff supports webhooks to notify external systems of verification events, which is a basic building block for event-driven automation, but there is no evidence of a rule-definition system or conditional logic engine that lets users configure custom triggers/actions within Veriff itself. missing for 10: rule engine or conditional automation builder, evidence of user-configurable trigger logic beyond simple webhook delivery, AI-native automation tooling.

   • [claimed-docs] “Set up webhooks to get responses from Veriff”
   • [claimed-docs] “You can trigger decisions for test integration sessions.”

   proof ↗⚑ 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 drawn
   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

   Veriff—none0/10

   The only relevant evidence (veriff-docs-11) is a single generic marketing-style sentence claiming the liveness solution 'ensures biometric data is from a live person' — it names no specific detection capabilities (e.g., anti-spoofing models, deepfake detection, camera-injection detection) as the story requires. Missing for 10: named technical defenses against AI-generated faces, deepfake detection methodology, camera/virtual-camera injection detection, and any independent validation of these claims.

   • [claimed-docs] “Veriff Biometric Liveness solution ensures that the biometric data being captured is from a live person, significantly reducing the risk of …”

   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

   Veriff—none0/10

   Evidence covers session creation, webhooks, HMAC auth, biometric liveness (live-person spoof detection) and manual review in the portal, but nothing describes cross-session duplicate/repeat-identity detection (e.g., flagging the same face or document reappearing under a different name). Biometric liveness [veriff-docs-11] only addresses spoof/liveness, not identity deduplication across verifications.

   • [claimed-docs] “Veriff Biometric Liveness solution ensures that the biometric data being captured is from a live person, significantly reducing the risk of …”
   • [claimed-docs] “Learn how to manually review and manage verification sessions in the Veriff Customer Portal.”
   • [claimed-docs] “Manually: the **Verifications page in the** Veriff Customer Portal”

   proof ↗⚑ 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 Entrust Identity Verification (Onfido)
   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

   Veriff~partialclaimed4/10

   Veriff's docs confirm a dedicated biometric liveness feature that verifies the captured biometric data comes from a live person, matching the core story of selfie-to-document liveness matching, but there is no detail on specific anti-spoofing defenses (printed photo, screen replay, video injection) or any independent certification/testing evidence. Missing for 10: documented defenses against specific spoof types (print/screen/replay), independent liveness certification (e.g., iBeta/NIST), and hands-on/third-party validation of match accuracy.

   • [claimed-docs] “Veriff Biometric Liveness solution ensures that the biometric data being captured is from a live person, significantly reducing the risk of …”

   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

   Veriff—none0/10

   All evidence describes Veriff's document- and biometric-based verification flows (session creation, SDKs, webhooks, liveness) plus a PEP/Sanctions add-on, but nothing shows a no-document database-only check against SSN, national registry, or credit-header data. missing for 10: any API/doc showing a no-doc data-only verification mode, evidence of SSN/registry/credit-header lookups.

   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Veriff Biometric Liveness solution ensures that the biometric data being captured is from a live person, significantly reducing the risk of …”
   • [claimed-docs] “PEP & Sanctions check (+$0.64)”

   proof ↗⚑ 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

   Veriff—none0/10

   All evidence describes person-level identity verification (KYC) via sessions, SDKs, webhooks, biometric liveness, and PEP/sanctions checks; nothing addresses business registry lookups, UBO identification, or a documented KYB flow chaining into KYC of owners. Missing for 10: business registry/company lookup API, UBO identification workflow, KYB-to-KYC chaining documentation, any KYB product page or endpoint.

   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “PEP & Sanctions check (+$0.64)”
   • [claimed-docs] “Veriff Biometric Liveness solution ensures that the biometric data being captured is from a live person, significantly reducing the risk of …”

   proof ↗⚑ 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

   Veriff—none0/10

   Evidence covers document/biometric verification, webhooks, HMAC auth, and PEP & sanctions checks, but nothing documents phone/email/device risk signals such as carrier checks, address history, or device fingerprinting as check types.

   • [claimed-docs] “Veriff Biometric Liveness solution ensures that the biometric data being captured is from a live person, significantly reducing the risk of …”
   • [claimed-docs] “PEP & Sanctions check (+$0.64)”

   proof ↗⚑ 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 Entrust Identity Verification (Onfido)
   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

   Veriff—none0/10

   The evidence pack contains only API/SDK/webhook integration docs, HMAC auth, biometric liveness, and pricing add-ons — none of it lists supported countries or document types (passports, national IDs, driver licenses, residence permits) or points to a published coverage list.

   ⚑ 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

   Veriff—none0/10

   The evidence pack shows session creation, decision polling, and webhook endpoints, but nothing documents that extracted document fields (name, DOB, document number, address, expiry) are returned as structured data via the API — only pass/fail-style 'decision' retrieval is mentioned.

   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [claimed-docs] “You can trigger decisions for test integration sessions.”

   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

   Veriff~partialprobed6/10

   Veriff's API returns structured decision data via session creation, polling GET /v1/sessions/{id}/decision, and webhooks with HMAC-verified payloads, which an automated flow could branch on; docs also mention risk-related add-ons like PEP & Sanctions checks. However, there's no evidence of a documented schema for risk signals/failure-reason codes, no OpenAPI spec (probe found 404s), and manual review via the Customer Portal is emphasized alongside automation, suggesting outcomes aren't always fully machine-resolved. Missing for 10: published response schema/enum of failure reasons and risk signal fields, OpenAPI spec for structured parsing, and evidence of fully automated (non-manual-review) decisioning suitable for agent branching.

   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [claimed-docs] “Set up webhooks to get responses from Veriff”
   • [claimed-docs] “Veriff uses the HMAC-SIGNATURES (as `x-hmac-signature` header or `VRF-HMAC-SIGNATURE` header) and allowed IP lists and ranges for that purpo…”
   • [claimed-docs] “Manually: the **Verifications page in the** Veriff Customer Portal”
   • [claimed-docs] “PEP & Sanctions check (+$0.64)”
   • [probe] “PROBE openapi: all candidate paths 404 (https://devdocs.veriff.com/openapi.json, https://devdocs.veriff.com/swagger.json, https://devdocs.ve…”

   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 drawn
   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

   Veriff~partialprobed5/10

   Veriff's API supports the core pipeline pieces an agent would need: creating sessions (veriff-docs-6), polling decision status (veriff-docs-7), webhook-based outcome delivery (veriff-docs-3), and scoped credential auth via HMAC/shared-secret and IP allowlisting (veriff-docs-5, veriff-docs-10). However there is no MCP server or agent-oriented surface, no clear 'retrieve extracted data' endpoint distinct from decision polling, and re-check/decision-triggering is only documented for test integrations (veriff-docs-9), not general production re-checks; a probe for a machine-readable OpenAPI spec also 404'd (veriff-probe-2). missing for 10: MCP surface, documented extracted-data retrieval endpoint, production re-check trigger, discoverable OpenAPI schema.

   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [claimed-docs] “Set up webhooks to get responses from Veriff”
   • [claimed-docs] “the shared secret key, used to create the X-HMAC-SIGNATURE header”
   • [claimed-docs] “Veriff uses the HMAC-SIGNATURES (as `x-hmac-signature` header or `VRF-HMAC-SIGNATURE` header) and allowed IP lists and ranges for that purpo…”
   • [claimed-docs] “You can trigger decisions for test integration sessions.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://devdocs.veriff.com/openapi.json, https://devdocs.veriff.com/swagger.json, https://devdocs.ve…”

   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 Veriff
   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

   Veriff~partialclaimed6/10

   Veriff docs confirm a test integration mode where sessions don't count toward paid usage and where developers can explicitly trigger decisions for test sessions, supporting a sandbox-like exercise of outcomes. However, there's no documented catalog of specific test documents/personas or magic values that deterministically map to pass/fail/review, and batch/service-quality testing is described as ad hoc and use-case-specific rather than self-serve. Missing for 10: documented magic-value/test-document list per outcome, self-serve deterministic mapping without onboarding-team coordination, independent confirmation of sandbox fidelity.

   • [claimed-docs] “Any verification session done in the test integrations **do not count towards paid usage**.”
   • [claimed-docs] “You can trigger decisions for test integration sessions.”
   • [claimed-docs] “Batch upload tests are **sometimes** agreed with Veriff onboarding team and are **very use case specific**.”

   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

   Veriff~partialclaimed5/10

   Docs clearly cover creating a session, polling for decision/status, webhooks, and passing end-user data (veriff-docs-1, veriff-docs-6, veriff-docs-7, veriff-docs-3), but there's no evidence of API endpoints for retrieving captured media, or for cancelling/redacting a session — review/management is instead shown via the Customer Portal UI (veriff-docs-12, veriff-docs-13), not the API. missing for 10: documented API endpoints for retrieving captured media, and for cancel/redact/delete operations.

   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [claimed-docs] “Pass end-user data via API and check out endpoint behavior”
   • [claimed-docs] “Set up webhooks to get responses from Veriff”
   • [claimed-docs] “Learn how to manually review and manage verification sessions in the Veriff Customer Portal.”
   • [claimed-docs] “Manually: the **Verifications page in the** Veriff Customer Portal”

   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

   Veriff~partialclaimed6/10

   Veriff docs confirm webhooks are the primary integration path (with polling only as a fallback) and that responses are authenticated via HMAC signature headers, matching the 'signed webhooks instead of polling' pattern. However, the evidence never enumerates the specific lifecycle event types (created, processing, verified, requires-input) or shows a payload schema/event-type list confirming granular status callbacks. Missing for 10: explicit event-type/status enumeration in webhook payloads, sample payload showing verification state transitions, independent/hands-on confirmation of signature verification working in practice.

   • [claimed-docs] “Set up webhooks to get responses from Veriff”
   • [claimed-docs] “the shared secret key, used to create the X-HMAC-SIGNATURE header”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [claimed-docs] “Veriff uses the HMAC-SIGNATURES (as `x-hmac-signature` header or `VRF-HMAC-SIGNATURE` header) and allowed IP lists and ranges for that purpo…”

   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

   Veriff~partialprobed5/10

   Veriff's API covers the core verification lifecycle (session creation, decision retrieval, webhooks, HMAC auth) per veriff-docs-6/7/3/10, but its own docs show manual review and case management are portal-only ('Verifications page in the Veriff Customer Portal', veriff-docs-12/13), and PDF export appears tied to the portal (veriff-docs-14), indicating UI-only functionality not mirrored in the API. No OpenAPI spec is discoverable (veriff-probe-2), limiting confidence that full API parity/documentation exists for programmatic exploration. Missing for 10: evidence of API endpoints for manual review/case management, PDF export via API, and a public OpenAPI spec confirming full endpoint coverage.

   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [claimed-docs] “Set up webhooks to get responses from Veriff”
   • [claimed-docs] “Veriff uses the HMAC-SIGNATURES (as `x-hmac-signature` header or `VRF-HMAC-SIGNATURE` header) and allowed IP lists and ranges for that purpo…”
   • [claimed-docs] “Learn how to manually review and manage verification sessions in the Veriff Customer Portal.”
   • [claimed-docs] “Manually: the **Verifications page in the** Veriff Customer Portal”
   • [claimed-docs] “Export verification session details to PDF”
   • [probe] “PROBE openapi: all candidate paths 404 (https://devdocs.veriff.com/openapi.json, https://devdocs.veriff.com/swagger.json, https://devdocs.ve…”

   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

   Veriff—none0/10

   No evidence pack items mention data residency, regional storage options, or GDPR-style data localization controls; none of the docs address where verification data is stored or configurable region choice.

   ⚑ 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

   Veriff—none0/10

   Evidence covers session creation, webhooks, HMAC security, and manual review, but nothing addresses data retention periods, deletion requests, or user-initiated data control/removal APIs.

   ⚑ 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

   Veriff—none0/10

   The evidence pack only covers API/SDK integration mechanics, biometric liveness feature descriptions, and pricing — there is no documentation of GDPR legal bases, BIPA or other US biometric statute compliance, or consent language guidance for legal review.

   ⚑ 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

   Veriff—none0/10

   Evidence covers session creation, decisions, webhooks, HMAC auth, and manual review in the portal, but nothing documents data retention windows or a redaction/deletion API for scrubbing PII on demand.

   ⚑ 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 to Veriff
   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

   Veriff✓fullclaimed8/10

   Docs confirm the core flow: create a session server-side via POST /v1/sessions, bring the end-user to verification via hosted or embedded web/native SDKs, and read results via webhook or by polling the decision endpoint — covering document+selfie/liveness capture without building custom capture UI. missing for 10: no independent/hands-on developer corroboration of the end-to-end flow and no explicit confirmation that both document and selfie capture are bundled by default in the hosted flow.

   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Bring the end-user to verification flow using web or native SDKs”
   • [claimed-docs] “Set up webhooks to get responses from Veriff”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [claimed-docs] “Veriff Biometric Liveness solution ensures that the biometric data being captured is from a live person, significantly reducing the risk of …”
   • [claimed-docs] “No-code identity verification solution”

   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

   Veriff~partialclaimed3/10

   Docs confirm native and web SDKs exist for bringing users into the verification flow, but there is no evidence describing guided capture UX details like glare, blur, or edge detection coaching. missing for 10: SDK feature documentation on real-time image quality checks, glare/blur detection, edge detection guidance, and any independent/hands-on validation of first-try capture success.

   • [claimed-docs] “Bring the end-user to verification flow using web or native SDKs”
   • [claimed-docs] “Veriff Biometric Liveness solution ensures that the biometric data being captured is from a live person, significantly reducing the risk of …”

   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

   Veriff~partialclaimed4/10

   Veriff explicitly advertises a 'No-code identity verification solution' (veriff-docs-4) and a Customer Portal for managing verifications (veriff-docs-12/13), suggesting some no-code capability exists, but the evidence pack never details a shareable link or QR-code workflow, session creation without API/engineering involvement, or a portal UI for generating one-off verification requests. Missing for 10: explicit documentation of link/QR-code generation in the portal, confirmation that ops staff (not engineers) can trigger sessions without API calls, and any UI screenshots or workflow docs for one-off verification requests.

   • [claimed-docs] “No-code identity verification solution”
   • [claimed-docs] “Learn how to manually review and manage verification sessions in the Veriff Customer Portal.”
   • [claimed-docs] “Manually: the **Verifications page in the** Veriff Customer Portal”

   proof ↗⚑ 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 drawn
   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

   Veriff—none0/10

   The evidence pack covers session creation, decisions, webhooks, HMAC auth, and manual review, but nothing documents identity reuse/portability — e.g., a 'reuse prior passed verification' or cross-session/cross-product identity linking feature. Each session creation doc (veriff-docs-6) implies a fresh verification flow rather than recognizing a previously verified person.

   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”

   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

   Veriff—none0/10

   Evidence covers session creation, webhooks, HMAC auth, manual review portal, and PDF export, but nothing describes funnel analytics, pass-rate dashboards, drop-off analysis, completion-time metrics, or 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 Veriff
   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

   Veriff~partialclaimed5/10

   Docs confirm a manual review queue exists in the Veriff Customer Portal (Verifications page) where sessions can be reviewed and decisions triggered/exported, and webhooks/API decision endpoints propagate results back into the record. However, the evidence pack does not detail what evidence reviewers see (document images, extracted fields, check results) or explicitly describe how reviewer decisions are written back to the underlying verification record beyond the decision endpoint. Missing for 10: documentation of the reviewer UI's evidence display (images/fields/check results), explicit reviewer-decision-to-record feedback mechanism, and independent/hands-on corroboration.

   • [claimed-docs] “Learn how to manually review and manage verification sessions in the Veriff Customer Portal.”
   • [claimed-docs] “Manually: the **Verifications page in the** Veriff Customer Portal”
   • [claimed-docs] “You can trigger decisions for test integration sessions.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [claimed-docs] “Set up webhooks to get responses from Veriff”

   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

   Veriff~partialclaimed3/10

   The devdocs reference a 'No-code identity verification solution' and a Customer Portal for managing verification sessions/decisions, suggesting some no-code configuration exists, but there is no concrete evidence of conditional step logic, risk-based routing, country-specific requirement rules, or template editing without an engineering deploy. missing for 10: documented conditional/branching logic builder, risk-based routing rules, country-specific requirement configuration, and template editing workflow evidence.

   • [claimed-docs] “No-code identity verification solution”
   • [claimed-docs] “Learn how to manually review and manage verification sessions in the Veriff Customer Portal.”
   • [claimed-docs] “Manually: the **Verifications page in the** Veriff Customer Portal”

   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 drawn
   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

   Veriff—none0/10

   Evidence only shows a one-time PEP & Sanctions check at verification time and generic webhooks for session decisions; there is no mention of continuous re-screening of previously verified users against updated watchlists or of events triggered by post-verification watchlist changes.

   • [claimed-docs] “PEP & Sanctions check (+$0.64)”
   • [claimed-docs] “Set up webhooks to get responses from Veriff”

   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 to Entrust Identity Verification (Onfido)
   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

   Veriff~partialclaimed6/10

   Veriff's pricing page confirms a PEP & Sanctions check add-on ($0.64) that integrates into the same verification flow/API, and the Customer Portal already supports manual review of verification sessions, suggesting one vendor/API for both identity and watchlist screening. However, adverse-media screening is not explicitly mentioned, and there's no dedicated documentation showing watchlist hits surfaced in the same review UI as biometric/identity results. Missing for 10: explicit adverse-media watchlist coverage, and documentation showing unified review surface combining identity + watchlist results.

   • [claimed-docs] “PEP & Sanctions check (+$0.64)”
   • [claimed-docs] “Learn how to manually review and manage verification sessions in the Veriff Customer Portal.”
   • [claimed-docs] “Manually: the **Verifications page in the** Veriff Customer Portal”
   • [claimed-docs] “Export verification session details to PDF”

   proof ↗⚑ flag