Signifyd vs Riskified

Agent detection

1. ai-native userThe product distinguishes malicious bots from legitimate AI buying agents, so agent-driven purchases aren't blanket-blocked as fraud

   weight 2 · round drawn
   Signifyd—none0/10

   The evidence pack covers Signifyd's fraud-decision API, webhooks, device profiling, chargebacks, and refund/return tooling, but nothing addresses distinguishing malicious bots from legitimate AI shopping/purchasing agents or any agentic-commerce-specific fraud logic. Missing for 10: any mention of AI agent identification, agent-vs-bot classification, or policy to avoid blocking legitimate AI buying agents.

   ⚑ flag

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

Agent identity

1. developerPass verified agent identity — agentic-payment protocols, signed agent tokens, delegated spending scopes — into the risk decision as a first-class signal

   weight 2 · round drawn
   Signifyd—none0/10

   No evidence in the pack mentions agentic-payment protocols, signed agent tokens, or delegated spending scopes being ingested as risk signals; the API docs cover standard order/checkout/sale/chargeback events and device profiling only.

   ⚑ flag

   Riskified—none0/10

   No evidence in the pack mentions agentic-payment protocols, signed agent tokens, or delegated spending scopes as inputs to Riskified's risk decision; the documented signals are customer/order/payment data, HMAC request auth, and Beacon session IDs, none of which represent verified agent identity as a first-class fraud signal.

   ⚑ flag

Agent access

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

   weight 2 · round to Riskified
   Signifyd—none0/10

   The llms.txt probe returned a 404, showing no dedicated agent-oriented manifest exists, and while a markdown-rendered docs page was found at one URL, there's no evidence of a systematic agent-oriented docs structure or llms.txt file across the site. missing for 10: a working llms.txt or equivalent agent-discoverable docs index, and any indication docs are structured/announced for AI agent consumption.

   • [probe] “PROBE llms.txt: HTTP 404 at https://developer.signifyd.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 200 at https://developer.signifyd.com/main/reference/introduction.md --- updatedAt: 2026-01-06T12:05:16.000Z --- # Fund…”

   proof ↗⚑ flag

   Riskified✓fullprobed8/10

   A probe confirms Riskified hosts a working llms.txt at developers.riskified.com/llms.txt returning HTTP 200, and docs explicitly note pages can be fetched as markdown by appending .md — exactly the agent-oriented docs pattern. Missing for 10: no independent/third-party corroboration of an agent successfully consuming it, and no broader agent-specific documentation beyond the llms.txt index.

   • [probe] “PROBE llms.txt: HTTP 200 at https://developers.riskified.com/llms.txt # Riskified documentation Documentation > Riskified Documentation Ap…”

   proof ↗⚑ flag

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

   weight 2 · round to Signifyd
   Signifyd~partialclaimed5/10

   Signifyd's core product is a REST API (with SDKs and webhooks) intended for backend/server-side integration rather than a UI-dependent tool, which inherently supports headless/programmatic use in automated pipelines. However, there is no explicit documentation of CI-specific tooling, a CLI, or automated-testing guidance — missing for 10: CI-specific setup docs, CLI/automation tooling, service-account/API-key guidance for pipeline use, and independent confirmation of headless CI usage.

   • [claimed-docs] “This document will show you how to use Signifyd's REST API to authenticate, make requests, and retrieve data.”
   • [claimed-docs] “The Sale endpoint in Signifyd's API is used to record a Sale Event, which represents the completion of a purchase flow and the associated pa…”
   • [claimed-docs] “The Checkout endpoint in Signifyd's API is used to record a Checkout Event in a Pre-Auth flow. This call should be made _before_ calling you…”
   • [claimed-docs] “Create a new webhook. This will add to the list of any existing webhooks.”
   • [claimed-docs] “SDKs provide mobile application developers with self-contained libraries for implementing Signifyd. Each SDK include instructions, examples,…”

   proof ↗⚑ flag

   Riskified~partialclaimed4/10

   Riskified is fundamentally an API-first fraud-decision service (decide/submit/advise/chargeback endpoints, SDKs, webhook notifications) that can be called programmatically without a UI, which supports headless/automated integration into checkout pipelines. However, there is no evidence of CI/CD-specific tooling, a CLI, or documented automation-testing workflows — the docs focus on production checkout integration, not build/test automation. Missing for 10: explicit CI/CD examples, a CLI or automation-testing guide, and confirmation of headless operation outside the live transaction flow.

   • [claimed-docs] “The `/decide` endpoint is used to request that Riskified review an order for fraud after the customer has input their payment data and compl…”
   • [claimed-docs] “The `/submit` endpoint sends transaction data to Riskified after the gateway authorizes the transaction for fraud analysis... the fraud deci…”
   • [claimed-docs] “For each order reviewed by advise we provide a synchronous decision if it is clear fraud... CVV/3DS recommendations can be provided... TRA/S…”
   • [claimed-docs] “Riskified provides SDKs for several languages to simplify API integration. SDK usage is optional, and all API endpoints can also be accessed…”
   • [claimed-docs] “Riskified can send automated decision notifications to a merchant-defined endpoint when an order is approved or declined... If the endpoint …”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Signifyd—none0/10

   Signifyd is a fraud-protection SaaS with a REST API and webhooks, but there is no evidence of an official MCP server for agent connectivity; the llms.txt probe even 404s. missing for 10: any official MCP server, documentation, or first-party endpoint enabling agent connectivity.

   • [probe] “PROBE llms.txt: HTTP 404 at https://developer.signifyd.com/llms.txt”

   proof ↗⚑ flag

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

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Signifyd—none0/10

   No evidence of any official CLI tool; Signifyd only documents REST API endpoints, SDKs for mobile apps, and webhooks, with no mention of a command-line interface for AI-native workflows.

   ⚑ flag

   Riskified—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
   Signifyd✓fullprobed8/10

   Signifyd provides a comprehensive, well-documented REST API covering authentication, sale/checkout events, decisions, chargebacks, webhooks, and SDKs, confirmed by both docs and a live probe returning 200 with actual API content. Missing for 10: no llms.txt or explicit AI-agent-oriented documentation, and no independent third-party corroboration of API usability.

   • [claimed-docs] “This document will show you how to use Signifyd's REST API to authenticate, make requests, and retrieve data.”
   • [claimed-docs] “The Sale endpoint in Signifyd's API is used to record a Sale Event, which represents the completion of a purchase flow and the associated pa…”
   • [claimed-docs] “The Checkout endpoint in Signifyd's API is used to record a Checkout Event in a Pre-Auth flow. This call should be made _before_ calling you…”
   • [claimed-docs] “Retrieve the latest fraud decision for an order in the Signifyd system.”
   • [claimed-docs] “Create a new webhook. This will add to the list of any existing webhooks.”
   • [probe] “PROBE docs-md: HTTP 200 at https://developer.signifyd.com/main/reference/introduction.md --- updatedAt: 2026-01-06T12:05:16.000Z --- # Fund…”

   proof ↗⚑ flag

   Riskified✓fullprobed8/10

   Riskified exposes a comprehensive documented REST API (decide, submit, advise, chargeback, notifications, login) with authentication (HMAC), synchronous/asynchronous flows, and optional SDKs, all directly callable via HTTP — clearly a documented public API an AI-native user could drive. The docs site also exposes an llms.txt for AI-friendly consumption, though no machine-readable OpenAPI/Swagger spec was found (404s on standard paths). Missing for 10: a discoverable OpenAPI/swagger schema and explicit rate-limit/versioning documentation.

   • [claimed-docs] “The `/decide` endpoint is used to request that Riskified review an order for fraud after the customer has input their payment data and compl…”
   • [claimed-docs] “The `/submit` endpoint sends transaction data to Riskified after the gateway authorizes the transaction for fraud analysis... the fraud deci…”
   • [claimed-docs] “For each order reviewed by advise we provide a synchronous decision if it is clear fraud... CVV/3DS recommendations can be provided... TRA/S…”
   • [claimed-docs] “Riskified provides SDKs for several languages to simplify API integration. SDK usage is optional, and all API endpoints can also be accessed…”
   • [claimed-docs] “X-RISKIFIED-HMAC-SHA256 | Verification hash for the Request. Generated by performing an SHA256 encryption on the request's POST body and cal…”
   • [claimed-docs] “Riskified can send automated decision notifications to a merchant-defined endpoint when an order is approved or declined... If the endpoint …”
   • [claimed-docs] “Riskified supports different integration types:\n- **Pre-authorization Synchronous**: Review orders before payment authorization\n- **Post-a…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developers.riskified.com/llms.txt # Riskified documentation Documentation > Riskified Documentation Ap…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.riskified.com/openapi.json, https://developers.riskified.com/swagger.json, https:…”

   proof ↗⚑ flag

