Signifyd vs Forter

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

   Forter~partialprobed7/10

   Forter's agentic-orders docs show a dedicated orderType=AI_AGENT field that flags agent-driven purchases so Forter's risk engine can treat them distinctly rather than blanket-blocking, which directly targets this story. However, the evidence is entirely first-party documentation with no independent testing or detail on the underlying bot-vs-legitimate-agent classification logic. Missing for 10: independent/hands-on validation of accuracy, technical detail on how malicious bots are distinguished from legitimate agents beyond a merchant-set flag.

   • [claimed-docs] “Set orderType to AI_AGENT”
   • [claimed-docs] “Set orderType to AI_AGENT ... This additional data improves Forter's risk decisions and provides the merchant better reporting on agentic tr…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.forter.com/llms.txt # docs.forter.com ## Overviews - [Agentic Orders](https://docs.forter.com/age…”

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

   Forter~partialclaimed5/10

   Forter's agentic-orders API lets developers set orderType to AI_AGENT so the risk engine treats agent-originated traffic differently and improves decisioning/reporting, which shows agent identity is ingested as a factor. However, the evidence only shows a coarse flag, not verified signed agent tokens, delegated spending scopes, or support for specific agentic-payment protocols (e.g., AP2/Visa/Mastercard agent tokens) as first-class structured signals. missing for 10: schema/fields for signed agent credentials or delegation scopes, explicit protocol support for agentic-payment standards, independent confirmation these fields are cryptographically verified rather than self-declared.

   • [claimed-docs] “Set orderType to AI_AGENT”
   • [claimed-docs] “Set orderType to AI_AGENT ... This additional data improves Forter's risk decisions and provides the merchant better reporting on agentic tr…”
   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”

   proof ↗⚑ flag

