[ { "productId": "mastercard-open-finance", "storyId": "account-numbers-for-ach", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Mastercard's docs list dedicated 'Get ACH details' and 'Validate account details' products alongside account-ownership verification and balance checks, which together match the story of retrieving account/routing data and validating funding source without micro-deposits. However, the evidence pack only shows product titles/index links rather than detailed descriptions of the actual data returned (e.g., explicit account/routing number fields, tokenization format, or confirmation that validation replaces micro-deposits). Missing for 10: detailed API schema/response showing routing+account numbers or tokens, explicit statement that validation eliminates micro-deposit verification, and independent developer confirmation of real-world usage.", "evidenceIds": [ "mastercard-open-finance-docs-6", "mastercard-open-finance-docs-14", "mastercard-open-finance-docs-3", "mastercard-open-finance-docs-16", "mastercard-open-finance-docs-1", "mastercard-open-finance-docs-15" ] }, { "productId": "mastercard-open-finance", "storyId": "account-ownership-data", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Docs explicitly describe an Account Owner Verification service retrieving name, address, email and phone from the connected FI account, and a match-account-ownership endpoint that compares provided customer data against the bank's on-file details with confidence scores — directly matching the ops matching workflow. Missing for 10: independent/hands-on corroboration beyond vendor docs and more detail on data completeness/edge cases across FIs.", "evidenceIds": [ "mastercard-open-finance-docs-1", "mastercard-open-finance-docs-15", "mastercard-open-finance-docs-28" ] }, { "productId": "mastercard-open-finance", "storyId": "agent-links-and-reads", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Mastercard's Open Finance APIs clearly support the core actions an agent would need — creating link sessions via Connect, retrieving balances (Account Balance service), pulling transactions (Transaction Data), and managing connections/webhooks — all gated by PartnerID/secret/appKey OAuth tokens that function as scoped credentials. There is also a documented official MCP surface (agent-toolkit/mcp-overview) explicitly referencing Open Finance use cases like verifying ownership and checking balances, but its documented function is 'dynamic code generation' for developers rather than confirmed direct agentic execution of live account operations. missing for 10: evidence the MCP server itself executes link-session/balance/transaction calls (vs. just generating code samples), and independent/hands-on confirmation of an agent operating end-to-end with scoped MCP credentials.", "evidenceIds": [ "mastercard-open-finance-docs-2", "mastercard-open-finance-docs-7", "mastercard-open-finance-docs-9", "mastercard-open-finance-docs-10", "mastercard-open-finance-docs-23", "mastercard-open-finance-docs-27", "mastercard-open-finance-docs-12", "mastercard-open-finance-docs-28", "mastercard-open-finance-probe-2" ] }, { "productId": "mastercard-open-finance", "storyId": "agent-ready-financial-data", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Mastercard Open Finance provides structured JSON APIs with documented schemas for account, transaction, balance, and enrichment data (transaction categorization, recurring transactions, spending insights), an OpenAPI spec with generated client libraries, and even an official MCP/agent-toolkit for AI consumption. However, evidence doesn't show explicit example JSON payloads or schema definitions in the pack, nor confirmation that enrichment fields are agent-optimized (e.g., no heuristic parsing needed) versus requiring developer interpretation. missing for 10: concrete JSON schema examples/response samples, explicit confirmation that enrichment output avoids downstream heuristic parsing, independent developer corroboration of agent-readiness.", "evidenceIds": [ "mastercard-open-finance-docs-7", "mastercard-open-finance-docs-8", "mastercard-open-finance-docs-22", "mastercard-open-finance-gh-1", "mastercard-open-finance-probe-2", "mastercard-open-finance-docs-12" ] }, { "productId": "mastercard-open-finance", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "A probe confirms llms.txt is live at developer.mastercard.com/llms.txt (HTTP 200), and Mastercard also documents an agent-oriented MCP toolkit with dynamic code generation for agents. Missing for 10: no independent third-party confirmation that agents actually consume this llms.txt effectively, and no explicit doc listing Open Finance-specific sections within it.", "evidenceIds": [ "mastercard-open-finance-probe-1", "mastercard-open-finance-probe-2", "mastercard-open-finance-docs-12", "mastercard-open-finance-docs-28" ] }, { "productId": "mastercard-open-finance", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence shows Mastercard Open Finance exposes categorized financial data (transaction types, recurring transactions, spending, loan payments) via APIs, and a separate MCP agent toolkit for developers to generate code, but there is no evidence of AI-generated insights or suggestions surfaced to an end-user inside the product itself.", "evidenceIds": [ "mastercard-open-finance-docs-22", "mastercard-open-finance-docs-12", "mastercard-open-finance-docs-28" ] }, { "productId": "mastercard-open-finance", "storyId": "agentic-autonomous-automation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence shows webhooks for event notifications and an MCP toolkit for code generation, but nothing about scheduling or configuring autonomous background automations/workflows that run without user intervention. Missing for 10: any documentation of scheduled/triggered automation setup, autonomous workflow orchestration, or agentic task execution running independently in the background.", "evidenceIds": [ "mastercard-open-finance-docs-9", "mastercard-open-finance-docs-26", "mastercard-open-finance-docs-12" ] }, { "productId": "mastercard-open-finance", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Mastercard Open Finance is a developer API platform for financial data/verification, not a consumer or workflow product with a built-in AI assistant persona to delegate tasks to; the MCP toolkit evidence is about exposing APIs to external agents/tools, not a native in-product assistant.", "evidenceIds": [] }, { "productId": "mastercard-open-finance", "storyId": "agentic-headless", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "As a pure REST API platform, Open Finance is inherently headless — it uses PartnerID/secret token auth (docs-10, docs-23), an OpenAPI spec with generated client libraries (mastercard-open-finance-gh-1), and a non-billable 'Test Drive' sandbox with scripted test personas (docs-24, docs-25) suitable for automated/CI testing. Missing for 10: no explicit CI/CD pipeline examples, no documented headless SDK/CLI runner, and no first-party guidance on automating the flow end-to-end in a build pipeline.", "evidenceIds": [ "mastercard-open-finance-docs-10", "mastercard-open-finance-docs-23", "mastercard-open-finance-docs-24", "mastercard-open-finance-docs-25", "mastercard-open-finance-gh-1" ] }, { "productId": "mastercard-open-finance", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Mastercard Open Finance is a financial data/API platform, not an agent or assistant host that could itself consume external MCP servers as tools; the evidence only shows Mastercard publishing its own MCP server (agent-toolkit) for others to call into Open Finance APIs, which is the opposite role from 'plugging MCP servers into this product'.", "evidenceIds": [ "mastercard-open-finance-probe-2", "mastercard-open-finance-docs-12" ] }, { "productId": "mastercard-open-finance", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Mastercard documents an official Agent Toolkit MCP server (mcp-overview) that includes dynamic code generation and an example use case directly referencing Open Finance verification and balance checks, confirming AI agents can connect via this official MCP server to access Open Finance APIs. Missing for 10: independent/hands-on corroboration of the MCP server working with Open Finance endpoints, and detailed API-to-tool mapping documentation.", "evidenceIds": [ "mastercard-open-finance-docs-12", "mastercard-open-finance-docs-28", "mastercard-open-finance-probe-2" ] }, { "productId": "mastercard-open-finance", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Mastercard offers an official Agent Toolkit/MCP server with dynamic code generation and natural-language-friendly API access (e.g., 'I need to integrate Open Finance to verify account ownership and check balances'), which supports operating the platform via AI-native/natural-language workflows. However, this is a developer-integration tool rather than end-user natural-language command execution over the product's core financial functions. missing for 10: evidence of an end-user-facing natural-language interface, broader coverage of MCP tool capabilities beyond code generation, and independent/hands-on validation of the MCP server's reliability.", "evidenceIds": [ "mastercard-open-finance-docs-12", "mastercard-open-finance-docs-28", "mastercard-open-finance-probe-2" ] }, { "productId": "mastercard-open-finance", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence of an official CLI tool; evidence covers APIs, webhooks, MCP server, and SDK/test client generation but nothing describing a command-line interface for AI-native workflows. Missing for 10: any mention of an official CLI, its installation, or its use in agentic/AI workflows.", "evidenceIds": [] }, { "productId": "mastercard-open-finance", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Mastercard Open Finance exposes a well-documented public REST API (accounts, balances, transactions, ownership verification, webhooks) with OpenAPI spec, token-based auth, sandbox/test-drive access, and even an llms.txt plus official MCP toolkit for agent-driven access. missing for 10: independent third-party developer confirmation of API usability/reliability beyond vendor docs.", "evidenceIds": [ "mastercard-open-finance-docs-10", "mastercard-open-finance-docs-23", "mastercard-open-finance-docs-24", "mastercard-open-finance-gh-1", "mastercard-open-finance-probe-1", "mastercard-open-finance-probe-2", "mastercard-open-finance-docs-12" ] }, { "productId": "mastercard-open-finance", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows PartnerID/secret/appKey token generation for API access (docs-10, docs-23) but no mention of scoped, least-privilege, or per-agent credential issuance — auth appears to be a single partner-level secret rather than granular scoped tokens for agents. Missing for 10: any documentation of scoped/limited-permission API keys, per-agent credential issuance, or role-based access control for agent use.", "evidenceIds": [ "mastercard-open-finance-docs-10", "mastercard-open-finance-docs-23" ] }, { "productId": "mastercard-open-finance", "storyId": "agentic-sdks", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "The only relevant evidence is a GitHub repo showing an OpenAPI-generated client library used for testing, not a fully documented, officially published SDK across languages. Missing for 10: dedicated official SDK repositories/packages (e.g., npm, PyPI, Maven), SDK version support docs, and independent developer confirmation of SDK usability.", "evidenceIds": [ "mastercard-open-finance-gh-1" ] }, { "productId": "mastercard-open-finance", "storyId": "agentic-webhooks", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Docs explicitly describe webhook support for real-time event notifications (avoiding polling) and a subscription-based OBWMS API letting developers subscribe to specific events. Missing for 10: concrete webhook payload/setup examples, independent/hands-on confirmation, and detail on programmatic subscription management via API/SDK.", "evidenceIds": [ "mastercard-open-finance-docs-9", "mastercard-open-finance-docs-26" ] }, { "productId": "mastercard-open-finance", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence shows extensive product/API documentation, an OpenAPI spec-driven test client, and a 'Test Drive' sandbox plan, but nothing describes an interactive API reference (e.g., Swagger/Postman-style try-it console) with runnable code examples in the docs portal itself.", "evidenceIds": [ "mastercard-open-finance-docs-24", "mastercard-open-finance-gh-1", "mastercard-open-finance-docs-11" ] }, { "productId": "mastercard-open-finance", "storyId": "api-machine-spec", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "A GitHub repo (open-banking-us-openapi) explicitly generates an API client library from a published OpenAPI specification, confirming a machine-readable spec is downloadable/usable, and Mastercard also exposes an llms.txt and MCP toolkit for machine-consumable API access. Missing for 10: no direct link/documentation showing a single canonical spec file download page or version history, and no independent third-party confirmation of spec completeness.", "evidenceIds": [ "mastercard-open-finance-gh-1", "mastercard-open-finance-probe-1", "mastercard-open-finance-probe-2", "mastercard-open-finance-docs-12" ] }, { "productId": "mastercard-open-finance", "storyId": "api-sandbox", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Mastercard provides a dedicated non-billable 'Test Drive' plan with unlimited access to all Open Finance API endpoints plus documented testing personas representing example users, explicitly for sandbox-style integration testing without production data, and a GitHub sample project generating a client from the API spec for testing. missing for 10: independent/hands-on confirmation of full production-data isolation and details on sandbox data realism or limitations.", "evidenceIds": [ "mastercard-open-finance-docs-24", "mastercard-open-finance-docs-11", "mastercard-open-finance-docs-25", "mastercard-open-finance-gh-1" ] }, { "productId": "mastercard-open-finance", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence pack items mention API versioning scheme or a documented deprecation policy; docs reference endpoints, onboarding, testing, and webhooks but not version lifecycle management.", "evidenceIds": [] }, { "productId": "mastercard-open-finance", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence describes batch/bulk endpoints or multi-item operations (e.g., submitting many account IDs or requests in a single call); documented APIs appear per-account/per-transaction oriented, and webhooks only address real-time single-event notifications, not bulk processing.", "evidenceIds": [] }, { "productId": "mastercard-open-finance", "storyId": "automation-rules-engine", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Webhooks provide event notifications but there is no evidence of user-definable rules or automated triggered actions based on those events; missing for 10: rule-definition engine, conditional logic, automated action execution tied to events.", "evidenceIds": [ "mastercard-open-finance-docs-9", "mastercard-open-finance-docs-26" ] }, { "productId": "mastercard-open-finance", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "mastercard-open-finance", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Mastercard Open Finance is a financial data/API platform, not an automation/workflow tool with user-created 'automations' to version or roll back; no evidence pack item addresses automation versioning, review, or rollback capabilities.", "evidenceIds": [] }, { "productId": "mastercard-open-finance", "storyId": "connection-repair-relink", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers account data products, webhooks, onboarding, and testing personas, but nothing documents connection health statuses (expired/revoked), a re-authentication or 'update mode' flow, or any repair-without-restart mechanism for broken links. Missing for 10: documented connection status states (e.g., expired/revoked/error), an update/re-auth flow API or UI, and any evidence of preserving existing account links during re-auth.", "evidenceIds": [ "mastercard-open-finance-docs-9", "mastercard-open-finance-docs-27" ] }, { "productId": "mastercard-open-finance", "storyId": "data-deletion-api", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence pack item documents a delete/disconnect endpoint, user data purge process, or data retention/deletion policy for connections or held account data; coverage is limited to data retrieval, verification, and onboarding APIs.", "evidenceIds": [] }, { "productId": "mastercard-open-finance", "storyId": "hosted-link-flow", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "The evidence only briefly references a 'Connect' mechanism for linking accounts ('link them to at least one account via Connect') but provides no detail on a hosted, drop-in widget, server-side session creation, or token retrieval flow that a developer would use to avoid building institution UI. Missing for 10: documentation of Connect widget UI, session token generation API, and end-to-end token exchange after linking.", "evidenceIds": [ "mastercard-open-finance-docs-27" ] }, { "productId": "mastercard-open-finance", "storyId": "income-cashflow-insights", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm transaction data services with insights into recurring transactions, transaction types, consumer spending, and loan payments, plus credit-decisioning report APIs — directly supporting cash-flow/recurring-stream signals. However, there's no explicit mention of payroll detection or a dedicated income-verification product built on this data. missing for 10: explicit payroll/income detection feature, named income-verification product, independent validation of accuracy.", "evidenceIds": [ "mastercard-open-finance-docs-7", "mastercard-open-finance-docs-22", "mastercard-open-finance-docs-13", "mastercard-open-finance-docs-8" ] }, { "productId": "mastercard-open-finance", "storyId": "institution-coverage-breadth", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers API capabilities (verification, balances, transaction data, webhooks, onboarding) but contains no published institution-coverage numbers, geographic breakdowns, or bank-reach statistics that a founder could check against their users' banks.", "evidenceIds": [] }, { "productId": "mastercard-open-finance", "storyId": "institution-status-visibility", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers API products (balance, ownership, transaction data, webhooks, onboarding) but contains no mention of institution status dashboards, outage/degradation signals, or error codes distinguishing bank-side vs integration-side issues.", "evidenceIds": [] }, { "productId": "mastercard-open-finance", "storyId": "multi-product-sessions", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence lists multiple separate data products (account ownership, balances, transactions) and mentions a generic 'Connect' linking step, but nothing describes a single link/Connect session simultaneously provisioning auth, balances, transactions, and identity without repeated connection flows per product.", "evidenceIds": [] }, { "productId": "mastercard-open-finance", "storyId": "oauth-bank-connections", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers Connect/account-linking, webhooks, and API products but never mentions OAuth-based bank authentication coverage, connectivity method mix, or a documented plan/status for retiring screen-scraped credential flows. Without explicit documentation of OAuth coverage vs. legacy scraping, this specific developer-facing transparency claim is unevidenced.", "evidenceIds": [ "mastercard-open-finance-docs-27", "mastercard-open-finance-docs-9" ] }, { "productId": "mastercard-open-finance", "storyId": "on-demand-refresh", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Evidence shows account balance can be 'real-time or cached' and webhooks provide event notifications, but there is no documented API endpoint or explicit refresh semantics (e.g., a force-refresh trigger, freshness guarantees, or polling-for-refresh-status flow) for triggering an on-demand data refresh. Missing for 10: an explicit refresh/force-update endpoint, documented refresh semantics (sync vs async, staleness thresholds), and any independent confirmation of on-demand refresh behavior.", "evidenceIds": [ "mastercard-open-finance-docs-2", "mastercard-open-finance-docs-9", "mastercard-open-finance-docs-7" ] }, { "productId": "mastercard-open-finance", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "As an API-first data platform, virtually all core functions (account verification, balances, transactions, ACH details, webhooks/event management, token generation) are exposed directly via documented REST APIs rather than gated behind a UI, and even administrative functions like webhook subscriptions and token creation are API-driven (docs-9, docs-23, docs-26). However, the 'Connect' account-linking flow is a hosted widget/UI experience (docs-27) whose full API-equivalence isn't evidenced, and there's no explicit confirmation that all developer-portal/dashboard actions (billing, partner management) have API parity. Missing for 10: explicit API equivalents for the Connect linking UI, and confirmation that portal/dashboard admin tasks are fully scriptable.", "evidenceIds": [ "mastercard-open-finance-docs-9", "mastercard-open-finance-docs-23", "mastercard-open-finance-docs-26", "mastercard-open-finance-docs-27", "mastercard-open-finance-docs-7", "mastercard-open-finance-docs-1" ] }, { "productId": "mastercard-open-finance", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "This is a B2B financial data API platform, not a consumer product with user-owned data to export; the evidence shows no data export/portability feature for end users to take their data out in open formats and leave. No mention of any account/data export or account deletion/portability capability anywhere in the docs.", "evidenceIds": [] }, { "productId": "mastercard-open-finance", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "mastercard-open-finance", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Mastercard Open Finance is a hosted financial-data API/SaaS platform; self-hosting the core product is not a coherent capability for this kind of service, so the axis does not apply.", "evidenceIds": [] }, { "productId": "mastercard-open-finance", "storyId": "pay-by-bank-initiation", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack describes the 'Pay' product family only as verification (account ownership, balance, ACH details, match), fraud/success prediction, and switching services — none of the docs describe an actual payment-initiation endpoint that moves funds from a connected account, nor any stated live geographies for such a capability. Without a documented API to actually initiate a bank payment, this axis is unmet.", "evidenceIds": [ "mastercard-open-finance-docs-1", "mastercard-open-finance-docs-2", "mastercard-open-finance-docs-15", "mastercard-open-finance-docs-17", "mastercard-open-finance-docs-18", "mastercard-open-finance-docs-6" ] }, { "productId": "mastercard-open-finance", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence anywhere in the pack discusses data residency, regional storage options, or geographic controls for where customer data is stored/processed. This is an applicable axis for a financial data platform handling sensitive PII, but nothing addresses it.", "evidenceIds": [] }, { "productId": "mastercard-open-finance", "storyId": "privacy-no-training", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence anywhere in the pack addresses AI-training data opt-out or data usage controls; the documentation covers financial data APIs and MCP tooling but nothing about preventing use of user data for AI model training.", "evidenceIds": [] }, { "productId": "mastercard-open-finance", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers API products (account data, verification, transactions, webhooks, onboarding) but contains no mention of data retention policies, deletion controls, or user-facing privacy/data-lifecycle management tools. Missing for 10: any documentation of data retention periods, deletion/erasure APIs, or consumer-facing controls over stored financial data.", "evidenceIds": [] }, { "productId": "mastercard-open-finance", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence pack items mention telemetry, usage tracking, analytics collection, or any opt-out mechanism for AI-native or any users; this is an applicable axis for a developer platform but simply unevidenced.", "evidenceIds": [] }, { "productId": "mastercard-open-finance", "storyId": "processor-integrations", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Mastercard Open Finance provides account ownership verification, balance, ACH details, and account aggregation APIs accessible via token-based auth (PartnerID/secret) that developers can integrate into payment processing flows, and it supports Connect for account linking. However, the evidence does not document specific third-party payment processor/platform integration partnerships or an explicit token-exchange handoff mechanism to hand verified credentials to external processors — the story implies pre-built plug-and-play integrations rather than raw APIs a developer must wire up themselves. missing for 10: named third-party processor/platform integration partners, explicit token-exchange-to-processor handoff documentation, independent confirmation of such integrations working in production.", "evidenceIds": [ "mastercard-open-finance-docs-1", "mastercard-open-finance-docs-2", "mastercard-open-finance-docs-6", "mastercard-open-finance-docs-10", "mastercard-open-finance-docs-23", "mastercard-open-finance-docs-27" ] }, { "productId": "mastercard-open-finance", "storyId": "quickstart-first-connection", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs show a self-serve-ish onboarding path (PartnerID/secret/appKey token generation, a non-billable unlimited 'Test Drive' plan, and test personas for sandbox account linking) and a GitHub OpenAPI spec that can generate a client library, but there's no explicit runnable quickstart tutorial or multi-language official client libraries beyond the one generated test project. Missing for 10: an explicit step-by-step quickstart guide, published official SDKs in multiple languages, and clear evidence of instant self-serve API key issuance without a sales/partner approval step.", "evidenceIds": [ "mastercard-open-finance-docs-10", "mastercard-open-finance-docs-23", "mastercard-open-finance-docs-24", "mastercard-open-finance-docs-25", "mastercard-open-finance-gh-1" ] }, { "productId": "mastercard-open-finance", "storyId": "realtime-balance-checks", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Docs explicitly describe an Account Balance service returning real-time or cached balance data from the connected FI, matching the NSF/risk-check use case, and MCP overview references verifying ownership and checking balances as a supported integration flow. Missing for 10: explicit request/response schema examples, independent/hands-on confirmation of real-time latency, and no direct mention of pre-payment NSF workflow tying balance check to payment initiation.", "evidenceIds": [ "mastercard-open-finance-docs-2", "mastercard-open-finance-docs-28" ] }, { "productId": "mastercard-open-finance", "storyId": "recurring-variable-payments", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers account data (balances, ownership, transactions), ACH details, and 'switch deposits and bill payments' but nothing documents variable recurring payments, standing consents, or a recurring debit/payment-initiation flow — this product's Pay APIs appear focused on verification (account owner, balance, ACH details) rather than initiating recurring debits.", "evidenceIds": [] }, { "productId": "mastercard-open-finance", "storyId": "sandbox-test-institutions", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm a dedicated Test Drive sandbox with unlimited access to all endpoints, testing personas representing different user scenarios, and a GitHub sample project generating a real API client for end-to-end testing — covering linking, data retrieval, and onboarding tokens. However, there is no explicit documentation of error-state simulation or a catalog of documented test credentials/institutions with specific failure scenarios. Missing for 10: explicit documented test credentials list, coverage of error/failure state simulation, and independent/hands-on confirmation of the sandbox experience.", "evidenceIds": [ "mastercard-open-finance-docs-11", "mastercard-open-finance-docs-24", "mastercard-open-finance-docs-25", "mastercard-open-finance-gh-1", "mastercard-open-finance-docs-27" ] }, { "productId": "mastercard-open-finance", "storyId": "scoped-data-access", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "The docs show a product-based API structure (separate endpoints for account ownership, balance, transactions, ACH, etc.), which implicitly allows requesting only specific data products rather than a single blob, but there is no explicit documentation of scoped consent tokens, granular permission grants, or data-minimization controls presented to developers. missing for 10: explicit consent-scoping API/parameters, documentation of minimal-data-grant mechanisms, evidence of per-scope authorization tokens, and any independent confirmation of data-minimization enforcement.", "evidenceIds": [ "mastercard-open-finance-docs-1", "mastercard-open-finance-docs-2", "mastercard-open-finance-docs-7", "mastercard-open-finance-docs-8", "mastercard-open-finance-docs-19" ] }, { "productId": "mastercard-open-finance", "storyId": "transaction-enrichment", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Docs confirm Transaction Data Services return categorized insights (transaction types, recurring transactions, consumer spending, loan payments), which implies some enrichment/categorization layer, but nothing explicitly documents merchant-name cleansing or logo attachment as a first-class capability. Missing for 10: explicit documentation of merchant name normalization/cleanup and logo enrichment fields in the transaction schema.", "evidenceIds": [ "mastercard-open-finance-docs-7", "mastercard-open-finance-docs-8", "mastercard-open-finance-docs-22" ] }, { "productId": "mastercard-open-finance", "storyId": "transactions-history-api", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Evidence confirms a dedicated Transaction Data Services API that returns account/transaction details and varies by account type, plus a webhook/notification system explicitly framed as eliminating constant polling, which implies a change-based sync pattern. However, no evidence documents pagination mechanics or a specific stated history depth (e.g., days/months of transactions) for the transaction endpoint. missing for 10: explicit pagination documentation, stated transaction history depth/lookback window, explicit delta/cursor sync pattern for transactions specifically (webhooks reference is generic, not transaction-specific).", "evidenceIds": [ "mastercard-open-finance-docs-7", "mastercard-open-finance-docs-8", "mastercard-open-finance-docs-9", "mastercard-open-finance-docs-19", "mastercard-open-finance-docs-22", "mastercard-open-finance-docs-26" ] }, { "productId": "mastercard-open-finance", "storyId": "user-consent-management", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence pack covers data retrieval, verification, transaction data, webhooks, onboarding tokens, and testing personas, but nowhere documents an end-user-facing consent management portal, dashboard, or revocation mechanism for shared bank-data access. No mention of a consent surface for users to view or revoke connected apps' access.", "evidenceIds": [] }, { "productId": "mastercard-open-finance", "storyId": "webhook-data-events", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm webhooks exist for real-time event notifications instead of polling, and OBWMS lets you subscribe to specific events; transaction/notification-type docs exist too. However, there's no evidence of webhook payload signing/verification, and no explicit documentation enumerating events like balance updates or connection-state changes with delivery guarantees. Missing for 10: signature verification mechanism, explicit event-type catalog (transactions/balances/connection state), delivery retry/reliability details.", "evidenceIds": [ "mastercard-open-finance-docs-9", "mastercard-open-finance-docs-26", "mastercard-open-finance-docs-20" ] }, { "productId": "mx", "storyId": "account-numbers-for-ach", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "MX's Instant Account Verification explicitly retrieves account and routing numbers for demand deposit accounts without micro-deposits, and Tokenized Account Numbers (TANs) provide a secure tokenized alternative for ACH money movement, both documented as distinct from the separate microdeposits verification method. missing for 10: independent/hands-on corroboration beyond first-party docs.", "evidenceIds": [ "mx-docs-1", "mx-docs-15", "mx-docs-24", "mx-docs-3" ] }, { "productId": "mx", "storyId": "account-ownership-data", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "MX's Account Owner Identification product explicitly retrieves name and address data tied to a financial account, directly enabling ops to match account holder identity against a customer record; this is well documented with first-party docs. Missing for 10: independent/hands-on corroboration beyond MX's own docs, and no explicit mention of retrieving full contact data (phone/email) alongside name/address.", "evidenceIds": [ "mx-docs-2", "mx-docs-16" ] }, { "productId": "mx", "storyId": "agent-links-and-reads", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "MX exposes a full Platform API (with OpenAPI spec) covering balances, transactions, account aggregation, connect sessions/members, and webhooks, and there is a documented MCP surface at docs.mx.com/mcp confirming an MCP entry point exists. However, the evidence pack lacks detail on MCP tool scoping, credential/permission scoping for agent use, or hands-on confirmation of agent-driven session creation and connection management via MCP. missing for 10: documented MCP tool list/schema, evidence of scoped credentials for agent access, independent/hands-on validation of the MCP surface in agentic workflows.", "evidenceIds": [ "mx-probe-3", "mx-gh-1", "mx-docs-4", "mx-docs-5", "mx-docs-21", "mx-docs-22" ] }, { "productId": "mx", "storyId": "agent-ready-financial-data", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "MX publishes a full OpenAPI specification (mx-gh-1, mx-docs-12/26) covering structured request/response payloads across accounts, transactions, balances, identity, and verification endpoints, plus webhooks for event-driven consumption (mx-docs-7/22) and even an official MCP server for agent access (mx-probe-3), directly supporting machine-consumable, schema-documented data for automated workflows. Missing for 10: concrete sample JSON response bodies in the evidence pack and independent third-party corroboration that the schemas are agent-friendly without extra parsing.", "evidenceIds": [ "mx-gh-1", "mx-docs-12", "mx-docs-26", "mx-docs-7", "mx-probe-3", "mx-probe-1" ] }, { "productId": "mx", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "MX hosts a working llms.txt at docs.mx.com/llms.txt (confirmed HTTP 200 with structured doc links) and also documents an official MCP server, both explicitly agent-oriented entry points into their docs. Missing for 10: independent third-party confirmation of an AI agent successfully consuming these resources end-to-end.", "evidenceIds": [ "mx-probe-1", "mx-probe-3" ] }, { "productId": "mx", "storyId": "agentic-ai-insights", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "MX's marketing pages describe personalized financial guidance and a conversational 'ask about your money' experience generated from each consumer's data (mx-docs-14, mx-docs-27), which matches the AI-insights story, and mx-docs-13 references 'data-driven intelligence.' However, these are thin, high-level marketing snippets rather than detailed product docs, and there is no independent/hands-on corroboration or technical documentation of the underlying AI model or insight-generation pipeline. Missing for 10: dedicated technical documentation of the AI/insights feature, concrete examples of generated insights, and independent verification of the claim.", "evidenceIds": [ "mx-docs-13", "mx-docs-14", "mx-docs-27", "mx-docs-28" ] }, { "productId": "mx", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "MX documents autonomous background behavior — automatic re-aggregation of accounts roughly every 24 hours and webhook callbacks for events — which could underpin background automations, and an MCP endpoint is referenced. However there's no evidence of a user-facing automation/workflow builder or agent-orchestration framework for setting up custom autonomous tasks. Missing for 10: explicit automation/workflow configuration tooling, evidence of AI-agent-driven autonomous task execution beyond scheduled sync, and independent confirmation of the MCP server's automation capabilities.", "evidenceIds": [ "mx-docs-25", "mx-docs-7", "mx-docs-22", "mx-probe-3" ] }, { "productId": "mx", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence shows MX enabling data connectivity and hints at conversational/personalized finance experiences (mx-docs-27, mx-docs-13/14) that MX's customers could build for their end-users, but there is no evidence of a built-in AI assistant inside the MX product itself that an AI-native user could delegate tasks to.", "evidenceIds": [] }, { "productId": "mx", "storyId": "agentic-headless", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "MX is an API-first platform with a documented REST/OpenAPI spec (mx-gh-1, mx-docs-12/26) and webhooks (mx-docs-7/22) that could be driven headlessly from CI, but there is no explicit evidence of a CLI, headless SDK mode, or documented CI/automation workflow — the Connect Widget appears UI-embedded (mx-docs-9, mx-docs-21) which cuts against pure headless use. missing for 10: explicit CI/headless usage docs, a CLI or automation-focused SDK, confirmation that Connect flows can run without embedded UI.", "evidenceIds": [ "mx-gh-1", "mx-docs-12", "mx-docs-26", "mx-docs-7", "mx-docs-9", "mx-docs-21" ] }, { "productId": "mx", "storyId": "agentic-mcp-client", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows MX publishes its own MCP server (docs.mx.com/mcp) so external agents can call MX's tools, but this is the opposite role from the story, which asks whether MX itself can consume/plug in external MCP servers and use their tools. There is no documentation of MX acting as an MCP client or any mechanism for feeding third-party MCP tool servers into MX's own workflows or its conversational AI feature.", "evidenceIds": [ "mx-probe-3", "mx-docs-27" ] }, { "productId": "mx", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "MX documents an official MCP server at docs.mx.com/mcp, confirmed via probe, indicating a first-party MCP integration point. Missing for 10: detailed setup/config docs excerpt, independent/hands-on confirmation of the MCP server working, and specifics on tool coverage exposed via MCP.", "evidenceIds": [ "mx-probe-3" ] }, { "productId": "mx", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "MX documents an official MCP server (mx-probe-3) that would let AI agents issue natural-language commands against the platform, and marketing copy (mx-docs-27) describes enabling plain-language financial queries. However, there is no detailed documentation of the NL command set, limits, or hands-on confirmation of how well it works. Missing for 10: detailed MCP tool/command documentation, independent verification of NL command execution, and coverage of edge cases/limitations.", "evidenceIds": [ "mx-probe-3", "mx-docs-27" ] }, { "productId": "mx", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "MX is a financial data API/SDK platform; no evidence of an official CLI tool for developers or AI-native workflows appears in the evidence pack — only API specs, webhooks, and a widget/UI. Evidence exists of an MCP server and OpenAPI spec, but no CLI is documented.", "evidenceIds": [] }, { "productId": "mx", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "MX exposes a documented Platform API with OpenAPI spec (available via GitHub and Postman import), REST endpoints across account verification, aggregation, statements, and webhooks, plus llms.txt and an MCP endpoint enabling AI-native access. Missing for 10: the official openapi.json isn't directly hosted at expected docs.mx.com paths (probe 404s), and there's no independent third-party corroboration of API robustness beyond MX's own docs.", "evidenceIds": [ "mx-gh-1", "mx-docs-12", "mx-docs-26", "mx-probe-1", "mx-probe-3", "mx-docs-21", "mx-docs-7" ] }, { "productId": "mx", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of scoped/least-privilege API credential issuance for agents—docs cover data connectivity, webhooks, OpenAPI spec, and even an MCP server reference, but nothing about issuing restricted-scope API keys/tokens for AI agent use.", "evidenceIds": [] }, { "productId": "mx", "storyId": "agentic-sdks", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "MX publishes an official OpenAPI specification (mx-gh-1) and supports importing it into Postman for API exploration (mx-docs-12/26), which enables building typed/generated clients, but there is no evidence of dedicated first-party SDK libraries (e.g., Python, JS, Java) or SDK-specific documentation/examples. missing for 10: named official SDK packages/libraries, language-specific SDK docs, and independent confirmation of SDK usage.", "evidenceIds": [ "mx-gh-1", "mx-docs-12", "mx-docs-26" ] }, { "productId": "mx", "storyId": "agentic-webhooks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "MX documents a webhooks system that sends HTTPS POST callbacks so developers can subscribe to specific events, clearly supporting webhook-based event subscription. Missing for 10: an exhaustive list of supported event types and independent/hands-on confirmation beyond first-party docs.", "evidenceIds": [ "mx-docs-7", "mx-docs-22" ] }, { "productId": "mx", "storyId": "api-interactive-docs", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "MX publishes an OpenAPI spec (mx-gh-1) that users can import into Postman to explore requests/responses (mx-docs-12, mx-docs-26), and provides a sandbox test-platform with test institutions (mx-docs-8). However, there is no evidence of an embedded, in-docs interactive API reference with directly runnable examples (e.g., a Swagger/Redoc-style try-it-now console) — probes for a hosted openapi.json on the docs site 404 (mx-probe-2), meaning users must leave the docs and use an external tool like Postman to run calls. Missing for 10: an in-browser interactive explorer with click-to-run examples, and confirmation the OpenAPI spec is directly hosted/interactive on docs.mx.com rather than requiring external import.", "evidenceIds": [ "mx-docs-12", "mx-docs-26", "mx-gh-1", "mx-docs-8", "mx-probe-2" ] }, { "productId": "mx", "storyId": "api-machine-spec", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "MX explicitly documents downloading its OpenAPI Specification for import into Postman, and a dedicated GitHub repo (mxenabled/openapi) hosts the machine-readable spec. Missing for 10: no evidence of a standard hosted openapi.json endpoint (probe found 404s at common paths), so discovery relies on docs/GitHub rather than a canonical URL.", "evidenceIds": [ "mx-docs-12", "mx-docs-26", "mx-gh-1", "mx-probe-2" ] }, { "productId": "mx", "storyId": "api-sandbox", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "MX explicitly documents a test platform with four test institutions and OpenAPI spec/Postman import for exercising the API without touching real production financial data, plus dedicated guidance for testing the Connect Widget/OAuth flows. missing for 10: no explicit statement distinguishing a separate 'sandbox' credential set or environment isolation guarantee, and no independent/hands-on confirmation that test data never touches production systems.", "evidenceIds": [ "mx-docs-8", "mx-docs-12", "mx-docs-23", "mx-docs-26" ] }, { "productId": "mx", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence confirms MX publishes an OpenAPI spec (mx-gh-1, mx-docs-12/26) but nowhere documents API versioning conventions or a formal deprecation policy for breaking changes. Missing for 10: documented version numbering scheme, deprecation timeline/notice policy, changelog of breaking changes.", "evidenceIds": [ "mx-gh-1", "mx-docs-12", "mx-docs-26" ] }, { "productId": "mx", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence describes per-user/per-account connectivity, aggregation, and identity verification features, but nothing documents bulk or batch operations across many items/accounts/users at once. Missing for 10: any batch API endpoints, bulk data export/import operations, or documentation of multi-item processing at scale.", "evidenceIds": [] }, { "productId": "mx", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "MX provides webhooks that let subscribers receive event notifications (e.g., aggregation completion) which developers can use to trigger their own downstream actions, but there is no evidence of a native rules/automation engine where users define conditional trigger-action logic within MX itself. missing for 10: a documented rules/automation builder or conditional trigger-action configuration UI, evidence of built-in actions (not just external webhook consumption).", "evidenceIds": [ "mx-docs-7", "mx-docs-22", "mx-docs-25" ] }, { "productId": "mx", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "MX's aggregation happens automatically on a fixed ~24-hour cycle (mx-docs-25) and webhooks push events, but there is no evidence of user-defined recurring job/workflow scheduling, cron-like configuration, or workflow orchestration for AI-native users. missing for 10: user-configurable schedule/frequency controls, workflow/orchestration engine, any AI-native automation scheduling feature.", "evidenceIds": [ "mx-docs-25", "mx-docs-7" ] }, { "productId": "mx", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "MX is a financial data connectivity/aggregation API platform, not an automation-builder tool; there is no concept of 'automations' with version/review/rollback in its product surface, so this axis is a category error rather than an unmet capability.", "evidenceIds": [] }, { "productId": "mx", "storyId": "connection-repair-relink", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers MX's connectivity products (aggregation, IAV, AOI, microdeposits, webhooks) but never documents connection/member status codes (e.g., expired, revoked, challenged) or a dedicated re-authentication/update flow that lets users fix a broken link without re-onboarding. This is a plausible and expected capability for an account-aggregation platform, but nothing in the pack substantiates it.", "evidenceIds": [] }, { "productId": "mx", "storyId": "data-deletion-api", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers connectivity, aggregation, webhooks, and API testing but contains no documentation of a delete/disconnect flow for members or users, nor any statement about MX stopping data collection or purging held data upon request. This is a fair question for a financial data aggregator handling sensitive consumer data, but no supporting evidence exists.", "evidenceIds": [] }, { "productId": "mx", "storyId": "hosted-link-flow", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "MX docs describe the Connect Widget as a ready-made, embeddable UI that prompts end users to authenticate with their institution credentials, paired with the Platform API for server-side session/member creation, matching the drop-in hosted flow with no custom institution UI needed. Webhooks and member/account tokens (e.g., guid-based member connections) round out the server-to-client flow.\nmissing for 10: explicit mention of a 'connect token' generation endpoint and independent/third-party confirmation of the end-to-end session-create-then-widget-open flow.", "evidenceIds": [ "mx-docs-9", "mx-docs-21", "mx-docs-22", "mx-docs-23", "mx-docs-25" ] }, { "productId": "mx", "storyId": "income-cashflow-insights", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "MX's evidence covers account aggregation, balances, identity/ownership verification, and general 'data intelligence' or 'personalized guidance' claims, but nothing documents a specific income/cash-flow signal product — no mention of recurring-income detection, payroll detection, or a named income verification offering built on transaction data.", "evidenceIds": [] }, { "productId": "mx", "storyId": "institution-coverage-breadth", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers MX's connectivity products, APIs, and webhooks but contains no published figures on number of institutions reached, geographic coverage, or any coverage map/list a founder could check against their users' banks.", "evidenceIds": [] }, { "productId": "mx", "storyId": "institution-status-visibility", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers connectivity, aggregation, webhooks, and test institutions, but there is no documented institution status dashboard, outage/degradation signal, or error-code taxonomy distinguishing bank-side failures from client-side issues. Missing for 10: institution health/status page, outage or degradation indicators, and documented error codes for bank vs integration failure.", "evidenceIds": [] }, { "productId": "mx", "storyId": "multi-product-sessions", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "MX's Connect Widget/Platform API model uses a single connection (member) per institution that then exposes multiple products—verification, identity, balances, aggregation, extended history—via the same member without re-prompting the user (mx-docs-21, mx-docs-9, mx-docs-15/16/18/19/20). Webhooks and the 24-hour auto-aggregation cycle (mx-docs-25, mx-docs-7) further support a single persistent connection powering ongoing multi-product data access. missing for 10: no explicit documentation or hands-on confirmation that a single Connect session activates all products simultaneously without separate per-product entitlement/config steps, and no independent developer account of this exact flow.", "evidenceIds": [ "mx-docs-21", "mx-docs-9", "mx-docs-15", "mx-docs-16", "mx-docs-18", "mx-docs-19", "mx-docs-20", "mx-docs-25", "mx-docs-7" ] }, { "productId": "mx", "storyId": "oauth-bank-connections", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows MX supports OAuth in its Connect Widget (mx-docs-23) but there is no documentation of overall OAuth coverage across institutions or any stated plan for retiring legacy credential-based (screen-scraped) connections, which is the core of this story.", "evidenceIds": [ "mx-docs-23" ] }, { "productId": "mx", "storyId": "on-demand-refresh", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence only shows MX automatically aggregates accounts on a ~24-hour cycle (mx-docs-25) and describes webhooks for event notifications, but there is no documented API endpoint or semantics for a developer-triggered on-demand refresh of a connected account's data.", "evidenceIds": [ "mx-docs-25", "mx-docs-7" ] }, { "productId": "mx", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "MX exposes a full Platform API (with public OpenAPI spec and even an MCP server) covering the same core capabilities as its Connect Widget UI—account verification, aggregation, balances, transaction history, webhooks—so most end-user and data flows are API-accessible. However, there is no explicit documentation confirming full parity between the API and MX's dashboard/admin UI (e.g., configuration, analytics, or account-management screens), so some UI-only functions may not be exposed. Missing for 10: explicit parity statement, evidence covering dashboard/admin functions via API, independent confirmation of no UI-only features.", "evidenceIds": [ "mx-docs-21", "mx-gh-1", "mx-probe-3", "mx-docs-26" ] }, { "productId": "mx", "storyId": "openness-full-export", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "MX supports sharing held data with an FDX open finance platform and exposes an OpenAPI spec, suggesting some open-format data portability for the businesses that integrate with it, but there is no evidence of an end-user-facing 'export all my data and leave' feature or documented full data export/deletion workflow. missing for 10: end-user self-service export tool, documentation of full data export scope/format, evidence of account closure/data portability workflow, independent confirmation of FDX export usage.", "evidenceIds": [ "mx-docs-11", "mx-gh-1", "mx-docs-26" ] }, { "productId": "mx", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "MX is a closed commercial fintech API/SaaS product; the only public GitHub repo (mx-gh-1) contains an OpenAPI specification for documentation/integration purposes, not the actual application source code, and no license grants access to MX's implementation source.", "evidenceIds": [ "mx-gh-1" ] }, { "productId": "mx", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "MX is a cloud-hosted financial data connectivity API/SaaS platform with no evidence of any self-hostable core product; self-hosting is a category error for this kind of managed financial-data service.", "evidenceIds": [] }, { "productId": "mx", "storyId": "pay-by-bank-initiation", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "MX's evidence covers account verification, aggregation, balance, transaction history, and identity data, plus 'Tokenized Account Numbers... for secure ACH money movement' (mx-docs-24), but there is no documented payment-initiation API/product, no description of initiating a bank payment/transfer, and no stated live geographies for such a capability.", "evidenceIds": [ "mx-docs-24", "mx-docs-15", "mx-docs-19" ] }, { "productId": "mx", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses data residency, region selection, or storage location controls for MX's data; all citations concern connectivity, aggregation, and API/testing features. missing for 10: any mention of data residency/region options, compliance certifications tied to geographic storage, or configuration for where data is stored.", "evidenceIds": [] }, { "productId": "mx", "storyId": "privacy-no-training", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses AI training data usage, opt-out controls, or any privacy policy statement about model training; the pack is entirely about financial data connectivity, aggregation, and webhooks.", "evidenceIds": [] }, { "productId": "mx", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack contains no mention of data retention periods, deletion policies, or user/data-controller controls over stored financial data; all citations relate to connectivity, aggregation, and API features rather than privacy/data lifecycle controls.", "evidenceIds": [] }, { "productId": "mx", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence pack item addresses telemetry, usage tracking, analytics opt-out, or data collection controls for AI-native usage; the docs focus entirely on financial data connectivity and APIs. Missing for 10: any mention of telemetry collection, an opt-out mechanism, or privacy settings related to usage tracking.", "evidenceIds": [] }, { "productId": "mx", "storyId": "processor-integrations", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "MX provides Instant Account Verification (account/routing numbers) and Tokenized Account Numbers (TANs) explicitly described as 'substitute account numbers used for secure ACH money movement,' which supports handing verified account credentials to processors for payment initiation, plus a Connect Widget/Platform API for linking accounts. However, evidence does not show explicit named integrations or token-exchange flows with specific third-party payment processors (e.g., Stripe, Plaid-style processor partnerships) beyond MX's own ACH/TAN mechanism. missing for 10: documented named processor/platform integrations or partner list, explicit token-exchange API examples handing credentials to a specific external processor, independent confirmation of processor handoff working in production.", "evidenceIds": [ "mx-docs-1", "mx-docs-15", "mx-docs-24", "mx-docs-21", "mx-gh-1" ] }, { "productId": "mx", "storyId": "quickstart-first-connection", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "MX provides developer-facing artifacts like a downloadable OpenAPI spec (importable into Postman), a public GitHub OpenAPI repo, and a test platform with sandbox test institutions, which support quick experimentation. However there's no evidence of a self-serve API key signup flow, a step-by-step quickstart guide, or officially maintained client libraries/SDKs in specific languages. missing for 10: self-serve API key/account signup flow, official quickstart tutorial, language-specific client libraries/SDKs.", "evidenceIds": [ "mx-docs-8", "mx-docs-12", "mx-docs-26", "mx-gh-1", "mx-probe-2" ] }, { "productId": "mx", "storyId": "realtime-balance-checks", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "MX documents a balance product ('Get the available balance for an end user's financial accounts') confirming real-time balance retrieval for connected accounts, which aligns with the story's core ask. However, there is no explicit mention of NSF/risk-check use case, no documented latency/real-time SLA, and no dedicated endpoint spec or code sample shown in evidence. missing for 10: explicit NSF/risk-check framing, real-time performance guarantees, concrete endpoint/request-response example.", "evidenceIds": [ "mx-docs-4", "mx-docs-18" ] }, { "productId": "mx", "storyId": "recurring-variable-payments", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "MX's evidence covers account aggregation, identity/verification, balances, transaction history and ACH microdeposit verification, plus tokenized account numbers for ACH money movement — but there is no mention of variable recurring payments, standing consents, or any recurring/scheduled debit payment-initiation flow.", "evidenceIds": [] }, { "productId": "mx", "storyId": "sandbox-test-institutions", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "MX documents a dedicated test platform with four test institutions and an OpenAPI spec importable into Postman, plus guidance on testing the Connect Widget's OAuth flow end-to-end — directly supporting sandbox-based linking/testing before production use. However, the evidence does not show explicit documented test credentials for each test institution or guidance on simulating specific error states. Missing for 10: documented test credentials per institution, explicit error-state/failure simulation guidance.", "evidenceIds": [ "mx-docs-8", "mx-docs-12", "mx-docs-26", "mx-docs-23" ] }, { "productId": "mx", "storyId": "scoped-data-access", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "MX splits data access into distinct products (Instant Account Verification, Account Owner Identification, Account Aggregation, Extended Transaction History, Balance), which implies a developer could integrate only the specific product/data type needed rather than one monolithic grant. However, there is no explicit documentation of a consent-scoping mechanism, a permission UI showing only requested scopes to end users, or stated data-minimization principles/controls. Missing for 10: explicit consent/scope management docs, evidence of end-user-facing scope selection in Connect Widget, and any stated data-minimization policy.", "evidenceIds": [ "mx-docs-1", "mx-docs-2", "mx-docs-5", "mx-docs-6", "mx-docs-4", "mx-docs-21" ] }, { "productId": "mx", "storyId": "transaction-enrichment", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers connectivity, verification, aggregation, webhooks, and testing tools, but never documents transaction enrichment specifics like cleaned merchant names, categorization, or logos — only vague references to 'data-driven intelligence' and 'account and transaction history in one view.' Since enrichment is a fair and expected capability for a financial-data-aggregation platform, but no concrete documentation of merchant cleansing/categories/logos appears, this is 'none' rather than 'na'.", "evidenceIds": [ "mx-docs-13", "mx-docs-28", "mx-docs-5", "mx-docs-19" ] }, { "productId": "mx", "storyId": "transactions-history-api", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "MX clearly documents transaction history depth (90 days standard via Account Aggregation, up to 24 months via Extended Transaction History) and provides a sync mechanism via webhooks plus automatic ~24hr re-aggregation of connected accounts, backed by a public OpenAPI spec for the Platform API. However, the evidence never explicitly documents pagination parameters/behavior for the transactions endpoint itself, and the webhook-based sync isn't described as an incremental 'only what changed' diff pattern (e.g., no mention of delta/cursor tokens). Missing for 10: explicit pagination documentation for transaction list endpoints, explicit incremental/delta sync mechanism beyond generic webhooks/24h refresh.", "evidenceIds": [ "mx-docs-5", "mx-docs-6", "mx-docs-19", "mx-docs-20", "mx-docs-25", "mx-docs-7", "mx-docs-22", "mx-gh-1", "mx-docs-12" ] }, { "productId": "mx", "storyId": "user-consent-management", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers MX's data connectivity products (account verification, aggregation, transaction history) and webhooks, but contains no mention of any end-user-facing consent dashboard, permissions center, or revocation portal where users can view/manage which apps hold access to their bank data. missing for 10: documented consent/permissions portal, revocation flow, any UI or API for end users to view/manage connected app access.", "evidenceIds": [ "mx-docs-9", "mx-docs-21", "mx-docs-11" ] }, { "productId": "mx", "storyId": "webhook-data-events", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "MX docs confirm webhooks with HTTPS POST callbacks for subscribing to events like transaction/balance/connection changes, and note that account aggregation runs automatically (~every 24h) with webhook notification rather than requiring polling. Missing for 10: explicit documentation of webhook payload signing/verification mechanism and a full enumerated list of event types, plus independent/hands-on corroboration beyond first-party docs.", "evidenceIds": [ "mx-docs-7", "mx-docs-22", "mx-docs-25" ] }, { "productId": "plaid", "storyId": "account-numbers-for-ach", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Plaid Auth explicitly provides checking/savings/cash management account and routing numbers to initiate ACH/wire debits/credits without micro-deposits, and is paired with Balance and Identity for verification, with Sandbox/Link supporting full dev testing. missing for 10: no independent/hands-on corroboration of micro-deposit-free instant verification success rate, and no explicit mention of tokenized-equivalent output formats.", "evidenceIds": [ "plaid-docs-1", "plaid-docs-2", "plaid-docs-3", "plaid-docs-5", "plaid-docs-13" ] }, { "productId": "plaid", "storyId": "account-ownership-data", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Plaid's Identity product is explicitly documented to return name, phone, email, and mailing address on file with the account holder's financial institution, directly matching the ops-lead need to verify account-owner identity against a customer record. Missing for 10: no independent/hands-on corroboration of match-accuracy or match-rate quality, and no explicit description of a 'match' scoring feature (e.g., identity match API) beyond raw data retrieval.", "evidenceIds": [ "plaid-docs-3", "plaid-docs-12" ] }, { "productId": "plaid", "storyId": "agent-links-and-reads", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Plaid's REST API comprehensively covers the core story — creating Link sessions (plaid-docs-5), retrieving balances (plaid-docs-2), pulling transactions (plaid-docs-4, plaid-gh-1), and managing connections/Items via webhooks (plaid-docs-8) — and SDKs like plaid-node make this scriptable by an agent. However, the only documented MCP surface is the Dashboard MCP server, which is scoped to Production diagnostics/analytics (debugging Items, Link conversion, usage metrics) rather than operational banking actions like initiating Link or pulling balances/transactions (plaid-docs-9, plaid-probe-4). Missing for 10: an MCP surface (or equivalent agent-native interface) that actually performs Link session creation/balance/transaction retrieval, and explicit documentation of scoped/limited credentials designed for autonomous agent use rather than server-side API keys.", "evidenceIds": [ "plaid-docs-5", "plaid-docs-2", "plaid-docs-4", "plaid-docs-8", "plaid-gh-1", "plaid-docs-9", "plaid-probe-4" ] }, { "productId": "plaid", "storyId": "agent-ready-financial-data", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Plaid's docs describe structured JSON products (Auth, Balance, Identity, Transactions) with clear semantics and webhooks for async updates, and SDKs show typed request/response handling with try/catch error parsing, suggesting machine-consumable output. However, there's no evidence of a public OpenAPI/JSON-schema spec (probe explicitly found 404s for openapi.json/swagger.json), and no documentation of transaction enrichment/categorization features an agent could reason over without extra parsing logic. Missing for 10: published OpenAPI or JSON schema definitions, explicit enrichment/categorization documentation, and independent confirmation that outputs require no heuristic post-processing.", "evidenceIds": [ "plaid-docs-1", "plaid-docs-2", "plaid-docs-4", "plaid-docs-8", "plaid-gh-1", "plaid-gh-2", "plaid-probe-3" ] }, { "productId": "plaid", "storyId": "agentic-agent-docs", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Plaid has a live llms.txt at plaid.com/llms.txt (HTTP 200) confirming basic agent-oriented discovery, but the content is minimal (a short description, not a full doc index), the /docs/.md and openapi.json probes 404 rather than exposing machine-readable docs, and there's no independent corroboration of agents actually consuming these successfully. missing for 10: richer llms.txt content indexing full doc set, working markdown/OpenAPI endpoints, independent/hands-on evidence of an agent successfully using these to navigate docs.", "evidenceIds": [ "plaid-probe-1", "plaid-probe-2", "plaid-probe-3" ] }, { "productId": "plaid", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence that Plaid generates AI-driven insights or suggestions from a user's financial data; the closest item (Dashboard MCP server) only exposes diagnostics/analytics tools for developers, not AI-generated insights delivered to end users. Missing for 10: any AI/ML insight-generation feature, natural-language summarization of transactions/balances, or user-facing recommendation engine.", "evidenceIds": [ "plaid-docs-9" ] }, { "productId": "plaid", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Plaid provides webhooks and transactionsSync for asynchronous, background processing of financial data changes (docs-8, gh-1), which could underpin automations, but there is no evidence of any AI-native automation/agent orchestration capability, scheduling, or autonomous workflow builder — the Dashboard MCP server is limited to diagnostics/analytics, not automation setup. Missing for 10: explicit automation/agent framework, scheduling or trigger-action tooling, and any AI-native framing of background autonomy beyond generic webhooks.", "evidenceIds": [ "plaid-docs-8", "plaid-gh-1", "plaid-docs-9" ] }, { "productId": "plaid", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Plaid is a financial data/payments API infrastructure product, not a user-facing product with a built-in AI assistant persona; this axis is a category error for this kind of B2B fintech API platform. No evidence describes a built-in AI assistant for delegating tasks (the MCP server is for dashboard diagnostics, not an in-product assistant).", "evidenceIds": [] }, { "productId": "plaid", "storyId": "agentic-headless", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Plaid's Sandbox exposes a special API endpoint (/sandbox/public_token/create) that lets developers generate test Items and public tokens purely via API calls, without any UI, which supports scripted/headless testing suitable for CI (plaid-docs-14, plaid-docs-13). The Node SDK further demonstrates programmatic, promise-based server-side calls (plaid-gh-1, plaid-gh-2) that can run in automated pipelines. However, real (non-sandbox) account linking still requires the client-side Plaid Link UI component, so full production automation isn't headless, and no explicit CI/automation documentation or examples are provided. missing for 10: explicit CI/headless automation guide, confirmation that production flows can bypass Link UI, independent evidence of running Plaid in automated pipelines.", "evidenceIds": [ "plaid-docs-14", "plaid-docs-13", "plaid-gh-1", "plaid-gh-2", "plaid-docs-10" ] }, { "productId": "plaid", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Plaid is a fintech data/API platform, not an agentic host or assistant interface where a user would plug in MCP servers for it to consume tools; the only MCP-related evidence shows Plaid exposing its own Dashboard as an MCP server (a different, server-provider axis), not Plaid acting as an MCP client consuming external tools.", "evidenceIds": [ "plaid-docs-9", "plaid-probe-4" ] }, { "productId": "plaid", "storyId": "agentic-mcp-server", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Plaid documents an official 'Dashboard MCP server' hosted by Plaid providing Production diagnostics and analytics tools (debugging Items, Link conversion data, usage metrics), confirmed by both docs and a probe hit. However, this MCP server is scoped only to dashboard/analytics functions rather than full API/product access (Auth, Transactions, Identity, etc.), so an agent cannot use it to perform general Plaid operations via MCP. Missing for 10: MCP coverage of core Plaid API functionality (Auth, Transactions, Payments) and independent/community corroboration of real-world MCP usage.", "evidenceIds": [ "plaid-docs-9", "plaid-probe-4" ] }, { "productId": "plaid", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Plaid documents an official 'Dashboard MCP server' that exposes diagnostics/analytics tools (debugging Items, Link conversion data, usage metrics) which an AI agent could invoke via natural language, but this only covers dashboard operations, not the core product functionality (Auth, Transactions, Identity, Payments) — there is no broader natural-language interface for operating Plaid's main capabilities. Missing for 10: NL control over core Plaid products (linking, transactions, payments), independent/hands-on confirmation of MCP usability, and any conversational agent interface beyond dashboard diagnostics.", "evidenceIds": [ "plaid-docs-9", "plaid-probe-4" ] }, { "productId": "plaid", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence shows Plaid SDKs (e.g., plaid-node), Quickstart apps, and a hosted MCP server, but no mention anywhere of an official CLI tool for interacting with Plaid's API or dashboard.", "evidenceIds": [] }, { "productId": "plaid", "storyId": "agentic-public-api", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Plaid provides extensive public API documentation (Auth, Balance, Identity, Transactions, Payment Initiation), SDKs (plaid-node), webhooks, and a Sandbox for programmatic testing, all of which let a developer (including an AI agent) drive the product via documented endpoints. However, there's no discoverable OpenAPI/Swagger spec (404s on all candidate paths) and no llms.txt-style machine-readable API map beyond a generic landing page, which limits pure agentic/machine-driven discovery. missing for 10: publicly discoverable OpenAPI/machine-readable spec, evidence of AI-agent-specific API tooling beyond the separate Dashboard MCP server.", "evidenceIds": [ "plaid-docs-1", "plaid-docs-2", "plaid-docs-3", "plaid-docs-4", "plaid-docs-7", "plaid-docs-8", "plaid-docs-14", "plaid-gh-1", "plaid-gh-2", "plaid-probe-2", "plaid-probe-3" ] }, { "productId": "plaid", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Plaid's evidence covers products (Auth, Balance, Identity, Transactions), Sandbox testing, Link, and a read-only diagnostics MCP server, but nothing describes issuing scoped or least-privilege API credentials/tokens specifically for an agent or any granular permissioning model for AI-native use. Missing for 10: any documentation of scoped API keys, credential minimization, or agent-specific access tokens.", "evidenceIds": [ "plaid-docs-9", "plaid-docs-10", "plaid-docs-7" ] }, { "productId": "plaid", "storyId": "agentic-sdks", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Plaid ships an official Node.js SDK (plaid-node) with documented async/await error-handling patterns and a quickstart guide showing API-key based setup, which supports building integrations programmatically. However, the evidence pack only shows one language SDK, no explicit mention of other official SDKs (Python, Java, Go, etc.) or SDK features tailored to AI-native/agentic workflows, and no independent corroboration of SDK quality. missing for 10: evidence of multi-language official SDKs, AI-specific SDK tooling or agent integration guides, independent developer corroboration of SDK usability.", "evidenceIds": [ "plaid-gh-1", "plaid-gh-2", "plaid-docs-10" ] }, { "productId": "plaid", "storyId": "agentic-webhooks", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Plaid documents a first-class webhooks system that notifies subscribers of Item/product state changes (e.g., new transactions), which any AI-native integration could consume just like a human-built app. Missing for 10: independent/hands-on corroboration of webhook reliability and any agent-specific guidance for consuming webhooks programmatically.", "evidenceIds": [ "plaid-docs-8", "plaid-docs-4" ] }, { "productId": "plaid", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows only static docs pages, a Quickstart sample app to clone locally, and a Sandbox test environment, but no interactive API reference (e.g., try-it console, embedded runnable code snippets) — probes for an OpenAPI spec and docs-as-markdown interactive surface both returned 404s, suggesting no such interactive reference exists.", "evidenceIds": [ "plaid-docs-10", "plaid-probe-2", "plaid-probe-3" ] }, { "productId": "plaid", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Direct probes for OpenAPI/swagger spec files at standard paths all returned 404, and no documentation references a downloadable machine-readable API spec; only an llms.txt marketing page was found, not an OpenAPI/equivalent spec.", "evidenceIds": [ "plaid-probe-3", "plaid-probe-2", "plaid-probe-1" ] }, { "productId": "plaid", "storyId": "api-sandbox", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Plaid provides a dedicated, fully-featured Sandbox environment supporting all API/Link functionality with unlimited test Items and test credentials, plus a special sandbox-only endpoint for programmatic Item creation, clearly separating test from production data. missing for 10: no independent/hands-on developer corroboration of sandbox fidelity, and no explicit mention of AI-agent-specific sandbox testing workflows.", "evidenceIds": [ "plaid-docs-7", "plaid-docs-13", "plaid-docs-14", "plaid-docs-10" ] }, { "productId": "plaid", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack contains no documentation of API versioning scheme or a deprecation policy — no changelog, version headers, or sunset timeline are mentioned anywhere, only product feature docs (Auth, Balance, Identity, Transactions) and SDK error-handling snippets.", "evidenceIds": [] }, { "productId": "plaid", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Plaid's docs describe per-Item operations (Auth, Balance, Identity, Transactions, sandbox item creation) and webhooks, but no evidence shows a bulk/batch API for operating across many Items simultaneously (e.g., no bulk sync, bulk webhook re-fire, or multi-item query endpoint documented).", "evidenceIds": [] }, { "productId": "plaid", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Plaid provides webhooks that notify developers of events (item changes, transaction updates, async completions), which can be used to build automated reactions, but there is no evidence of a declarative rules engine where an AI-native user defines 'if event X then action Y' logic directly within Plaid—developers must write their own handling code. Missing for 10: a native rule/condition-action builder, AI-triggered automation config, or no-code trigger definitions beyond raw webhook payloads.", "evidenceIds": [ "plaid-docs-8", "plaid-docs-4", "plaid-gh-1" ] }, { "productId": "plaid", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "plaid", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Plaid is a financial data/payments API platform, not an automation-building tool with workflows to version, review, or roll back; this axis doesn't apply to its product category.", "evidenceIds": [] }, { "productId": "plaid", "storyId": "connection-repair-relink", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Plaid's webhook docs mention that webhooks inform developers about 'changes to Plaid Items or the status of asynchronous processes' (plaid-docs-8), which touches on connection status changes, and Link (plaid-docs-5, plaid-docs-11) is the client-side re-linking component. However, the evidence pack never explicitly documents the specific re-authentication 'update mode' flow, named error statuses like ITEM_LOGIN_REQUIRED, or confirmation that re-auth avoids re-onboarding from scratch. Missing for 10: explicit documentation of update-mode Link flow, named broken-connection status codes/webhooks, and confirmation users don't restart the full linking process.", "evidenceIds": [ "plaid-docs-8", "plaid-docs-5", "plaid-docs-11" ] }, { "productId": "plaid", "storyId": "data-deletion-api", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no documentation of an item/access-token deletion endpoint, account disconnection flow, or data purge/retention policy — only product feature docs (Auth, Balance, Identity, Transactions) and Sandbox/dashboard mentions. A community comment even shows a user asking how to revoke Plaid's bank access with no clear answer surfaced, reinforcing the absence of a documented sever-and-purge mechanism in the pack.", "evidenceIds": [ "plaid-comm-2", "plaid-docs-4", "plaid-docs-8" ] }, { "productId": "plaid", "storyId": "hosted-link-flow", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Plaid Link is explicitly documented as the client-side hosted widget that lets users connect their bank without the developer building institution UI, paired with server-side session/token creation (public_token/access_token flow) shown in SDKs and Sandbox docs. missing for 10: no independent/hands-on developer report confirming the end-to-end token exchange experience, and no explicit token-exchange code snippet in this pack (only Sandbox/public_token creation and general Link description).", "evidenceIds": [ "plaid-docs-5", "plaid-docs-11", "plaid-docs-14", "plaid-docs-13", "plaid-docs-10", "plaid-gh-1" ] }, { "productId": "plaid", "storyId": "income-cashflow-insights", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers Auth, Balance, Identity, Transactions, Payment Initiation and Link, but contains no mention of an Income product, payroll detection, or recurring-stream/cash-flow analytics built on transaction data — the specific capability the story asks about is absent from the pack.", "evidenceIds": [] }, { "productId": "plaid", "storyId": "institution-coverage-breadth", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "The pack shows only a narrow geography claim (payment-initiation supports '18 European markets') but no overall institution count or country-by-country coverage list that a founder could check against user banks. missing for 10: published total institution count, per-country/region coverage breakdown, and any independent verification of coverage claims.", "evidenceIds": [ "plaid-docs-15" ] }, { "productId": "plaid", "storyId": "institution-status-visibility", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Plaid documents webhooks for Item status changes and SDK-level error handling, and offers a Dashboard MCP server with 'diagnostics tools' for debugging Items, which supports some institution-health visibility. However, there is no evidence of a documented institution-status/error-code taxonomy (e.g., distinguishing bank outages from integration errors) or a public status page for individual institutions. Missing for 10: documented per-institution error code list distinguishing bank vs. client errors, an institution status/outage dashboard or feed, and independent confirmation these diagnostics reliably surface bank-side outages.", "evidenceIds": [ "plaid-docs-8", "plaid-gh-1", "plaid-gh-2", "plaid-docs-9", "plaid-probe-4" ] }, { "productId": "plaid", "storyId": "multi-product-sessions", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Plaid's sandbox docs explicitly mention creating an Item with 'initial products' (plural) via a single public_token, implying one Link-created Item can be enabled for multiple products (auth, balance, identity, transactions) at once rather than separate connections. However, the evidence pack never explicitly confirms a single Link session UX flow surfacing multiple products to the end user in one consent step. Missing for 10: an explicit doc/example showing a single Link token configured with products=['auth','balances','transactions','identity'] and the resulting single end-user consent flow, plus independent/hands-on confirmation.", "evidenceIds": [ "plaid-docs-14", "plaid-docs-5", "plaid-docs-1", "plaid-docs-2", "plaid-docs-3", "plaid-docs-4" ] }, { "productId": "plaid", "storyId": "oauth-bank-connections", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no Plaid documentation describing OAuth coverage for institutions or a plan to retire legacy credential/screen-scraping flows; docs only describe Auth/Balance/Identity/Transactions products generically. Community evidence in fact describes Plaid using screen-scraped credentials and even mimicking bank login pages, reinforcing the absence of documented OAuth-first coverage.", "evidenceIds": [ "plaid-comm-4", "plaid-comm-5", "plaid-comm-13", "plaid-docs-5" ] }, { "productId": "plaid", "storyId": "on-demand-refresh", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "The evidence shows Plaid supports webhook-based updates (plaid-docs-8, plaid-docs-4) and an API-driven `transactionsSync` call (plaid-gh-1, plaid-gh-2) that developers can invoke to pull current data, which is adjacent to an on-demand refresh trigger, but the pack never cites Plaid's dedicated refresh endpoint (e.g. /transactions/refresh) or documents its specific semantics (timing, cost, which products support it). Missing for 10: explicit documentation of a refresh-on-demand endpoint and its semantics, confirmation of which products it applies to, and any independent/hands-on confirmation of its behavior.", "evidenceIds": [ "plaid-docs-8", "plaid-docs-4", "plaid-gh-1", "plaid-gh-2" ] }, { "productId": "plaid", "storyId": "openness-api-parity", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Plaid is API-first for core financial data products, and Sandbox Items can be created via API instead of the Dashboard UI (plaid-docs-14), suggesting some UI/API parity. However, the docs explicitly describe Dashboard-only actions like customizing and publishing Link's flow (plaid-docs-11) and signing up for API keys (plaid-docs-10) with no corresponding API endpoint shown, and there's no OpenAPI spec or full endpoint catalog to confirm total parity (plaid-probe-3). Missing for 10: evidence that Dashboard-only settings (Link customization, key management, analytics) have API equivalents, and independent confirmation of full UI/API feature parity.", "evidenceIds": [ "plaid-docs-11", "plaid-docs-14", "plaid-docs-10", "plaid-probe-3" ] }, { "productId": "plaid", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "plaid", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Plaid is a closed-source commercial API/SaaS product; its client SDKs (e.g., plaid-node) are open-source wrappers but the core Plaid service/source is not published under an open license, and no evidence shows the product's actual source available for inspection.", "evidenceIds": [] }, { "productId": "plaid", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Plaid is a hosted financial-data/API SaaS product built on proprietary bank connections and infrastructure; self-hosting the core service is not a plausible axis for this category (only a local quickstart demo app is offered, not the core Plaid backend).", "evidenceIds": [] }, { "productId": "plaid", "storyId": "pay-by-bank-initiation", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Plaid documents a real Payment Initiation product enabling real-time bank payments across 18 named European markets, which is a fairly honest geography disclosure, but Plaid explicitly does not offer this product in the US (US flows rely on Auth+ACH via third-party rails, not Plaid-initiated payment). missing for 10: explicit US/global payment-initiation coverage or a clear statement of unsupported geographies beyond Europe, independent/hands-on confirmation of the payment-initiation flow working as documented, and clarity on settlement/liability model for developers.", "evidenceIds": [ "plaid-docs-6", "plaid-docs-15", "plaid-docs-1" ] }, { "productId": "plaid", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence of any data residency/region selection controls in Plaid's documentation; the evidence pack covers products, sandbox, MCP server, and payment features but never mentions data storage location choice or regional hosting options.", "evidenceIds": [] }, { "productId": "plaid", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Plaid is a financial data connectivity API, not an AI model or AI product feature; the evidence pack contains no mention of AI model training or opt-out controls for such training. This axis is a category error for this type of product.", "evidenceIds": [] }, { "productId": "plaid", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence pack item documents any user- or developer-facing mechanism for controlling data retention periods or deleting stored financial data in Plaid; docs cover data collection (Auth, Identity, Transactions, Balance) but not retention/deletion controls. Community commentary even shows a user unsure how to revoke Plaid's access, underscoring the absence of a clear deletion/retention feature.", "evidenceIds": [ "plaid-docs-4", "plaid-comm-2" ] }, { "productId": "plaid", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence in the pack addresses telemetry or usage-tracking opt-out for Plaid's SDKs, Link, or APIs; the docs and community items focus on financial data access and privacy concerns about data collection scope, not an opt-out mechanism for usage analytics.", "evidenceIds": [] }, { "productId": "plaid", "storyId": "processor-integrations", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Plaid's Auth product explicitly hands over verified account and routing numbers to enable third-party ACH/wire debits/credits, and Payment Initiation extends this to real-time European bank transfers without manual entry, with Balance/Identity supplementing verification data used by payment processors. This is documented as a core first-party capability (token exchange via Link → API access to account credentials for downstream money movement).\nmissing for 10: named case studies/integrations with specific processors (e.g., Stripe), independent technical corroboration of the token-exchange flow beyond docs.", "evidenceIds": [ "plaid-docs-1", "plaid-docs-2", "plaid-docs-6", "plaid-docs-15", "plaid-docs-5" ] }, { "productId": "plaid", "storyId": "quickstart-first-connection", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Docs show self-serve signup via Dashboard for API keys, a runnable Quickstart app, a fully-featured free Sandbox environment supporting all products, and a Node client library with async/await error handling. However, there's no explicit evidence of the breadth of client libraries across multiple languages, no independent hands-on confirmation of quickstart speed/ease, and no OpenAPI spec discoverable via probes. missing for 10: multi-language client library coverage evidence, independent/hands-on time-to-first-linked-account confirmation, public OpenAPI/API reference spec.", "evidenceIds": [ "plaid-docs-7", "plaid-docs-10", "plaid-docs-13", "plaid-docs-14", "plaid-gh-1", "plaid-gh-2", "plaid-probe-3" ] }, { "productId": "plaid", "storyId": "realtime-balance-checks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Plaid's Balance product is explicitly documented as a real-time balance endpoint used to check sufficient funds before using an account as a payment funding source, directly matching the NSF/risk-check use case. missing for 10: independent hands-on developer confirmation of the /accounts/balance/get endpoint behavior and no explicit mention of latency/SLA guarantees for pre-payment checks.", "evidenceIds": [ "plaid-docs-2" ] }, { "productId": "plaid", "storyId": "recurring-variable-payments", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Plaid's Payment Initiation docs describe single real-time payments across European markets, with no mention of variable recurring payments, standing orders, or documented recurring debit/consent flows; Auth/ACH docs also only describe initiating one-off credits/debits, not recurring mandates.", "evidenceIds": [ "plaid-docs-6", "plaid-docs-15", "plaid-docs-1" ] }, { "productId": "plaid", "storyId": "sandbox-test-institutions", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Plaid's Sandbox docs describe a free, fully-featured test environment supporting all API and Link functionality, unlimited test Items, a special sandbox-only endpoint to create Items with arbitrary institution IDs and test credentials, and SDK error-handling examples for exercising error states end-to-end. This directly matches the story's need to test linking, data retrieval, and error flows before touching real accounts. Missing for 10: independent/hands-on developer corroboration of the sandbox experience beyond first-party docs.", "evidenceIds": [ "plaid-docs-7", "plaid-docs-13", "plaid-docs-14", "plaid-gh-1", "plaid-gh-2", "plaid-docs-5" ] }, { "productId": "plaid", "storyId": "scoped-data-access", "verdict": "disputed", "quality": 4, "confidence": "medium", "rationale": "Plaid's docs show genuinely separate, scopeable products (Auth, Balance, Identity, Transactions, Payment Initiation) that a developer can choose to request individually rather than one monolithic grant, which supports a product-scoped consent model. However, independent/community reports concretely contradict the 'data-minimization by design' claim: users report Plaid flows give 'no indication... you're likely giving away much more than just the bare minimum' and that dark patterns lead to over-broad grants (transaction, identity, balance data) beyond what the integrating app needs. Missing for 10: first-party documentation of a scoped-consent UI/permission screen, independent audit confirming least-privilege enforcement, and no rebuttal to the dark-pattern complaints.", "evidenceIds": [ "plaid-docs-1", "plaid-docs-2", "plaid-docs-3", "plaid-docs-4", "plaid-docs-6", "plaid-comm-3", "plaid-comm-1" ] }, { "productId": "plaid", "storyId": "transaction-enrichment", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "While Plaid's Transactions product is documented as returning transaction data, none of the evidence describes enrichment specifics like cleaned merchant names, categories, or logos being a documented feature — only raw transaction retrieval and webhooks are mentioned (plaid-docs-4, plaid-gh-1). Missing for 10: explicit documentation of merchant name cleaning, category taxonomy, and logo/icon fields as part of the Transactions response.", "evidenceIds": [ "plaid-docs-4", "plaid-gh-1" ] }, { "productId": "plaid", "storyId": "transactions-history-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Plaid's Transactions docs confirm up to 24 months of history and webhook-based updates, and the plaid-node SDK demonstrates the transactionsSync pattern for fetching only changed data, matching the story's pagination/sync/history-depth requirements. missing for 10: no explicit mention of pagination cursor mechanics or rate limits, and no independent/hands-on corroboration of sync behavior beyond the SDK snippet.", "evidenceIds": [ "plaid-docs-4", "plaid-gh-1", "plaid-gh-2" ] }, { "productId": "plaid", "storyId": "user-consent-management", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no documentation of a Plaid-hosted consent management portal or dashboard where end users can view or revoke connected apps' access to their bank data; Plaid Link (docs-5) only covers the initial linking/consent flow, not ongoing management or revocation. Community comments even show a user explicitly asking how to revoke Plaid's access with no clear answer, reinforcing the absence of a documented self-service revocation surface.", "evidenceIds": [ "plaid-docs-5", "plaid-comm-2" ] }, { "productId": "plaid", "storyId": "webhook-data-events", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Plaid's docs explicitly describe webhooks for transactions, balance, and Item/connection state changes to keep systems updated without polling, and this is a well-documented core mechanism (plaid-docs-4, plaid-docs-8) reinforced by SDK error-handling examples showing transactionsSync usage in conjunction with webhooks (plaid-gh-1). No evidence indicates webhook signing/verification is missing or broken. Missing for 10: explicit mention of webhook signature verification mechanics and independent third-party confirmation of webhook reliability in production.", "evidenceIds": [ "plaid-docs-4", "plaid-docs-8", "plaid-gh-1" ] }, { "productId": "stripe-financial-connections", "storyId": "account-numbers-for-ach", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Docs explicitly describe an 'instant' verification flow with 'no manual entry and microdeposit fallback' for ACH Direct Debit, collecting bank account + ownership/balance data in one integration, eliminating the need for users to locate account/routing numbers, and a real-world adopter (comm-6) confirms using it for instant account verification and ACH fraud signaling in production, replacing Plaid Auth. Missing for 10: explicit technical detail on the exact token/PaymentMethod format returned to the server and any independent benchmarking of ACH failure-rate reduction beyond Stripe's own claims.", "evidenceIds": [ "stripe-financial-connections-docs-16", "stripe-financial-connections-docs-17", "stripe-financial-connections-docs-8", "stripe-financial-connections-docs-29", "stripe-financial-connections-comm-6" ] }, { "productId": "stripe-financial-connections", "storyId": "account-ownership-data", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Docs explicitly state you can 'Access account owners' names and mailing addresses' and 'mitigate fraud by verifying account ownership details,' plus an ownership-refresh webhook event confirms this data can be kept current for ownership matching. Community evidence corroborates real-world use as a fraud/ownership signal for ACH payments. Missing for 10: explicit documentation of contact/phone/email fields beyond name+address, and independent hands-on verification of the exact data schema returned.", "evidenceIds": [ "stripe-financial-connections-docs-3", "stripe-financial-connections-docs-21", "stripe-financial-connections-docs-24", "stripe-financial-connections-comm-6" ] }, { "productId": "stripe-financial-connections", "storyId": "agent-links-and-reads", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Financial Connections' API clearly supports creating link sessions, retrieving balances/transactions, and managing connections (docs-2,3,4,5,6,14), and Stripe publishes both a generic MCP server for AI agents to interact with the Stripe API (docs-18, probe-4) and an explicit 'Financial insights for agents' use case mentioning agent-powered spending analysis and balance/transaction monitoring (docs-11). However, no evidence specifies that the MCP surface exposes Financial-Connections-specific tools (e.g., create_link_session, get_balances) or how scoped/restricted credentials are issued for agent use. missing for 10: explicit MCP tool list for Financial Connections actions, documentation of scoped-credential/permission model for agent access, independent confirmation of agent operation end-to-end.", "evidenceIds": [ "stripe-financial-connections-docs-2", "stripe-financial-connections-docs-4", "stripe-financial-connections-docs-6", "stripe-financial-connections-docs-11", "stripe-financial-connections-docs-14", "stripe-financial-connections-docs-18", "stripe-financial-connections-probe-4" ] }, { "productId": "stripe-financial-connections", "storyId": "agent-ready-financial-data", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Stripe's docs show structured API objects for balances, ownership, and transactions plus typed webhook events (docs-2,3,4,12-14,24,25), and even a dedicated 'Financial insights for agents' use-case section citing agent-powered spending analysis and balance/transaction monitoring (docs-11), supporting agent-consumable data. However, no OpenAPI/schema file could be found (probe-3 shows all openapi.json paths 404), and there's no independent/hands-on evidence confirming an agent can parse this data without additional tooling. Missing for 10: published OpenAPI/JSON schema docs, and independent corroboration of agent-consumability beyond Stripe's own docs.", "evidenceIds": [ "stripe-financial-connections-docs-2", "stripe-financial-connections-docs-3", "stripe-financial-connections-docs-4", "stripe-financial-connections-docs-11", "stripe-financial-connections-docs-12", "stripe-financial-connections-docs-13", "stripe-financial-connections-docs-24", "stripe-financial-connections-docs-25", "stripe-financial-connections-probe-3" ] }, { "productId": "stripe-financial-connections", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe hosts a live llms.txt (HTTP 200) and markdown-formatted docs (financial-connections.md) confirmed by direct probes, and there's also agent-oriented documentation like use-cases.md with an explicit 'Financial insights for agents' section referencing agent-powered analysis tools. Missing for 10: independent/community confirmation that agents actually consume these docs successfully, and no dedicated llms.txt content specific to Financial Connections (it's the site-wide docs.stripe.com/llms.txt).", "evidenceIds": [ "stripe-financial-connections-probe-1", "stripe-financial-connections-probe-2", "stripe-financial-connections-docs-11" ] }, { "productId": "stripe-financial-connections", "storyId": "agentic-ai-insights", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Docs list 'Financial insights for agents' with 'Agent-powered spending analysis' and 'Balance and transaction monitoring' as a named use case, and Stripe's MCP server lets AI agents query account data — but these are thin, high-level mentions rather than a documented native AI-insights feature inside the Financial Connections product itself; the core product is described as raw data access (balances, transactions, ownership) for developers to build on, not an insight-generation UI. Missing for 10: concrete documentation of an actual AI-generated insights/suggestions feature, UI screenshots or workflow showing insights surfaced to end users, and independent/hands-on confirmation that agent-powered analysis works as described.", "evidenceIds": [ "stripe-financial-connections-docs-11", "stripe-financial-connections-docs-18", "stripe-financial-connections-probe-4", "stripe-financial-connections-docs-2", "stripe-financial-connections-docs-4" ] }, { "productId": "stripe-financial-connections", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Financial Connections supports webhook events (account linked, balance/ownership/transaction refresh completed) and a relink API, which let developers build background automations that react to account/data changes without manual polling, and docs even reference an 'agent-powered spending analysis' use case. However, there's no evidence of built-in scheduling, orchestration, or agent-specific automation tooling beyond webhooks — it's infrastructure a developer must wire up themselves. Missing for 10: native scheduling/orchestration primitives, explicit AI-agent automation framework, and hands-on evidence of autonomous background agents running on this data.", "evidenceIds": [ "stripe-financial-connections-docs-12", "stripe-financial-connections-docs-13", "stripe-financial-connections-docs-14", "stripe-financial-connections-docs-24", "stripe-financial-connections-docs-25", "stripe-financial-connections-docs-11" ] }, { "productId": "stripe-financial-connections", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows Stripe's MCP server lets external AI agents call the Stripe API and a customer use-case of building agent-powered spending analysis apps, but there is no evidence of a built-in AI assistant inside Financial Connections itself that a user can delegate tasks to.", "evidenceIds": [ "stripe-financial-connections-docs-11", "stripe-financial-connections-docs-18", "stripe-financial-connections-probe-4" ] }, { "productId": "stripe-financial-connections", "storyId": "agentic-headless", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Financial Connections exposes server-side webhooks and a documented testing mode where test institutions can be linked without credentials, which supports some automated/CI testing (docs-15, docs-26, docs-12/13/24/25), and Stripe's broader platform offers a CLI and MCP server for agent-driven automation (probe-4, probe-5, docs-18). However, the core account-linking flow requires a client-side authentication step (collectFinancialConnectionsAccounts) that is inherently interactive, not headless, for real accounts. Missing for 10: explicit documentation of a fully headless/server-only flow for production account linking, and independent confirmation that CI-only automation works end-to-end without any UI step.", "evidenceIds": [ "stripe-financial-connections-docs-15", "stripe-financial-connections-docs-26", "stripe-financial-connections-docs-12", "stripe-financial-connections-docs-13", "stripe-financial-connections-docs-24", "stripe-financial-connections-docs-25", "stripe-financial-connections-docs-6", "stripe-financial-connections-probe-4", "stripe-financial-connections-probe-5" ] }, { "productId": "stripe-financial-connections", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Financial Connections is a bank-data API/embeddable component, not an agentic platform that itself consumes external MCP servers' tools; the only MCP evidence describes Stripe's own MCP server exposing Stripe's API to agents (the opposite direction), which is a separate axis.", "evidenceIds": [ "stripe-financial-connections-docs-18", "stripe-financial-connections-probe-4" ] }, { "productId": "stripe-financial-connections", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Stripe documents an official MCP server that lets AI agents interact with the Stripe API and knowledge base, and Financial Connections docs explicitly call out an agent use case ('Financial insights for agents' with agent-powered spending analysis and balance/transaction monitoring), confirmed by a live docs probe at docs.stripe.com/mcp. Missing for 10: independent/hands-on confirmation that Financial Connections-specific tools (balances, transactions, ownership) are exposed via the MCP server, and no community reports of using it.", "evidenceIds": [ "stripe-financial-connections-docs-18", "stripe-financial-connections-docs-11", "stripe-financial-connections-probe-4" ] }, { "productId": "stripe-financial-connections", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Stripe's docs mention an 'agent-powered spending analysis' use case for Financial Connections and Stripe's general MCP server lets AI agents call the Stripe API, implying some natural-language operability, but there's no detailed documentation of specific natural-language commands or agent workflows scoped to Financial Connections itself. Missing for 10: concrete examples of NL commands/agent interactions specific to Financial Connections, independent/hands-on validation that agents can operate this product conversationally, and clarity on how much of the flow (bank auth, consent) can be agent-driven vs. requiring a human UI step.", "evidenceIds": [ "stripe-financial-connections-docs-11", "stripe-financial-connections-docs-18", "stripe-financial-connections-probe-4" ] }, { "productId": "stripe-financial-connections", "storyId": "agentic-official-cli", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Stripe provides an official Stripe CLI documented at docs.stripe.com/stripe-cli, which applies across Stripe products including Financial Connections, and this is a first-party, well-documented tool rather than just a wrapper. missing for 10: Financial Connections-specific CLI usage examples/workflows and independent hands-on corroboration of CLI use for this product's API.", "evidenceIds": [ "stripe-financial-connections-probe-5" ] }, { "productId": "stripe-financial-connections", "storyId": "agentic-public-api", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Stripe Financial Connections is documented via Stripe's broader public REST API and webhooks (account linking, balance/ownership/transaction refresh events, relink API), and Stripe provides an official MCP server for AI agents to interact with the Stripe API plus a documented CLI, which together support agent-driven use. However, evidence doesn't show Financial Connections-specific MCP tools or agent-native documentation beyond a generic 'Financial insights for agents' use-case mention, and no independent corroboration of agents successfully driving this specific product exists. Missing for 10: dedicated Financial Connections MCP tool documentation, hands-on/independent verification of agentic API usage for this product specifically, and full OpenAPI spec discoverability (404s found).", "evidenceIds": [ "stripe-financial-connections-docs-18", "stripe-financial-connections-docs-11", "stripe-financial-connections-docs-6", "stripe-financial-connections-probe-4", "stripe-financial-connections-probe-5", "stripe-financial-connections-probe-3", "stripe-financial-connections-docs-14" ] }, { "productId": "stripe-financial-connections", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers Financial Connections' bank-linking, data-access, and webhook features, plus a generic Stripe MCP server for agent API access, but nothing about issuing scoped or least-privilege API credentials/keys specifically for agents. No mention of restricted API keys, credential scoping, or permission granularity for agentic use is present.", "evidenceIds": [] }, { "productId": "stripe-financial-connections", "storyId": "agentic-sdks", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Stripe provides official SDKs and client integration methods (e.g., collectFinancialConnectionsAccounts) for Financial Connections, plus a documented official CLI and an official MCP server enabling AI agents to interact with Stripe APIs including this product, and docs explicitly mention 'Financial insights for agents' use cases. missing for 10: independent hands-on developer confirmation of building an AI-native agent integration specifically with Financial Connections via SDK/MCP, and no explicit SDK code samples in multiple languages shown in evidence.", "evidenceIds": [ "stripe-financial-connections-docs-6", "stripe-financial-connections-docs-11", "stripe-financial-connections-docs-18", "stripe-financial-connections-probe-4", "stripe-financial-connections-probe-5" ] }, { "productId": "stripe-financial-connections", "storyId": "agentic-webhooks", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Stripe Financial Connections documents specific webhook events (account linked, balance/ownership/transaction refresh completed) that any integrator, including AI-native agent backends, can subscribe to for event-driven workflows. This is standard first-party webhook documentation but lacks AI-specific framing or independent corroboration of agentic webhook consumption. Missing for 10: independent/hands-on confirmation of AI agents consuming these webhooks, and explicit agent-oriented event subscription guidance.", "evidenceIds": [ "stripe-financial-connections-docs-12", "stripe-financial-connections-docs-13", "stripe-financial-connections-docs-14", "stripe-financial-connections-docs-24", "stripe-financial-connections-docs-25" ] }, { "productId": "stripe-financial-connections", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack shows only text-based documentation pages (feature descriptions, webhooks list, testing docs) and confirms no OpenAPI spec was found at any candidate path (probe-3: all 404). There is no mention of an interactive API reference, live code runner, or runnable examples for Financial Connections specifically.", "evidenceIds": [ "stripe-financial-connections-probe-3", "stripe-financial-connections-docs-2" ] }, { "productId": "stripe-financial-connections", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "A direct probe for OpenAPI/swagger specs at expected doc paths returned 404 for all candidates, and no other evidence in the pack shows a downloadable machine-readable API spec for Financial Connections; only markdown docs (.md) and llms.txt are available, which are not an OpenAPI-equivalent spec.", "evidenceIds": [ "stripe-financial-connections-probe-3" ] }, { "productId": "stripe-financial-connections", "storyId": "api-sandbox", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Stripe documents a dedicated testing mode where the authentication flow shows only Stripe-managed test institutions and accounts can be linked without real credentials, explicitly separating sandbox testing from production data access. Missing for 10: no explicit mention of a fully isolated test API key/environment guarantee for financial data, no independent hands-on confirmation of sandbox fidelity, and no detail on how test data maps to production behavior.", "evidenceIds": [ "stripe-financial-connections-docs-15", "stripe-financial-connections-docs-26" ] }, { "productId": "stripe-financial-connections", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence pack items reference API versioning, version headers, or a documented deprecation policy for Stripe Financial Connections; only feature descriptions, webhooks, and community sentiment are present.", "evidenceIds": [] }, { "productId": "stripe-financial-connections", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of bulk/batch operations (e.g., batch account linking, bulk transaction pulls, multi-item API calls) for AI-native automation; the closest evidence is a webhook that emits one event per linked account, which is not a bulk-operation capability.", "evidenceIds": [ "stripe-financial-connections-docs-12" ] }, { "productId": "stripe-financial-connections", "storyId": "automation-rules-engine", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Financial Connections offers webhooks for events (account linked, balance refresh, etc.) but there is no evidence of a rules engine or automation layer where users can define conditional rules that trigger actions on those events—developers would need to build that logic themselves outside the product. missing for 10: rule-definition interface, conditional trigger-action mapping, any built-in automation/workflow engine.", "evidenceIds": [ "stripe-financial-connections-docs-12", "stripe-financial-connections-docs-13", "stripe-financial-connections-docs-24", "stripe-financial-connections-docs-25" ] }, { "productId": "stripe-financial-connections", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "stripe-financial-connections", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Financial Connections is a bank-data/account-linking API product, not an automation/workflow-builder tool; versioning, reviewing, and rolling back 'automations' is not a concept this product's category addresses.", "evidenceIds": [] }, { "productId": "stripe-financial-connections", "storyId": "connection-repair-relink", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Stripe documents a dedicated relink API to help reconnect an inactive/broken account, plus webhooks marking refresh completions (balance, ownership, transaction), implying some status tracking for account health. However, the pack lacks explicit documentation of distinct 'expired' vs 'revoked' status codes or a walkthrough showing the re-auth update flow preserving prior account context so users don't start over. missing for 10: explicit status enumeration for expired/revoked links, end-to-end UX documentation of the re-auth flow without data loss, and independent confirmation the relink flow works as described.", "evidenceIds": [ "stripe-financial-connections-docs-14", "stripe-financial-connections-docs-12", "stripe-financial-connections-docs-13", "stripe-financial-connections-docs-24", "stripe-financial-connections-docs-25" ] }, { "productId": "stripe-financial-connections", "storyId": "data-deletion-api", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence pack item documents a disconnect/delete-account API, data deletion/purge process, or account termination workflow for Financial Connections; the docs focus on connecting, collecting, and refreshing account data, not severing/purging it. Missing for 10: documented disconnect/delete API or account endpoint, data retention/purge policy, and any confirmation that collection stops and data is deleted upon disconnection.", "evidenceIds": [ "stripe-financial-connections-docs-12", "stripe-financial-connections-docs-14", "stripe-financial-connections-probe-2" ] }, { "productId": "stripe-financial-connections", "storyId": "hosted-link-flow", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Docs describe a server-side session (client_secret) that launches a hosted collectFinancialConnectionsAccounts widget with built-in institution selection across 12,000+ banks, returning connected account data and firing webhooks on link — exactly the drop-in flow described, and community reports confirm real-world adoption for ACH/fraud use cases (docs-6, docs-7, docs-12, comm-6). missing for 10: no explicit doc snippet naming a returned 'token' object schema, and no independent hands-on write-up specifically validating the create-session-then-widget code path (only high-level docs and general community sentiment).", "evidenceIds": [ "stripe-financial-connections-docs-6", "stripe-financial-connections-docs-7", "stripe-financial-connections-docs-12", "stripe-financial-connections-docs-15", "stripe-financial-connections-comm-6" ] }, { "productId": "stripe-financial-connections", "storyId": "income-cashflow-insights", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Financial Connections documents raw data access (balances, transactions, ownership) and encourages building 'fintech products with transactions data' or 'personal finance apps,' but there is no evidence of Stripe itself deriving income/cash-flow signals — no recurring-stream detection, payroll identification, or documented income-verification product built on this data. Community discussion also focuses on account linking reliability and pricing, not income analytics.", "evidenceIds": [ "stripe-financial-connections-docs-4", "stripe-financial-connections-docs-10", "stripe-financial-connections-docs-22" ] }, { "productId": "stripe-financial-connections", "storyId": "institution-coverage-breadth", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Stripe's docs publish a single coverage figure (\"more than 12,000 supported banks\") but no official breakdown of geographies or country-level coverage; the only geography signal comes from community reports that the product is US-only (and doesn't work for Canada or other countries), which isn't corroborated by first-party documentation. Missing for 10: official geographic coverage documentation, per-country institution counts, and any first-party statement matching the community's US-only observation.", "evidenceIds": [ "stripe-financial-connections-docs-7", "stripe-financial-connections-comm-9", "stripe-financial-connections-comm-11", "stripe-financial-connections-comm-12" ] }, { "productId": "stripe-financial-connections", "storyId": "institution-status-visibility", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Docs show webhook events for refresh completions (balance, ownership, transaction) and a relink API for inactive accounts, which provide some signal that an account/connection has degraded, but there is no documented institution status page, no outage/degradation signal feed, and no error-code taxonomy that distinguishes a bank-side problem from an integration-side problem. Missing for 10: institution health/status dashboard, explicit outage signals, and documented error codes separating bank vs. merchant-side failures.", "evidenceIds": [ "stripe-financial-connections-docs-13", "stripe-financial-connections-docs-14", "stripe-financial-connections-docs-24", "stripe-financial-connections-docs-25" ] }, { "productId": "stripe-financial-connections", "storyId": "multi-product-sessions", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Docs confirm one Financial Connections session/client_secret lets a user link an account and expose auth, balances, ownership/identity, and transactions data together (docs-1, docs-8/9/10, docs-2/3/4), and a community integrator confirms using the same link for verification, ACH fraud signal, and adjacent Stripe products (comm-6). missing for 10: no explicit first-party statement that all four data products are requested/returned in a single session without re-prompting the user, and one community report notes transactions/other data products were 'coming soon' at beta (comm-8), leaving some ambiguity about full simultaneous availability.", "evidenceIds": [ "stripe-financial-connections-docs-1", "stripe-financial-connections-docs-2", "stripe-financial-connections-docs-3", "stripe-financial-connections-docs-4", "stripe-financial-connections-docs-8", "stripe-financial-connections-docs-9", "stripe-financial-connections-docs-10", "stripe-financial-connections-comm-6", "stripe-financial-connections-comm-8" ] }, { "productId": "stripe-financial-connections", "storyId": "oauth-bank-connections", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "None of the docs mention OAuth explicitly, document which institutions use bank-hosted OAuth versus other methods, or describe retirement of legacy credential-based flows. In fact, community commentary indicates Stripe proxies to Plaid-like providers (i.e., non-OAuth/screen-scraping) for institutions lacking OAuth support, undermining the premise that connections are exclusively OAuth-based.", "evidenceIds": [ "stripe-financial-connections-comm-1", "stripe-financial-connections-docs-7", "stripe-financial-connections-docs-1" ] }, { "productId": "stripe-financial-connections", "storyId": "on-demand-refresh", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs mention webhook events fired after a balance, ownership, and transaction 'refresh' is complete (docs-13, docs-24, docs-25), implying an underlying refresh mechanism exists, but the evidence pack never documents the actual API call/endpoint to trigger an on-demand refresh or its semantics (rate limits, latency, cost). A community report even suggests refresh is limited to daily pulls rather than freely on-demand, indicating real constraints on freshness. Missing for 10: explicit API reference for a refresh endpoint, documented refresh-trigger semantics (frequency limits, sync latency), and confirmation this applies across balance/ownership/transaction data uniformly.", "evidenceIds": [ "stripe-financial-connections-docs-13", "stripe-financial-connections-docs-24", "stripe-financial-connections-docs-25", "stripe-financial-connections-comm-7" ] }, { "productId": "stripe-financial-connections", "storyId": "openness-api-parity", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Most Financial Connections operations (creating sessions, retrieving balances/ownership/transactions, webhooks, relink) are documented as pure server-side API calls, and Stripe also exposes an MCP server and CLI for agent-driven interaction with the API (docs-11, docs-18, probe-4, probe-5). However, the actual account-linking/authentication step inherently requires the client-side `collectFinancialConnectionsAccounts` hosted flow (docs-6, docs-7) — a consumer-facing UI that cannot be bypassed via pure API calls, so an AI-native user cannot complete the core linking action through API alone. Missing for 10: evidence of a pure-API path to complete bank authentication/consent without the client SDK, and confirmation that all Dashboard-configurable settings are also API-exposed.", "evidenceIds": [ "stripe-financial-connections-docs-6", "stripe-financial-connections-docs-7", "stripe-financial-connections-docs-11", "stripe-financial-connections-docs-18", "stripe-financial-connections-probe-4", "stripe-financial-connections-probe-5", "stripe-financial-connections-docs-12", "stripe-financial-connections-docs-14" ] }, { "productId": "stripe-financial-connections", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "stripe-financial-connections", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "stripe-financial-connections", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Financial Connections is a hosted SaaS API/service for accessing bank account data; self-hosting the core product is a category error for this type of managed cloud service, not an applicable axis.", "evidenceIds": [] }, { "productId": "stripe-financial-connections", "storyId": "pay-by-bank-initiation", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Financial Connections lets a linked bank account be used to collect ACH Direct Debit payments (docs-8, docs-16, docs-17, docs-27-29), which is a debit-based bank payment initiation flow, but this is not a full 'pay-by-bank' push-payment product, and there is no documented statement of live geographies — the only geography signal comes from community reports that it is US-only (comm-9, comm-11, comm-12), not honest first-party docs. Missing for 10: explicit documented geography/coverage list, and evidence of true push-payment (real-time transfer) initiation rather than just ACH debit collection.", "evidenceIds": [ "stripe-financial-connections-docs-8", "stripe-financial-connections-docs-16", "stripe-financial-connections-docs-17", "stripe-financial-connections-docs-27", "stripe-financial-connections-docs-28", "stripe-financial-connections-docs-29", "stripe-financial-connections-comm-9", "stripe-financial-connections-comm-11", "stripe-financial-connections-comm-12" ] }, { "productId": "stripe-financial-connections", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack mentions data residency, regional storage options, or user/customer choice of data location for Financial Connections; comments even note it's US-only, which suggests no regional selection capability. Missing for 10: any documentation of region/residency configuration, data localization options, or EU/other data center choices.", "evidenceIds": [ "stripe-financial-connections-comm-11", "stripe-financial-connections-comm-12" ] }, { "productId": "stripe-financial-connections", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Financial Connections is a financial account-data aggregation API/product, not an AI model or AI training platform; there is no axis in this product for controlling AI training data use. This story is a category error for this kind of product.", "evidenceIds": [] }, { "productId": "stripe-financial-connections", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses data retention controls, deletion APIs/mechanisms, or configurable data lifecycle policies for Financial Connections data; docs describe data access (balances, transactions, ownership) and webhooks but not retention/deletion controls for AI-native users. Missing for 10: any documentation of data retention settings, account/data deletion endpoints, or user-controlled data lifecycle management.", "evidenceIds": [] }, { "productId": "stripe-financial-connections", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Financial Connections is a financial data aggregation API/product, not an AI agent or developer tool with local telemetry collection that a user would opt out of; the axis of 'opting out of AI-native telemetry/usage tracking' is a category error for this kind of product.", "evidenceIds": [] }, { "productId": "stripe-financial-connections", "storyId": "processor-integrations", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe's docs describe explicit, well-documented integrations where Financial Connections hands verified bank-account data (balances, ownership, transactions) to other Stripe payment products—ACH Direct Debit collection, Connect payouts, and underwriting/fraud tooling—via a documented client_secret/token exchange flow and webhooks, and a Hacker News commenter confirms real-world production use for ACH verification and fraud signals alongside other Stripe products. missing for 10: evidence of handoff to non-Stripe third-party processors/platforms specifically, and independent security review of the credential-exchange mechanism.", "evidenceIds": [ "stripe-financial-connections-docs-6", "stripe-financial-connections-docs-8", "stripe-financial-connections-docs-9", "stripe-financial-connections-docs-16", "stripe-financial-connections-docs-12", "stripe-financial-connections-comm-6" ] }, { "productId": "stripe-financial-connections", "storyId": "quickstart-first-connection", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs show a testable sandbox flow (test institutions requiring no real credentials, client_secret-based auth via collectFinancialConnectionsAccounts) and an official CLI, indicating a runnable quickstart path to a first linked sandbox account. However, the pack lacks explicit evidence of self-serve API key issuance or language-specific client library listings for Financial Connections. missing for 10: explicit self-serve API key/dashboard signup evidence, explicit client library/SDK language coverage, and independent hands-on confirmation of quickstart speed.", "evidenceIds": [ "stripe-financial-connections-docs-15", "stripe-financial-connections-docs-6", "stripe-financial-connections-probe-5", "stripe-financial-connections-comm-8" ] }, { "productId": "stripe-financial-connections", "storyId": "realtime-balance-checks", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Docs explicitly state Financial Connections lets you 'Access an account's current and available balances' and 'reduce underwriting risk with balances data', with a dedicated balance-refresh webhook event, and community evidence confirms real customers use the linked-account data as a fraud/risk signal before ACH debits. This matches the NSF/risk-check use case described in the story. missing for 10: explicit API reference/endpoint schema for the balance object, and confirmation of real-time (vs refresh-triggered) latency guarantees.", "evidenceIds": [ "stripe-financial-connections-docs-2", "stripe-financial-connections-docs-8", "stripe-financial-connections-docs-13", "stripe-financial-connections-docs-20", "stripe-financial-connections-comm-6" ] }, { "productId": "stripe-financial-connections", "storyId": "recurring-variable-payments", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Financial Connections explicitly supports collecting a bank account for ACH Direct Debit payments (docs-8, docs-16, docs-17), and ACH Direct Debit mandates are inherently reusable for repeat debits, but the evidence never documents a specific recurring/subscription debit flow, standing consent, or variable recurring payment (VRP) mechanism built on top of the connection. Missing for 10: explicit documentation of mandate reuse for recurring charges, standing consent/authorization language, and any VRP-style flow or recurring-debit API guidance.", "evidenceIds": [ "stripe-financial-connections-docs-8", "stripe-financial-connections-docs-16", "stripe-financial-connections-docs-17", "stripe-financial-connections-comm-6" ] }, { "productId": "stripe-financial-connections", "storyId": "sandbox-test-institutions", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Docs explicitly describe a dedicated testing mode where the authentication flow shows only Stripe-managed test institutions that can be linked without credentials, enabling end-to-end exercise of the linking flow before touching real banks. However, evidence doesn't detail documented test credentials for specific error-state scenarios (e.g., forced failures, specific test account numbers for different data states) or confirm sandbox coverage of balances/transactions/ownership retrieval scenarios. Missing for 10: documented specific test credentials/account numbers for triggering distinct error states, and explicit confirmation that data retrieval (balances/transactions) can be exercised in test mode with corroborating independent developer accounts.", "evidenceIds": [ "stripe-financial-connections-docs-15", "stripe-financial-connections-docs-26" ] }, { "productId": "stripe-financial-connections", "storyId": "scoped-data-access", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs show Financial Connections lets you request specific data types (balances, ownership, transactions) rather than a single blanket account link, and different use-case flows (ACH, Connect payouts, personal finance apps) pull only the subset of data relevant to that use case, implying product-scoped consent. However, there's no explicit documentation of a formal 'permissions' parameter/API, no description of the actual consent screen showing scoped checkboxes, and no independent/community evidence confirming data-minimization behavior in practice. Missing for 10: explicit permissions/scopes API reference, documented consent UI mechanics, and independent verification that only requested scopes are granted.", "evidenceIds": [ "stripe-financial-connections-docs-2", "stripe-financial-connections-docs-3", "stripe-financial-connections-docs-4", "stripe-financial-connections-docs-8", "stripe-financial-connections-docs-9", "stripe-financial-connections-docs-10" ] }, { "productId": "stripe-financial-connections", "storyId": "transaction-enrichment", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The docs describe raw transaction history access (docs-4) but never mention any enrichment layer — no cleaned/normalized merchant names, spending categories, or merchant logos are documented anywhere in the evidence pack. Community threads even note the transactions product was still 'Coming Soon' at one point, with no follow-up confirming enrichment features shipped.", "evidenceIds": [ "stripe-financial-connections-docs-4", "stripe-financial-connections-docs-10", "stripe-financial-connections-comm-8" ] }, { "productId": "stripe-financial-connections", "storyId": "transactions-history-api", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs confirm access to an account's transaction history (docs-4) and a webhook-driven refresh model (transaction refresh completed events, docs-25) that lets a client know when to pull new data, and community evidence confirms documented depth/cadence limits (180 days history, daily pulls) as a real sync pattern. However, there is no explicit documentation in the pack of the transactions list endpoint's pagination parameters (cursor/starting_after) or a formal delta/sync-token mechanism for fetching only changed transactions. Missing for 10: explicit API pagination documentation for the transactions list endpoint, and a documented incremental-sync/cursor mechanism beyond the refresh webhook.", "evidenceIds": [ "stripe-financial-connections-docs-4", "stripe-financial-connections-docs-25", "stripe-financial-connections-docs-13", "stripe-financial-connections-comm-7" ] }, { "productId": "stripe-financial-connections", "storyId": "user-consent-management", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence describes an end-user-facing consent dashboard or portal where users can view/revoke which apps hold access to their linked bank data; documentation only covers merchant-side integration flows (linking, webhooks, relink API) and business-side account/balance/transaction access controls. This is a fair axis for a financial data aggregation product (competitors offer such portals), but Stripe's evidence pack contains no mention of a user-facing consent management surface.", "evidenceIds": [ "stripe-financial-connections-docs-6", "stripe-financial-connections-docs-12", "stripe-financial-connections-docs-14", "stripe-financial-connections-docs-23" ] }, { "productId": "stripe-financial-connections", "storyId": "webhook-data-events", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm signed webhook events for account linking, balance refresh, ownership refresh, and transaction refresh, directly enabling event-driven freshness instead of polling. However, evidence lacks detail on signature verification specifics, latency/timeliness guarantees, connection state-change events beyond relink, and independent/hands-on confirmation of webhook reliability. missing for 10: signature verification documentation detail, guaranteed latency/freshness SLAs, broader connection-state-change event coverage, independent developer corroboration of webhook reliability.", "evidenceIds": [ "stripe-financial-connections-docs-12", "stripe-financial-connections-docs-13", "stripe-financial-connections-docs-24", "stripe-financial-connections-docs-25", "stripe-financial-connections-docs-14" ] }, { "productId": "teller", "storyId": "account-numbers-for-ach", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Teller's docs describe an account-details endpoint providing verified account/routing numbers with instant verification for 7,000+ institutions, explicitly positioned to avoid microdeposits, with balances API used to confirm funds before ACH debit. However the same docs show a same-day microdeposit fallback is still required for institutions outside instant coverage, and there is no independent/hands-on confirmation of the instant-verification success rate or that routing numbers are tokenized rather than plaintext. missing for 10: independent corroboration of instant verification working in practice, clarity on tokenization vs raw account/routing number exposure, and confirmation that non-covered institutions aren't a common real-world limitation.", "evidenceIds": [ "teller-docs-6", "teller-docs-11", "teller-docs-22", "teller-docs-4" ] }, { "productId": "teller", "storyId": "account-ownership-data", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Teller's Identity API explicitly returns beneficial owner identity information for each authorized account, directly matching the story's need to retrieve account-holder names/identity data for owner matching (teller-docs-4, teller-docs-19), and the docs message frames account ownership verification as a core use case (teller-docs-1). Missing for 10: explicit confirmation that address/contact fields (not just legal name) are included in the Identity payload, and independent/hands-on corroboration beyond vendor docs.", "evidenceIds": [ "teller-docs-4", "teller-docs-19", "teller-docs-1" ] }, { "productId": "teller", "storyId": "agent-links-and-reads", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Teller's REST API supports the core primitives (balances, transactions, identity, connect/link sessions via Teller Connect, mTLS-scoped credentials) that an agent could call, but there is no evidence of an MCP server, agent-oriented SDK, or machine-readable API spec — probes for llms.txt, docs.md, and openapi.json all returned 404, indicating no first-class AI-agent integration surface. missing for 10: an MCP server or agent tool-calling interface, machine-readable OpenAPI/llms.txt discovery, and any documentation framing agent-driven scoped access.", "evidenceIds": [ "teller-docs-1", "teller-docs-2", "teller-docs-3", "teller-docs-12", "teller-probe-1", "teller-probe-2", "teller-probe-3" ] }, { "productId": "teller", "storyId": "agent-ready-financial-data", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Teller's docs describe a REST API with well-defined resources (balances, transactions, identity, payments) and some enrichment like transaction categorization, pagination, and idempotency, suggesting structured, documented data an app could parse programmatically. However, there is no evidence of a machine-readable schema (OpenAPI/swagger) or llms.txt for agent discovery—probes show all such endpoints 404—so an AI agent would have to rely on human-oriented docs rather than a formal schema. missing for 10: machine-readable OpenAPI/schema files, llms.txt or agent-specific docs, richer enrichment metadata (e.g., merchant/location tags) beyond basic categorization.", "evidenceIds": [ "teller-docs-2", "teller-docs-3", "teller-docs-4", "teller-docs-16", "teller-docs-20", "teller-docs-21", "teller-probe-1", "teller-probe-2", "teller-probe-3" ] }, { "productId": "teller", "storyId": "agentic-agent-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Probes directly show no llms.txt, no docs.md, and no OpenAPI file at expected locations (all 404), and no evidence of any agent-oriented documentation format elsewhere in the pack.", "evidenceIds": [ "teller-probe-1", "teller-probe-2", "teller-probe-3" ] }, { "productId": "teller", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "teller", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Teller offers webhooks that fire on enrollment/data changes, enabling event-driven background processing without polling, which is the closest analog to autonomous automation for this financial-data API. However there's no evidence of an AI-agent framework, scheduling/orchestration engine, or any AI-native automation tooling — webhooks are a generic API feature, not an agentic automation capability. Missing for 10: AI agent orchestration support, scheduled/recurring automation tooling, explicit AI-native automation framework or examples.", "evidenceIds": [ "teller-docs-7", "teller-docs-17" ] }, { "productId": "teller", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Teller is a banking-data/API infrastructure product (account linking, balances, transactions, payments) for developers to build financial applications, not an end-user product with a built-in AI assistant persona. This axis is a category error for this type of product.", "evidenceIds": [] }, { "productId": "teller", "storyId": "agentic-headless", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Teller is an API-first product (mTLS-authenticated REST API with a sandbox environment) that is inherently callable headlessly from scripts, and a community example shows a script consuming the API to export data. However there is no explicit documentation of CI integration, a CLI, or automation-specific guidance/examples for headless pipelines. Missing for 10: explicit CI/CD documentation, CLI or SDK examples for automated pipelines, and any first-party guidance on non-interactive/headless usage patterns.", "evidenceIds": [ "teller-docs-12", "teller-docs-8", "teller-docs-9", "teller-comm-1" ] }, { "productId": "teller", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Teller is a banking-data API/service, not an AI agent or coding assistant; the MCP-client story (plugging MCP servers into an agent) is a category error for this product type. No evidence discusses MCP integration at all.", "evidenceIds": [] }, { "productId": "teller", "storyId": "agentic-mcp-server", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "teller", "storyId": "agentic-nl-commands", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Teller is a banking-data API/SDK product with no evidence of a natural-language command interface, chatbot, or AI-native interaction layer; probes for llms.txt/docs.md/openapi also failed, and no docs mention NL commands or agent interfaces.", "evidenceIds": [ "teller-probe-1", "teller-probe-2", "teller-probe-3" ] }, { "productId": "teller", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of an official CLI for Teller; only a REST API, SDKs, and a React connect component are documented, and probes for llms.txt/openapi/docs.md all 404. Missing for 10: any mention of a CLI tool, package, or command-line workflow for AI-native/agentic use.", "evidenceIds": [ "teller-probe-1", "teller-probe-2", "teller-probe-3", "teller-gh-1" ] }, { "productId": "teller", "storyId": "agentic-public-api", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Teller documents a full REST API (accounts, balances, transactions, identity, payments, webhooks, mTLS auth, pagination, idempotency) that a developer or agent can drive programmatically, and a community member confirms it as an 'easy to use API' for scripting exports. However, probes show no OpenAPI/Swagger spec or llms.txt/docs.md machine-readable format, which limits easy AI-native discovery/automation of the API surface. missing for 10: OpenAPI/Swagger spec, llms.txt or docs.md for agent-friendly discovery, broader independent evidence of agentic/automated API usage beyond one CSV-export script.", "evidenceIds": [ "teller-docs-2", "teller-docs-3", "teller-docs-4", "teller-docs-5", "teller-docs-12", "teller-docs-20", "teller-docs-21", "teller-probe-1", "teller-probe-2", "teller-probe-3", "teller-comm-1" ] }, { "productId": "teller", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Teller's docs describe mTLS client-certificate authentication and per-enrollment user consent, but there is no evidence of any mechanism to mint scoped, least-privilege API credentials specifically for delegating access to an AI agent (e.g., granular permission scopes, agent-specific keys, or revocable sub-credentials). Missing for 10: any documentation of scoped/limited-permission credential issuance, agent-specific key management, or fine-grained access control beyond whole-enrollment consent.", "evidenceIds": [ "teller-docs-12", "teller-docs-15", "teller-docs-4", "teller-docs-19", "teller-docs-13" ] }, { "productId": "teller", "storyId": "agentic-sdks", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Teller provides an official REST API with documented endpoints and a first-party React SDK (teller-connect-react) for integrating Teller Connect, giving developers something concrete to build against. However, probes show no OpenAPI/swagger spec or llms.txt for machine-readable discovery, and there's no evidence of official SDKs beyond the single React component (e.g., no Python/Node/mobile SDKs), limiting AI-native tooling support. Missing for 10: multi-language official SDKs, machine-readable OpenAPI spec, llms.txt or other AI-agent-friendly documentation.", "evidenceIds": [ "teller-gh-1", "teller-docs-23", "teller-docs-12", "teller-probe-1", "teller-probe-2", "teller-probe-3" ] }, { "productId": "teller", "storyId": "agentic-webhooks", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Teller documents a webhooks API where users register a URL to receive events for enrollment/data changes, configurable via the Dashboard, covering the core subscribe-to-events capability. missing for 10: no documented event type catalog/payload schema, no independent/hands-on confirmation of webhook reliability, and no AI-agent-specific integration pattern beyond generic docs.", "evidenceIds": [ "teller-docs-7", "teller-docs-17" ] }, { "productId": "teller", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Teller has extensive markdown-based API documentation but no evidence of an interactive reference with runnable examples (e.g., Swagger/OpenAPI explorer). Probes for openapi.json/swagger.json all returned 404, and no docs mention a try-it-now console or code sandbox.", "evidenceIds": [ "teller-probe-3", "teller-docs-23" ] }, { "productId": "teller", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Probes for llms.txt, docs.md, and common OpenAPI/swagger paths all return 404, and no evidence pack item references a downloadable machine-readable spec; documentation is only in prose/markdown form.", "evidenceIds": [ "teller-probe-1", "teller-probe-2", "teller-probe-3" ] }, { "productId": "teller", "storyId": "api-sandbox", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Teller documents a dedicated sandbox environment using simulated data that never connects to real financial institutions, with defined test flows (e.g., OTP MFA with code 0000), letting developers test integrations without touching production data or real accounts. Missing for 10: independent/hands-on developer confirmation of sandbox fidelity and no mention of sandbox-specific rate limits or data reset options.", "evidenceIds": [ "teller-docs-8", "teller-docs-9", "teller-docs-13" ] }, { "productId": "teller", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of API versioning scheme or a documented deprecation policy anywhere in the docs pack; probes for llms.txt/openapi spec also failed, suggesting no machine-readable API contract either.", "evidenceIds": [ "teller-probe-1", "teller-probe-2", "teller-probe-3" ] }, { "productId": "teller", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Teller's docs describe per-item endpoints (single account balances, single transaction list with pagination, single payment with idempotency) but there is no evidence of any batch/bulk endpoint for operating across many accounts, transactions, or payments at once. Pagination controls exist for reading a transaction list, but that is not a bulk operation on multiple items simultaneously.", "evidenceIds": [ "teller-docs-21", "teller-docs-20", "teller-docs-5", "teller-docs-3" ] }, { "productId": "teller", "storyId": "automation-rules-engine", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Teller offers webhooks for event notifications (teller-docs-7, teller-docs-17), but there is no evidence of a rules engine or automation-configuration capability where users can define conditional actions triggered by events — webhook delivery only notifies an external app, it doesn't let a user define trigger-action rules within Teller itself. missing for 10: any rule/condition builder, action templates, or automation configuration UI/API beyond raw webhook event delivery.", "evidenceIds": [ "teller-docs-7", "teller-docs-17" ] }, { "productId": "teller", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "teller", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Teller is a financial data/payments API, not an automation or workflow tool; there is no concept of 'automations' to version, review, or roll back in this product's domain.", "evidenceIds": [] }, { "productId": "teller", "storyId": "connection-repair-relink", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence covers enrollment webhooks, MFA/OTP sandbox flows, and microdeposit verification, but nowhere documents a specific 'broken connection' status taxonomy or a re-authentication/update flow for expired or revoked links. Webhook docs mention 'changes in user enrollments' generically but don't detail reconnect/repair UX.", "evidenceIds": [ "teller-docs-7", "teller-docs-17", "teller-docs-9" ] }, { "productId": "teller", "storyId": "data-deletion-api", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack documents a deletion/disconnection flow, data purge process, or user/connection removal API — the docs focus on connecting, verifying, and retrieving financial data (balances, transactions, identity, payments) with no mention of offboarding or data deletion mechanics.", "evidenceIds": [] }, { "productId": "teller", "storyId": "hosted-link-flow", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Teller has a documented Connect widget (React SDK, teller-connect-react) and quickstart flow that lets users link accounts, plus a sandbox environment for testing enrollments and OTP flows, matching the drop-in hosted-flow story. However, evidence lacks explicit detail on server-side session creation and the exact token exchange flow, and no independent hands-on account of the widget UX beyond first-party docs. missing for 10: explicit session-creation API docs, independent/hands-on verification of the widget flow, and detail on token retrieval mechanics.", "evidenceIds": [ "teller-docs-23", "teller-docs-14", "teller-gh-1", "teller-docs-9", "teller-docs-8", "teller-docs-11" ] }, { "productId": "teller", "storyId": "income-cashflow-insights", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Teller's docs cover balances, transactions, categorization, and identity, but no evidence describes recurring-stream detection, payroll detection, or an income-verification product built on the transaction data — this is a fair axis for an account-aggregation platform but unaddressed in the evidence pack.", "evidenceIds": [] }, { "productId": "teller", "storyId": "institution-coverage-breadth", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Teller publishes a single aggregate figure (\"more than 7,000 financial institutions\") but no breakdown by geography, no searchable list of supported institutions, and no way for a founder to verify coverage against their specific user base. The old community thread references only a handful of UK banks, but this appears to be from an earlier version of the product and is not directly comparable to the current 7,000+ claim. missing for 10: geographic breakdown, institution-name list/coverage tool, independent verification of the 7,000 figure.", "evidenceIds": [ "teller-docs-11", "teller-comm-2" ] }, { "productId": "teller", "storyId": "institution-status-visibility", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of a status page, per-institution outage/degradation signals, or documented error codes distinguishing bank-side failures from client-side errors. Webhooks are mentioned for enrollment/data change events, but nothing ties to institution health visibility or error taxonomy.", "evidenceIds": [] }, { "productId": "teller", "storyId": "multi-product-sessions", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Teller's architecture centers on a single enrollment/access-token granted via one Connect flow, which then powers balances, transactions, identity, and account-details APIs (teller-docs-1, teller-docs-4/19 note identity covers 'all accounts the end-user granted access authorization', teller-docs-13 defines an enrollment as one bank login with multiple accounts). This implies a single link session unlocks multiple data products without repeated connect flows.\nmissing for 10: an explicit statement confirming no re-authentication is needed per product, and independent/hands-on developer corroboration of this multi-product single-session behavior.", "evidenceIds": [ "teller-docs-1", "teller-docs-4", "teller-docs-19", "teller-docs-13", "teller-docs-2", "teller-docs-3" ] }, { "productId": "teller", "storyId": "oauth-bank-connections", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Teller's docs describe connecting via 'Verify Account Details via Microdeposit' and general account-linking language, but nowhere document OAuth coverage of major institutions or a retirement plan for legacy credential-based flows. Community evidence actually points the other way — the founder compares Teller's terms to 'incumbent screen-scrapers in the market, e.g. Yodlee and Plaid,' and users note banks disclaim liability 'if you give your online banking credentials to a third party,' indicating credential-based (not bank-hosted OAuth) connections were in use historically.", "evidenceIds": [ "teller-comm-4", "teller-comm-8", "teller-docs-6", "teller-docs-11" ] }, { "productId": "teller", "storyId": "on-demand-refresh", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Teller's balances API is documented as returning \"live, real-time account balances\" (teller-docs-2, teller-docs-22), implying each API call effectively refreshes data on demand, and webhooks fire on data changes (teller-docs-7, teller-docs-17). However, there is no dedicated refresh/sync endpoint, no documented semantics for how or when transaction data is refreshed, and no explanation of caching or refresh triggers for the transactions API — missing for 10: a documented refresh endpoint/mechanism, explicit refresh semantics (latency, staleness window), and confirmation for transactions data (not just balances).", "evidenceIds": [ "teller-docs-2", "teller-docs-22", "teller-docs-7", "teller-docs-17", "teller-docs-3" ] }, { "productId": "teller", "storyId": "openness-api-parity", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Teller exposes rich API endpoints for balances, transactions, identity, payments, and account details (teller-docs-2,3,4,5,6), suggesting most financial data operations are API-driven, but account linking is done through the Teller Connect UI widget and webhook registration is explicitly described as being configured 'from the Teller Dashboard' rather than via an API endpoint (teller-docs-7), indicating some UI-only actions lack documented API equivalents. Missing for 10: an API endpoint for webhook/enrollment management equivalent to Dashboard actions, explicit documentation confirming full API/UI parity, and independent confirmation of no UI-exclusive features.", "evidenceIds": [ "teller-docs-2", "teller-docs-3", "teller-docs-4", "teller-docs-5", "teller-docs-6", "teller-docs-7", "teller-docs-23" ] }, { "productId": "teller", "storyId": "openness-full-export", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Teller exposes account balances/transactions/identity via JSON API (open format), and a community member built a third-party script exporting Teller data to CSV/QIF, showing data can be extracted. However there is no first-party 'export all my data and leave' feature, no bulk data-export or account-deletion tooling, and no documentation of full data portability for end users. Missing for 10: official bulk export/download-all-data feature, documented account closure/data portability process, and independent confirmation beyond one hobbyist script.", "evidenceIds": [ "teller-comm-1", "teller-docs-2", "teller-docs-3", "teller-docs-19" ] }, { "productId": "teller", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Teller is a closed, proprietary financial API/service; the only open-source artifact found is a client-side React SDK wrapper (teller-connect-react), not the product's core source. A community comment explicitly wishes Teller were open source, implying it is not, and no license or source-availability claims appear in vendor docs.", "evidenceIds": [ "teller-gh-1", "teller-comm-11" ] }, { "productId": "teller", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Teller is a hosted financial data/banking API SaaS with a managed mTLS-secured cloud API and dashboard; self-hosting the core product is a category error for this kind of managed financial-connectivity service — no self-host mode is architecturally plausible or referenced.", "evidenceIds": [] }, { "productId": "teller", "storyId": "pay-by-bank-initiation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Teller docs confirm a payments API that lets a developer send a payment from a connected account to self or a third party, with idempotency support (teller-docs-5, teller-docs-18, teller-docs-20), and separately state broad institution coverage (7,000+ US institutions) for account connectivity (teller-docs-11). However, the payments API explicitly supports only the Zelle scheme currently, not general ACH/bank-transfer payment initiation, and there is no explicit geography statement scoped to the payments product itself (vs. the broader account-linking coverage claim). Missing for 10: multi-rail payment initiation beyond Zelle, an explicit payments-specific geography/eligibility statement, and independent/hands-on confirmation that payment initiation works live in production.", "evidenceIds": [ "teller-docs-5", "teller-docs-18", "teller-docs-20", "teller-docs-11", "teller-docs-13" ] }, { "productId": "teller", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence of any data residency/region selection controls in Teller's docs or community discussion; the pack covers account linking, payments, mTLS auth, and webhooks but nothing about data storage location choice.", "evidenceIds": [] }, { "productId": "teller", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Teller is a financial account aggregation/banking API product, not an AI model or AI-native content/data platform; the story about preventing data from being used to train AI models is an axis that applies to AI tools/assistants, not to a fintech data API. No evidence suggests Teller trains AI models on user data or offers AI opt-out controls, so this axis is a category mismatch.", "evidenceIds": [] }, { "productId": "teller", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence anywhere in the pack addresses data retention policies, deletion controls, or data lifecycle management for end-user financial data; docs cover connectivity, API resources, auth, and webhooks but nothing on retention/deletion controls.", "evidenceIds": [] }, { "productId": "teller", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Teller is a financial data/banking API product, not an AI developer tool or CLI/agent with telemetry collection concerns; the evidence pack contains no mention of any telemetry or usage tracking mechanism at all, and this axis is a category error for this kind of product.", "evidenceIds": [] }, { "productId": "teller", "storyId": "processor-integrations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Teller's docs describe its own Payments resource (Zelle transfers) and Identity/Balances APIs, but there is no documented processor-token exchange or integration flow that hands verified account credentials to third-party payment processors/platforms (e.g., a Stripe/Dwolla-style processor token). Community threads even confirm Teller does not enable moving money to arbitrary third parties beyond its own Zelle feature.", "evidenceIds": [ "teller-docs-5", "teller-docs-18", "teller-comm-4" ] }, { "productId": "teller", "storyId": "quickstart-first-connection", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs confirm a quickstart guide that ends with linking a first sandbox account, a dedicated sandbox environment with simulated data and OTP test flows, and at least one client library (React hook/component) for Teller Connect. However, authentication requires mTLS with client certificates rather than a simple self-serve API key (raising integration friction), and there's no evidence of client libraries beyond React or of a fast self-serve signup process for keys/certs. Missing for 10: explicit self-serve API-key/signup flow, additional-language client libraries (Node/Python/etc.), independent hands-on confirmation of speed from quickstart to first linked sandbox account.", "evidenceIds": [ "teller-docs-14", "teller-docs-8", "teller-docs-9", "teller-docs-12", "teller-gh-1" ] }, { "productId": "teller", "storyId": "realtime-balance-checks", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Teller's docs explicitly provide a dedicated real-time balances API endpoint, and marketing/docs copy directly frames it for underwriting/NSF risk checks before submitting an ACH debit, matching the story precisely. Missing for 10: no independent/hands-on developer confirmation of the balance endpoint's real-time accuracy or latency in production.", "evidenceIds": [ "teller-docs-2", "teller-docs-22", "teller-docs-1" ] }, { "productId": "teller", "storyId": "recurring-variable-payments", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Teller's payments resource only supports Zelle-based payments to self or third parties; there is no mention of variable recurring payments, standing consents, or documented recurring debit flows.", "evidenceIds": [ "teller-docs-5", "teller-docs-18", "teller-docs-20" ] }, { "productId": "teller", "storyId": "sandbox-test-institutions", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Docs confirm a sandbox environment with simulated data that never touches real institutions, plus documented test credentials/flows (e.g., OTP MFA code '0000'), and full documented APIs for linking, balances, transactions, identity, and payments that can be exercised in sandbox. Missing for 10: independent/hands-on developer accounts specifically validating the sandbox test-credential workflow and documented error-state simulation beyond MFA.", "evidenceIds": [ "teller-docs-8", "teller-docs-9", "teller-docs-2", "teller-docs-3", "teller-docs-13" ] }, { "productId": "teller", "storyId": "scoped-data-access", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence describes separate API resources (balances, transactions, identity, payments) but there is no documentation of a consent flow where developers can request only specific scopes or where end-users see a product-scoped grant rather than an all-or-nothing authorization. No mention of a 'products' parameter, granular permission toggles, or data-minimization consent screen in Teller Connect.", "evidenceIds": [ "teller-docs-1", "teller-docs-4", "teller-docs-19", "teller-docs-23" ] }, { "productId": "teller", "storyId": "transaction-enrichment", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Docs confirm the transactions API includes categorization of transactions (teller-docs-16, teller-docs-3), but there is no documented evidence of merchant name cleaning/normalization or merchant logos as a platform capability. missing for 10: documented merchant-name cleaning, logo enrichment, independent corroboration of enrichment quality.", "evidenceIds": [ "teller-docs-16", "teller-docs-3" ] }, { "productId": "teller", "storyId": "transactions-history-api", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm a transactions API with pagination support and category enrichment, plus webhooks that fire on data changes (a plausible 'fetch only what changed' mechanism), and a community report of successfully exporting transaction history via the API. However, there's no documented statement of how far back transaction history extends, and no explicit incremental-sync/cursor endpoint beyond generic webhook notifications. Missing for 10: documented history depth/lookback window, an explicit delta-sync or cursor-based endpoint (not just webhooks) for changed transactions.", "evidenceIds": [ "teller-docs-3", "teller-docs-21", "teller-docs-16", "teller-docs-17", "teller-docs-7", "teller-comm-1" ] }, { "productId": "teller", "storyId": "user-consent-management", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of an end-user consent dashboard or portal where users can view or revoke third-party app access to their bank data; docs cover enrollment, data APIs, webhooks, and auth but nothing about consent management/revocation UI. Missing for 10: a documented end-user consent portal, revocation flow/API, and any independent confirmation of such a surface.", "evidenceIds": [ "teller-docs-14", "teller-docs-13", "teller-docs-23" ] }, { "productId": "teller", "storyId": "webhook-data-events", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Teller docs confirm webhook events exist for enrollment/data changes (teller-docs-17) and describe how to register a webhook URL (teller-docs-7), covering the general 'push not poll' data-freshness goal. However, the evidence pack contains no mention of webhook payload signing/verification mechanism, nor independent confirmation that webhooks reliably fire for transactions, balances, and connection-state changes as described. Missing for 10: explicit signature/verification scheme for webhooks, documented list of event types (transaction created, balance updated, enrollment disconnected), and third-party/hands-on confirmation of webhook delivery reliability.", "evidenceIds": [ "teller-docs-7", "teller-docs-17" ] }, { "productId": "truelayer", "storyId": "account-numbers-for-ach", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "TrueLayer's documented Payments/Verification/Data APIs operate on UK/EU account identifiers (sort code/account number, IBAN, Direct Debit, Faster Payments, VRPs) and provide identity/name verification, not US-style ACH funding via account/routing numbers or tokenized ACH equivalents. No evidence pack item references ACH, routing numbers, or micro-deposit-free bank-debit tokenization.", "evidenceIds": [ "truelayer-docs-3", "truelayer-docs-8", "truelayer-docs-29", "truelayer-docs-30", "truelayer-docs-6" ] }, { "productId": "truelayer", "storyId": "account-ownership-data", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "TrueLayer's Data API exposes 'identity' data alongside accounts/transactions/balances, and its Verification API explicitly compares identity data (name) against connected account holders — supporting name-based ownership matching. However, the evidence never confirms retrieval of addresses or contact details on file at the bank, only name matching. Missing for 10: explicit documentation of address/contact fields returned by the identity endpoint, and any hands-on confirmation of full account-holder profile retrieval.", "evidenceIds": [ "truelayer-docs-28", "truelayer-docs-29" ] }, { "productId": "truelayer", "storyId": "agent-links-and-reads", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "TrueLayer ships an official MCP server for Claude AI (truelayer-docs-17, probe-3) with at least a documented `create-truelayer-payment-link` tool (truelayer-docs-27), and its APIs separately support account/balance/transaction retrieval (truelayer-docs-5, truelayer-docs-28) and connection management with scoped client credentials and ECDSA-signed requests (truelayer-docs-12, truelayer-docs-21). However, the MCP surface itself is only shown to expose link-session creation, not balance/transaction retrieval or connection management as MCP tools. Missing for 10: explicit MCP tools/endpoints for balance/transaction retrieval and connection management, and documentation of MCP-specific scoped credentials rather than general API auth.", "evidenceIds": [ "truelayer-docs-17", "truelayer-docs-27", "truelayer-docs-5", "truelayer-docs-28", "truelayer-docs-12", "truelayer-docs-21", "truelayer-probe-3" ] }, { "productId": "truelayer", "storyId": "agent-ready-financial-data", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "TrueLayer's Data API returns structured JSON (identity, accounts, transactions, balances) with a dedicated MCP server letting an AI assistant like Claude perform banking operations directly, and typed SDKs abstract the raw API surface — all strong signals of agent-consumable design. However, a probe found no discoverable OpenAPI/JSON schema (all candidate schema paths 404'd), and no evidence describes transaction enrichment (categorization, merchant normalization) that would let an agent reason without heuristic parsing. Missing for 10: published machine-readable schema/OpenAPI spec, documented data enrichment/categorization features, independent corroboration of agent consumption in practice.", "evidenceIds": [ "truelayer-docs-28", "truelayer-docs-14", "truelayer-docs-11", "truelayer-docs-24", "truelayer-docs-17", "truelayer-docs-27", "truelayer-probe-3", "truelayer-probe-2" ] }, { "productId": "truelayer", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "TrueLayer hosts a verified llms.txt at docs.truelayer.com/llms.txt (probe confirms HTTP 200) with a documented convention that any docs page can be appended with .md for markdown, directly enabling agent-oriented consumption; docs also explicitly cover an MCP integration for AI assistants, reinforcing agent-native design. Missing for 10: no independent third-party confirmation that agents reliably use this in practice beyond TrueLayer's own docs.", "evidenceIds": [ "truelayer-probe-1", "truelayer-docs-19", "truelayer-docs-17", "truelayer-probe-3" ] }, { "productId": "truelayer", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "TrueLayer's evidence covers Data/Payments APIs and an MCP integration letting Claude perform banking actions on a user's behalf, but nothing shows TrueLayer itself generating AI insights or suggestions from account/transaction data inside its Console or product surface.", "evidenceIds": [] }, { "productId": "truelayer", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "TrueLayer supports payment mandates (VRPs/Direct Debits) that, once authorised, execute automatically in the background without further user authorisation, and webhooks provide event-driven automation; the MCP server integration also lets an AI agent (Claude) trigger banking/payment operations. However, there is no dedicated AI-native automation/scheduling framework—just mandate-based recurring payments plus generic webhooks and a single third-party MCP integration. Missing for 10: a first-party AI-agent automation/orchestration feature, evidence of persistent autonomous background agents beyond mandate execution, and broader multi-step automation tooling.", "evidenceIds": [ "truelayer-docs-15", "truelayer-docs-16", "truelayer-docs-30", "truelayer-docs-31", "truelayer-docs-33", "truelayer-docs-17", "truelayer-docs-27", "truelayer-probe-3" ] }, { "productId": "truelayer", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "TrueLayer is a payments/banking API platform, not a product with a built-in AI assistant UI; its AI-related evidence is an MCP server for integrating with external assistants like Claude, not a delegated in-product assistant. This is a category mismatch, not a missing feature.", "evidenceIds": [] }, { "productId": "truelayer", "storyId": "agentic-headless", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "TrueLayer is API-first with SDKs (Node.js, Python, Java, .NET) and signing libraries, which are inherently usable in headless/automated/CI contexts since there is no GUI dependency for core payment/data operations. However, there is no explicit documentation about CI/CD integration, automated testing pipelines, or headless deployment guidance. Missing for 10: explicit CI/automation documentation, example CI pipeline configs, headless testing guidance, non-interactive auth flow docs for automated environments.", "evidenceIds": [ "truelayer-docs-11", "truelayer-docs-24", "truelayer-gh-1", "truelayer-docs-1" ] }, { "productId": "truelayer", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "TrueLayer is a payments/banking API platform, not an AI agent or assistant that itself consumes tools via MCP; the evidence shows the opposite relationship — TrueLayer ships an MCP *server* so that AI assistants like Claude can call TrueLayer's payment tools, not a mechanism for TrueLayer to plug in and use other MCP servers' tools.", "evidenceIds": [ "truelayer-docs-17", "truelayer-docs-27", "truelayer-probe-3" ] }, { "productId": "truelayer", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "TrueLayer documents an official MCP server integration for Claude AI, exposing at least one concrete tool (create-truelayer-payment-link) that lets an agent perform banking/payment operations, and a probe confirms the doc page exists. Missing for 10: broader tool catalog beyond payment-link creation, independent/hands-on verification of the MCP server working, and details on setup/auth for non-Claude MCP clients.", "evidenceIds": [ "truelayer-docs-17", "truelayer-docs-27", "truelayer-probe-3" ] }, { "productId": "truelayer", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "TrueLayer documents an official MCP server integration with Claude AI that lets users invoke banking/payment operations (e.g., 'create-truelayer-payment-link') via natural language, directly enabling AI-native NL command usage. However, evidence only shows one example tool and a single AI assistant integration rather than a broad natural-language command surface across the full API. Missing for 10: evidence of broader NL command coverage across accounts/verification/mandates, independent hands-on confirmation of the MCP server's reliability, and support beyond Claude AI.", "evidenceIds": [ "truelayer-docs-17", "truelayer-docs-27", "truelayer-probe-3" ] }, { "productId": "truelayer", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "TrueLayer is a payments/banking API platform with SDKs, an MCP server for Claude, and signing libraries, but no evidence anywhere in the pack of an official CLI tool for developers or AI-native workflows.", "evidenceIds": [] }, { "productId": "truelayer", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "TrueLayer publishes extensive public API documentation covering Payments API v3, Data API, Verification API, webhooks, signing, and SDKs for Node.js/Python/Java/.NET, with a quickstart for making a test payment — clear evidence of a documented, programmatically drivable API for an AI-native or any developer user. Missing for 10: a discoverable machine-readable OpenAPI/Swagger spec (probe found only 404s), so full API surface must be inferred from prose docs rather than a formal schema.", "evidenceIds": [ "truelayer-docs-1", "truelayer-docs-5", "truelayer-docs-11", "truelayer-docs-12", "truelayer-docs-24", "truelayer-docs-32", "truelayer-probe-1", "truelayer-probe-2" ] }, { "productId": "truelayer", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "TrueLayer's docs describe standard API client credentials, OAuth-style bearer tokens plus ECDSA signing, and an MCP integration for Claude, but nothing describes issuing scoped or least-privilege credentials specifically for an AI agent (e.g., agent-specific API keys, granular permission tiers, or restricted scopes for automated/agentic use). Missing for 10: any mention of agent-specific credential scoping, permission tiers, or least-privilege key issuance beyond generic client_id/secret and bearer tokens.", "evidenceIds": [ "truelayer-docs-21", "truelayer-docs-12", "truelayer-docs-17", "truelayer-docs-27" ] }, { "productId": "truelayer", "storyId": "agentic-sdks", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "TrueLayer explicitly documents official SDKs for Node.js, Python, Java and .NET (truelayer-docs-11) that simplify API calls with typed interfaces and automate request signing (truelayer-docs-24), backed by a public GitHub signing library (truelayer-gh-1). Missing for 10: broader language coverage evidence, independent developer adoption signals (stars, community usage), and versioned changelog/release cadence proof.", "evidenceIds": [ "truelayer-docs-11", "truelayer-docs-24", "truelayer-docs-26", "truelayer-gh-1" ] }, { "productId": "truelayer", "storyId": "agentic-webhooks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "TrueLayer documents webhooks as JSON notifications for Payments API v3 events (e.g. payment status changes), configurable per-app via a webhook URI in Console, with signature verification (Tl-Signature) recommended via signing libraries. This gives a clear, documented subscribe-to-events-via-webhook mechanism usable programmatically by an AI-native integration. Missing for 10: no independent/hands-on corroboration of webhook reliability, and no evidence of webhook management via API (vs Console-only configuration) or filtering/subscription granularity.", "evidenceIds": [ "truelayer-docs-14", "truelayer-docs-33", "truelayer-docs-34", "truelayer-docs-35", "truelayer-docs-13" ] }, { "productId": "truelayer", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains only static documentation descriptions (guides, webhook references, SDK mentions) with no mention of an interactive API reference or runnable code examples/try-it-out console. A direct probe for OpenAPI/Swagger specs at standard paths returned 404 across all candidates, indicating no discoverable interactive API explorer.", "evidenceIds": [ "truelayer-probe-2", "truelayer-docs-11", "truelayer-probe-1" ] }, { "productId": "truelayer", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "A direct probe for OpenAPI/Swagger spec files at common paths (openapi.json, swagger.json, etc.) returned 404 across the board, and no documentation item references a downloadable machine-readable API spec despite extensive API docs.", "evidenceIds": [ "truelayer-probe-2" ] }, { "productId": "truelayer", "storyId": "api-sandbox", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "TrueLayer provides a free test/sandbox merchant account for making test payments (truelayer-docs-32, quickstart-make-a-test-payment), which lets a developer or AI agent exercise the Payments API without touching production data. However, there is no explicit documentation of a dedicated sandbox environment concept (separate sandbox base URLs, sandbox-specific credentials, or sandbox banks/test providers) distinct from a 'free account' used for a first test payment, and no confirmation the MCP integration itself can be pointed at a sandbox. Missing for 10: explicit sandbox environment documentation (test-mode endpoints, mock bank providers), confirmation that the MCP server/agent tooling can target sandbox vs production, and independent/hands-on verification of sandbox isolation.", "evidenceIds": [ "truelayer-docs-32", "truelayer-docs-17", "truelayer-probe-3" ] }, { "productId": "truelayer", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence confirms TrueLayer exposes a versioned API (Payments API v3) but nowhere documents a deprecation policy, versioning changelog, or sunset schedule for older API versions. Missing for 10: any versioning/deprecation policy page, changelog, migration guide, or sunset timeline evidence.", "evidenceIds": [ "truelayer-docs-1", "truelayer-docs-12", "truelayer-probe-2" ] }, { "productId": "truelayer", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers single-payment, single-payout, and single-mandate creation flows, webhooks, and MCP tool for one-off payment links, but no documentation of any batch/bulk endpoint for processing many payments, payouts, or accounts in one call. Missing for 10: batch payment/payout creation endpoints, bulk data export or bulk verification APIs, any documented rate/volume-oriented bulk operation.", "evidenceIds": [ "truelayer-docs-1", "truelayer-docs-2", "truelayer-docs-8", "truelayer-docs-15", "truelayer-docs-27" ] }, { "productId": "truelayer", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "TrueLayer provides webhooks that notify external systems on payment status events, and payment mandates that execute automatically once authorised (e.g. VRPs, Direct Debits), giving building blocks for event-driven automation. However, there is no evidence of a native rules-engine or condition/action configuration UI where a user defines arbitrary 'if event X then do Y' automations within TrueLayer itself — the actual rule logic must be built by the developer's own system consuming the webhook. Missing for 10: a documented rules/automation engine, in-product trigger-action configuration, and any first-party or independent example of user-defined automation rules beyond webhooks and fixed mandate execution.", "evidenceIds": [ "truelayer-docs-14", "truelayer-docs-33", "truelayer-docs-15", "truelayer-docs-16", "truelayer-docs-30", "truelayer-docs-35" ] }, { "productId": "truelayer", "storyId": "automation-scheduled-jobs", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "TrueLayer supports payment mandates (VRPs) that, once authorised, let a payment execute automatically and repeatedly without further user authorisation — a domain-specific form of recurring workflow (docs-15, docs-16, docs-30, docs-31). However there is no evidence of a general-purpose scheduler, cron-like triggers, or workflow orchestration beyond recurring payments themselves. missing for 10: general job/workflow scheduling primitives, evidence of scheduling cadence configuration (daily/weekly/custom), and any non-payment automation use case.", "evidenceIds": [ "truelayer-docs-15", "truelayer-docs-16", "truelayer-docs-30", "truelayer-docs-31" ] }, { "productId": "truelayer", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "TrueLayer is a payments/banking API platform, not an automation-building tool with a workflow/version history concept; versioning, review, and rollback of 'automations' is a category error for this product type.", "evidenceIds": [] }, { "productId": "truelayer", "storyId": "connection-repair-relink", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "TrueLayer's docs cover consent, mandates, and webhooks for payment status but nowhere document how expired/revoked account-links surface as distinct statuses or how a user re-authenticates via an update flow without restarting; the evidence pack has no reference to reconnection/re-auth UX for broken links.", "evidenceIds": [] }, { "productId": "truelayer", "storyId": "data-deletion-api", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence pack item documents a way to delete a connection/user, revoke consent, stop data collection, or purge held data; documentation covers payments, mandates, webhooks, and MCP integration but nothing about consent revocation or data deletion/erasure workflows.", "evidenceIds": [] }, { "productId": "truelayer", "storyId": "hosted-link-flow", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack describes TrueLayer's Data API for reading account/identity/transaction info and lists supported providers, but nowhere documents a drop-in hosted widget with a server-side session creation and token retrieval flow for account-linking (the closest analog, 'payment links', applies only to payments, not data/account linking). Missing for 10: hosted account-linking widget SDK/UI docs, session-creation endpoint for linking, and evidence of a returned account-link token from a widget flow.", "evidenceIds": [ "truelayer-docs-28", "truelayer-docs-5", "truelayer-docs-10" ] }, { "productId": "truelayer", "storyId": "income-cashflow-insights", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "TrueLayer's Data API covers identity, accounts, balances and raw transaction history, but no evidence describes derived income/cash-flow signals such as recurring stream detection, payroll detection, or a dedicated income verification product built on the data.", "evidenceIds": [ "truelayer-docs-5", "truelayer-docs-28", "truelayer-docs-29" ] }, { "productId": "truelayer", "storyId": "institution-coverage-breadth", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs state payments coverage spans UK and EU and provide a providers endpoint to query which banks are supported per country/segment, giving founders a way to check coverage against their user base. However, there's no published aggregate coverage numbers (e.g., total institutions reached) or a static geography breakdown document — only an API-based lookup. Missing for 10: published institution-count statistics, a documented list/table of supported countries and bank counts, and independent verification of coverage claims.", "evidenceIds": [ "truelayer-docs-1", "truelayer-docs-10" ] }, { "productId": "truelayer", "storyId": "institution-status-visibility", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows a providers endpoint for bank coverage/support by country (truelayer-docs-10) and generic webhook status events (truelayer-docs-33), but nothing documents per-institution health status, outage/degradation signals, or error codes that distinguish a bank-side failure from an integration-side one — missing for 10: institution status page/API, outage/degradation indicators, and error taxonomy separating bank vs merchant faults.", "evidenceIds": [ "truelayer-docs-10", "truelayer-docs-33" ] }, { "productId": "truelayer", "storyId": "multi-product-sessions", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "TrueLayer's Data API docs describe a single interface that covers identity, accounts, transactions and balance data across all integrated banks, implying one connection can serve multiple data products rather than separate flows per product ([truelayer-docs-28], [truelayer-docs-5]). Missing for 10: explicit description of the underlying consent/session mechanics (e.g., how one auth link's token scopes map to multiple product calls without re-prompting the user) and independent/hands-on confirmation that no re-authentication is required per product.", "evidenceIds": [ "truelayer-docs-28", "truelayer-docs-5", "truelayer-docs-3", "truelayer-docs-29" ] }, { "productId": "truelayer", "storyId": "oauth-bank-connections", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers TrueLayer's Payments, Data, and Verification APIs, SDKs, and a providers endpoint listing supported banks per country, but nothing explicitly documents that connections use bank-hosted OAuth versus screen-scraping, nor any statement about retiring legacy credential-based flows. Without that specific documentation, this axis is unsupported.", "evidenceIds": [ "truelayer-docs-10", "truelayer-docs-28" ] }, { "productId": "truelayer", "storyId": "on-demand-refresh", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack documents TrueLayer's Data API for reading account info, balances, and transactions, but contains no mention of an explicit on-demand refresh endpoint or documented refresh semantics (e.g., cache TTLs, force-refresh parameters, or freshness guarantees). This is a fair axis for an open banking data API, but no supporting evidence exists.", "evidenceIds": [ "truelayer-docs-5", "truelayer-docs-28" ] }, { "productId": "truelayer", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "TrueLayer is API-first: payments, payouts, mandates, data/account access, verification, webhooks and signing are all exposed as core API operations with SDKs, and Console (the UI) appears to largely mirror these merchant operations. However, some Console-only functions (inviting team users, MFA setup, account management, monitoring/reporting dashboards) are described as UI actions with no evidence of an equivalent API/endpoint, and no OpenAPI spec is discoverable (probe 404s), making full programmatic parity unverifiable. missing for 10: API-equivalents for Console user/team management and MFA setup, a public OpenAPI/schema confirming full endpoint parity, and independent confirmation that all UI actions have API counterparts.", "evidenceIds": [ "truelayer-docs-1", "truelayer-docs-19", "truelayer-docs-20", "truelayer-docs-21", "truelayer-docs-22", "truelayer-probe-2" ] }, { "productId": "truelayer", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "truelayer", "storyId": "openness-open-license", "verdict": "partial", "quality": 2, "confidence": "medium", "rationale": "TrueLayer's core payments/banking product is a closed proprietary SaaS API with no evidence of full source availability, but one auxiliary component—the request-signing library—is published as open source on GitHub. missing for 10: no open license for the actual product/platform source, only a small signing helper library is open.", "evidenceIds": [ "truelayer-gh-1" ] }, { "productId": "truelayer", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "TrueLayer is a regulated banking/payments API SaaS platform, not open-source software; self-hosting the core product is a category error for this kind of licensed financial infrastructure provider.", "evidenceIds": [] }, { "productId": "truelayer", "storyId": "pay-by-bank-initiation", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "TrueLayer's Payments API v3 is well documented for initiating pay-by-bank payments from a connected account, with a quickstart to create a test payment, payment links, mandates for recurring payments, and webhooks — and it explicitly states its live geographies as UK and EU (truelayer-docs-1, truelayer-docs-23, truelayer-docs-32, truelayer-docs-10). Missing for 10: independent/hands-on developer confirmation of the payment flow working end-to-end and a fully granular, country-by-country live-market breakdown beyond the UK/EU summary.", "evidenceIds": [ "truelayer-docs-1", "truelayer-docs-23", "truelayer-docs-4", "truelayer-docs-15", "truelayer-docs-32", "truelayer-docs-10", "truelayer-docs-33" ] }, { "productId": "truelayer", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "TrueLayer's evidence covers UK/EU payments and data APIs but nowhere mentions user-selectable data residency or region storage controls; the mention of UK/EU scope reflects operational coverage, not a configurable data-residency choice. Missing for 10: any documentation of data residency options, region selection controls, or storage location configurability.", "evidenceIds": [ "truelayer-docs-1", "truelayer-docs-28" ] }, { "productId": "truelayer", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "TrueLayer is a banking/payments API provider, not an AI model provider or platform that trains models on user data; opting out of AI training is a category error for this product type.", "evidenceIds": [] }, { "productId": "truelayer", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of any data retention or deletion controls (e.g., data export, deletion API, retention policy settings) for AI-native users; evidence pack covers payments, data access APIs, webhooks, and MCP integration but nothing about controlling or deleting stored data.", "evidenceIds": [] }, { "productId": "truelayer", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "TrueLayer is a payments/banking API platform; no evidence in the pack addresses telemetry/usage-tracking opt-out settings for AI-native users interacting with its MCP integration or SDKs. This axis is plausible for a platform with SDKs and an MCP server, but no documentation or feature is cited, so it's 'none' rather than 'na'.", "evidenceIds": [] }, { "productId": "truelayer", "storyId": "processor-integrations", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "TrueLayer documents Data API/Verification API flows that verify account ownership and identity, plus Payments API mechanisms (mandates, webhooks, signed requests) that let merchants/platforms initiate verified payments to bank accounts — this covers the core 'linked accounts feed a payment processor' story. However, evidence is entirely first-party docs describing TrueLayer's own APIs as the processor, not clear documentation of handing verified credentials to a distinct third-party processor/platform via token exchange. missing for 10: independent/hands-on confirmation, explicit third-party processor handoff or OAuth token exchange spec, and real-world integration case studies beyond marketing snippets.", "evidenceIds": [ "truelayer-docs-3", "truelayer-docs-5", "truelayer-docs-6", "truelayer-docs-8", "truelayer-docs-28", "truelayer-docs-29", "truelayer-docs-15", "truelayer-docs-31", "truelayer-docs-18" ] }, { "productId": "truelayer", "storyId": "quickstart-first-connection", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "TrueLayer docs describe a self-serve quickstart that creates a free UK merchant account and completes a first test payment, plus SDKs for Node.js, Python, Java and .NET and dedicated signing libraries to speed integration. This directly matches the signup-to-first-linked-sandbox-account story, though all evidence is first-party docs with no independent/hands-on corroboration of actual time-to-first-success. Missing for 10: independent developer reports confirming ease/speed of the flow, explicit sandbox-environment terminology (vs 'test payment'), and confirmation that API key generation itself is fully self-serve without sales contact.", "evidenceIds": [ "truelayer-docs-32", "truelayer-docs-11", "truelayer-docs-24", "truelayer-docs-26", "truelayer-gh-1" ] }, { "productId": "truelayer", "storyId": "realtime-balance-checks", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "TrueLayer's Data API documents reading account balances (truelayer-docs-5, truelayer-docs-28), which could be used before initiating a payment, but there is no documented endpoint or guidance explicitly framed as a pre-payment real-time balance/NSF or risk check tied to the Payments API flow. missing for 10: explicit documentation of a balance-check step integrated into the payment initiation flow, real-time/NSF-specific balance endpoint framing, and independent confirmation of this workflow.", "evidenceIds": [ "truelayer-docs-5", "truelayer-docs-28", "truelayer-docs-1" ] }, { "productId": "truelayer", "storyId": "recurring-variable-payments", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "TrueLayer documents payment mandates explicitly covering Sweeping VRPs, Wave 1 VRPs, and Direct Debits, with dedicated docs on creating a mandate and executing recurring payments on an authorised mandate without further user auth. This directly matches variable recurring payments, standing consents, and recurring debit flows built on the Payments API. Missing for 10: independent/hands-on corroboration beyond first-party docs, and more detail on standing consent lifecycle management (renewal/revocation).", "evidenceIds": [ "truelayer-docs-15", "truelayer-docs-16", "truelayer-docs-30", "truelayer-docs-31" ] }, { "productId": "truelayer", "storyId": "sandbox-test-institutions", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Docs reference a quickstart that walks through creating a free account and completing a 'test payment' and a providers endpoint to see supported banks, implying some testing path exists, but there is no explicit mention of a sandbox environment, documented test institutions, or test credentials for exercising the Data API (linking/account retrieval) or specific error-state scenarios end-to-end. Missing for 10: explicit sandbox/test-bank credentials documentation, coverage of Data API linking and retrieval testing, and documented error-state simulation.", "evidenceIds": [ "truelayer-docs-32", "truelayer-docs-10", "truelayer-docs-5" ] }, { "productId": "truelayer", "storyId": "scoped-data-access", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "TrueLayer offers distinct product APIs (Payments, Data/Account Info, Verification, Payouts) that developers can integrate separately, implying some scoping by product, and Data API notes consent is tied to specific connected accounts a user has approved. However there is no explicit documentation of granular, developer-selectable OAuth scopes or a consent screen showing minimized data requests per call. missing for 10: explicit scope/permission parameters documented in API reference, evidence of a consent UI showing selectable data categories, and independent confirmation that unused scopes aren't granted by default.", "evidenceIds": [ "truelayer-docs-28", "truelayer-docs-29", "truelayer-docs-5", "truelayer-docs-1", "truelayer-docs-8" ] }, { "productId": "truelayer", "storyId": "transaction-enrichment", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The Data API is documented as returning identity, accounts, transactions and balance data (truelayer-docs-28), but no evidence describes merchant name cleaning, categorization, or logo enrichment as a documented capability. Missing for 10: any mention of transaction enrichment, merchant name normalization, category tagging, or logo/icon data in the docs.", "evidenceIds": [ "truelayer-docs-28" ] }, { "productId": "truelayer", "storyId": "transactions-history-api", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Docs confirm a Data API that reads account, balance and transaction history via a single interface (truelayer-docs-5, truelayer-docs-28), but there is no evidence of pagination mechanics, documented history depth/lookback window, or an incremental sync pattern (e.g., delta/cursor endpoints) for fetching only changed transactions. missing for 10: pagination details, documented transaction history depth/limits, incremental/delta sync mechanism.", "evidenceIds": [ "truelayer-docs-5", "truelayer-docs-28" ] }, { "productId": "truelayer", "storyId": "user-consent-management", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of an end-user-facing consent dashboard or portal for viewing/revoking bank data access; documentation only covers developer-side consent creation (mandates, verification consent) and admin Console user management, not an end-user self-service revocation surface.", "evidenceIds": [] }, { "productId": "truelayer", "storyId": "webhook-data-events", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "TrueLayer documents signed webhooks (Tl-Signature validation) for the Payments API, notifying about payment status changes during authorisation — this covers signed delivery and payment state changes, but the evidence never shows webhooks for the Data API events explicitly named in the story (new transactions, balance updates, connection/consent state changes). Missing for 10: documented webhook events for transaction/balance/connection state changes on the Data/Accounts side, and any confirmation these are pushed rather than requiring polling of the Data API.", "evidenceIds": [ "truelayer-docs-13", "truelayer-docs-14", "truelayer-docs-33", "truelayer-docs-34", "truelayer-docs-35", "truelayer-docs-28" ] }, { "productId": "yapily", "storyId": "account-numbers-for-ach", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "yapily", "storyId": "account-ownership-data", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Yapily explicitly documents confirming account ownership and retrieving customer details, plus broader Data API access to account details/balances for identity matching purposes. Missing for 10: no explicit breakdown of which fields (name, address, contact) are returned, and no independent/hands-on corroboration beyond first-party docs.", "evidenceIds": [ "yapily-docs-4", "yapily-docs-15", "yapily-docs-2" ] }, { "productId": "yapily", "storyId": "agent-links-and-reads", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Yapily's API clearly supports creating consent/link sessions, retrieving balances/transactions, and managing connections (yapily-docs-2, -7, -9, -15), and there is an MCP surface (yapily-docs-6, yapily-probe-3) — but that MCP is documented as connecting coding agents (Claude/Cursor) to the documentation, not as an operational interface for agents to actually invoke banking actions with scoped credentials. Missing for 10: evidence of an MCP tool surface that performs live API calls (link sessions, balance/transaction retrieval) rather than just docs access, and explicit scoped-credential/agent-auth model for such calls.", "evidenceIds": [ "yapily-docs-2", "yapily-docs-7", "yapily-docs-9", "yapily-docs-15", "yapily-docs-6", "yapily-probe-3" ] }, { "productId": "yapily", "storyId": "agent-ready-financial-data", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs show enrichment (merchant detection, spending insights) and a Data API returning structured account/transaction/balance data, plus OpenAPI-based client generation implying documented schemas (yapily-docs-3, yapily-docs-2, yapily-docs-8, yapily-docs-15). However, a probe found the openapi.json/swagger.json spec not resolvable at standard paths, casting doubt on how discoverable the machine-readable schema actually is, and no evidence pack item shows an actual JSON response sample or schema definition. Missing for 10: concrete JSON response examples/schema snippets, confirmation of a publicly resolvable OpenAPI spec, and explicit statement that enrichment fields are machine-parseable without heuristics.", "evidenceIds": [ "yapily-docs-2", "yapily-docs-3", "yapily-docs-8", "yapily-docs-15", "yapily-probe-2" ] }, { "productId": "yapily", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Yapily explicitly documents an llms.txt file (confirmed live via probe returning HTTP 200) and dedicated agent-oriented docs describing how to connect Claude, Cursor, or other AI agents via MCP, llms.txt, or Agent Skills, directly matching the story. Missing for 10: independent third-party confirmation of an agent successfully consuming the docs end-to-end.", "evidenceIds": [ "yapily-docs-6", "yapily-docs-7", "yapily-probe-1", "yapily-probe-3" ] }, { "productId": "yapily", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Yapily's data API supports transaction categorisation and spending insights (yapily-docs-3), but this is not documented as AI-generated insights or suggestions surfaced within a Yapily product interface; the only AI-related evidence concerns connecting coding agents to its docs via MCP, not AI-driven analysis of user data.", "evidenceIds": [ "yapily-docs-3", "yapily-docs-6" ] }, { "productId": "yapily", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Yapily's Payments API supports scheduled and recurring/variable-recurring payments that execute autonomously without re-authorisation, and webhooks provide background event notifications — both are forms of autonomous background automation. However, there's no evidence of an AI-agent-specific automation-setup flow (e.g., an agent configuring or monitoring these jobs), just generic API-level scheduling. Missing for 10: explicit AI-agent-driven automation setup, agent monitoring/adjusting of scheduled tasks, and independent confirmation of reliability of unattended runs.", "evidenceIds": [ "yapily-docs-1", "yapily-docs-5", "yapily-docs-16", "yapily-docs-13", "yapily-docs-18" ] }, { "productId": "yapily", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Yapily is an open banking API/infrastructure platform, not an AI assistant product; the evidence shows it supports AI agents connecting to its docs (MCP/llms.txt) as an API consumer, but it does not embed a built-in AI assistant for users to delegate tasks to within the product itself.", "evidenceIds": [] }, { "productId": "yapily", "storyId": "agentic-headless", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Yapily is a REST/API-first platform (payments, data, webhooks) with a sandbox for testing and generated client libraries, implying it can be scripted/automated without a UI, but there is no explicit documentation of running it headlessly in a CI pipeline, no CLI tool, and no automation/testing-pipeline example. missing for 10: explicit CI/CD or headless automation documentation, a CLI or scriptable test harness, evidence of pipeline integration examples.", "evidenceIds": [ "yapily-docs-12", "yapily-docs-8", "yapily-docs-13", "yapily-docs-9" ] }, { "productId": "yapily", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Yapily is an open-banking API/platform, not an agentic runtime that consumes external tools; the evidence only shows Yapily exposing an MCP server so AI coding agents can query its docs, not Yapily itself acting as an MCP client that plugs in and uses other servers' tools. This client-side 'use MCP tools' axis is a category mismatch for a banking API product.", "evidenceIds": [ "yapily-docs-6", "yapily-probe-3" ] }, { "productId": "yapily", "storyId": "agentic-mcp-server", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Yapily documents an official MCP server for connecting AI agents (Claude, Cursor) to its docs, confirmed by both docs and a probe verifying the ai-agents.md resource, so the axis clearly applies and is addressed. However, the evidence only shows MCP access to documentation/context, not to Yapily's actual banking APIs (payments, data, AIS/PIS) as agent-callable tools, and there's no independent or hands-on confirmation of the MCP server's tool set in action. Missing for 10: evidence that the MCP server exposes real API operations (payments, account data) as agent tools, tool/resource list details, and independent corroboration beyond first-party docs.", "evidenceIds": [ "yapily-docs-6", "yapily-probe-3" ] }, { "productId": "yapily", "storyId": "agentic-nl-commands", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Yapily's evidence covers a developer API/SDKs and an MCP-served documentation assistant for coding agents (yapily-docs-6, yapily-probe-3), but there is no evidence that end users can issue natural-language commands to actually operate Yapily's core functions (payments, account data retrieval, etc.). The MCP/llms.txt integration is for helping coding agents navigate docs, not a natural-language control interface for the product's operations.", "evidenceIds": [ "yapily-docs-6", "yapily-probe-3" ] }, { "productId": "yapily", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Yapily provides SDK/client library generation (yapily-docs-8) and AI-agent connectivity via MCP/llms.txt (yapily-docs-6), but there is no evidence of an official CLI tool for interacting with the Yapily platform or APIs.", "evidenceIds": [] }, { "productId": "yapily", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Yapily is API-first: docs describe endpoints for payments, data, webhooks, and confirm OpenAPI-based client library generation, plus explicit AI-agent access via MCP/llms.txt (confirmed live by probe-1 and probe-3), directly matching the 'documented public API for AI-native use' story. Missing for 10: a verifiable OpenAPI spec file (probe-2 found all standard OpenAPI/swagger paths 404) and independent third-party confirmation of API completeness beyond first-party docs.", "evidenceIds": [ "yapily-docs-8", "yapily-docs-6", "yapily-probe-1", "yapily-probe-3", "yapily-probe-2", "yapily-docs-16", "yapily-docs-15" ] }, { "productId": "yapily", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack describes issuing scoped or least-privilege API credentials/keys for agent use; documentation covers payments, data access, consent flows, and AI-agent documentation connectivity (MCP/llms.txt) but not credential scoping mechanisms.", "evidenceIds": [] }, { "productId": "yapily", "storyId": "agentic-sdks", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Yapily documents generating client libraries from an OpenAPI spec for Java, Python, Node.js, etc., which supports the 'official SDK' story, but this is code generation rather than a maintained, first-party SDK repository, and the probe found no accessible OpenAPI spec file, undermining confidence in this claim. missing for 10: evidence of actual published/maintained SDK repos (GitHub links, versioning, install instructions), independent corroboration, and working OpenAPI spec access.", "evidenceIds": [ "yapily-docs-8", "yapily-probe-2" ] }, { "productId": "yapily", "storyId": "agentic-webhooks", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Yapily documents a dedicated webhooks system delivering real-time HTTP notifications of platform events (e.g., payment status changes), directly matching the story. Missing for 10: independent/hands-on corroboration of webhook reliability and no detail on subscription filtering/event types.", "evidenceIds": [ "yapily-docs-13", "yapily-docs-18" ] }, { "productId": "yapily", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of an interactive API reference or runnable code examples; the OpenAPI spec probe returned 404s and docs only mention static content, code-gen libraries, and AI-agent integration (MCP/llms.txt), not an interactive playground with runnable examples.", "evidenceIds": [ "yapily-probe-2", "yapily-docs-8", "yapily-docs-6" ] }, { "productId": "yapily", "storyId": "api-machine-spec", "verdict": "disputed", "quality": 4, "confidence": "medium", "rationale": "Docs reference an OpenAPI specification used to generate client libraries (yapily-docs-8), implying a machine-readable spec exists, but a direct probe for standard OpenAPI/Swagger file locations returned 404 everywhere (yapily-probe-2), meaning no publicly downloadable spec could be located. missing for 10: a working public URL/download link for the OpenAPI/Swagger file, confirmation of its format and completeness, and independent corroboration that it can actually be fetched.", "evidenceIds": [ "yapily-docs-8", "yapily-probe-2" ] }, { "productId": "yapily", "storyId": "api-sandbox", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Yapily explicitly documents a sandbox environment that simulates real Open Banking flows with test accounts/banks so developers can test without touching production data (yapily-docs-12), supported by webhook and API docs for testing flows. Missing for 10: independent/hands-on confirmation of sandbox behavior and explicit detail on data isolation guarantees beyond the doc description.", "evidenceIds": [ "yapily-docs-12", "yapily-docs-13" ] }, { "productId": "yapily", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence pack items mention API versioning scheme or a documented deprecation policy; docs reference API capabilities, sandbox, webhooks, and client library generation but nothing about version lifecycle or deprecation commitments. missing for 10: versioning scheme documentation, deprecation policy/notice process, changelog or migration guides.", "evidenceIds": [] }, { "productId": "yapily", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Yapily's docs mention 'bulk' as a supported payment type alongside scheduled/periodic/international payments, indicating some batch-processing capability, but there is no detailed documentation of bulk API semantics (batch size limits, bulk data retrieval, bulk consent management, etc.) beyond this one-line reference. missing for 10: dedicated bulk API endpoint documentation, batch limits/pagination for data retrieval, examples of bulk operations in practice.", "evidenceIds": [ "yapily-docs-17", "yapily-docs-16" ] }, { "productId": "yapily", "storyId": "automation-rules-engine", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Yapily documents webhooks for real-time event notifications, but there is no evidence of a rules engine or mechanism letting users define conditional triggers that automatically execute actions based on events — webhooks only notify, they don't let a user configure 'if X then do Y' automation.", "evidenceIds": [ "yapily-docs-13", "yapily-docs-18" ] }, { "productId": "yapily", "storyId": "automation-scheduled-jobs", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Yapily's Payments API explicitly supports scheduled and recurring (periodic/variable recurring) payment initiation, which is a concrete recurring-job capability exposed via API and webhooks for status tracking. However, this is domain-specific (payments only) rather than a general-purpose job/workflow scheduler or automation engine that an AI agent could use to orchestrate arbitrary recurring tasks. Missing for 10: evidence of a generic scheduling/orchestration API or cron-like trigger system beyond payment initiation, and no independent corroboration of this working end-to-end.", "evidenceIds": [ "yapily-docs-1", "yapily-docs-5", "yapily-docs-16", "yapily-docs-17", "yapily-docs-18", "yapily-docs-21" ] }, { "productId": "yapily", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Yapily is an open banking API/payments platform, not an automation-builder product with a versionable workflow concept; version/review/rollback of 'automations' is a category error for this kind of product.", "evidenceIds": [] }, { "productId": "yapily", "storyId": "connection-repair-relink", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers payments, data retrieval, webhooks, and Yapily Connect UI, but nothing documents how expired/revoked consent links surface as statuses or how users re-authenticate via an update flow without restarting the linking process — missing for 10: documented consent-expiry/revocation status codes, and an explicit re-auth/update flow that preserves prior linkage.", "evidenceIds": [] }, { "productId": "yapily", "storyId": "data-deletion-api", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence describes a documented deletion/revocation flow for connections or users, nor confirmation that data collection stops and held data is purged; docs only mention consent collection, sandbox, webhooks, and data retrieval, not consent revocation or data deletion/purge.", "evidenceIds": [] }, { "productId": "yapily", "storyId": "hosted-link-flow", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Yapily Connect is explicitly documented as a ready-built, white-label hosted UI for AIS/PIS flows with pre-built institution selection and consent screens, no frontend engineering required, automatic SCA/redirect handling, and customizable branding — matching the drop-in widget story closely. Missing for 10: explicit documentation of the server-side 'create session' API call and the exact token/consent-object returned to the backend after widget completion, plus independent/hands-on corroboration beyond vendor docs.", "evidenceIds": [ "yapily-docs-7", "yapily-docs-9", "yapily-docs-10", "yapily-docs-11", "yapily-docs-20" ] }, { "productId": "yapily", "storyId": "income-cashflow-insights", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Yapily's docs show transaction categorisation, merchant detection, and spending insights (yapily-docs-3), but there is no evidence of recurring income/payroll detection, cash-flow signal derivation, or income verification products built on the data.", "evidenceIds": [] }, { "productId": "yapily", "storyId": "institution-coverage-breadth", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack contains no published institution counts, geographic coverage lists, or bank-name directories that a founder could check against their users' banks—only product/API feature descriptions.", "evidenceIds": [] }, { "productId": "yapily", "storyId": "institution-status-visibility", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of a documented institution status page, outage/degradation signals, or error-code taxonomy distinguishing bank-side failures from client-side issues; only generic webhook and payment-status mentions are present. Missing for 10: institution status/availability page, degradation/outage signals, and documented bank-vs-integration error code distinctions.", "evidenceIds": [ "yapily-docs-18", "yapily-docs-13" ] }, { "productId": "yapily", "storyId": "multi-product-sessions", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Yapily's Data API and consent flow (via Yapily Connect) grant access to accounts, balances, transactions, and identity data under a single AIS consent/session (yapily-docs-2, yapily-docs-4, yapily-docs-15, yapily-docs-20), and Yapily Connect explicitly reduces repeated consent screens across flows (yapily-docs-7, yapily-docs-9). However, payments (PIS) are documented as a separate initiation flow/API from data access (AIS), and no evidence explicitly confirms a single link/consent session spans both AIS and PIS products without re-authentication. missing for 10: explicit confirmation that one consent/session token covers both payments and data products together, and independent/hands-on evidence of a true single multi-product session rather than per-product consent screens.", "evidenceIds": [ "yapily-docs-2", "yapily-docs-4", "yapily-docs-7", "yapily-docs-9", "yapily-docs-15", "yapily-docs-20", "yapily-docs-16" ] }, { "productId": "yapily", "storyId": "oauth-bank-connections", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Yapily's docs describe bank redirect and SCA-based consent flows (docs-9, docs-10) which imply OAuth-style bank-hosted authentication rather than screen-scraping, but no evidence explicitly uses the term 'OAuth,' documents OAuth coverage across institutions, or discusses retirement of legacy credential-scraping flows. Missing for 10: explicit OAuth terminology/documentation, institution-by-institution OAuth coverage stats, and any statement about phasing out screen-scraped credential flows.", "evidenceIds": [ "yapily-docs-9", "yapily-docs-10" ] }, { "productId": "yapily", "storyId": "on-demand-refresh", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Evidence covers account data retrieval, webhooks for real-time notifications, and payments, but nothing describes an on-demand refresh endpoint/parameter or documents refresh semantics (e.g., how often data updates or how to force a refresh). Missing for 10: any mention of a refresh API/endpoint, refresh frequency/rate limits, or documented semantics for on-demand data freshness.", "evidenceIds": [ "yapily-docs-2", "yapily-docs-13", "yapily-docs-15" ] }, { "productId": "yapily", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Yapily's UI (Yapily Connect) is explicitly described as a pre-built white-label layer for AIS/PIS flows that sits on top of the same Data and Payments APIs (docs-7, docs-9, docs-15, docs-16), implying most UI functionality is API-backed rather than API-exclusive. However, there is no explicit documentation stating full UI/API parity, and a probe found no discoverable OpenAPI spec at expected locations, raising doubt about complete self-service API coverage. Missing for 10: explicit parity statement enumerating any UI-only conveniences (e.g., branding, consent screen customization) and their API equivalents, and a working public OpenAPI spec confirming full endpoint coverage.", "evidenceIds": [ "yapily-docs-7", "yapily-docs-9", "yapily-docs-15", "yapily-docs-16", "yapily-docs-8", "yapily-probe-2" ] }, { "productId": "yapily", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "yapily", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Yapily is a closed commercial open banking API/SaaS platform; there is no evidence of any open-source license or public source repository for its core product. Documentation and OpenAPI probes exist but source code openness is not evidenced anywhere in the pack.", "evidenceIds": [] }, { "productId": "yapily", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Yapily is a regulated open-banking API/aggregation platform requiring bank connectivity, licensing, and infrastructure that only the vendor can provide; self-hosting the core product is not a meaningful capability for this category of service.", "evidenceIds": [] }, { "productId": "yapily", "storyId": "pay-by-bank-initiation", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Yapily's docs clearly describe payment initiation (single, scheduled, periodic, recurring/VRP) via its Payments API using local rails like UK Faster Payments and European SEPA, giving some geographic grounding, but there is no comprehensive, explicit list of supported countries/markets or independent confirmation of live coverage claims. missing for 10: full country/geography list, independent verification of live markets, and any hands-on confirmation of payment success rates.", "evidenceIds": [ "yapily-docs-1", "yapily-docs-16", "yapily-docs-17", "yapily-docs-21", "yapily-docs-18" ] }, { "productId": "yapily", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence in the pack addresses data residency, regional storage choice, or hosting location options for customer data; all docs focus on payments, data access APIs, and AI-agent connectivity.", "evidenceIds": [] }, { "productId": "yapily", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Yapily is an open banking API/payments platform, not an AI model or AI product that trains on user data; the axis of preventing data use for AI model training does not apply to its category.", "evidenceIds": [] }, { "productId": "yapily", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence in the pack addresses data retention policies, deletion controls, or user-initiated data removal options for Yapily; the documentation covers data access, payments, and AI-agent integration but nothing about retention/deletion controls.", "evidenceIds": [] }, { "productId": "yapily", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses telemetry opt-out or usage tracking controls for Yapily's products or docs; this is a fair question for an API/SaaS platform but is unaddressed.", "evidenceIds": [] }, { "productId": "yapily", "storyId": "processor-integrations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Yapily's docs describe account verification and payment initiation via its own Payments/Data APIs, but there is no evidence of documented integrations or token-exchange mechanisms that hand verified account credentials to third-party payment processors or platforms.", "evidenceIds": [] }, { "productId": "yapily", "storyId": "quickstart-first-connection", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Evidence confirms a sandbox test environment (yapily-docs-12) and client library generation via OpenAPI spec for Java, Python, Node.js, etc. (yapily-docs-8), but there is no evidence of a self-serve signup flow, API key issuance process, or a runnable quickstart guide. The openapi.json probe returned 404s across all candidate paths, casting doubt on how straightforward the client-library generation actually is in practice. missing for 10: self-serve signup/API-key evidence, an explicit quickstart walkthrough, working OpenAPI spec endpoint, independent corroboration of time-to-first-sandbox-account.", "evidenceIds": [ "yapily-docs-12", "yapily-docs-8", "yapily-probe-2" ] }, { "productId": "yapily", "storyId": "realtime-balance-checks", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Yapily's Data API explicitly documents retrieving account balances (via AIS/Open Banking) alongside accounts and transactions, which is the core capability needed for pre-payment balance checks. Missing for 10: explicit 'real-time' latency guarantees and explicit framing of the endpoint for NSF/risk-check use cases.", "evidenceIds": [ "yapily-docs-2", "yapily-docs-15" ] }, { "productId": "yapily", "storyId": "recurring-variable-payments", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Docs explicitly cover recurring/scheduled/periodic payments (yapily-docs-1, -16, -17) and dedicated variable recurring payment support without re-authorisation (yapily-docs-5), plus webhook-based status tracking and local rail settlement for recurring debits (yapily-docs-18, -21). Missing for 10: independent/hands-on confirmation of VRP flows in production and more detail on standing consent lifecycle management beyond docs claims.", "evidenceIds": [ "yapily-docs-1", "yapily-docs-5", "yapily-docs-16", "yapily-docs-17", "yapily-docs-18", "yapily-docs-21" ] }, { "productId": "yapily", "storyId": "sandbox-test-institutions", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm a sandbox exists to connect to test banks and simulate the Open Banking experience, but the evidence pack doesn't detail documented test credentials, specific error-state simulation, or step-by-step end-to-end linking/retrieval walkthroughs. missing for 10: explicit test credentials list, error/edge-case simulation documentation, independent/hands-on confirmation of the sandbox experience.", "evidenceIds": [ "yapily-docs-12" ] }, { "productId": "yapily", "storyId": "scoped-data-access", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Yapily separates its offerings into distinct products (Data API for AIS, Payments API for PIS, account confirmation, VRP) each with its own consent screen, implying developers only request the product-specific consent they need rather than a single blanket grant (yapily-docs-2, -15, -16, -20). However, there is no explicit documentation of fine-grained data-minimization controls within a product (e.g., requesting balances only vs. full transaction history) or scope parameters in the API reference.\nmissing for 10: granular in-product scope/field-level consent documentation, explicit data-minimization API parameters, independent confirmation of scope enforcement.", "evidenceIds": [ "yapily-docs-2", "yapily-docs-15", "yapily-docs-16", "yapily-docs-20" ] }, { "productId": "yapily", "storyId": "transaction-enrichment", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs explicitly claim categorisation, merchant detection, and spending insights on transaction data (yapily-docs-3, yapily-docs-15), directly supporting enrichment as a documented platform capability rather than a DIY task. However, no evidence specifically documents merchant logo enrichment or detailed 'cleaned name' normalization, and there's no independent/hands-on confirmation of enrichment quality. Missing for 10: explicit logo enrichment documentation, detail on merchant name cleaning methodology, third-party/hands-on validation of enrichment accuracy.", "evidenceIds": [ "yapily-docs-3", "yapily-docs-15" ] }, { "productId": "yapily", "storyId": "transactions-history-api", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Docs confirm transaction/account/balance retrieval via the Data API with consent (yapily-docs-2, yapily-docs-15) and webhooks for real-time change notifications (yapily-docs-13), which could support a sync pattern, but there is no documented pagination mechanism, no stated history depth/lookback window, and no explicit delta/incremental-fetch API for transactions. missing for 10: pagination details, documented transaction history depth, explicit changed-only/delta sync endpoint or pattern beyond generic webhooks.", "evidenceIds": [ "yapily-docs-2", "yapily-docs-15", "yapily-docs-13" ] }, { "productId": "yapily", "storyId": "user-consent-management", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows Yapily Connect provides consent screens for initiating AIS/PIS authorization (docs-7, docs-20) but nothing about a portal or surface where end users can view all apps/connections and actively revoke previously granted consent to their bank data.", "evidenceIds": [] }, { "productId": "yapily", "storyId": "webhook-data-events", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Yapily documents webhooks for real-time HTTP notifications of platform changes, explicitly used for payment status tracking, supporting event-driven updates instead of polling. However, the evidence never confirms webhook payloads are cryptographically signed, nor details specific coverage for new transactions/balance updates/connection state changes as separate event types. Missing for 10: signature/verification mechanism documentation, explicit event types for transactions/balances/connection state, and independent confirmation of reliability.", "evidenceIds": [ "yapily-docs-13", "yapily-docs-18" ] } ]