Sift vs Signifyd

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

   Evidence covers general fraud scoring, workflows, and decisions but nothing addresses distinguishing AI shopping agents from malicious bots or agentic-commerce specific handling; missing for 10: any mention of AI agent traffic detection, agent-vs-bot classification, or agentic-commerce policy/whitelisting.

   ⚑ flag

   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

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

   No evidence Sift supports ingesting verified agent identity, agentic-payment protocol tokens, signed agent tokens, or delegated spending scopes as risk signals; docs only describe generic user/business event and custom-field ingestion. missing for 10: any mention of agentic-commerce protocols, signed agent tokens, or delegated spending scope support as a risk signal.

   ⚑ flag

   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

Agent access

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

   weight 2 · round drawn
   Sift—none0/10

   No evidence of an llms.txt file or agent-oriented documentation format; the docs are standard developer API references with no mention of AI-agent consumption. missing for 10: llms.txt file, agent-readable docs format, any mention of AI-agent-targeted documentation.

   ⚑ flag

   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

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

   weight 2 · round to Signifyd
   Sift~partialclaimed4/10

   Sift is fundamentally API-driven (REST Events/Decisions APIs, SDKs) which is inherently 'headless' and can be called from backend or automated systems, but there is no explicit evidence of a CLI, CI pipeline integration, or documented headless automation workflow. Missing for 10: explicit CI/CD examples, CLI tooling, or automation-specific documentation beyond generic API integration.

   • [claimed-docs] “Sift easily integrates into your existing systems using modern REST APIs, Javascript snippet, and SDKs for iOS and Android.”
   • [claimed-docs] “What actions your users are taking, usually key user lifecycle events (e.g., creating an account, placing an order, posting content to other…”
   • [claimed-docs] “What actions your business is taking in response to users (e.g., approve an order, block and event due to fraud, cancel order due to chargeb…”
   • [claimed-docs] “Because Sift gets smarter the more data it has about your business, you can jump start your integration by backfilling a few months worth of…”

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Sift—none0/10

   Sift is a fraud-detection SaaS with REST/Decisions APIs and SDKs, but no evidence of an official MCP server for agent connectivity. missing for 10: any mention of MCP, agent integration protocol, or official MCP server endpoint.

   • [claimed-docs] “Sift easily integrates into your existing systems using modern REST APIs, Javascript snippet, and SDKs for iOS and Android.”

   proof ↗⚑ flag

   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

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Sift—none0/10

   Sift's evidence pack covers REST APIs, SDKs, JS snippet, and Decisions/Workflows APIs, but no official CLI tool is mentioned anywhere in docs or community sources.

   ⚑ flag

   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

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

   weight 3 · round to Signifyd
   Sift~partialcommunity6/10

   Sift documents REST APIs (Events, Decisions, Score, Workflows) that let developers programmatically drive fraud scoring and decisioning, which supports an AI-native integration story. However, this is a traditional fraud-ops API, not one purpose-built for AI agent orchestration, and there's no evidence of agent-specific tooling like an MCP server, function-calling schemas, or SDKs for LLM agents. missing for 10: agent-oriented API framing (e.g., MCP server, function-calling schema), independent hands-on validation of API usability beyond one user noting confusing docs.

   • [claimed-docs] “Sift easily integrates into your existing systems using modern REST APIs, Javascript snippet, and SDKs for iOS and Android.”
   • [claimed-docs] “What actions your users are taking, usually key user lifecycle events (e.g., creating an account, placing an order, posting content to other…”
   • [claimed-docs] “What actions your business is taking in response to users (e.g., approve an order, block and event due to fraud, cancel order due to chargeb…”
   • [claimed-docs] “Sift represents this risk with a score between 0 and 100, where risky events have higher scores.”
   • [claimed-docs] “Workflows enable you to make risk-based decisions in real time during key events. Follow this guide to create your own custom Workflow.”
   • [community] “Early user feedback: 'I have been integrating it for a day or so. The documentation is slightly confusing and they've had a few minor bugs i…”

   proof ↗⚑ flag

   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

6. ai-native userBuild against official SDKs

   weight 2 · round to Signifyd
   Sift—none0/10

   Evidence shows Sift has REST APIs, JS snippet, and mobile SDKs for iOS/Android, but there's no mention of SDKs oriented toward AI-native development (e.g., LLM/agent SDKs, official Python/Node/AI framework SDKs). This story concerns AI-native developer tooling, which is not addressed anywhere in the pack. missing for 10: any evidence of AI-agent-oriented SDKs, LLM integration libraries, or agent framework support.

   ⚑ flag

   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

7. ai-native userSubscribe to events via webhooks

   weight 2 · round to Signifyd
   Sift—none0/10

   Sift's documented integration model is inbound REST APIs (Events, Decisions, Score, Workflows) for sending data to Sift, not outbound webhooks for subscribing to events from Sift. No evidence pack item mentions webhook subscriptions or event push notifications to external consumers.

   ⚑ flag

   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

Agentic features

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

   weight 2 · round drawn
   Sift—none0/10

   Sift provides risk scores and rule-based Workflows/Decisions derived from ML models, but there is no evidence of AI-generated natural-language insights or suggestions surfaced to users inside a product UI—everything is API-driven scoring and automation rather than generative/agentic insight delivery. Missing for 10: any documented AI-generated narrative insights, recommendations, or conversational/agentic assistant surfaced in-product, and any independent confirmation of such a feature.

   • [claimed-docs] “Sift represents this risk with a score between 0 and 100, where risky events have higher scores.”
   • [claimed-docs] “Workflows enable you to make risk-based decisions in real time during key events. Follow this guide to create your own custom Workflow.”
   • [claimed-docs] “Sift offers Workflows, a powerful rules automation platform, and Review Queues.”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Sift~partialclaimed4/10

   Sift's Workflows feature is described as a 'rules automation platform' that runs risk-based decisions autonomously in real time on incoming events, which fits the general notion of background automations. However, this is traditional rules/ML-based fraud automation, not an AI-native/agentic automation-building experience tailored to an 'AI-native user.' Missing for 10: evidence of AI-native automation authoring (e.g., natural-language or agent-driven workflow creation), broader use-case automations beyond fraud decisioning, and independent confirmation of autonomous operation quality.

   • [claimed-docs] “Workflows enable you to make risk-based decisions in real time during key events. Follow this guide to create your own custom Workflow.”
   • [claimed-docs] “Sift offers Workflows, a powerful rules automation platform, and Review Queues.”
   • [claimed-docs] “Learn to set up custom Decisions, like Ban Account or Cancel Order, that are connected to real business actions in your backend.”

   proof ↗⚑ flag

   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

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

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

   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

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

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

   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

Api quality

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

   weight 2 · round drawn
   Sift—none0/10

   Evidence shows REST/Decisions/Events API docs exist but nothing describes an interactive API reference with runnable examples (e.g., embedded sandbox, try-it console). Missing for 10: interactive API explorer, runnable code examples, sandbox/try-it functionality.

   ⚑ flag

   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

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

   weight 2 · round drawn
   Sift—none0/10

   Evidence shows Sift has REST APIs (Events, Decisions, Score, Workflows) with docs, but no mention of a downloadable OpenAPI spec or other machine-readable API schema anywhere in the pack.

   • [claimed-docs] “Sift easily integrates into your existing systems using modern REST APIs, Javascript snippet, and SDKs for iOS and Android.”
   • [claimed-docs] “What actions your users are taking, usually key user lifecycle events (e.g., creating an account, placing an order, posting content to other…”
   • [claimed-docs] “What actions your business is taking in response to users (e.g., approve an order, block and event due to fraud, cancel order due to chargeb…”
   • [claimed-docs] “Workflows enable you to make risk-based decisions in real time during key events. Follow this guide to create your own custom Workflow.”

   proof ↗⚑ flag

   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

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

   weight 1 · round drawn
   Sift—none0/10

   No evidence pack item mentions a sandbox environment, test mode, or any way to test Sift integrations without touching production data; all docs reference live Events/Decisions/Score APIs. Missing for 10: sandbox/test environment docs, test API keys or staging mode, any mention of separating test vs production data.

   ⚑ flag

   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

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

   weight 2 · round drawn
   Sift—none0/10

   Evidence shows Sift has REST APIs, SDKs, and docs but no mention of API versioning scheme or a documented deprecation policy anywhere in the pack. Missing for 10: explicit API versioning documentation, deprecation policy or changelog, migration timelines for breaking changes.

   ⚑ flag

   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

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

   weight 2 · round to Sift
   Sift~partialclaimed3/10

   Sift documents backfilling months of historical data as a bulk-load capability, but there is no evidence of a dedicated bulk API for batch-scoring, batch-deciding, or bulk-updating many items at once (e.g., no batch endpoint documentation). Missing for 10: explicit bulk/batch API documentation, batch decision or batch scoring examples, and any hands-on evidence of bulk workflows being used successfully.

   • [claimed-docs] “Because Sift gets smarter the more data it has about your business, you can jump start your integration by backfilling a few months worth of…”
   • [claimed-docs] “What actions your users are taking, usually key user lifecycle events (e.g., creating an account, placing an order, posting content to other…”
   • [claimed-docs] “What actions your business is taking in response to users (e.g., approve an order, block and event due to fraud, cancel order due to chargeb…”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Sift
   Sift!disputedcontradicted5/10

   Sift's docs clearly describe a 'Workflows' rules automation platform that triggers real-time Decisions (Ban Account, Cancel Order) based on event risk scores, directly matching the story. However, a Sift co-founder is quoted saying 'we do not have any rules in our product... rules are rather easy for fraudsters to circumvent,' directly contradicting the vendor's later rules-automation framing. missing for 10: reconciliation of this contradiction and independent hands-on confirmation that customer-defined Workflow rules reliably trigger automated actions in production.

   • [claimed-docs] “Workflows enable you to make risk-based decisions in real time during key events. Follow this guide to create your own custom Workflow.”
   • [claimed-docs] “Learn to set up custom Decisions, like Ban Account or Cancel Order, that are connected to real business actions in your backend.”
   • [claimed-docs] “Sift offers Workflows, a powerful rules automation platform, and Review Queues.”
   • [community] “CEO explains no-rules ML approach: 'we do not have any rules in our product... rules are rather easy for fraudsters to circumvent, and they …”

   proof ↗⚑ flag

   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

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

   No evidence anywhere in the pack mentions a chargeback guarantee, liability shift, reimbursement for approved-then-disputed orders, or coverage terms — Sift is documented only as a fraud-scoring/risk-decision API, not an insurance-backed guarantee product.

   ⚑ flag

   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

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

   Evidence covers APIs, scoring, workflows, and general product sentiment, but there is no mention of finance-lead dashboards, dispute-rate/false-positive/approval-lift metrics, review workload reporting, or board-ready export capability. missing for 10: dispute-rate and false-positive-rate metrics reporting, approval-rate lift analytics, review workload/queue metrics, export or reporting functionality for finance/board consumption.

   ⚑ flag

   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

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 Signifyd
   Sift—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

   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

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

   Evidence shows REST/Decisions/Workflows APIs for events, scoring, and rules automation, but nothing describes an AI agent reading fraud posture or proposing/updating rules and lists with a human-approval workflow — this is a generic developer API story, not an agent-access pattern. missing for 10: any mention of AI agent integration, agentic rule-proposal workflow, or human-approval gate mechanism tied to programmatic rule/list changes.

   • [claimed-docs] “Sift easily integrates into your existing systems using modern REST APIs, Javascript snippet, and SDKs for iOS and Android.”
   • [claimed-docs] “What actions your business is taking in response to users (e.g., approve an order, block and event due to fraud, cancel order due to chargeb…”
   • [claimed-docs] “Sift offers Workflows, a powerful rules automation platform, and Review Queues.”

   proof ↗⚑ flag

   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

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

   Sift has Review Queues and REST/Decisions APIs for humans to review flagged cases (sift-docs-12, sift-docs-3), and community evidence confirms a human-in-the-loop review model (sift-comm-4), but there is no evidence of an AI agent programmatically pulling flagged cases, summarizing evidence, or recommending decisions for human confirmation.

   • [claimed-docs] “Sift offers Workflows, a powerful rules automation platform, and Review Queues.”
   • [claimed-docs] “What actions your business is taking in response to users (e.g., approve an order, block and event due to fraud, cancel order due to chargeb…”
   • [community] “Sift Science founder on false positives: 'Most of our customers review each user we flag, and have a human make a final go/no-go decision ab…”

   proof ↗⚑ flag

   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

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

   The evidence pack covers Sift's APIs, scoring, workflows/rules automation, and review queues, but there is no mention of any built-in AI assistant, natural-language query capability, drafted rules generation, or investigation summary generation in the console. Missing for 10: any documentation or mention of a natural-language/AI assistant feature, evidence of NL-to-query capability, evidence of AI-drafted rules or summaries.

   • [claimed-docs] “Workflows enable you to make risk-based decisions in real time during key events. Follow this guide to create your own custom Workflow.”
   • [claimed-docs] “Sift offers Workflows, a powerful rules automation platform, and Review Queues.”

   proof ↗⚑ flag

   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

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 Sift
   Sift✓fullclaimed8/10

   Docs explicitly cover multiple fraud surfaces beyond checkout — account takeover ('Block unauthorized access in real time'), fake account creation ('Stop fraudulent signups at the door'), and abuse-specific scoring ('fight multiple types of fraud at once... add an abuse-specific risk score'), all managed within the same Workflows/Decisions/Review Queue system. Missing for 10: dedicated documentation or case study specifically on promo/policy abuse handling, and independent hands-on verification of multi-surface scoring in one unified dashboard.

   • [claimed-docs] “Block unauthorized access in real time.”
   • [claimed-docs] “Stop fraudulent signups at the door.”
   • [claimed-docs] “Want to fight multiple types of fraud at once? Learn how to add an abuse-specific risk score so that you can easily do so.”
   • [claimed-docs] “Workflows enable you to make risk-based decisions in real time during key events. Follow this guide to create your own custom Workflow.”
   • [claimed-docs] “Sift offers Workflows, a powerful rules automation platform, and Review Queues.”
   • [claimed-docs] “Learn to set up custom Decisions, like Ban Account or Cancel Order, that are connected to real business actions in your backend.”

   proof ↗⚑ flag

   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

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 drawn
   Sift—none0/10

   Evidence shows only generic REST API, JS snippet, and mobile SDKs — no mention of maintained Shopify, Salesforce Commerce, BigCommerce, or PSP-specific integrations. Everything points to a raw API/SDK integration model, not prebuilt commerce-platform connectors.

   • [claimed-docs] “Sift easily integrates into your existing systems using modern REST APIs, Javascript snippet, and SDKs for iOS and Android.”
   • [claimed-docs] “What actions your users are taking, usually key user lifecycle events (e.g., creating an account, placing an order, posting content to other…”
   • [claimed-docs] “What actions your business is taking in response to users (e.g., approve an order, block and event due to fraud, cancel order due to chargeb…”

   proof ↗⚑ flag

   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

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 to Signifyd
   Sift~partialclaimed5/10

   Sift's architecture (generic REST Events/Decisions API, JS snippet, SDKs) is inherently processor-agnostic — it ingests events from any application regardless of which PSP or gateway processes the payment, rather than being tied to one processor's rails. However, there is no explicit documentation or case evidence naming specific PSPs/gateways/platforms it integrates with or confirming multi-processor deployments in practice. Missing for 10: explicit multi-PSP/gateway integration examples, named partner processors, or customer testimony confirming cross-stack usage.

   • [claimed-docs] “Sift easily integrates into your existing systems using modern REST APIs, Javascript snippet, and SDKs for iOS and Android.”
   • [claimed-docs] “What actions your users are taking, usually key user lifecycle events (e.g., creating an account, placing an order, posting content to other…”
   • [claimed-docs] “What actions your business is taking in response to users (e.g., approve an order, block and event due to fraud, cancel order due to chargeb…”
   • [claimed-docs] “Custom events and fields describe user actions not captured by the supported events in our Events API.”

   proof ↗⚑ flag

   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

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

   The evidence pack documents Sift's 0–100 risk score, Workflows, and Decisions APIs, but nowhere mentions score explanations, reason codes, or top contributing risk factors accompanying each score. Missing for 10: any documentation of explainability/reason-code output, feature-importance breakdowns, or examples of a score being paired with human-readable risk drivers.

   • [claimed-docs] “Sift represents this risk with a score between 0 and 100, where risky events have higher scores.”
   • [claimed-docs] “Workflows enable you to make risk-based decisions in real time during key events. Follow this guide to create your own custom Workflow.”
   • [claimed-docs] “Sift offers Workflows, a powerful rules automation platform, and Review Queues.”

   proof ↗⚑ flag

   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

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

   Evidence covers scoring, workflows, decisions, and events APIs, but there is no mention of precision/recall metrics on the customer's own traffic, model performance measurement, or shadow-mode trialing of new models/rules before they go live. missing for 10: precision/recall measurement tooling, shadow-mode/challenger model testing, any model transparency reporting for finance/business stakeholders.

   ⚑ flag

   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

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

   weight 2 · round to Sift
   Sift~partialclaimed6/10

   Sift's docs show extensive REST APIs covering events, decisions, scoring, and even a Workflows API for automation, indicating broad programmatic access mirroring core UI functions (sift-docs-1,2,3,5,6,12). However, there's no explicit evidence that Review Queues or full workflow configuration UI actions are fully API-equivalent, and no independent confirmation of complete UI/API parity. missing for 10: explicit parity claim for Review Queues and workflow UI configuration, independent verification of full CRUD API coverage matching every console action.

   • [claimed-docs] “Sift easily integrates into your existing systems using modern REST APIs, Javascript snippet, and SDKs for iOS and Android.”
   • [claimed-docs] “What actions your users are taking, usually key user lifecycle events (e.g., creating an account, placing an order, posting content to other…”
   • [claimed-docs] “What actions your business is taking in response to users (e.g., approve an order, block and event due to fraud, cancel order due to chargeb…”
   • [claimed-docs] “Sift represents this risk with a score between 0 and 100, where risky events have higher scores.”
   • [claimed-docs] “Workflows enable you to make risk-based decisions in real time during key events. Follow this guide to create your own custom Workflow.”
   • [claimed-docs] “Sift offers Workflows, a powerful rules automation platform, and Review Queues.”

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Sift—none0/10

   Sift is a fraud-detection API platform; evidence covers sending events/data into Sift via REST API, scoring, workflows, but there is no mention of exporting or bulk-downloading customer data out of Sift in open formats, nor any data-portability/export feature. missing for 10: any documented data export/download capability, open-format export (CSV/JSON dumps), or account data portability tooling.

   ⚑ flag

   Signifyd—none0/10

   Evidence shows a REST API for submitting order/checkout/chargeback data into Signifyd and retrieving decisions, but nothing indicates a full data-export capability or open-format bulk export/portability feature for users to take all their data and leave. No mention of GDPR-style export, data portability tooling, or account deletion/export flows. missing for 10: bulk/full data export feature, open-format (CSV/JSON) export documentation, account closure/data portability guarantee.

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Sift—none0/10

   No evidence in the pack mentions data residency, regional storage options, or geographic control over where Sift stores customer data; one community comment even notes hesitation about sending data to Sift without clarity on compliance handling. Missing for 10: any documentation of region selection, data residency options, or compliance certifications addressing storage location.

   • [community] “Potential customer notes hesitation: reservations about sending personal user data to an aggregator that would then require legal review for…”

   proof ↗⚑ flag

   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

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round drawn
   Sift—none0/10

   Sift is a fraud-detection platform whose business model relies on ingesting user behavioral data to train its ML risk models; no evidence pack item mentions any opt-out, data-training-exclusion policy, or AI-training-specific privacy controls for end users. Missing for 10: any documentation of an opt-out mechanism, training-data exclusion policy, or user-facing privacy control preventing model training use.

   ⚑ flag

   Signifyd—none0/10

   No evidence addresses AI-model-training data usage or opt-out controls; the pack only covers fraud-protection APIs and sensitive-data rejection at the API layer, which is unrelated to AI training data policy.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Sift—none0/10

   Sift is a fraud-detection API/platform, and the evidence pack contains no documentation of data retention controls, deletion APIs, or configurable data lifecycle policies for users. One community comment (sift-comm-3) even flags unresolved privacy/legal review concerns about sending personal data to Sift, but this is not concrete evidence of a retention/deletion mechanism either way. missing for 10: any documentation of data retention settings, a deletion/right-to-be-forgotten API, or data lifecycle/export controls.

   • [community] “Potential customer notes hesitation: reservations about sending personal user data to an aggregator that would then require legal review for…”

   proof ↗⚑ flag

   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

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

   No evidence pack items discuss regional data residency, data hosting locations, retention periods, or compliance/privacy review controls; one comment even notes a prospective customer's hesitation about privacy/legal review with no resolution shown. Missing for 10: any documentation of regional hosting/data residency options, retention/configurable deletion policies, or compliance certifications addressing privacy review.

   • [community] “Potential customer notes hesitation: reservations about sending personal user data to an aggregator that would then require legal review for…”

   proof ↗⚑ flag

   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

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

   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

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 to Sift
   Sift~partialcommunity5/10

   Sift documents Review Queues as a product feature alongside Workflows, and community evidence confirms human analysts do review flagged users to make final decisions, supporting the general workflow. However, there is no evidence detailing the review queue UI showing customer history, similar cases, or signal context in one view. missing for 10: documentation/screenshots of review queue UI showing customer history and similar cases, evidence of consolidated signal context, independent hands-on confirmation of queue usability.

   • [claimed-docs] “Sift offers Workflows, a powerful rules automation platform, and Review Queues.”
   • [community] “Sift Science founder on false positives: 'Most of our customers review each user we flag, and have a human make a final go/no-go decision ab…”

   proof ↗⚑ flag

   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

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 Sift
   Sift~partialcommunity6/10

   Sift's Decisions API explicitly captures business actions like 'block due to fraud' or 'cancel due to chargeback' and feeds them back to Sift, and docs state Sift 'gets smarter the more data it has,' supporting a feedback loop from confirmed outcomes into the model. Review Queues and Workflows are documented as connected to decisions, and a founder note confirms customers commonly have analysts make final go/no-go calls that presumably feed Decisions API. Missing for 10: explicit documentation that individual analyst review-queue verdicts (not just automated decisions) are looped back per-case to retrain the model, and any detail on how confirmed fraud outcomes update rules/workflows specifically.

   • [claimed-docs] “What actions your business is taking in response to users (e.g., approve an order, block and event due to fraud, cancel order due to chargeb…”
   • [claimed-docs] “Because Sift gets smarter the more data it has about your business, you can jump start your integration by backfilling a few months worth of…”
   • [claimed-docs] “Sift offers Workflows, a powerful rules automation platform, and Review Queues.”
   • [community] “Sift Science founder on false positives: 'Most of our customers review each user we flag, and have a human make a final go/no-go decision ab…”

   proof ↗⚑ flag

   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

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 to Sift
   Sift~partialcommunity5/10

   Sift documents Review Queues and Workflows for human review, plus a Decisions API that logs business actions like approve/ban/cancel tied to real events, which supports a basic audit trail; a founder comment also confirms a human-in-the-loop review pattern ('have a human make a final go/no-go decision'). However, there's no evidence of explicit team-workflow features like assignment routing, escalation paths, or SLA tracking. missing for 10: assignment/routing mechanics, escalation workflows, SLA timers/tracking, explicit 'who approved what and why' UI/reporting beyond raw decision logs.

   • [claimed-docs] “Sift offers Workflows, a powerful rules automation platform, and Review Queues.”
   • [claimed-docs] “What actions your business is taking in response to users (e.g., approve an order, block and event due to fraud, cancel order due to chargeb…”
   • [claimed-docs] “Learn to set up custom Decisions, like Ban Account or Cancel Order, that are connected to real business actions in your backend.”
   • [community] “Sift Science founder on false positives: 'Most of our customers review each user we flag, and have a human make a final go/no-go decision ab…”

   proof ↗⚑ flag

   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

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 Sift
   Sift✓fullclaimed8/10

   Sift's docs clearly support ingesting custom events, custom fields, session/device signals, and business action data via Events/Decisions APIs, and scoring incorporates this custom data plus historical backfill to tailor risk to the business rather than generic network defaults. Missing for 10: independent hands-on verification of custom-field scoring impact and explicit device-fingerprint API documentation beyond general SDK mentions.

   • [claimed-docs] “What actions your users are taking, usually key user lifecycle events (e.g., creating an account, placing an order, posting content to other…”
   • [claimed-docs] “What actions your business is taking in response to users (e.g., approve an order, block and event due to fraud, cancel order due to chargeb…”
   • [claimed-docs] “Because Sift gets smarter the more data it has about your business, you can jump start your integration by backfilling a few months worth of…”
   • [claimed-docs] “Custom events and fields describe user actions not captured by the supported events in our Events API.”
   • [claimed-docs] “When users are anonymous for parts or all of their experience on your site, we provide a special `session_id` field in the JS Snippet and Ev…”
   • [claimed-docs] “Sift represents this risk with a score between 0 and 100, where risky events have higher scores.”

   proof ↗⚑ flag

   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

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

   The evidence pack describes Sift's own ML scoring, event/decision APIs, and workflows, but nowhere claims that risk signals (e.g., a card or identity) are shared or aggregated across Sift's merchant customer base to inform another business's score. sift-docs-4 only references a business's own historical data improving its own model, not cross-merchant network effects.

   ⚑ flag

   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

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 to Sift
   Sift~partialcommunity7/10

   Sift's docs describe Workflows as a rules automation platform for real-time risk-based decisions, with custom Decisions (e.g., Ban Account, Cancel Order) tied to score ranges (0-100), and Review Queues for human review — directly supporting configurable score-to-action mapping and threshold tuning. However, no evidence explicitly mentions 3DS step-up as an action type, and an older founder comment (sift-comm-8) claims 'no rules' which is in tension with the current Workflows rules-engine framing, though this appears to reflect product evolution rather than a live contradiction. missing for 10: explicit 3DS/step-up action documentation, independent hands-on confirmation of threshold customization in practice.

   • [claimed-docs] “Sift represents this risk with a score between 0 and 100, where risky events have higher scores.”
   • [claimed-docs] “Workflows enable you to make risk-based decisions in real time during key events. Follow this guide to create your own custom Workflow.”
   • [claimed-docs] “Learn to set up custom Decisions, like Ban Account or Cancel Order, that are connected to real business actions in your backend.”
   • [claimed-docs] “Sift offers Workflows, a powerful rules automation platform, and Review Queues.”
   • [community] “Sift Science founder on false positives: 'Most of our customers review each user we flag, and have a human make a final go/no-go decision ab…”
   • [community] “CEO explains no-rules ML approach: 'we do not have any rules in our product... rules are rather easy for fraudsters to circumvent, and they …”

   proof ↗⚑ flag

   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

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 Sift
   Sift~partialcommunity6/10

   Sift's documented Score API returns a 0-100 ML risk score via REST, and Workflows enable real-time risk-based decisions during key events, supporting synchronous scoring before a decision. However, the evidence doesn't explicitly confirm the Score API is called synchronously pre-authorization (vs. async/webhook-based scoring), and community feedback notes many customers use human review queues rather than pure real-time automated decisions. Missing for 10: explicit documentation of synchronous call/response latency guarantees for pre-authorization use, and independent confirmation of real-time performance under transaction-blocking scenarios.

   • [claimed-docs] “Sift represents this risk with a score between 0 and 100, where risky events have higher scores.”
   • [claimed-docs] “Workflows enable you to make risk-based decisions in real time during key events. Follow this guide to create your own custom Workflow.”
   • [claimed-docs] “Block unauthorized access in real time.”
   • [community] “Sift Science founder on false positives: 'Most of our customers review each user we flag, and have a human make a final go/no-go decision ab…”

   proof ↗⚑ flag

   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

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

   The evidence describes Workflows as a rules automation platform and mentions real-time decisioning, but nothing in the pack describes a backtest/simulation capability against historical traffic showing what a rule would have blocked/flagged/cost.

   • [claimed-docs] “Sift offers Workflows, a powerful rules automation platform, and Review Queues.”
   • [claimed-docs] “Workflows enable you to make risk-based decisions in real time during key events. Follow this guide to create your own custom Workflow.”

   proof ↗⚑ flag

   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

Lists

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

   weight 2 · round to Sift
   Sift!disputedcontradicted3/10

   Docs describe a general 'Workflows' rules automation platform and Review Queues, but there's no explicit mention of dedicated allow/block lists for emails, cards, devices, or IPs, nor velocity limit configuration in the dashboard or API. Compounding this, a Sift co-founder is quoted stating 'we do not have any rules in our product' as a core design philosophy, directly conflicting with the rules-engine framing implied by the Workflows docs. missing for 10: explicit allow/block list management (emails, cards, devices, IPs), velocity limit configuration, dashboard UI evidence, and resolution of the rules-vs-no-rules contradiction.

   • [claimed-docs] “Sift offers Workflows, a powerful rules automation platform, and Review Queues.”
   • [claimed-docs] “Workflows enable you to make risk-based decisions in real time during key events. Follow this guide to create your own custom Workflow.”
   • [community] “CEO explains no-rules ML approach: 'we do not have any rules in our product... rules are rather easy for fraudsters to circumvent, and they …”
   • [community] “Critical take: 'The biggest problem with ML is that it takes time for it to react to new fraud patterns/schemes. While rules engines have li…”

   proof ↗⚑ flag

   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

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 to Sift
   Sift!disputedcontradicted5/10

   Docs describe Workflows as a 'powerful rules automation platform' for real-time decisioning (allow/block/review) using scores and custom logic (sift-docs-6, sift-docs-7, sift-docs-12), suggesting the requested rule authoring capability. However, a Sift co-founder is on record stating 'we do not have any rules in our product' and that rules are easy to circumvent, directly contradicting the existence of a rules engine (sift-comm-8), and no evidence details velocity counters or list-match integration into rule logic. missing for 10: explicit documentation of velocity counters, list matching, and multi-attribute rule composition within Workflows; independent verification reconciling the rules-vs-no-rules discrepancy.

   • [claimed-docs] “Workflows enable you to make risk-based decisions in real time during key events. Follow this guide to create your own custom Workflow.”
   • [claimed-docs] “Learn to set up custom Decisions, like Ban Account or Cancel Order, that are connected to real business actions in your backend.”
   • [claimed-docs] “Sift offers Workflows, a powerful rules automation platform, and Review Queues.”
   • [community] “CEO explains no-rules ML approach: 'we do not have any rules in our product... rules are rather easy for fraudsters to circumvent, and they …”

   proof ↗⚑ flag

   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