Agent access

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

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

   Forter✓fullprobed9/10

   Forter has a confirmed live llms.txt at docs.forter.com/llms.txt (HTTP 200, forter-probe-1) listing agent-oriented doc overviews, plus explicit agent-facing docs like the MCP getting-started guide for connecting to Claude Desktop and agentic-orders docs — all markdown-served for agent consumption. Missing for 10: independent third-party confirmation that agents successfully consume the llms.txt in practice beyond the probe check.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.forter.com/llms.txt # docs.forter.com ## Overviews - [Agentic Orders](https://docs.forter.com/age…”
   • [claimed-docs] “Connect Forter MCP to Claude Desktop app for conversational AI workflows.”
   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”

   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

   Forter~partialprobed4/10

   Forter is a REST/webhook-based fraud API (order submission, status updates, webhooks, sandbox/test environment) which can technically be called from scripts or CI pipelines, and it offers an MCP server for programmatic/agentic access. However, there is no evidence of a CLI tool, CI/CD integration examples, headless testing harness, or automation-focused tooling explicitly designed for CI pipelines. missing for 10: dedicated CLI, CI/CD pipeline examples or GitHub Actions integration, headless test automation docs, explicit 'run in CI' guidance beyond generic sandbox API testing.

   • [claimed-docs] “Forter has both a production and a sandbox environment for your development process.”
   • [claimed-docs] “The main objective of the TEST site is to allow you to verify the integration prior to its deployment in the production environment.”
   • [claimed-docs] “Send order information at checkout to receive a fraud or abuse decision.”
   • [probe] “official MCP server documented at https://docs.forter.com/mcp”
   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”

   proof ↗⚑ flag

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

   weight 3 · round to Forter
   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

   Forter✓fullprobed8/10

   Forter documents an official MCP server enabling AI agents to review decisions, manage disputes, and update policies via natural language, with a getting-started guide for connecting to Claude Desktop. missing for 10: independent/third-party corroboration of real-world MCP usage and broader client compatibility beyond Claude Desktop.

   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”
   • [claimed-docs] “Connect Forter MCP to Claude Desktop app for conversational AI workflows.”
   • [probe] “official MCP server documented at https://docs.forter.com/mcp”

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

   Forter—none0/10

   Evidence shows Forter offers REST APIs, webhooks, and an MCP server for conversational AI workflows, but no official CLI tool is documented anywhere in the evidence pack.

   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”
   • [claimed-docs] “Connect Forter MCP to Claude Desktop app for conversational AI workflows.”
   • [probe] “official MCP server documented at https://docs.forter.com/mcp”

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

   Forter✓fullprobed8/10

   Forter publishes a documented public REST API (Order v3, Order Status, Evidence API, webhooks) with sandbox/production environments, giving AI-native users a clear path to drive the product programmatically; this is reinforced by an official MCP server enabling natural-language/agentic control of decisions and disputes. Missing for 10: independent/hands-on corroboration beyond vendor docs, and more detail on auth/rate limits or SDK coverage.

   • [claimed-docs] “Send order information at checkout to receive a fraud or abuse decision.”
   • [claimed-docs] “Inform of updates to the status of an order, including payment authorization, fulfillment, shipping details, and compensation granted.”
   • [claimed-docs] “Webhooks provide a way to configure Forter to send real-time notifications to your web store server or another service (ERP/OMS) whenever ce…”
   • [claimed-docs] “Forter has both a production and a sandbox environment for your development process.”
   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”
   • [claimed-docs] “Connect Forter MCP to Claude Desktop app for conversational AI workflows.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.forter.com/llms.txt # docs.forter.com ## Overviews - [Agentic Orders](https://docs.forter.com/age…”
   • [probe] “official MCP server documented at https://docs.forter.com/mcp”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Signifyd—none0/10

   Evidence shows only general REST API authentication docs and endpoints; there is no mention of scoped, least-privilege, or agent-specific API credentials/tokens, OAuth scopes, or granular permissioning for API keys.

   • [claimed-docs] “This document will show you how to use Signifyd's REST API to authenticate, make requests, and retrieve data.”

   proof ↗⚑ flag

   Forter—none0/10

   Forter has API/webhook docs and even an MCP server for agent-driven actions, but no evidence describes issuing scoped or least-privilege API credentials/tokens for an agent identity. Missing for 10: any mention of API key/token scoping, permission levels, or credential issuance workflow for agents.

   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”
   • [claimed-docs] “Connect Forter MCP to Claude Desktop app for conversational AI workflows.”
   • [probe] “official MCP server documented at https://docs.forter.com/mcp”

   proof ↗⚑ flag

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

   Forter~partialprobed5/10

   Forter provides extensive REST API references (Order v3, Order Status, Evidence API, webhooks), a sandbox/production environment, and even a documented MCP server for agentic workflows, which together give an AI-native developer solid material to build against. However, none of the evidence explicitly names or links to official client-language SDKs (e.g., Python/Node/Java packages) — only API/reference docs and an MCP integration are shown. Missing for 10: explicit official SDK packages/libraries, versioned SDK release notes, and independent corroboration of SDK usage in production.

   • [claimed-docs] “Send order information at checkout to receive a fraud or abuse decision.”
   • [claimed-docs] “Inform of updates to the status of an order, including payment authorization, fulfillment, shipping details, and compensation granted.”
   • [claimed-docs] “Webhooks provide a way to configure Forter to send real-time notifications to your web store server or another service (ERP/OMS) whenever ce…”
   • [claimed-docs] “Forter has both a production and a sandbox environment for your development process.”
   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”
   • [claimed-docs] “Connect Forter MCP to Claude Desktop app for conversational AI workflows.”
   • [probe] “official MCP server documented at https://docs.forter.com/mcp”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

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

   Forter✓fullclaimed7/10

   Forter documents a dedicated webhooks system for real-time event notifications (order status, chargeback forwarding, dispute webhooks) that can be configured to notify external services, directly matching the subscribe-to-events story; this is a well-documented first-party capability. missing for 10: independent/hands-on corroboration of webhook reliability, and a comprehensive list of subscribable event types/payload schema beyond the examples shown.

   • [claimed-docs] “Webhooks provide a way to configure Forter to send real-time notifications to your web store server or another service (ERP/OMS) whenever ce…”
   • [claimed-docs] “Inform of updates to the status of an order, including payment authorization, fulfillment, shipping details, and compensation granted.”
   • [claimed-docs] “Webhook-based forwarding enables: - Real-time claim ingestion - Faster transaction matching - Immediate eligibility assessment for dispute h…”
   • [claimed-docs] “How to provide Forter access to your Stripe Dispute Webhooks.”
   • [claimed-docs] “Webhook-based forwarding enables: Real-time claim ingestion - Faster transaction matching - Immediate eligibility assessment for dispute han…”

   proof ↗⚑ flag