6. ai-native userBuild against official SDKs

   weight 2 · round drawn
   Signifyd~partialclaimed5/10

   Signifyd documents official mobile SDKs with instructions, examples, and project files, plus a REST API reference for direct integration, but the evidence lacks concrete language-specific SDKs (Python, Node, Java, etc.), GitHub repos, or versioning/release info typical of AI-native SDK-driven workflows. missing for 10: language/server-side SDK documentation, GitHub repo links, code samples showing SDK usage beyond mobile.

   • [claimed-docs] “SDKs provide mobile application developers with self-contained libraries for implementing Signifyd. Each SDK include instructions, examples,…”
   • [claimed-docs] “This document will show you how to use Signifyd's REST API to authenticate, make requests, and retrieve data.”

   proof ↗⚑ flag

   Riskified~partialclaimed5/10

   Riskified's docs explicitly state that SDKs are provided for several languages to simplify API integration, confirming official SDK support (riskified-docs-5). However, the evidence lacks specifics such as which languages are covered, links to SDK repositories, or independent/community corroboration of SDK quality. Missing for 10: list of supported languages, links to SDK repos/package registries, hands-on developer feedback on SDK usability.

   • [claimed-docs] “Riskified provides SDKs for several languages to simplify API integration. SDK usage is optional, and all API endpoints can also be accessed…”

   proof ↗⚑ flag

