Sumsub vs Veriff

Agent access

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

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

   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 to Sumsub
   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

   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 to Sumsub
   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

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

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

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

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

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

   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 userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round drawn
   Sumsub—none0/10

   Evidence covers AI-driven verification checks (liveness, document verification, AML screening) and an MCP server for agents to perform actions, but there is no evidence of AI-generated insights, summaries, or suggestions surfaced to users from their own data inside the product dashboard. missing for 10: any documented AI-generated analytics/insights feature, dashboard summarization, or recommendation engine within the Sumsub UI.

   • [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] “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] “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

   Veriff—none0/10

   Evidence covers identity verification APIs, webhooks, HMAC auth, manual review portal, and pricing add-ons, but nothing indicates AI-generated insights or suggestions surfaced to users from their data. This is a verification/fraud-check product, not an analytics/insight tool, and no such feature is documented.

   ⚑ flag

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

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

   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

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

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

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

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

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

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

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

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

   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 to Sumsub
   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

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

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

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

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

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

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

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

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

   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 to Sumsub
   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

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

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

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

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

   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

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round drawn
   Sumsub—none0/10

   Sumsub is a KYC/verification platform storing applicant data, but no evidence shows a user-facing data export feature in open/portable formats or an account-closure data portability workflow; only API access for processing applicant data during integration is documented, not a 'take your data and leave' capability.

   • [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…”

   proof ↗⚑ flag

   Veriff—none0/10

   Veriff's docs mention exporting verification session details to PDF for business customers reviewing cases, but there is no evidence of an end-user-facing mechanism to export all personal/identity data in open, machine-readable formats (JSON/CSV) and delete one's account. The axis applies since Veriff stores significant PII/biometric data, but no comprehensive data-portability feature is documented.

   • [claimed-docs] “Export verification session details to PDF”

   proof ↗⚑ flag

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

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

   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 userPrevent my data from being used to train AI models

   weight 3 · round drawn
   Sumsub—none0/10

   No evidence in the pack addresses AI-training data usage or opt-out policies; Sumsub's docs cover verification, AML, and API features but nothing about preventing data from being used to train AI models.

   ⚑ flag

   Veriff—none0/10

   No evidence in the pack addresses AI training data opt-out or any privacy controls related to preventing use of user data for AI model training; the documentation covers verification API/SDK/webhook mechanics only.

   ⚑ flag

3. ai-native userControl data retention and deletion

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

   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

4. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Sumsub—none0/10

   No evidence pack item addresses telemetry/usage tracking or an opt-out mechanism; Sumsub's docs cover verification, API, security, and MCP features but nothing about analytics/telemetry controls.

   ⚑ flag

   Veriff—none0/10

   Veriff is an identity-verification API/service and its evidence pack covers session APIs, webhooks, HMAC security, and biometric liveness, but there is no mention of telemetry/usage tracking or any opt-out mechanism for such tracking.

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

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

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

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

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

   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 to Sumsub
   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

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

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

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

   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 to Sumsub
   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

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

   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