Agentic features

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

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

   Forter~partialclaimed6/10

   Forter provides an AI-driven recommendation engine that suggests additional evidence to bolster dispute win rates and a 'team of Forter Agents' concept, plus MCP-enabled natural language interactions for reviewing decisions and managing disputes. This shows some AI-generated insight/suggestion capability embedded in the product, but evidence is thin on broader analytics/insights (e.g., fraud trend explanations, risk scoring rationale) beyond the dispute-evidence use case. Missing for 10: broader in-product AI insights beyond dispute evidence suggestions, independent/hands-on corroboration of the recommendation engine's quality, and detail on what other 'Forter Agents' actually surface to users.

   • [claimed-docs] “our recommendation engine will suggest additional evidence to add to your dispute to bolster your win rate.”
   • [claimed-docs] “Once chargebacks are ingested into Forter, our recommendation engine will suggest additional evidence to add to your dispute to bolster your…”
   • [claimed-docs] “Meet your new team of Forter Agents, so you can spend more time on what matters most.”
   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”
   • [claimed-docs] “Connect Forter MCP to Claude Desktop app for conversational AI workflows.”

   proof ↗⚑ flag

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

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

   Forter~partialprobed5/10

   Forter's fraud automation (webhooks, chargeback forwarding, evidence recommendation, MCP for reviewing decisions/managing disputes) provides background automation of fraud/dispute workflows, and the MCP server lets AI agents trigger actions, but this is not framed as user-configurable 'set up automations that run autonomously' in the sense of scheduled/triggered workflows the AI-native user builds themselves. missing for 10: explicit user-facing automation builder/scheduler, evidence of autonomous background runs initiated by the user rather than reactive webhook/event responses, and independent confirmation of real-world autonomous operation.

   • [claimed-docs] “Webhooks provide a way to configure Forter to send real-time notifications to your web store server or another service (ERP/OMS) whenever ce…”
   • [claimed-docs] “Webhook-based forwarding enables: - Real-time claim ingestion - Faster transaction matching - Immediate eligibility assessment for dispute h…”
   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”
   • [claimed-docs] “Once chargebacks are ingested into Forter, our recommendation engine will suggest additional evidence to add to your dispute to bolster your…”
   • [claimed-docs] “Connect Forter MCP to Claude Desktop app for conversational AI workflows.”
   • [probe] “official MCP server documented at https://docs.forter.com/mcp”

   proof ↗⚑ flag

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

   weight 3 · round to Forter
   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

   Forter~partialclaimed3/10

   Forter's marketing mentions a 'team of Forter Agents' suggesting built-in AI-driven automation, but the evidence pack gives no detail on how a user interacts with or delegates tasks to such an assistant inside the product UI. The only detailed AI-interaction evidence (MCP) is about connecting external assistants like Claude Desktop to Forter, not a built-in assistant. Missing for 10: documentation of an in-product conversational assistant UI, examples of task delegation, and how 'Forter Agents' are invoked/configured.

   • [claimed-docs] “Meet your new team of Forter Agents, so you can spend more time on what matters most.”
   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”

   proof ↗⚑ flag

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

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

   Forter✓fullprobed8/10

   Forter documents a first-party MCP server enabling natural-language commands to review decisions, manage disputes, and update policies, with a getting-started guide for connecting to Claude Desktop for conversational workflows. Missing for 10: independent/hands-on corroboration beyond vendor docs, and broader coverage of which actions are NL-operable vs API-only.

   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”
   • [claimed-docs] “Connect Forter MCP to Claude Desktop app for conversational AI workflows.”
   • [probe] “official MCP server documented at https://docs.forter.com/mcp”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.forter.com/llms.txt # docs.forter.com ## Overviews - [Agentic Orders](https://docs.forter.com/age…”

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

   Forter—none0/10

   The evidence pack shows Forter has API reference documentation (order-v3, order-status, webhooks, environments) but nothing indicates the docs are interactive with runnable/try-it examples—no mention of an embedded API console, code sandbox, or 'try it' functionality typical of interactive API references.

   ⚑ 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

   Forter—none0/10

   Forter publishes REST API reference docs (order-v3, order-status, webhooks) but none of the evidence mentions a downloadable OpenAPI/Swagger spec or machine-readable API definition file; the llms.txt probe lists doc pages, not an API spec.

   • [claimed-docs] “Send order information at checkout to receive a fraud or abuse decision.”
   • [claimed-docs] “Inform of updates to the status of an order, including payment authorization, fulfillment, shipping details, and compensation granted.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.forter.com/llms.txt # docs.forter.com ## Overviews - [Agentic Orders](https://docs.forter.com/age…”

   proof ↗⚑ flag

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

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

   Forter✓fullclaimed8/10

   Forter explicitly documents both production and sandbox (TEST) environments, stating the sandbox's purpose is to verify integration before production deployment, allowing testing without touching production data. Missing for 10: no independent/hands-on corroboration of sandbox behavior or details on sandbox data parity/limitations.

   • [claimed-docs] “Forter has both a production and a sandbox environment for your development process.”
   • [claimed-docs] “The main objective of the TEST site is to allow you to verify the integration prior to its deployment in the production environment.”

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

   Forter—none0/10

   Evidence shows versioned API endpoints (e.g. order-v3) and sandbox/production environments, but there is no documentation of a versioning scheme, version support lifecycle, or a deprecation policy anywhere in the pack.

   • [claimed-docs] “Send order information at checkout to receive a fraud or abuse decision.”
   • [claimed-docs] “Forter has both a production and a sandbox environment for your development process.”
   • [claimed-docs] “The main objective of the TEST site is to allow you to verify the integration prior to its deployment in the production environment.”

   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

   Forter—none0/10

   Forter's docs describe per-order/per-dispute APIs (Order v3, Evidence API, webhooks, MCP natural-language actions) but no evidence of a bulk/batch endpoint or mechanism for acting across many items simultaneously. The axis is applicable (merchants would plausibly want bulk dispute/evidence submission or bulk order review), but no such capability is documented.

   • [claimed-docs] “Send order information at checkout to receive a fraud or abuse decision.”
   • [claimed-docs] “Save time and effort by using our Evidence API endpoint to automatically send post-order evidence for chargeback disputes.”
   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”

   proof ↗⚑ flag

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

   weight 3 · round to Forter
   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

   Forter~partialclaimed5/10

   Forter supports event-driven automation via webhooks (real-time notifications on events like disputes/chargebacks) and configurable decision behaviors (e.g., Auto Invoice triggering capture), and its MCP interface lets an AI agent perform actions like reviewing decisions or updating policies via natural language. However, there is no evidence of a user-facing rule-definition engine (e.g., 'if X then Y' conditions) that AI-native users can author themselves. Missing for 10: explicit rule-builder/conditional logic UI or API, examples of user-defined trigger-action pairs beyond fixed webhook events and preset decision toggles.

   • [claimed-docs] “Webhooks provide a way to configure Forter to send real-time notifications to your web store server or another service (ERP/OMS) whenever ce…”
   • [claimed-docs] “If the Auto Invoice option is set to YES, then the payment capture amount operation is executed and order is placed”
   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”
   • [claimed-docs] “Webhook-based forwarding enables: - Real-time claim ingestion - Faster transaction matching - Immediate eligibility assessment for dispute h…”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   Signifyd—none0/10

   No evidence of any versioning, review, or rollback mechanism for automations/rules/workflows in Signifyd; the docs only cover API endpoints for fraud decisioning, webhooks, and chargebacks. Missing for 10: version history UI, audit trail for rule/automation changes, and rollback capability.

   ⚑ flag

   Forter—none0/10

   No evidence of any versioning, review, or rollback mechanism for automations/workflows in Forter's docs; the MCP and agentic-order features cover fraud decisioning and dispute automation, not automation lifecycle management like version history or rollback.

   ⚑ 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

   Forter—none0/10

   The evidence pack details dispute automation, evidence submission, webhook forwarding, and win-rate optimization tools, but none of it documents an actual chargeback guarantee, reimbursement mechanism, or liability-shift terms — the core of this finance-lead story. Missing for 10: explicit guarantee/reimbursement policy language, coverage terms, or liability-shift contract details.

   • [claimed-docs] “Webhook-based forwarding enables: - Real-time claim ingestion - Faster transaction matching - Immediate eligibility assessment for dispute h…”
   • [claimed-docs] “our recommendation engine will suggest additional evidence to add to your dispute to bolster your win rate.”
   • [claimed-docs] “Once chargebacks are ingested into Forter, our recommendation engine will suggest additional evidence to add to your dispute to bolster your…”
   • [claimed-docs] “Save time and effort by using our Evidence API endpoint to automatically send post-order evidence for chargeback disputes.”
   • [claimed-docs] “Fight fraud, increase approvals, reduce chargebacks”
   • [claimed-docs] “Automate disputes, streamline operations, improve win rates”

   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

   Forter—none0/10

   The evidence pack covers APIs, webhooks, MCP, and dispute automation but contains no mention of a reporting dashboard, board-level metrics (dispute rate, false-positive rate, approval-rate lift, review workload), or any export/reporting feature aimed at finance leads. Only a vague reference to 'better reporting on agentic traffic' exists, which does not address the specific KPIs in the story.

   • [claimed-docs] “Set orderType to AI_AGENT ... This additional data improves Forter's risk decisions and provides the merchant better reporting on agentic tr…”

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

   Forter~partialclaimed6/10

   Forter documents automated evidence workflows: chargebacks are ingested via webhook forwarding, matched to transactions, and a recommendation engine suggests additional evidence, plus an Evidence API to 'automatically send post-order evidence for chargeback disputes' without manual copy-paste of transaction data. However, the evidence is described as 'suggested' by a recommendation engine rather than fully autonomous compilation and submission, and there's no explicit mention of session data being incorporated into evidence packages. Missing for 10: explicit confirmation that session-level data is included in compiled evidence, and independent/hands-on validation that submission is fully automatic without ops review step.

   • [claimed-docs] “Webhook-based forwarding enables: - Real-time claim ingestion - Faster transaction matching - Immediate eligibility assessment for dispute h…”
   • [claimed-docs] “our recommendation engine will suggest additional evidence to add to your dispute to bolster your win rate.”
   • [claimed-docs] “Once chargebacks are ingested into Forter, our recommendation engine will suggest additional evidence to add to your dispute to bolster your…”
   • [claimed-docs] “Save time and effort by using our Evidence API endpoint to automatically send post-order evidence for chargeback disputes.”
   • [claimed-docs] “Map Stripe's PaymentIntent ID (the value that starts with pi_) to the processorTransactionId field ... This is required to map the dispute b…”

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

   Forter~partialprobed5/10

   Forter documents an official MCP server that lets an AI system 'review decisions, manage disputes, or update policies through natural language commands' and can connect to Claude Desktop for conversational workflows, which supports agentic read/manage access to fraud posture. However, there is no explicit documentation of proposing a velocity rule, updating a blocklist, or any human-in-the-loop approval gate mechanism for these programmatic changes. Missing for 10: explicit velocity-rule/blocklist management examples, documented approval-gate workflow, and independent/hands-on corroboration of MCP write actions.

   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”
   • [claimed-docs] “Connect Forter MCP to Claude Desktop app for conversational AI workflows.”
   • [probe] “official MCP server documented at https://docs.forter.com/mcp”

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

   Forter~partialprobed5/10

   Forter's MCP server explicitly lets an AI agent 'perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural language commands' via Claude Desktop, showing agent access to review/decision workflows. However, there is no explicit documentation of pulling a flagged-case queue, summarizing evidence, or producing a recommendation for human confirmation as a distinct workflow. missing for 10: explicit queue-pulling UI/API for flagged cases, evidence-summarization output, human-confirm approval step.

   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”
   • [claimed-docs] “Connect Forter MCP to Claude Desktop app for conversational AI workflows.”
   • [probe] “official MCP server documented at https://docs.forter.com/mcp”

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

   Forter~partialprobed3/10

   Forter markets 'Forter Agents' and ships an MCP server letting external AI systems (e.g., Claude Desktop) issue natural-language commands to review decisions, manage disputes, or update policies, which gestures at the AI-assistant theme. However, the evidence never describes a native, embedded console assistant with NL querying over fraud data, rule drafting, or investigation summaries — the MCP approach is an integration layer for external AI clients rather than a first-party in-console assistant. Missing for 10: concrete documentation of a built-in console chat/assistant UI, evidence of drafted-rule generation, and investigation-summary generation features.

   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”
   • [claimed-docs] “Meet your new team of Forter Agents, so you can spend more time on what matters most.”
   • [claimed-docs] “Connect Forter MCP to Claude Desktop app for conversational AI workflows.”
   • [probe] “official MCP server documented at https://docs.forter.com/mcp”

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

   Forter~partialclaimed5/10

   Forter's marketing copy explicitly claims to 'Stop ATO, block fake accounts, protect account integrity' alongside its checkout/fraud-decision APIs, indicating account-takeover and fake-account protection live in the same platform as order-level fraud scoring. However, there is no documentation of promo abuse or policy abuse detection/management, and no detail on how ATO/fake-account signals are scored or surfaced to analysts beyond a single marketing line. Missing for 10: dedicated docs/API for promo abuse and policy abuse detection, analyst-facing workflow/management details for ATO and fake-account cases beyond marketing claims.

   • [claimed-docs] “Stop ATO, block fake accounts, protect account integrity”
   • [claimed-docs] “Send order information at checkout to receive a fraud or abuse decision.”
   • [claimed-docs] “Fight fraud, increase approvals, reduce chargebacks”

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

   Forter~partialclaimed5/10

   Evidence confirms a maintained Shopify integration (quickstart-shopify.md) and Stripe dispute webhook support, indicating some pre-built commerce/PSP connectors exist. However, there is no evidence of maintained integrations for Salesforce Commerce, BigCommerce, or other major PSPs (Adyen, Braintise, PayPal, etc.), leaving the breadth of the 'commerce stack' claim largely unsubstantiated. missing for 10: documented Salesforce Commerce Cloud integration, BigCommerce integration, coverage of additional major PSPs beyond Stripe, and any partner/marketplace integration directory confirming maintenance status.

   • [claimed-docs] “You implement: Nothing - Forter handles everything”
   • [claimed-docs] “How to provide Forter access to your Stripe Dispute Webhooks.”
   • [claimed-docs] “Map Stripe's PaymentIntent ID (the value that starts with pi_) to the processorTransactionId field ... This is required to map the dispute b…”

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

   Forter~partialclaimed5/10

   Forter is payment-agnostic in principle (works off order/checkout data, not tied to a specific processor's rails), and evidence shows Stripe-specific dispute webhook integration plus a Shopify quickstart, implying multi-platform support. However there is no explicit documentation enumerating support across multiple PSPs/gateways beyond Stripe and Shopify, nor guidance for other major processors (Adyen, Braintree, PayPal, etc.). missing for 10: explicit list/documentation of supported PSPs and gateways beyond Stripe/Shopify, evidence of platform-agnostic integration guides for other processors, independent confirmation of multi-PSP deployments.

   • [claimed-docs] “How to provide Forter access to your Stripe Dispute Webhooks.”
   • [claimed-docs] “Map Stripe's PaymentIntent ID (the value that starts with pi_) to the processorTransactionId field ... This is required to map the dispute b…”
   • [claimed-docs] “You implement: Nothing - Forter handles everything”
   • [claimed-docs] “Forter has both a production and a sandbox environment for your development process.”

   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

   Forter—none0/10

   No evidence describes score explainability, reason codes, or risk-factor breakdowns accompanying Forter's fraud decisions; the evidence pack covers order submission, webhooks, disputes, and agentic order tagging but nothing about transparency into why a score was assigned.

   ⚑ 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

   Forter—none0/10

   No evidence of model-level metrics (precision/recall), shadow-mode trials, or A/B testing of models/rules before rollout; evidence covers order decisioning, webhooks, disputes, and agentic orders but nothing about model performance measurement or staged rollout tooling for finance leads.

   ⚑ flag

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

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

   Forter~partialprobed6/10

   Forter exposes core actions via API/webhooks (order decisions, order status, evidence submission, chargeback forwarding) and an MCP server that lets AI agents review decisions, manage disputes, and update policies via natural language, suggesting broad API/agent coverage of UI functions. However, there is no explicit documentation stating full feature parity between the UI dashboard and API/MCP, and some UI-only configuration (e.g., policy setup screens, analytics dashboards) isn't shown as API-accessible. Missing for 10: explicit parity statement, evidence that every UI configuration/reporting feature is also API-exposed, independent confirmation of MCP completeness.

   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”
   • [claimed-docs] “Set orderType to AI_AGENT”
   • [claimed-docs] “Save time and effort by using our Evidence API endpoint to automatically send post-order evidence for chargeback disputes.”
   • [claimed-docs] “Send order information at checkout to receive a fraud or abuse decision.”
   • [claimed-docs] “Inform of updates to the status of an order, including payment authorization, fulfillment, shipping details, and compensation granted.”
   • [claimed-docs] “Webhooks provide a way to configure Forter to send real-time notifications to your web store server or another service (ERP/OMS) whenever ce…”
   • [probe] “official MCP server documented at https://docs.forter.com/mcp”

   proof ↗⚑ flag

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

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

   Forter—none0/10

   Forter is a fraud-detection/risk B2B API platform; no evidence of any end-user data export feature or open-format data portability for merchants or consumers to 'leave' with their data. Missing for 10: any documented data export tool, open format (CSV/JSON) export capability, or account-closure data portability process.

   ⚑ 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

   Forter—none0/10

   No evidence in the pack addresses data residency, regional storage options, or geographic controls over where customer data is held; all evidence concerns fraud decisioning, disputes, webhooks, and agentic order tagging.

   ⚑ flag

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

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

   Forter—none0/10

   Forter is a fraud-detection/e-commerce risk platform; the evidence pack contains no privacy policy, data-processing agreement, or opt-out mechanism addressing whether user data is used for AI model training. No documentation of a training opt-out or data-use control was found.

   ⚑ flag

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

   Forter—none0/10

   No evidence pack items address data retention policies, deletion controls, or user-facing privacy/data-management settings; the docs focus on fraud detection, disputes, and MCP integration.

   ⚑ 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

   Forter—none0/10

   No evidence pack items address data residency options, regional data storage, or retention/deletion controls; documentation covers order APIs, webhooks, disputes, PCI scope, and MCP/agent features but nothing about where fraud data is stored or how long it is kept.

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

   Forter—none0/10

   No evidence in the pack mentions SCA, 3DS, PSD2 exemptions, or European payment authentication routing at all; Forter's docs focus on fraud decisioning, disputes, chargebacks, and agentic order tagging, none of which address SCA/3DS logic.

   ⚑ 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

   Forter—none0/10

   Evidence covers order decisioning APIs, webhooks, chargeback/dispute automation, and MCP/agentic order tagging, but there is no mention of a review queue UI showing flagged transactions with customer history, signals, or similar cases for analyst decisioning.

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

   Forter~partialclaimed4/10

   Forter's docs show data flowing back to Forter post-decision (order status updates including compensation granted, chargeback/dispute webhook ingestion, Evidence API) which implies outcome data reaches Forter's systems, but there is no explicit documentation that a risk analyst's manual review decisions or confirmed-fraud outcomes are used to retrain models or update rules. Missing for 10: explicit description of a feedback/learning loop tying analyst review outcomes to model or rule updates, and any mention of an analyst review queue at all.

   • [claimed-docs] “Inform of updates to the status of an order, including payment authorization, fulfillment, shipping details, and compensation granted.”
   • [claimed-docs] “Webhook-based forwarding enables: - Real-time claim ingestion - Faster transaction matching - Immediate eligibility assessment for dispute h…”
   • [claimed-docs] “Webhook-based forwarding enables: Real-time claim ingestion - Faster transaction matching - Immediate eligibility assessment for dispute han…”
   • [claimed-docs] “How to provide Forter access to your Stripe Dispute Webhooks.”
   • [claimed-docs] “Map Stripe's PaymentIntent ID (the value that starts with pi_) to the processorTransactionId field ... This is required to map the dispute b…”
   • [claimed-docs] “Save time and effort by using our Evidence API endpoint to automatically send post-order evidence for chargeback disputes.”

   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

   Forter—none0/10

   The evidence pack covers order decisioning, webhooks, chargeback/dispute automation, and AI-agent/MCP integrations, but contains no mention of a human team review workflow with case assignment, escalation rules, SLAs, or an approval audit trail for ops reviewers. missing for 10: case assignment/queue management, escalation rules, SLA tracking, and a decision audit trail showing reviewer approvals and rationale.

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

   Forter~partialclaimed4/10

   Forter's Order API accepts order data and metadata at checkout (forter-docs-1) and supports custom decision configuration (forter-docs-18), implying some ability to send custom signals, but there is no documented schema or capability for developers to submit their own device fingerprints, custom behavioral signals, or arbitrary metadata that directly influences scoring weights. missing for 10: explicit API fields/documentation for submitting custom device fingerprint or behavioral data, evidence that custom signals are actually weighted in scoring versus Forter's own network-derived signals, and any tuning/configuration interface for business-specific signal weighting.

   • [claimed-docs] “Send order information at checkout to receive a fraud or abuse decision.”
   • [claimed-docs] “If the Auto Invoice option is set to YES, then the payment capture amount operation is executed and order is placed”

   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

   Forter—none0/10

   The evidence pack covers order submission, webhooks, disputes, chargebacks, PCI scope, and agentic/MCP features, but none of it describes a cross-merchant network effect, shared identity/card risk signals, or network-wide fraud intelligence informing decisions. Missing for 10: any documentation or claim about network-level data sharing, identity graph across merchants, or aggregated fraud signals from other businesses.

   ⚑ 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

   Forter—none0/10

   The evidence pack covers order decisions, webhooks, disputes, PCI scope, and agentic order tagging, but contains no mention of score-range-to-action mapping, configurable thresholds, or step-up 3DS logic that ops users could tune. Forter's docs reference binary/decision-based order outcomes (fraud/abuse decision) rather than a threshold-tuning console. Missing for 10: any documentation of score bands, adjustable thresholds, or 3DS step-up configuration UI/API.

   • [claimed-docs] “Send order information at checkout to receive a fraud or abuse decision.”
   • [claimed-docs] “If the Auto Invoice option is set to YES, then the payment capture amount operation is executed and order is placed”

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

   Forter~partialclaimed6/10

   Forter's Order API (order-v3) is documented as a synchronous checkout-time call returning a fraud/abuse decision, and order-status/webhooks show authorization events are tracked separately, implying the decision precedes authorization — consistent with real-time pre-auth scoring. However, the docs describe a categorical 'decision' rather than an explicit numeric ML risk score, and there's no independent/hands-on latency or scoring-format confirmation. Missing for 10: explicit documentation of a numeric/probabilistic risk score field, and independent verification of real-time performance.

   • [claimed-docs] “Send order information at checkout to receive a fraud or abuse decision.”
   • [claimed-docs] “Inform of updates to the status of an order, including payment authorization, fulfillment, shipping details, and compensation granted.”
   • [claimed-docs] “Forter has both a production and a sandbox environment for your development process.”

   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

   Forter—none0/10

   No evidence of any rule backtesting, historical simulation, or cost/impact preview capability in the evidence pack — coverage is about order decisioning, webhooks, disputes, and MCP/agentic orders, none of which address testing rules against historical traffic 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

   Forter—none0/10

   The evidence pack contains no mention of allow/block lists (emails, cards, devices, IPs) or velocity limit configuration, either via dashboard or API — only order decisioning, webhooks, disputes, and agentic order APIs are documented. This is a fair capability to expect from a fraud-rules platform, but no evidence supports it.

   ⚑ 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

   Forter—none0/10

   The evidence pack covers order submission, webhooks, chargeback/dispute automation, and MCP/agentic order tagging, but contains no mention of a custom rules engine, rule authoring UI/API, velocity counters, list matching, or configurable allow/block/review decision logic controlled by risk analysts.

   ⚑ flag