7. ai-native userSubscribe to events via webhooks

   weight 2 · round to Signifyd
   Signifyd✓fullclaimed7/10

   Signifyd has documented webhook creation (createteamwebhook) and configuration docs describing real-time notifications for guarantee decisions, directly supporting event subscription via webhooks. Missing for 10: independent/hands-on corroboration of webhook reliability, full event-type catalog, and payload schema documentation.

   • [claimed-docs] “Create a new webhook. This will add to the list of any existing webhooks.”
   • [claimed-docs] “Signifyd can send a webhook to notify your online store every time a guarantee decision is made on a submitted order. This provides you with…”

   proof ↗⚑ flag

   Riskified~partialclaimed6/10

   Riskified documents a webhook-style notification mechanism: decision outcomes are pushed to a merchant-defined endpoint with retries on non-2xx and HMAC-SHA256 signature verification, which functions as an event webhook for fraud decisions and chargebacks. However, this is a fixed set of built-in notification types (order decision, chargeback) rather than a general-purpose subscribable event system with selectable event topics or a dashboard for managing webhook subscriptions. Missing for 10: a documented event catalog/subscription model letting users choose which event types to receive, and any UI/API for creating or managing multiple webhook subscriptions.

   • [claimed-docs] “Riskified can send automated decision notifications to a merchant-defined endpoint when an order is approved or declined... If the endpoint …”
   • [claimed-docs] “Riskified can send automated decision notifications to a merchant-defined endpoint when an order is approved or declined.”
   • [claimed-docs] “X-RISKIFIED-HMAC-SHA256 | Verification hash for the Request. Generated by performing an SHA256 encryption on the request's POST body and cal…”
   • [claimed-docs] “The `/submit` endpoint sends transaction data to Riskified after the gateway authorizes the transaction for fraud analysis... the fraud deci…”
   • [claimed-docs] “Notifies Riskified that a chargeback has been submitted for a specific order.”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round drawn
   Signifyd—none0/10

   The evidence pack shows API endpoints, webhooks, SDKs, and marketing blurbs like 'Return Insights' offering 'actionable intelligence,' but nothing describes AI-generated insights, natural-language explanations, or suggestions surfaced to users inside the product. No dashboard, chat, or generative-AI feature is documented.

   • [claimed-docs] “Return Insights Actionable intelligence to reduce returns and protect revenue”
   • [claimed-docs] “Instant Refunds Deliver instant, risk-free refunds that drive loyalty and revenue”

   proof ↗⚑ flag

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

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

   weight 2 · round to Signifyd
   Signifyd~partialclaimed4/10

   Signifyd's core product (fraud decisioning, chargeback handling, webhook notifications) runs autonomously in the background once integrated, and webhooks/API endpoints let a merchant configure automated event flows (e.g. createteamwebhook, getdecision, createchargeback) that fire without manual intervention. However, there is no evidence of an AI-native automation builder, scheduler, or agent-configurable workflow system — the 'automation' here is fixed product behavior wired via API/webhooks rather than a user-defined autonomous automation platform. Missing for 10: evidence of a user-configurable automation/rules engine, scheduling or trigger-condition builder, and any AI-specific automation tooling.

   • [claimed-docs] “Create a new webhook. This will add to the list of any existing webhooks.”
   • [claimed-docs] “Signifyd can send a webhook to notify your online store every time a guarantee decision is made on a submitted order. This provides you with…”
   • [claimed-docs] “Retrieve the latest fraud decision for an order in the Signifyd system.”
   • [claimed-docs] “To create a chargeback against an Order in the Signifyd system, you need to record a Chargeback Event.”
   • [claimed-docs] “This document will show you how to use Signifyd's REST API to authenticate, make requests, and retrieve data.”

   proof ↗⚑ flag

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

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round drawn
   Signifyd—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

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

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

   weight 2 · round drawn
   Signifyd—none0/10

   Signifyd's evidence pack only shows a REST API and webhook integration for fraud/chargeback management; there is no mention of natural-language command interfaces, chat-based control, or NL-driven operation of the product. missing for 10: any NL command interface, chatbot/assistant control surface, or documented natural-language API layer.

   • [claimed-docs] “This document will show you how to use Signifyd's REST API to authenticate, make requests, and retrieve data.”
   • [claimed-docs] “The Sale endpoint in Signifyd's API is used to record a Sale Event, which represents the completion of a purchase flow and the associated pa…”
   • [claimed-docs] “The Checkout endpoint in Signifyd's API is used to record a Checkout Event in a Pre-Auth flow. This call should be made _before_ calling you…”

   proof ↗⚑ flag

   Riskified—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
   Signifyd—none0/10

   Evidence shows Signifyd has an extensive REST API reference (endpoints for Sale, Checkout, Decision, Chargeback, Webhooks, etc.) but nothing in the pack indicates an interactive console, runnable code samples, or 'try it now' functionality typical of an AI-native API reference. Missing for 10: any mention of interactive/runnable request builder, live sandbox execution, or SDK-embedded runnable snippets.

   • [claimed-docs] “This document will show you how to use Signifyd's REST API to authenticate, make requests, and retrieve data.”
   • [claimed-docs] “The Sale endpoint in Signifyd's API is used to record a Sale Event, which represents the completion of a purchase flow and the associated pa…”
   • [claimed-docs] “The Checkout endpoint in Signifyd's API is used to record a Checkout Event in a Pre-Auth flow. This call should be made _before_ calling you…”
   • [claimed-docs] “Retrieve the latest fraud decision for an order in the Signifyd system.”

   proof ↗⚑ flag

   Riskified—none0/10

   Evidence shows only static API reference docs (endpoints, parameters, notifications) with no mention of an interactive console, runnable examples, or live API explorer; the openapi.json/swagger.json probe returned 404s, indicating no machine-readable spec to power an interactive reference.

   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.riskified.com/openapi.json, https://developers.riskified.com/swagger.json, https:…”
   • [claimed-docs] “The `/decide` endpoint is used to request that Riskified review an order for fraud after the customer has input their payment data and compl…”
   • [claimed-docs] “Riskified supports different integration types:\n- **Pre-authorization Synchronous**: Review orders before payment authorization\n- **Post-a…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Signifyd—none0/10

   The evidence pack shows Signifyd has REST API reference docs (built on a docs platform) but no mention of a downloadable OpenAPI/Swagger spec file or machine-readable schema anywhere in the pack, and a direct probe for llms.txt returned 404 with no OpenAPI equivalent found.

   • [claimed-docs] “This document will show you how to use Signifyd's REST API to authenticate, make requests, and retrieve data.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developer.signifyd.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 200 at https://developer.signifyd.com/main/reference/introduction.md --- updatedAt: 2026-01-06T12:05:16.000Z --- # Fund…”

   proof ↗⚑ flag

   Riskified—none0/10

   A probe explicitly checked common OpenAPI/swagger spec locations and all returned 404, and no evidence pack item references a downloadable machine-readable API spec; only human-readable docs and an llms.txt are present.

   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.riskified.com/openapi.json, https://developers.riskified.com/swagger.json, https:…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developers.riskified.com/llms.txt # Riskified documentation Documentation > Riskified Documentation Ap…”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   Signifyd—none0/10

   No evidence pack item mentions a sandbox, test environment, or test mode for Signifyd's API; all evidence describes production-oriented endpoints (Sale, Checkout, chargeback, webhooks) with no mention of a separate testing environment. Missing for 10: any sandbox/test API docs, test credentials or environment flags, or independent confirmation of a non-production testing mode.

   • [claimed-docs] “This document will show you how to use Signifyd's REST API to authenticate, make requests, and retrieve data.”
   • [claimed-docs] “The Sale endpoint in Signifyd's API is used to record a Sale Event, which represents the completion of a purchase flow and the associated pa…”
   • [claimed-docs] “The Checkout endpoint in Signifyd's API is used to record a Checkout Event in a Pre-Auth flow. This call should be made _before_ calling you…”
   • [claimed-docs] “Integrating Signifyd on your online stores enables orders placed on your stores to be sent to Signifyd for Guaranteed Fraud Protection.”

   proof ↗⚑ flag

   Riskified—none0/10

   No evidence of a sandbox or test environment separate from production; docs describe live API endpoints, integration flows, and Shopify onboarding but never mention a sandbox/test mode for AI-native or developer testing.

   ⚑ flag

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

   weight 2 · round drawn
   Signifyd—none0/10

   Evidence shows a REST API with numerous documented endpoints, but nothing indicates API versioning scheme or a documented deprecation policy anywhere in the docs pack. missing for 10: explicit API version numbering, changelog, deprecation notice/policy, sunset timelines.

   ⚑ flag

   Riskified—none0/10

   No evidence of API versioning scheme (e.g., v1/v2 paths, version headers) or any documented deprecation policy; OpenAPI spec probes all returned 404. missing for 10: versioned endpoint scheme, deprecation/sunset policy documentation, changelog or migration guides.

   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.riskified.com/openapi.json, https://developers.riskified.com/swagger.json, https:…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Signifyd—none0/10

   The evidence shows only per-order/per-event API endpoints (Sale, Checkout, Chargeback, etc.) with no batch/bulk endpoints or documentation of processing multiple items in a single call.

   ⚑ flag

   Riskified—none0/10

   Riskified's API is order-by-order (decide/submit/advise per transaction), with no evidence of a batch or bulk endpoint for processing many orders/items in a single call, nor any bulk chargeback or data-export operation.

   ⚑ flag

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

   weight 3 · round to Riskified
   Signifyd—none0/10

   Signifyd's API/webhook docs support event ingestion and notifications, but there's no evidence of a user-facing rules engine where AI-native users can define custom trigger-condition-action automations. missing for 10: rule-definition interface, conditional trigger/action configuration, evidence of automation builder.

   • [claimed-docs] “Create a new webhook. This will add to the list of any existing webhooks.”
   • [claimed-docs] “Signifyd can send a webhook to notify your online store every time a guarantee decision is made on a submitted order. This provides you with…”

   proof ↗⚑ flag

   Riskified~partialclaimed3/10

   Riskified automatically triggers fixed actions on fraud-decision events (webhook notifications, Shopify integration auto-voiding/restocking/capturing on approve/decline) but there is no evidence of a user-configurable rules engine where an AI-native user can define custom conditions/actions themselves — the automation is built-in and non-customizable rather than rule-definable. Missing for 10: a rules/condition-authoring API or UI, examples of custom trigger logic, and any AI-native/agentic rule-configuration workflow.

   • [claimed-docs] “Riskified can send automated decision notifications to a merchant-defined endpoint when an order is approved or declined... If the endpoint …”
   • [claimed-docs] “Riskified can send automated decision notifications to a merchant-defined endpoint when an order is approved or declined.”
   • [claimed-docs] “Voids authorization on orders declined by Riskified. Enables automatic restocking of orders declined by Riskified. Captures funds for orders…”
   • [claimed-docs] “Voids authorization on orders declined by Riskified. Enables automatic restocking of orders declined by Riskified. Captures funds for orders…”

   proof ↗⚑ flag

Guarantee

1. finance leadShift fraud liability to the vendor — a chargeback guarantee that reimburses approved-then-disputed orders, with clear coverage terms

   weight 2 · round to Signifyd
   Signifyd✓fullclaimed8/10

   Signifyd's docs describe the core chargeback-guarantee mechanics: 'Guaranteed Fraud Protection' on integrated orders, a Chargeback Event API to record disputes, Representment Outcome tracking, and explicit guarantee-cancellation rules tied to returns/refunds, plus a dedicated 'Chargeback Recovery' offering. This directly matches the liability-shift/reimbursement story with documented workflow and terms touchpoints (cancellation conditions, representment outcomes). Missing for 10: explicit contractual coverage terms/limits (e.g., reimbursement caps, eligibility exclusions) and independent/customer confirmation that claims are actually paid out as promised.

   • [claimed-docs] “Integrating Signifyd on your online stores enables orders placed on your stores to be sent to Signifyd for Guaranteed Fraud Protection.”
   • [claimed-docs] “To create a chargeback against an Order in the Signifyd system, you need to record a Chargeback Event.”
   • [claimed-docs] “To set the outcome of a Chargeback's Representment in the Signifyd system, you need to record a Representment Outcome Event.”
   • [claimed-docs] “Once a return, refund, or appeasement has been completed, merchants can cancel the Signifyd Guarantee associated with the order.”
   • [claimed-docs] “Chargeback Recovery Take charge of your chargebacks”

   proof ↗⚑ flag

   Riskified~partialclaimed5/10

   The evidence pack documents Riskified's API decisioning, chargeback notification, and chargeback gateway integration (automating chargeback reporting/disputing) but never states explicit financial liability-shift terms, reimbursement guarantees, coverage limits, or exclusions that a finance lead would need to evaluate a chargeback guarantee. Chargeback automation is a workflow/process feature, not proof of a monetary guarantee. missing for 10: explicit guarantee/reimbursement terms, coverage scope and exclusions, contractual liability-shift language, any evidence of actual reimbursement payouts.

   • [claimed-docs] “Riskified offers fully automated chargeback gateway integrations for major gateways: Braintree, Stripe, Adyen, PayPal; this process automate…”
   • [claimed-docs] “Notifies Riskified that a chargeback has been submitted for a specific order.”
   • [claimed-docs] “The Chargeback Gateway Integration (CGI) framework enables seamless connectivity with leading payment gateways, including Adyen, Stripe, Bra…”
   • [claimed-docs] “Riskified can send automated decision notifications to a merchant-defined endpoint when an order is approved or declined... If the endpoint …”

   proof ↗⚑ flag

Outcome reporting

1. finance leadSee the numbers that matter — dispute rate, false-positive rate, approval-rate lift, review workload — and export them for the board

   weight 2 · round drawn
   Signifyd—none0/10

   Evidence covers API endpoints for sales, checkouts, chargebacks, webhooks, and device profiling, but nothing mentions a finance/board-facing dashboard, KPI reporting (dispute rate, false-positive rate, approval-rate lift, review workload), or export functionality for reporting purposes. Missing for 10: any documentation of analytics/reporting dashboards, defined KPI metrics, or export/board-reporting features.

   • [claimed-docs] “Chargeback Recovery Take charge of your chargebacks”
   • [claimed-docs] “Return Insights Actionable intelligence to reduce returns and protect revenue”
   • [claimed-docs] “Instant Refunds Deliver instant, risk-free refunds that drive loyalty and revenue”

   proof ↗⚑ flag

   Riskified—none0/10

   Evidence covers API/integration mechanics (decide, submit, chargeback automation, notifications) but nothing about a finance/reporting dashboard, KPI metrics (dispute rate, false-positive rate, approval-rate lift, review workload), or board-ready export functionality.

   ⚑ flag

Representment

1. ops userChargeback responses are automated — evidence compiled from order, delivery, and session data and submitted to the issuer without manual copy-paste

   weight 3 · round to Riskified
   Signifyd~partialclaimed5/10

   Signifyd's API includes explicit Chargeback and Representment Outcome endpoints (createchargeback, representmentoutcome) and a dedicated 'Chargeback Recovery' product line, indicating dispute handling automation exists, but the evidence never details the automated compilation of order/delivery/session evidence or direct submission to issuers without manual intervention. missing for 10: documentation of automatic evidence bundling from order/delivery/session data, proof of direct issuer submission, and any hands-on/independent confirmation of end-to-end automation.

   • [claimed-docs] “To create a chargeback against an Order in the Signifyd system, you need to record a Chargeback Event.”
   • [claimed-docs] “To set the outcome of a Chargeback's Representment in the Signifyd system, you need to record a Representment Outcome Event.”
   • [claimed-docs] “Chargeback Recovery Take charge of your chargebacks”

   proof ↗⚑ flag

   Riskified~partialclaimed6/10

   Riskified's Chargeback Gateway Integration (CGI) is documented as automating 'end-to-end chargeback handling from chargeback reporting to the disputing process' across major gateways, implying dispute evidence submission without manual copy-paste, and Riskified already ingests order, session (Beacon), and decision data through its APIs. However, the docs don't explicitly describe compiling delivery data or detail the specific evidence package sent to issuers during disputes. Missing for 10: explicit description of delivery-data inclusion in chargeback evidence, detail on the dispute evidence package format submitted to issuers, and independent/hands-on confirmation that submission is fully automated end-to-end.

   • [claimed-docs] “Riskified offers fully automated chargeback gateway integrations for major gateways: Braintree, Stripe, Adyen, PayPal; this process automate…”
   • [claimed-docs] “Notifies Riskified that a chargeback has been submitted for a specific order.”
   • [claimed-docs] “The Chargeback Gateway Integration (CGI) framework enables seamless connectivity with leading payment gateways, including Adyen, Stripe, Bra…”
   • [claimed-docs] “Riskfied's Beacon is a JavaScript snippet that merchants embed on their website. It collects fundamental data required to decide on the legi…”
   • [claimed-docs] “The `/submit` endpoint sends transaction data to Riskified after the gateway authorizes the transaction for fraud analysis... the fraud deci…”

   proof ↗⚑ flag

Agent operations

1. ai-native userAn agent can read my fraud posture and manage rules and lists programmatically — propose a velocity rule, update a blocklist — with human approval gates

   weight 3 · round drawn
   Signifyd—none0/10

   The evidence shows a REST API for order/event submission, decisions, chargebacks, and webhooks, but nothing about rules/lists management (e.g., velocity rules, blocklists) or an agentic workflow with human approval gates. No documentation of a rules API or agent-oriented approval mechanism is present.

   • [claimed-docs] “This document will show you how to use Signifyd's REST API to authenticate, make requests, and retrieve data.”
   • [claimed-docs] “Retrieve the latest fraud decision for an order in the Signifyd system.”
   • [claimed-docs] “Create a new webhook. This will add to the list of any existing webhooks.”

   proof ↗⚑ flag

   Riskified—none0/10

   Evidence covers order review/decision APIs, notifications, chargeback automation, and Beacon data collection, but there is no mention of programmatic management of fraud rules, velocity rules, or blocklists, nor any agent-facing approval workflow for such changes.

   ⚑ flag

Agent triage

1. ai-native userAn agent can work the review queue — pull flagged cases with their context, summarize the evidence, and recommend a decision for a human to confirm

   weight 2 · round drawn
   Signifyd—none0/10

   Evidence shows only standard REST endpoints for sale/checkout events, decision retrieval, chargebacks, and webhooks — nothing about a queue of flagged cases with case context, an agent summarizing evidence, or generating a recommendation for human confirmation. No case-management or review-queue API surface is documented at all.

   • [claimed-docs] “This document will show you how to use Signifyd's REST API to authenticate, make requests, and retrieve data.”
   • [claimed-docs] “Retrieve the latest fraud decision for an order in the Signifyd system.”
   • [claimed-docs] “To create a chargeback against an Order in the Signifyd system, you need to record a Chargeback Event.”

   proof ↗⚑ flag

   Riskified—none0/10

   Riskified's evidence describes automated decisioning APIs (/decide, /submit, /advise), notifications, and merchant integrations, but nothing describes an agent-accessible review queue with case context retrieval, evidence summarization, or a human-confirm workflow. No API for pulling flagged cases with context or generating human-reviewable recommendations is documented.

   ⚑ flag

Builtin ai

1. risk analystThe product ships its own AI assistant — natural-language queries over my fraud data, drafted rules, investigation summaries — built into the console

   weight 2 · round drawn
   Signifyd—none0/10

   Evidence covers only REST API endpoints, webhooks, SDKs, and documentation for fraud data/order management — nothing about a built-in AI assistant, natural-language query interface, rule drafting, or investigation summaries in the console. missing for 10: any mention of an AI/NLP assistant feature, natural-language query capability, AI-drafted rules, or AI-generated investigation summaries.

   ⚑ flag

   Riskified—none0/10

   Evidence covers API endpoints, webhooks, chargeback automation, Beacon SDK, and integration processes, but nothing describes a built-in AI assistant, natural-language query interface, rule drafting, or investigation summaries in the console.

   ⚑ flag

Abuse coverage

1. risk analystProtection extends beyond checkout — account takeover, fake account creation, promo and policy abuse are scored and managed in the same system

   weight 2 · round to Riskified
   Signifyd—none0/10

   Evidence covers checkout/payment fraud, chargebacks, returns, and refund protection, but nothing addresses account takeover, fake account creation, or promo/policy abuse scoring within Signifyd's system. Missing for 10: any documentation of account takeover protection, fake account detection, or promo/policy abuse scoring features.

   • [claimed-docs] “This document will show you how to use Signifyd's REST API to authenticate, make requests, and retrieve data.”
   • [claimed-docs] “The Sale endpoint in Signifyd's API is used to record a Sale Event, which represents the completion of a purchase flow and the associated pa…”
   • [claimed-docs] “The Checkout endpoint in Signifyd's API is used to record a Checkout Event in a Pre-Auth flow. This call should be made _before_ calling you…”
   • [claimed-docs] “Retrieve the latest fraud decision for an order in the Signifyd system.”
   • [claimed-docs] “To create a chargeback against an Order in the Signifyd system, you need to record a Chargeback Event.”
   • [claimed-docs] “Once a return, refund, or appeasement has been completed, merchants can cancel the Signifyd Guarantee associated with the order.”

   proof ↗⚑ flag

   Riskified~partialclaimed5/10

   Riskified's Login API explicitly scores account-takeover attempts (allow/notify/challenge) alongside its core checkout fraud decisioning (decide/submit/advise) and automated chargeback handling, showing the same system spans multiple fraud surfaces beyond checkout. However, there is no documentation of fake-account-creation detection or promo/coupon abuse scoring as distinct managed surfaces. Missing for 10: explicit fake-account-creation protection, promo/policy abuse scoring, and independent confirmation these are unified in one decisioning system.

   • [claimed-docs] “API is triggered only for customer-initiated authentication requests, e.g., user tries to login to their account... `decision` field will be…”
   • [claimed-docs] “`decision` field will be set as one of the following values: `allow`, `notify`, or `challenge`.”
   • [claimed-docs] “Riskified offers fully automated chargeback gateway integrations for major gateways: Braintree, Stripe, Adyen, PayPal; this process automate…”
   • [claimed-docs] “Notifies Riskified that a chargeback has been submitted for a specific order.”
   • [claimed-docs] “The `/decide` endpoint is used to request that Riskified review an order for fraud after the customer has input their payment data and compl…”
   • [claimed-docs] “For each order reviewed by advise we provide a synchronous decision if it is clear fraud... CVV/3DS recommendations can be provided... TRA/S…”

   proof ↗⚑ flag

Integrations

1. ops userThere are maintained integrations for my commerce stack — Shopify, Salesforce Commerce, BigCommerce, and the major PSPs — not just a raw API

   weight 2 · round to Riskified
   Signifyd—none0/10

   Evidence only covers Signifyd's raw REST API, webhooks, SDKs, and device-profiling script — there is no mention of maintained platform-specific integrations (Shopify app, Salesforce Commerce Cloud cartridge, BigCommerce app, or PSP-specific connectors). No evidence names or links any prebuilt/maintained integration for a specific commerce platform or PSP.

   • [claimed-docs] “This document will show you how to use Signifyd's REST API to authenticate, make requests, and retrieve data.”
   • [claimed-docs] “Integrating Signifyd on your online stores enables orders placed on your stores to be sent to Signifyd for Guaranteed Fraud Protection.”
   • [claimed-docs] “SDKs provide mobile application developers with self-contained libraries for implementing Signifyd. Each SDK include instructions, examples,…”

   proof ↗⚑ flag

   Riskified~partialclaimed7/10

   Riskified documents maintained platform integrations beyond raw API: a dedicated Shopify app with automated order actions (docs-11,12,21,22), a Salesforce Commerce Cloud/Agentforce Commerce fraud cartridge (docs-10), and automated Chargeback Gateway Integration with major PSPs (Braintree, Stripe, Adyen, PayPal) (docs-4,16,17). However, there is no mention of a BigCommerce integration, and the PSP integrations are scoped to chargeback data only rather than full checkout/decisioning flows. Missing for 10: explicit BigCommerce integration, evidence of maintained PSP integrations beyond chargebacks (e.g., payment/checkout-time connectors), independent confirmation of integration quality/maintenance cadence.

   • [claimed-docs] “Riskified offers fully automated chargeback gateway integrations for major gateways: Braintree, Stripe, Adyen, PayPal; this process automate…”
   • [claimed-docs] “Agentforce Commerce (formerly Salesforce Commerce Cloud / SFCC) fraud protection cartridge provides a structured integration process tailore…”
   • [claimed-docs] “Voids authorization on orders declined by Riskified. Enables automatic restocking of orders declined by Riskified. Captures funds for orders…”
   • [claimed-docs] “If we have questions about shop flows or encounter data issues, we will reach out to you for clarification... Once data validation passes, y…”
   • [claimed-docs] “The Chargeback Gateway Integration (CGI) framework enables seamless connectivity with leading payment gateways, including Adyen, Stripe, Bra…”
   • [claimed-docs] “Once you have installed the Riskified app in your Shopify store, the integration process can begin. During this time, most of the “heavy lif…”
   • [claimed-docs] “Voids authorization on orders declined by Riskified. Enables automatic restocking of orders declined by Riskified. Captures funds for orders…”

   proof ↗⚑ flag

Psp coverage

1. developerUse the product across whatever payment stack I run — multiple PSPs, gateways, and platforms — rather than being locked to one processor's rails

   weight 3 · round drawn
   Signifyd~partialclaimed6/10

   Signifyd's API is generic (Checkout/Sale events, webhooks) and explicitly designed to sit outside the payment flow — the Checkout event is called 'before calling your Payment Gateway' — implying gateway/PSP-agnostic architecture rather than lock-in to one processor's rails. However, the evidence pack never explicitly lists supported PSPs, gateways, or platforms, nor confirms interoperability across multiple stacks simultaneously. missing for 10: explicit documentation naming supported PSPs/gateways/platforms, and independent confirmation of multi-PSP usage in production.

   • [claimed-docs] “The Sale endpoint in Signifyd's API is used to record a Sale Event, which represents the completion of a purchase flow and the associated pa…”
   • [claimed-docs] “The Checkout endpoint in Signifyd's API is used to record a Checkout Event in a Pre-Auth flow. This call should be made _before_ calling you…”
   • [claimed-docs] “Integrating Signifyd on your online stores enables orders placed on your stores to be sent to Signifyd for Guaranteed Fraud Protection.”
   • [claimed-docs] “This document will show you how to use Signifyd's REST API to authenticate, make requests, and retrieve data.”

   proof ↗⚑ flag

   Riskified~partialclaimed6/10

   Riskified is gateway/platform-agnostic via its own API (/decide, /submit, /advise), with automated chargeback integrations naming specific gateways (Braintree, Stripe, Adyen, PayPal) and platform cartridges for Shopify and SFCC, indicating it can plug into multiple PSPs/platforms rather than lock a merchant into one processor. However, the evidence doesn't explicitly enumerate broad PSP/gateway compatibility beyond the four named chargeback gateways, nor discuss developer-facing flexibility across arbitrary payment stacks explicitly. missing for 10: a comprehensive list of supported PSPs/gateways beyond chargeback integrations, explicit statements about processor-agnostic architecture, and independent confirmation of multi-PSP interoperability.

   • [claimed-docs] “Riskified offers fully automated chargeback gateway integrations for major gateways: Braintree, Stripe, Adyen, PayPal; this process automate…”
   • [claimed-docs] “The Chargeback Gateway Integration (CGI) framework enables seamless connectivity with leading payment gateways, including Adyen, Stripe, Bra…”
   • [claimed-docs] “Agentforce Commerce (formerly Salesforce Commerce Cloud / SFCC) fraud protection cartridge provides a structured integration process tailore…”
   • [claimed-docs] “Voids authorization on orders declined by Riskified. Enables automatic restocking of orders declined by Riskified. Captures funds for orders…”
   • [claimed-docs] “Riskified supports different integration types:\n- **Pre-authorization Synchronous**: Review orders before payment authorization\n- **Post-a…”

   proof ↗⚑ flag

Explainability

1. risk analystEvery score comes with its top risk factors — why this transaction looks risky — not just an opaque number

   weight 3 · round drawn
   Signifyd—none0/10

   The evidence pack covers API endpoints for submitting orders, retrieving decisions, webhooks, chargebacks, and device profiling, but none of it describes the decision/score payload including risk factor breakdowns or explanations behind a fraud score. The getdecision endpoint doc only says it 'retrieves the latest fraud decision' with no mention of contributing risk factors or explainability.

   • [claimed-docs] “Retrieve the latest fraud decision for an order in the Signifyd system.”

   proof ↗⚑ flag

   Riskified—none0/10

   Evidence describes decision outcomes (approve/decline/allow/notify/challenge) and notification mechanisms, but nothing indicates that decisions are accompanied by explanatory risk factors or reason codes for analysts. No mention of feature-level explanations, contributing signals, or reason breakdowns anywhere in the docs.

   ⚑ flag

Model evaluation

1. finance leadMeasure the model itself — precision and recall on my traffic, shadow-mode trials of new models or rules before they take over decisions

   weight 2 · round drawn
   Signifyd—none0/10

   Evidence covers API integration, webhooks, chargeback/return workflows, and device profiling, but there is no mention of model performance metrics (precision/recall), shadow-mode testing, or A/B evaluation of decisioning models exposed to customers. Missing for 10: precision/recall reporting on customer traffic, shadow-mode/challenger model trials, any model-transparency or evaluation tooling.

   ⚑ flag

   Riskified—none0/10

   The evidence pack only covers API endpoints, integrations, notifications, and chargeback automation — nothing about model performance metrics (precision/recall), model versioning, or shadow-mode testing of new models/rules before go-live is documented.

   ⚑ flag

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

   weight 2 · round to Signifyd
   Signifyd~partialclaimed5/10

   Signifyd's API covers core fraud-protection workflows (sale/checkout events, decisions, chargebacks, webhooks, device profiling) that mirror much of what merchants would configure in the UI, suggesting broad API/UI parity for core fraud operations. However, there is no evidence confirming that dashboard-only features like Return Insights, Instant Refunds management, or Chargeback Recovery workflows are fully API-accessible, nor any explicit statement of full UI/API parity. missing for 10: explicit parity statement, API coverage for analytics/reporting features (Return Insights, Instant Refunds), evidence of account/team management via API.

   • [claimed-docs] “The Sale endpoint in Signifyd's API is used to record a Sale Event, which represents the completion of a purchase flow and the associated pa…”
   • [claimed-docs] “The Checkout endpoint in Signifyd's API is used to record a Checkout Event in a Pre-Auth flow. This call should be made _before_ calling you…”
   • [claimed-docs] “Retrieve the latest fraud decision for an order in the Signifyd system.”
   • [claimed-docs] “To create a chargeback against an Order in the Signifyd system, you need to record a Chargeback Event.”
   • [claimed-docs] “To set the outcome of a Chargeback's Representment in the Signifyd system, you need to record a Representment Outcome Event.”
   • [claimed-docs] “Create a new webhook. This will add to the list of any existing webhooks.”
   • [claimed-docs] “Once a return, refund, or appeasement has been completed, merchants can cancel the Signifyd Guarantee associated with the order.”
   • [claimed-docs] “Return Insights Actionable intelligence to reduce returns and protect revenue”
   • [claimed-docs] “Instant Refunds Deliver instant, risk-free refunds that drive loyalty and revenue”

   proof ↗⚑ flag

   Riskified—none0/10

   The evidence pack documents Riskified's API endpoints (decide, submit, advise, chargeback, notifications) and SDKs, but never discusses the merchant dashboard/UI or compares what can be done there versus via API, so there's no evidence of feature parity between UI and API.

   ⚑ flag

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

   weight 2 · round drawn
   Signifyd—none0/10

   No evidence in the pack mentions data residency, regional storage options, or any configurability of where data is stored; only API/webhook/fraud-decision docs are present. missing for 10: any mention of data residency/region selection, hosting locations, or compliance controls for data storage.

   ⚑ flag

   Riskified—none0/10

   No evidence in the pack mentions data residency, region selection, or storage location options for merchant/customer data; documentation covers API endpoints, integrations, and notifications only.

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Signifyd—none0/10

   Evidence only covers API endpoints, webhooks, and sensitive-data rejection at the API layer; there is no documentation of data retention policies, user-initiated deletion controls, or data lifecycle management. Missing for 10: retention policy documentation, deletion/export APIs or controls, data lifecycle configuration options.

   ⚑ flag

   Riskified—none0/10

   No evidence pack items address data retention policies, deletion mechanisms, or user/customer data control tools; the docs focus entirely on fraud-decision APIs and integrations with no privacy-posture or data lifecycle controls mentioned.

   ⚑ flag

Residency

1. ops userControl where fraud data lives and how long it's kept — regional residency options and retention controls that survive a privacy review

   weight 2 · round drawn
   Signifyd—none0/10

   Evidence covers API endpoints, webhooks, SDKs, and a sensitive-data protection layer, but nothing addresses regional data residency options or configurable retention/deletion policies that would survive a privacy review. Missing for 10: documented data residency regions, retention period controls, data deletion/export tooling, and any compliance certification (e.g., GDPR/SOC2) mapping to residency.

   • [claimed-docs] “Signifyd has implemented various protocols at the API layer that will reject requests that are identified to contain unwanted sensitive data…”

   proof ↗⚑ flag

   Riskified—none0/10

   No evidence in the pack addresses data residency options, regional data storage, or retention/deletion controls; documentation covers API flows, integrations, and authentication only.

   ⚑ flag

Sca

1. developerEuropean traffic is routed intelligently through SCA — 3DS triggered when required or risky, exemptions requested when safe — to protect both compliance and conversion

   weight 2 · round to Riskified
   Signifyd—none0/10

   The evidence pack covers Signifyd's fraud/guarantee API (Sale, Checkout, chargebacks, webhooks, device profiling) but contains no mention of SCA, 3DS, PSD2 exemptions, or any European payment-authentication routing logic. Nothing indicates the product decides when to trigger 3DS versus request an exemption. missing for 10: any documentation of SCA/3DS handling, exemption request logic, or PSD2-specific routing features.

   ⚑ flag

   Riskified✓fullclaimed7/10

   Riskified's /advise endpoint explicitly returns CVV/3DS recommendations and adds TRA/SCA exemption recommendations for regulated markets, directly matching the story of intelligently triggering 3DS or requesting exemptions per order. This is first-party documentation with no independent corroboration of real-world accuracy or European-specific behavior. Missing for 10: independent/hands-on validation of SCA exemption success rates, and explicit detail on how 'European traffic' specifically is distinguished/routed versus other regions.

   • [claimed-docs] “For each order reviewed by advise we provide a synchronous decision if it is clear fraud... CVV/3DS recommendations can be provided... TRA/S…”
   • [claimed-docs] “For each order reviewed by advise we provide a synchronous decision if it is clear fraud... In addition, CVV/3DS recommendations can be prov…”

   proof ↗⚑ flag

Case review

1. risk analystFlagged transactions land in a review queue that shows the full context — customer history, signals, similar cases — so I can decide quickly and consistently

   weight 3 · round drawn
   Signifyd—none0/10

   Evidence pack covers Signifyd's API endpoints (Sale, Checkout, chargeback, webhooks, device profiling) but contains no mention of a review queue UI, case management dashboard, or consolidated view showing customer history, signals, and similar cases for analysts. No evidence supports the analyst-facing review workflow described in the story.

   ⚑ flag

   Riskified—none0/10

   Evidence covers Riskified's API endpoints (/decide, /submit, /advise), notifications, chargeback automation, and Beacon data collection, but nothing describes a human review-queue UI showing analyst context, customer history, or similar cases for manual decisioning — Riskified's documented flow is automated/API-driven decisioning, not analyst-facing case review tooling.

   ⚑ flag

Feedback loop

1. risk analystMy review decisions and confirmed fraud outcomes feed back into the model and rules, so the system learns from every case we work

   weight 2 · round to Signifyd
   Signifyd~partialclaimed3/10

   Signifyd's API lets merchants record Chargeback and Representment Outcome events, which feed confirmed fraud outcomes into the system, but the evidence pack never states that analyst review-queue decisions or these outcomes are used to retrain the model or update rules. Missing for 10: explicit documentation of a review-queue/analyst decision feedback loop, evidence of model retraining or rule updates from confirmed outcomes, and any hands-on/independent confirmation that this loop improves detection.

   • [claimed-docs] “To create a chargeback against an Order in the Signifyd system, you need to record a Chargeback Event.”
   • [claimed-docs] “To set the outcome of a Chargeback's Representment in the Signifyd system, you need to record a Representment Outcome Event.”
   • [claimed-docs] “Retrieve the latest fraud decision for an order in the Signifyd system.”

   proof ↗⚑ flag

   Riskified—none0/10

   The evidence describes automated decisioning APIs (/decide, /submit, /advise), chargeback notification integrations, and onboarding model calibration by Riskified's own analytics team, but nothing describes an analyst-facing review queue where human review decisions or confirmed fraud outcomes are captured and fed back into the model/rules on an ongoing basis. Missing for 10: evidence of an analyst review UI, a mechanism for analysts to submit manual review/fraud confirmations, and documentation that such decisions retrain or update the fraud model/rules.

   • [claimed-docs] “If we have questions about shop flows or encounter data issues, we will reach out to you for clarification... Once data validation passes, y…”
   • [claimed-docs] “Notifies Riskified that a chargeback has been submitted for a specific order.”
   • [claimed-docs] “Riskified offers fully automated chargeback gateway integrations for major gateways: Braintree, Stripe, Adyen, PayPal; this process automate…”

   proof ↗⚑ flag

Team workflows

1. ops userReview work is a team workflow — assignment, escalation, SLAs, and a decision audit trail that shows who approved what and why

   weight 2 · round drawn
   Signifyd—none0/10

   Evidence covers API endpoints for fraud decisions, chargebacks, webhooks, and device profiling, but nothing about a human review-queue workflow with assignment, escalation, SLAs, or a decision audit trail showing who approved what and why. Missing for 10: assignment/queue management docs, escalation workflows, SLA tracking, human-approval audit trail features.

   • [claimed-docs] “Retrieve the latest fraud decision for an order in the Signifyd system.”
   • [claimed-docs] “To create a chargeback against an Order in the Signifyd system, you need to record a Chargeback Event.”
   • [claimed-docs] “Signifyd can send a webhook to notify your online store every time a guarantee decision is made on a submitted order. This provides you with…”

   proof ↗⚑ flag

   Riskified—none0/10

   Evidence covers API decisioning, notifications, chargeback automation, and integrations, but nothing describes a human ops review workflow with case assignment, escalation, SLAs, or an audit trail of who approved what and why.

   ⚑ flag

Custom signals

1. developerFeed the model my own signals — device fingerprints, behavioral data, custom metadata — so scoring reflects my business, not just network defaults

   weight 2 · round to Signifyd
   Signifyd~partialclaimed4/10

   Signifyd's Sale/Checkout API endpoints let developers submit order and event data, and device-profiling script captures fingerprints, but these are Signifyd's own structured schemas and proprietary device fingerprinting rather than a documented mechanism for injecting arbitrary custom behavioral signals or metadata into scoring. Missing for 10: explicit API fields for custom/behavioral metadata, documentation on how custom signals influence the risk score, and independent confirmation that scoring reflects merchant-specific inputs beyond standard order fields.

   • [claimed-docs] “The Sale endpoint in Signifyd's API is used to record a Sale Event, which represents the completion of a purchase flow and the associated pa…”
   • [claimed-docs] “The Checkout endpoint in Signifyd's API is used to record a Checkout Event in a Pre-Auth flow. This call should be made _before_ calling you…”
   • [claimed-docs] “Place the following script just before the closing `</head>` tag on your checkout page. The script loads asynchronously and does not affect …”
   • [claimed-docs] “Signifyd has implemented various protocols at the API layer that will reject requests that are identified to contain unwanted sensitive data…”

   proof ↗⚑ flag

   Riskified—none0/10

   Riskified's API endpoints (/decide, /submit, /advise) and Beacon.js collect a fixed, vendor-defined set of order/behavioral data required for fraud analysis, and model calibration is explicitly handled by Riskified's own analytics team (docs-12), not the developer. There is no evidence of an API or schema allowing developers to inject custom device fingerprints, arbitrary behavioral signals, or custom metadata fields into the scoring model to tailor it to their own business logic.

   • [claimed-docs] “Riskfied's Beacon is a JavaScript snippet that merchants embed on their website. It collects fundamental data required to decide on the legi…”
   • [claimed-docs] “If we have questions about shop flows or encounter data issues, we will reach out to you for clarification... Once data validation passes, y…”
   • [claimed-docs] “The `/submit` endpoint sends transaction data to Riskified after the gateway authorizes the transaction for fraud analysis... the fraud deci…”
   • [claimed-docs] “For each order reviewed by advise we provide a synchronous decision if it is clear fraud... CVV/3DS recommendations can be provided... TRA/S…”

   proof ↗⚑ flag

Network effects

1. founderScoring benefits from a cross-merchant network — a card or identity seen across thousands of other businesses informs the risk decision on mine

   weight 2 · round drawn
   Signifyd—none0/10

   The evidence pack covers Signifyd's API endpoints, webhooks, device profiling, chargebacks, and guarantees, but contains no mention of a cross-merchant network effect, shared consortium data, or how data from other merchants informs a given merchant's risk score. missing for 10: any documentation of network-wide identity/card matching, consortium data sharing, or cross-merchant signal aggregation.

   ⚑ flag

   Riskified—none0/10

   The evidence pack only documents Riskified's API endpoints, SDKs, and integration flows (decide, submit, advise, chargeback, notifications, Beacon, login) — none of it describes a cross-merchant data network, shared fraud signals across Riskified's merchant base, or how identity/card history from other businesses informs a given merchant's score. Without any documentation of the network-effect mechanism, this axis has no supporting evidence.

   ⚑ flag

Score actions

1. ops userMap score ranges to actions — allow, review, block, step-up 3DS — and tune thresholds to my own risk appetite instead of a fixed cutoff

   weight 2 · round drawn
   Signifyd—none0/10

   Evidence covers Signifyd's API endpoints for orders, decisions, chargebacks, and webhooks, but nothing describes configurable score-to-action mapping (allow/review/block/step-up 3DS) or threshold tuning for ops users; the getdecision endpoint only retrieves a decision, not a configurable rule engine.

   • [claimed-docs] “Retrieve the latest fraud decision for an order in the Signifyd system.”
   • [claimed-docs] “Signifyd can send a webhook to notify your online store every time a guarantee decision is made on a submitted order. This provides you with…”

   proof ↗⚑ flag

   Riskified—none0/10

   Riskified's docs describe its endpoints (/decide, /submit, /advise, login) returning pre-computed decisions like allow/notify/challenge or approve/decline, but there is no evidence that ops users can view underlying risk scores or configure/tune score-to-action thresholds themselves — decisioning appears to be Riskified's managed model rather than a merchant-tunable scorecard.

   • [claimed-docs] “The `/decide` endpoint is used to request that Riskified review an order for fraud after the customer has input their payment data and compl…”
   • [claimed-docs] “For each order reviewed by advise we provide a synchronous decision if it is clear fraud... CVV/3DS recommendations can be provided... TRA/S…”
   • [claimed-docs] “API is triggered only for customer-initiated authentication requests, e.g., user tries to login to their account... `decision` field will be…”
   • [claimed-docs] “`decision` field will be set as one of the following values: `allow`, `notify`, or `challenge`.”

   proof ↗⚑ flag

Scoring api

1. developerGet a machine-learning risk score for a transaction in real time — synchronously, before authorization completes — through a documented API

   weight 3 · round to Riskified
   Signifyd~partialclaimed5/10

   Signifyd's Checkout endpoint is documented to be called before the payment gateway in a Pre-Auth flow, aligning with the 'before authorization' requirement, and there is a documented GetDecision endpoint to retrieve the fraud decision. However, the evidence does not show the Checkout call synchronously returning an ML risk score in its response; decision retrieval appears to depend on a separate GetDecision call or webhook, suggesting an asynchronous decisioning pattern rather than an inline synchronous score. Missing for 10: explicit documentation that the Checkout API response includes a real-time ML score synchronously, and confirmation that no polling/webhook wait is required before authorization completes.

   • [claimed-docs] “The Checkout endpoint in Signifyd's API is used to record a Checkout Event in a Pre-Auth flow. This call should be made _before_ calling you…”
   • [claimed-docs] “Retrieve the latest fraud decision for an order in the Signifyd system.”
   • [claimed-docs] “Signifyd can send a webhook to notify your online store every time a guarantee decision is made on a submitted order. This provides you with…”

   proof ↗⚑ flag

   Riskified✓fullprobed7/10

   Riskified's documented `/decide` endpoint explicitly returns a synchronous fraud decision before payment authorization completes, matching the real-time pre-auth workflow described in the story, and Riskified's own docs classify this as 'Pre-authorization Synchronous' integration. However, the docs describe a categorical decision (approve/decline) rather than an explicit numeric ML risk score, and no OpenAPI/swagger spec exists (probe returned 404s) to confirm formal API schema. missing for 10: explicit numeric risk-score field documentation, machine-readable OpenAPI spec, independent/hands-on corroboration of latency/real-time behavior.

   • [claimed-docs] “The `/decide` endpoint is used to request that Riskified review an order for fraud after the customer has input their payment data and compl…”
   • [claimed-docs] “The `/decide` endpoint is used to request that Riskified review an order for fraud after the customer has input their payment data and compl…”
   • [claimed-docs] “Riskified supports different integration types:\n- **Pre-authorization Synchronous**: Review orders before payment authorization\n- **Post-a…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.riskified.com/openapi.json, https://developers.riskified.com/swagger.json, https:…”

   proof ↗⚑ flag

Backtesting

1. risk analystBacktest a rule against my historical traffic before deploying it, seeing exactly what it would have blocked, flagged, and cost

   weight 2 · round drawn
   Signifyd—none0/10

   No evidence pack items mention rule backtesting, simulation against historical traffic, or previewing block/flag/cost outcomes before deployment; the docs cover API integration, webhooks, chargebacks, and device profiling only.

   ⚑ flag

   Riskified—none0/10

   Evidence covers Riskified's fraud-decision APIs, notifications, chargeback integrations, and merchant integration flows, but nothing describes a rule backtesting capability against historical traffic showing what would have been blocked/flagged/cost before deployment.

   ⚑ flag

Lists

1. ops userMaintain allow and block lists — emails, cards, devices, IPs — and velocity limits, managed through the dashboard and programmatically

   weight 2 · round drawn
   Signifyd—none0/10

   The evidence pack covers Signifyd's REST API for sale/checkout events, decisions, chargebacks, webhooks, and device profiling, but contains no mention of allow/block lists, velocity limits, or list management endpoints/dashboard features for emails, cards, devices, or IPs.

   ⚑ flag

   Riskified—none0/10

   Evidence covers order decisioning APIs, notifications, chargebacks, and integrations, but nothing describes allow/block lists for emails, cards, devices, or IPs, nor velocity limit configuration via dashboard or API.

   ⚑ flag

Rule authoring

1. risk analystAuthor custom rules that combine model scores, velocity counters, list matches, and transaction attributes into allow, block, or review decisions

   weight 3 · round drawn
   Signifyd—none0/10

   The evidence pack covers API endpoints for sale/checkout events, webhooks, decisions, chargebacks, and device profiling, but contains no mention of a rules engine or capability for analysts to author custom rules combining model scores, velocity counters, list matches, and transaction attributes into allow/block/review decisions.

   ⚑ flag

   Riskified—none0/10

   Riskified's docs describe API endpoints (decide/submit/advise), notifications, and integrations, but there is no evidence of a user-facing custom rules authoring interface where a risk analyst can combine model scores, velocity counters, list matches, and transaction attributes into allow/block/review logic. The decisions described (allow/notify/challenge, approve/decline) are produced by Riskified's own models, not by analyst-authored rules. Missing for 10: any rule-builder UI, rule syntax/DSL, ability to combine velocity counters/list matches/model scores into custom logic, or analyst-facing rule management docs.

   • [claimed-docs] “The `/decide` endpoint is used to request that Riskified review an order for fraud after the customer has input their payment data and compl…”
   • [claimed-docs] “For each order reviewed by advise we provide a synchronous decision if it is clear fraud... CVV/3DS recommendations can be provided... TRA/S…”
   • [claimed-docs] “API is triggered only for customer-initiated authentication requests, e.g., user tries to login to their account... `decision` field will be…”
   • [claimed-docs] “`decision` field will be set as one of the following values: `allow`, `notify`, or `challenge`.”

   proof ↗⚑ flag