[ { "productId": "column", "storyId": "account-opening-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Docs confirm programmatic FDIC-insured account opening/management (column-docs-2) and a full sandbox environment with simulate endpoints for wires/ACH (column-docs-3), matching the story's application-to-active-account and sandbox parity requirements. Community feedback corroborates a smooth signup/setup flow (column-comm-5) and strong documentation quality (column-comm-8). Missing for 10: independent hands-on confirmation that the entire account application/approval step (not just account management) is fully API-driven without manual review, and explicit sandbox-to-production parity testing evidence beyond simulate endpoints.", "evidenceIds": [ "column-docs-2", "column-docs-3", "column-comm-5", "column-comm-8" ] }, { "productId": "column", "storyId": "ach-origination", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Column's docs confirm ACH credit/debit origination via API, sandbox simulation of incoming ACH credits/debits, and general webhook event support, plus a unified transfers endpoint that would include ACH. However, there's no direct evidence of same-day ACH windows, or first-class objects/webhooks for returns, NOCs, or reversals — the specific 'unhappy path' modeling the story asks for is unaddressed. Missing for 10: explicit documentation of same-day ACH windows, return/NOC/reversal objects, and webhook events tied to those unhappy paths.", "evidenceIds": [ "column-docs-1", "column-docs-3", "column-docs-7", "column-docs-9" ] }, { "productId": "column", "storyId": "agent-operated-account", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Column's docs describe general API capabilities (transfers, account permissioning, webhooks) and one community mention of per-account-number permissions/limits, but nothing documents scoped credentials, amount caps, or counterparty allowlists specifically for an AI agent use case by name. missing for 10: any mention of 'agent' or AI-native access patterns, documented amount-cap/allowlist controls tied to agent credentials, and a named agent-banking product or guide.", "evidenceIds": [ "column-comm-7", "column-docs-2", "column-docs-9" ] }, { "productId": "column", "storyId": "agent-reads-banking-state", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Column exposes a comprehensive REST/OpenAPI surface covering accounts, transactions, transfers (including pending/status), wires, checks, and reporting (CSV/JSON/Parquet), letting an agent programmatically read the full banking picture instead of scraping a dashboard. However, there is no evidence of an MCP server or agent-native surface — only a standard HTTP API with OpenAPI spec for SDK generation, and the company explicitly says most customers use raw HTTP APIs, not SDKs or agent tooling. Missing for 10: MCP server/tool-calling interface, explicit 'documents' retrieval endpoint beyond checks, and any AI-agent-specific integration evidence.", "evidenceIds": [ "column-docs-2", "column-docs-8", "column-docs-9", "column-docs-12", "column-docs-10", "column-comm-1" ] }, { "productId": "column", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Column serves a live llms.txt file (HTTP 200, confirmed by direct probe) plus markdown-rendered agent-friendly docs pages (e.g. .md versions of guides) and an OpenAPI spec, all of which an agent could be pointed at directly. This is concrete first-party evidence of agent-oriented documentation delivery. Missing for 10: independent/community confirmation that an agent was actually pointed at llms.txt and successfully used it.", "evidenceIds": [ "column-probe-1", "column-probe-2", "column-docs-1", "column-docs-10" ] }, { "productId": "column", "storyId": "agentic-ai-insights", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Column is a banking-as-a-service API platform for building payment/account infrastructure, not a data analytics or AI-insights product; nothing in its evidence pack relates to AI-generated insights or suggestions from user data. This axis is a category error for this type of product.", "evidenceIds": [] }, { "productId": "column", "storyId": "agentic-autonomous-automation", "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": "column", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Column is a banking-as-a-service API/platform for developers, not an AI assistant product; no evidence pack content relates to a built-in AI assistant feature. Delegating tasks to an in-product AI assistant is a category error for this type of product.", "evidenceIds": [] }, { "productId": "column", "storyId": "agentic-headless", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Column is a pure HTTP API/banking platform with an OpenAPI spec, sandbox simulate endpoints, and webhooks — all of which are usable in headless, scripted, or CI-driven workflows without any UI dependency. However, there is no explicit documentation or example of running Column in a CI pipeline, and the company notes it deliberately provides no first-party SDKs, relying on customers to generate their own from the OpenAPI spec. Missing for 10: explicit CI/CD examples or guides, first-party SDKs/tooling for automated test pipelines, and any community confirmation of headless/CI usage.", "evidenceIds": [ "column-docs-3", "column-docs-10", "column-probe-2", "column-comm-1" ] }, { "productId": "column", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Column is a banking-as-a-service API platform, not an AI agent or assistant; MCP server integration for tool use is not a relevant axis for this product's category.", "evidenceIds": [] }, { "productId": "column", "storyId": "agentic-mcp-server", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Column is a banking-as-a-service API platform; no evidence of an official MCP server for agent connectivity is present, only a REST API with OpenAPI spec. This axis applies since a developer-facing API platform could plausibly ship an MCP server, but absence of any such evidence yields none. missing for 10: any mention of an MCP server, agent integration, or AI-native tooling.", "evidenceIds": [ "column-docs-10", "column-probe-2" ] }, { "productId": "column", "storyId": "agentic-nl-commands", "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": "column", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Column is a banking API platform with no evidence of an official CLI; in fact a Column engineer explicitly states they don't even provide SDKs, only HTTP APIs, and no CLI is mentioned anywhere in docs or community evidence.", "evidenceIds": [ "column-comm-1" ] }, { "productId": "column", "storyId": "agentic-public-api", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Column is API-first: extensive first-party docs cover a full public API for payments, accounts, wires, ACH, cards, checks, webhooks, and reporting, backed by a documented OpenAPI spec (confirmed live at openapi.json) usable to generate client SDKs, plus a verified llms.txt for AI-native consumption. Community corroboration from a Column engineer confirms HTTP API is the primary supported interface. Missing for 10: no independent third-party audit of API completeness or hands-on agent-driven integration report.", "evidenceIds": [ "column-docs-9", "column-docs-10", "column-probe-1", "column-probe-2", "column-comm-1" ] }, { "productId": "column", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Column is a banking/payments API platform; there is no evidence of scoped or least-privilege API credential issuance for agents specifically (no API key scoping, permission roles, or agent-specific credential management mentioned). The ACH account-number permissioning feature (column-comm-7) relates to bank account routing limits, not API credential scoping for AI agents. Missing for 10: any documentation of API key/token scoping, role-based access control, or agent-specific credential issuance.", "evidenceIds": [] }, { "productId": "column", "storyId": "agentic-sdks", "verdict": "disputed", "quality": 3, "confidence": "medium", "rationale": "Docs point to an OpenAPI spec that can be used to 'generate type-safe client SDKs in any language' (column-docs-10), but this is code-gen from a spec, not official first-party SDKs. A Column engineer directly contradicts any SDK-first narrative, stating 'we have definitely considered creating SDK's but most of our customers prefer the HTTP API's' (column-comm-1), confirming no official SDKs exist. Missing for 10: actual first-party maintained SDKs in specific languages, official SDK repos/docs, and any retraction of the engineer's statement.", "evidenceIds": [ "column-docs-10", "column-comm-1" ] }, { "productId": "column", "storyId": "agentic-webhooks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Column's docs explicitly document webhook subscription for events, configurable via API or Dashboard (column-docs-7), enabling programmatic/agentic consumption of platform events. missing for 10: no independent/hands-on confirmation of webhook reliability or payload schema details, and no mention of event types or filtering granularity.", "evidenceIds": [ "column-docs-7" ] }, { "productId": "column", "storyId": "api-interactive-docs", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Column publishes an OpenAPI spec and markdown docs (docs.column.com) plus a sandbox environment with simulate endpoints for testing payment flows, which supports some hands-on exploration, but there is no direct evidence of an interactive in-docs API console or embedded runnable code examples typical of 'try it now' reference UIs. missing for 10: explicit interactive API explorer/try-it-out UI, embedded runnable code snippets, independent confirmation of an interactive reference experience.", "evidenceIds": [ "column-docs-3", "column-docs-10", "column-probe-2", "column-probe-1" ] }, { "productId": "column", "storyId": "api-machine-spec", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Column explicitly documents an OpenAPI spec available as JSON for generating client SDKs, and a live probe confirms the openapi.json endpoint returns HTTP 200 with a valid 'openapi' key, directly corroborating the vendor claim. missing for 10: no independent third-party review specifically validating the spec's completeness/usability beyond the probe.", "evidenceIds": [ "column-docs-10", "column-probe-2" ] }, { "productId": "column", "storyId": "api-sandbox", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Column's docs explicitly describe a sandbox environment with simulate endpoints (receive-wire, receive-ach-credit/debit) to test payment flows without touching production data, and community mentions confirm a separate Sandbox status page exists distinct from Production. missing for 10: no independent hands-on account of using the sandbox for a full workflow, and no explicit statement about data isolation guarantees between sandbox and production.", "evidenceIds": [ "column-docs-3", "column-comm-6" ] }, { "productId": "column", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Evidence shows Column has an OpenAPI spec and SDK generation, but there is no mention of API versioning scheme or a documented deprecation policy anywhere in the docs or community discussion.", "evidenceIds": [] }, { "productId": "column", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence covers many individual payment rails, reporting, and a unified query endpoint, but no documentation mentions batch/bulk operations (e.g., submitting many transfers or account actions in a single call) that an AI-native user could invoke for bulk automation.", "evidenceIds": [] }, { "productId": "column", "storyId": "automation-rules-engine", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Column exposes webhooks so external systems can be notified of events (column-docs-7), but there is no evidence of a native rules/automation engine within Column that lets a user define conditions and have Column itself trigger actions automatically — building on the webhook would require external logic. Missing for 10: any documented in-product rule/trigger definition, conditional action execution, or automation workflow builder.", "evidenceIds": [ "column-docs-7" ] }, { "productId": "column", "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": "column", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Column is a banking/payments API platform, not an automation/workflow builder; versioning, reviewing, and rolling back 'automations' is not a category-fit concept for this product—it's a wrong axis rather than a missing capability.", "evidenceIds": [] }, { "productId": "column", "storyId": "builtin-ai-banking-ops", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Column's evidence pack is entirely about banking-as-a-service APIs (wires, ACH, cards, reporting, webhooks) with no mention of any built-in AI features like natural-language transaction search, dispute drafting, or anomaly summaries. missing for 10: any AI/NLP capability, dispute-response drafting, anomaly detection or summarization features, natural-language search over transactions.", "evidenceIds": [] }, { "productId": "column", "storyId": "card-disputes-rege", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack addresses Reg E dispute handling, provisional credit timelines, or ops responsibilities for card/ACH disputes; docs cover payment rails, reporting, webhooks, and card issuing but nothing about dispute/chargeback investigation workflows.", "evidenceIds": [] }, { "productId": "column", "storyId": "check-support", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Column's docs confirm check issuance and deposit via API (column-docs-4), but there is no explicit mention of image capture mechanics, and a Column engineer noted in community discussion that 'Checks are currently in beta' (column-comm-2), suggesting immaturity. missing for 10: explicit image-capture/deposit workflow details, confirmation of GA (non-beta) status, and independent hands-on verification of check deposit reliability.", "evidenceIds": [ "column-docs-4", "column-comm-2" ] }, { "productId": "column", "storyId": "compliance-program-tooling", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence covers payment rails, account management, reporting, and webhooks, but there is no mention of transaction monitoring tooling, sanctions screening, alert case management, or SAR-filing support/workflow for ops users. Missing for 10: transaction monitoring dashboard/API, sanctions screening tooling, case management for compliance alerts, SAR filing workflow, and documented division of compliance duties between platform/bank/customer.", "evidenceIds": [] }, { "productId": "column", "storyId": "debit-card-issuance", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Column docs confirm a card program supporting both physical and virtual cards via major networks/issuer processors, and a Column engineer corroborates issuing bank/card program status. However, evidence lacks detail on spend controls (limits, MCC restrictions) and digital wallet (Apple/Google Pay) provisioning specifics. missing for 10: documented spend control APIs, digital wallet tokenization/push-provisioning support, independent hands-on confirmation of card issuance flow.", "evidenceIds": [ "column-docs-11", "column-comm-2" ] }, { "productId": "column", "storyId": "direct-bank-relationship", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Column clearly discloses it is itself a nationally chartered bank (not a middleware or partner-bank model) via its docs tagline 'Column N.A. is the first nationally chartered bank created to serve developers and builders' and confirms FDIC-insured accounts and being 'an issuing bank' sponsoring card programs directly. This answers 'who holds the charter' clearly, but the evidence pack has no explicit statement on what happens to customer funds/accounts in a failure/receivership scenario beyond the general FDIC-insurance mention. Missing for 10: explicit failure/receivership disclosure, pass-through insurance mechanics, and independent verification of charter claims beyond Column's own docs/HN comments.", "evidenceIds": [ "column-probe-1", "column-docs-2", "column-comm-2" ] }, { "productId": "column", "storyId": "fbo-structure-transparency", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Column's docs explicitly state accounts are FDIC insured and describe support for FBO, sweep, clearing, and custom account types, giving some transparency into account structure (column-docs-2). However there is no explicit documentation on how FDIC pass-through insurance attaches to underlying customers, nor on ledger access controls/who can view sub-ledger data — these are not addressed in the evidence pack. missing for 10: explicit FDIC pass-through insurance mechanics, documentation on ledger visibility/access permissions, and independent confirmation of these structural details.", "evidenceIds": [ "column-docs-2", "column-comm-7" ] }, { "productId": "column", "storyId": "fraud-loss-allocation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack addresses fraud liability allocation for ACH returns, card disputes, or account takeover losses, nor any documentation pairing prevention tooling with a stated liability split. Docs cover payment rails, reporting, webhooks, and account features but never discuss fraud economics or who bears losses.", "evidenceIds": [] }, { "productId": "column", "storyId": "international-payments", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Column documents sending/receiving international transfers via SWIFT and full raw wire message access, showing genuine cross-border wire capability, but there is no evidence of transparent FX rate disclosure or a documented map of supported currencies/corridors. missing for 10: FX rate transparency/pricing details, list of supported currencies and corridors, independent confirmation of SWIFT reliability.", "evidenceIds": [ "column-docs-5", "column-docs-12", "column-docs-1" ] }, { "productId": "column", "storyId": "kyc-kyb-onboarding", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers Column's payments, accounts, cards, checks, wires, and reporting APIs, but nowhere mentions KYC/KYB identity verification, document collection, watchlist/OFAC screening, or application state modeling for onboarding customers programmatically.", "evidenceIds": [] }, { "productId": "column", "storyId": "ledger-bank-reconciliation", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Column is a chartered bank itself and provides reporting/transaction query APIs (bank_account_transaction, bank_account_summary, unified transfer endpoint), but there is no documentation or community evidence describing an explicit daily reconciliation process between the ledger/API and actual held bank funds — the exact assurance a finance lead burned by Synapse would need. Missing for 10: any explicit reconciliation SLA/process documentation, third-party audit or attestation of ledger-to-bank-balance matching, and any commentary addressing the Synapse-style failure mode directly.", "evidenceIds": [ "column-docs-8", "column-docs-9", "column-docs-2" ] }, { "productId": "column", "storyId": "limits-holds-controls", "verdict": "partial", "quality": 2, "confidence": "low", "rationale": "Only a single thin community mention (comm-7) references per-account-number permissions and limits, hinting at some risk-control primitives, but there is no documentation of transaction/velocity limit configuration, holds on suspicious activity, account freezes, or reinstatement paths. missing for 10: documented velocity/transaction limit APIs, hold/freeze mechanisms, reinstatement workflow documentation, per-program risk configuration.", "evidenceIds": [ "column-comm-7" ] }, { "productId": "column", "storyId": "onboarding-review-controls", "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": "column", "storyId": "openness-api-parity", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Column's documentation shows an extensive, comprehensive API surface (accounts, wires, ACH, checks, SWIFT, real-time payments, cards, reporting, webhooks) with OpenAPI spec for SDK generation, and explicitly notes some features like webhooks can be configured 'via APIs or Dashboard' implying parity; a Column engineer also states most customers prefer raw HTTP APIs over SDKs, reinforcing API-first design. Missing for 10: an explicit statement or audit confirming every dashboard-only admin/config feature has an API equivalent, and independent verification of full UI-API parity beyond webhooks.", "evidenceIds": [ "column-docs-2", "column-docs-4", "column-docs-5", "column-docs-6", "column-docs-7", "column-docs-9", "column-docs-10", "column-comm-1" ] }, { "productId": "column", "storyId": "openness-full-export", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Column documents open, standard export formats for account data (CSV, JSON, Parquet reports) and API access to raw transaction/wire message data, plus a public OpenAPI spec for building custom integrations, which supports data portability for an AI-native user. However there is no explicit documentation of a full account-data export or an account-closure/migration workflow addressing 'leaving' the platform. Missing for 10: explicit full-account export/backup feature, documented account closure/data migration process, independent confirmation of export completeness.", "evidenceIds": [ "column-docs-8", "column-docs-12", "column-docs-10", "column-docs-9" ] }, { "productId": "column", "storyId": "openness-open-license", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Column is a banking-as-a-service API platform, not open-source software; source-code openness is a category error for this kind of product, not a missing capability.", "evidenceIds": [] }, { "productId": "column", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Column is a chartered bank offering banking-as-a-service via hosted APIs; self-hosting a bank's core infrastructure is not a coherent capability for this product category.", "evidenceIds": [] }, { "productId": "column", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Column is a US-chartered banking/payments API platform; data residency/region selection is not a relevant axis for this category as it operates as a single US bank entity, not a multi-region data platform.", "evidenceIds": [] }, { "productId": "column", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Column is a banking/payments infrastructure API, not an AI model or AI training data pipeline; preventing data from being used for AI model training is not an applicable axis for this product category.", "evidenceIds": [] }, { "productId": "column", "storyId": "privacy-retention-controls", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Column is a banking-as-a-service API platform for payments, accounts, and cards, not an AI tool that processes user data/conversations subject to retention controls; data retention/deletion for AI usage is a category mismatch for this product's role.", "evidenceIds": [] }, { "productId": "column", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Column is a banking/payments API platform, not an AI agent or tool with telemetry/usage-tracking settings relevant to AI-native privacy opt-out; the evidence pack contains no mention of telemetry collection at all, making this a category mismatch rather than an unmet capability.", "evidenceIds": [] }, { "productId": "column", "storyId": "program-limits-scaling", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence pack item documents program-level transaction/volume limits, approval or underwriting stages, or a defined process for raising limits as a growing customer scales; docs cover product features (wires, ACH, cards, checks) but not risk/compliance limit governance. Community threads mention account permissioning per sub-account but not program-wide growth limits or escalation paths.", "evidenceIds": [] }, { "productId": "column", "storyId": "realtime-balances-events", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Column documents configurable webhooks for transaction/event notifications and a unified endpoint to query transfers across payment types, supporting an event-driven integration pattern, but there is no explicit documentation of balance reads reflecting holds/pending activity or a full enumeration of webhook events per transaction state change. missing for 10: explicit balance-with-holds/pending semantics, a complete list of webhook events per state transition, and independent confirmation of real-time accuracy.", "evidenceIds": [ "column-docs-7", "column-docs-9", "column-docs-8" ] }, { "productId": "column", "storyId": "statements-tax-documents", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack mentions monthly statement generation or 1099-INT tax document production/retrieval via API; reports mentioned are transaction/summary CSV/JSON/Parquet exports, not statements or tax forms.", "evidenceIds": [] }, { "productId": "column", "storyId": "transaction-data-quality", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Column documents raw rail-level data access (full raw wire messages), a unified cross-rail transfers endpoint, and structured reporting/webhooks, suggesting transaction data goes beyond a raw bank feed. However, there is no explicit documentation of counterparty enrichment fields, stable transaction identifiers across rails, or a described enrichment/categorization layer for building customer-facing product experiences. Missing for 10: explicit counterparty detail schema, documented stable identifier scheme across payment rails, and independent/hands-on verification of enrichment depth beyond raw message passthrough.", "evidenceIds": [ "column-docs-12", "column-docs-9", "column-docs-8", "column-docs-7" ] }, { "productId": "column", "storyId": "virtual-account-numbers", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Column's docs explicitly support programmatic bank account creation including FBO, sweep, clearing and custom account types (column-docs-2), and community evidence confirms per-account-number permissioning ('Create account numbers that point to a single bank account and create specific permissions and limits for each one') which maps to virtual/sub-account use cases (column-comm-7). This directly supports issuing unique account/routing numbers at scale for reconciliation and sub-account structures. Missing for 10: explicit documentation of routing-number issuance mechanics and a dedicated 'virtual accounts' or 'sub-accounts' product page with scale/rate-limit details.", "evidenceIds": [ "column-docs-2", "column-comm-7", "column-docs-9" ] }, { "productId": "column", "storyId": "wires-instant-rails", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Column's docs explicitly cover domestic wires (with raw message access), RTP and FedNow send/receive/RFP through unified APIs, plus a unified transfers query endpoint across payment types, all under one OpenAPI-defined API surface. Per-rail nuances (e.g., wire raw data, simulate endpoints for sandbox testing) are documented, meeting the developer story well. Missing for 10: independent hands-on verification of RTP/FedNow origination beyond docs, and more granular per-rail limits/SLA documentation.", "evidenceIds": [ "column-docs-6", "column-docs-9", "column-docs-12", "column-docs-3", "column-docs-10", "column-probe-2" ] }, { "productId": "column", "storyId": "yield-interest-options", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Column documents that it supports 'sweep' as one of its bank account types (alongside FBO, clearing, custom), which addresses the 'documented sweep options' half of the story, but there is no mention anywhere of interest-bearing accounts, rate mechanics, or who keeps the spread. Missing for 10: interest rate documentation, spread/economics disclosure, and any explanation of how sweep proceeds are shared.", "evidenceIds": [ "column-docs-2", "column-comm-6" ] }, { "productId": "increase", "storyId": "account-opening-api", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Increase documents FDIC-insured deposit accounts at partner banks (increase-docs-13), full Sandbox parity for testing before launch (increase-docs-6), and API-driven account/entity workflows including compliance validations and programmatic account number issuance (increase-docs-12, increase-docs-7). Community evidence corroborates the white-label bank-partner insured account model (increase-comm-1). Missing for 10: explicit end-to-end documentation of the entity/application submission and account-activation API calls (KYC/KYB flow) and independent confirmation that sandbox behavior exactly mirrors production account approval outcomes.", "evidenceIds": [ "increase-docs-13", "increase-docs-6", "increase-docs-12", "increase-docs-7", "increase-comm-1" ] }, { "productId": "increase", "storyId": "ach-origination", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Docs confirm ACH transfer origination via POST /ach_transfers, approval holds, and webhooks for real-time events, showing the core API-first-class credit path with async notifications. However, the evidence pack contains no mention of debit-side ACH, same-day ACH windows, or return/NOC/reversal objects as first-class API entities with webhooks, which are central to the story. missing for 10: same-day ACH window support, explicit ACH debit examples, return/NOC/reversal object modeling and their webhook events.", "evidenceIds": [ "increase-docs-1", "increase-docs-5", "increase-docs-8", "increase-docs-6" ] }, { "productId": "increase", "storyId": "agent-operated-account", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Increase's docs show general transfer APIs, holds, and optional human approval for transfers, but there is no evidence of a named feature for AI-agent scoped credentials with amount caps and counterparty allowlists — the story's specific banking-agent-access capability is unevidenced.", "evidenceIds": [ "increase-docs-1", "increase-docs-8", "increase-docs-14" ] }, { "productId": "increase", "storyId": "agent-reads-banking-state", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Increase offers a full REST/JSON API (with OpenAPI spec) covering accounts, account numbers, transfers (ACH/wire/RTP/check), holds, webhooks for real-time events, and sandbox simulation — a clean programmatic surface well-suited to agentic access rather than dashboard scraping. However, there is no explicit MCP server offering, and no direct evidence of a unified 'documents' or transaction-history read endpoint being called out, nor confirmation of an agent-specific integration pattern. missing for 10: dedicated MCP server/tooling, explicit documents/statements API evidence, and independent hands-on confirmation of agent-based read access.", "evidenceIds": [ "increase-docs-1", "increase-docs-7", "increase-docs-14", "increase-docs-5", "increase-docs-6", "increase-probe-3", "increase-probe-2" ] }, { "productId": "increase", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Increase directly hosts an llms.txt file (HTTP 200 confirmed) and full markdown-formatted documentation (documentation.md) alongside a machine-readable OpenAPI spec, giving agents multiple structured entry points. Missing for 10: independent/community confirmation that agents actually consume these files successfully in practice.", "evidenceIds": [ "increase-probe-1", "increase-probe-2", "increase-probe-3" ] }, { "productId": "increase", "storyId": "agentic-ai-insights", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Increase is a banking/payments infrastructure API, not a data analytics or insights product; there is no axis for AI-generated insights/suggestions from user data — this is a category error for this product type.", "evidenceIds": [] }, { "productId": "increase", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Increase's webhook system and Real-Time Decision objects let a developer's application react automatically to transfers, card authorizations, and compliance events without manual polling (increase-docs-5, increase-docs-15), and holds/approval workflows (increase-docs-8, increase-docs-14) support autonomous background processes. However, there is no evidence of a dedicated automation/rules engine, scheduled or recurring transfer automation, or any AI-agent-specific orchestration—only generic webhook callbacks. Missing for 10: native scheduling/recurring automation features, AI-agent-specific automation tooling, and independent evidence of autonomous background automation working reliably in production.", "evidenceIds": [ "increase-docs-5", "increase-docs-15", "increase-docs-8", "increase-docs-14", "increase-docs-6" ] }, { "productId": "increase", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Increase is a banking/payments API platform, not a product with a user-facing built-in AI assistant to delegate tasks to; this axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "increase", "storyId": "agentic-headless", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Increase is a REST/API-first banking platform with a documented OpenAPI spec, sandbox with simulation APIs, and a CLI (increase-cli), all of which support headless/CI-style automation. However, there is no explicit evidence of CI-specific tooling (e.g., GitHub Actions, CI recipes), automated testing pipelines, or documentation framing the CLI/API for CI/automation workflows specifically. missing for 10: CI/CD integration examples, automated testing docs in CI, evidence the CLI is designed for pipeline/scripted use beyond ad hoc manual invocation.", "evidenceIds": [ "increase-docs-6", "increase-probe-3", "increase-probe-4" ] }, { "productId": "increase", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Increase is a banking/payments API platform, not an AI agent or MCP client/host; nothing in the evidence indicates a workflow where the user plugs MCP servers into Increase itself. This story applies to AI-native tools/agents, not to a banking API service.", "evidenceIds": [] }, { "productId": "increase", "storyId": "agentic-mcp-server", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Increase is a banking-API platform, so publishing an official MCP server for agent connectivity is a fair question, but the evidence pack shows only REST API docs, an OpenAPI spec, a CLI, and webhooks—no mention of an MCP server or MCP integration anywhere.", "evidenceIds": [] }, { "productId": "increase", "storyId": "agentic-nl-commands", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence shows Increase is a REST/JSON banking API with docs, OpenAPI spec, and a CLI, but nothing indicates a natural-language command interface, chat/agent layer, or NL-to-API translation capability.", "evidenceIds": [] }, { "productId": "increase", "storyId": "agentic-official-cli", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "There is a probe indicating an official GitHub repo for an Increase CLI (increase-cli), suggesting a first-party CLI exists, but no docs pack content describes its features, installation, or AI-native/agentic usage. Missing for 10: detailed documentation of the CLI's capabilities, examples of agentic/AI-native use, and independent corroboration of its functionality.", "evidenceIds": [ "increase-probe-4" ] }, { "productId": "increase", "storyId": "agentic-public-api", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Increase is fundamentally API-first: full documented REST endpoints for transfers, accounts, webhooks, sandbox/simulation, and OpenAPI spec are published (increase-docs-1..15, increase-probe-3), plus an official CLI (increase-probe-4) and llms.txt discovery endpoint aimed at AI-native consumption. Community feedback corroborates strong API design quality relative to peers (increase-comm-3,5,7). Missing for 10: independent hands-on report specifically confirming AI-agent-driven API usage rather than general developer usage.", "evidenceIds": [ "increase-docs-1", "increase-docs-5", "increase-docs-6", "increase-probe-1", "increase-probe-2", "increase-probe-3", "increase-probe-4", "increase-comm-3", "increase-comm-5", "increase-comm-7" ] }, { "productId": "increase", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence of scoped or least-privilege API key/credential issuance for agents (e.g., granular permission scopes, per-agent API keys, or role-based access controls); evidence covers transfers, webhooks, sandbox, and general API design but nothing about credential scoping. Missing for 10: scoped API key creation, permission/role-based access controls, agent-specific credential issuance documentation.", "evidenceIds": [] }, { "productId": "increase", "storyId": "agentic-sdks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows an OpenAPI spec, a CLI, and llms.txt/docs, but nothing in the pack documents official client SDKs (e.g., Python, Ruby, Node libraries) that AI-native developers could build against beyond the CLI tool.", "evidenceIds": [ "increase-probe-3", "increase-probe-4" ] }, { "productId": "increase", "storyId": "agentic-webhooks", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Increase's docs explicitly describe a webhooks system for subscribing to events (transaction updates, real-time decisions) so applications can programmatically react, and this is corroborated by the docs.md overview mentioning real-time webhooks for card authorizations. Missing for 10: no explicit webhook subscription management API details (e.g., listing/creating subscriptions) or independent third-party confirmation of webhook reliability.", "evidenceIds": [ "increase-docs-5", "increase-docs-15", "increase-docs-6" ] }, { "productId": "increase", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows only static markdown documentation and a raw OpenAPI spec, with no mention of an interactive API reference or runnable/try-it-out examples anywhere in the pack.", "evidenceIds": [ "increase-probe-3", "increase-probe-2", "increase-docs-1" ] }, { "productId": "increase", "storyId": "api-machine-spec", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "The evidence pack directly confirms a machine-readable OpenAPI spec is publicly downloadable at https://increase.com/openapi.json (HTTP 200, contains 'openapi' key), plus an llms.txt and full documentation.md index for AI-native discovery. Missing for 10: no independent/community confirmation of spec usage or completeness details beyond the probe check.", "evidenceIds": [ "increase-probe-3", "increase-probe-1", "increase-probe-2" ] }, { "productId": "increase", "storyId": "api-sandbox", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Increase's official docs state every API and dashboard feature is available in Sandbox, including Simulation APIs only available there, letting developers test transfers, cards, webhooks, etc. without touching production/real money. missing for 10: independent hands-on confirmation of sandbox fidelity and no explicit mention of test-data isolation guarantees beyond docs.", "evidenceIds": [ "increase-docs-6" ] }, { "productId": "increase", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack has extensive API documentation, an OpenAPI spec, and a CLI, but contains no mention of API versioning strategy or a documented deprecation policy for endpoints. Missing for 10: explicit API versioning scheme, deprecation policy documentation, changelog/migration guides for breaking changes.", "evidenceIds": [] }, { "productId": "increase", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Increase's docs describe individual transfer creation endpoints (ACH, wire, RTP, checks) and the ability to instantly create multiple account numbers, but there is no evidence of a batch/bulk API endpoint (e.g., submitting many transfers in a single call) or bulk listing/processing operations across many items at once.", "evidenceIds": [ "increase-docs-1", "increase-docs-2", "increase-docs-7", "increase-docs-6" ] }, { "productId": "increase", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Increase supports event-driven automation via webhooks and Real-Time Decisions, letting external code react to transaction events, and approval holds add a manual gating rule, but there's no evidence of a built-in rule engine where users define declarative 'if event X then action Y' automation inside Increase itself — it always requires custom code on the receiving end. Missing for 10: native rule/condition builder, in-platform automation logic beyond webhooks, and evidence of complex multi-condition triggers.", "evidenceIds": [ "increase-docs-5", "increase-docs-15", "increase-docs-8" ] }, { "productId": "increase", "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": "increase", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Increase is a banking/payments API platform, not an automation/workflow tool with versionable automations to review or roll back; this axis is a category error for its product type.", "evidenceIds": [] }, { "productId": "increase", "storyId": "builtin-ai-banking-ops", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence Increase ships built-in AI features like natural-language transaction search, drafted dispute/alert responses, or anomaly summaries; all evidence covers banking-rail APIs (ACH, wire, RTP, checks), compliance, and webhooks with no AI/NLP capability mentioned.", "evidenceIds": [] }, { "productId": "increase", "storyId": "card-disputes-rege", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers transfers, accounts, holds, webhooks, compliance validations, and card authorization decisions, but contains no mention of dispute handling, Reg E investigation timelines, provisional credit mechanics, or documented ops responsibilities for card/ACH disputes. Since Increase issues cards and ACH transfers, this is a fair axis, but no supporting evidence exists.", "evidenceIds": [] }, { "productId": "increase", "storyId": "check-support", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Increase supports programmatic check issuance (Check Transfers via API, with printing/mailing/tracking handled by Increase) per increase-docs-4, but there is no evidence in the pack of check deposit or image capture (e.g., check deposit/RDC endpoints) functionality. missing for 10: check deposit API/image capture documentation, evidence of inbound check image submission, independent confirmation of check deposit workflow.", "evidenceIds": [ "increase-docs-4", "increase-docs-10" ] }, { "productId": "increase", "storyId": "compliance-program-tooling", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Evidence shows Increase provides entity validation data via API and flags data issues for follow-up (compliance-overview.md), implying some compliance tooling and a duty split with the platform, but there's no evidence of dedicated transaction monitoring, sanctions screening, case management for alerts, or SAR-filing support tools. missing for 10: transaction monitoring tooling, sanctions screening workflow, alert case management UI, SAR filing support, explicit ops-role division documentation.", "evidenceIds": [ "increase-docs-12" ] }, { "productId": "increase", "storyId": "debit-card-issuance", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "The docs index (probe-2) lists a 'Cards' product category with a '3D Secure' page, and increase-docs-15 confirms real-time authorization decisioning for card transactions, indicating Increase does issue cards through its API. However, the evidence pack contains no explicit confirmation of virtual vs. physical card issuance, spend control mechanisms, or digital wallet (Apple Pay/Google Pay) provisioning. Missing for 10: documentation on physical card issuance/shipping, spend limit/control APIs, and digital wallet tokenization support.", "evidenceIds": [ "increase-probe-2", "increase-docs-15" ] }, { "productId": "increase", "storyId": "direct-bank-relationship", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Community evidence confirms Increase is a middleware/BaaS layer with named partner banks (First Internet Bank, Blue Ridge Bank) holding customer funds, and docs mention FDIC insurance via IntraFi network banks, giving founders some clarity on the sponsor-model structure. However, the evidence pack lacks explicit first-party documentation on failure scenarios (what happens to customer funds/accounts if Increase itself fails), lacks a clear charter/entity org chart, and doesn't address pass-through deposit insurance mechanics in depth. missing for 10: first-party docs on platform-failure contingency for customers, explicit charter/entity disclosure page, detail on pass-through insurance mechanics beyond one line, independent verification of bank-failure handling.", "evidenceIds": [ "increase-comm-1", "increase-docs-13" ] }, { "productId": "increase", "storyId": "fbo-structure-transparency", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Increase documents some structural transparency — accounts are held at partner banks (First Internet Bank/Blue Ridge Bank) rather than Increase itself, and FDIC insurance is available via participating IntraFi network banks — plus features like unique Account Numbers per counterparty for reconciliation. However, there's no explicit documentation of FBO pooled vs individual account structure, or of who can access/view the ledger. Missing for 10: explicit FBO-pool vs individual-account structural documentation, detailed FDIC insurance attachment mechanics, and ledger visibility/access-control documentation.", "evidenceIds": [ "increase-docs-13", "increase-docs-7", "increase-docs-10", "increase-comm-1" ] }, { "productId": "increase", "storyId": "fraud-loss-allocation", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers ACH/wire/RTP transfer mechanics, entity validation, holds, and real-time card decisioning, but nowhere states who bears financial liability for ACH return fraud, card disputes, or account takeover losses. No documented liability split or fraud-loss allocation is present alongside the prevention tooling.", "evidenceIds": [] }, { "productId": "increase", "storyId": "international-payments", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "All evidence describes US domestic rails only (ACH, domestic wire, RTP, FedNow, checks) with no mention of SWIFT, international wires, FX rates, or a currency/corridor coverage map. Missing for 10: any documentation of cross-border wire/SWIFT support, FX rate transparency, or supported currencies/corridors.", "evidenceIds": [ "increase-docs-2", "increase-docs-3", "increase-docs-11", "increase-docs-13" ] }, { "productId": "increase", "storyId": "kyc-kyb-onboarding", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Only compliance-overview.md is cited, noting that 'Entity validations' are available via the API and developers should follow up on data issues — implying some identity verification API exists, but there's no detail on document collection, watchlist/AML screening, or an explicit application state model for KYC/KYB. Missing for 10: explicit KYC vs KYB entity types, document upload/collection API, watchlist screening details, and documented application state machine (e.g. pending_review, requires_information, approved).", "evidenceIds": [ "increase-docs-12" ] }, { "productId": "increase", "storyId": "ledger-bank-reconciliation", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows Increase's transfer/account APIs and general banking features, but contains no documentation of a formal daily ledger-to-bank-core reconciliation process (the Synapse-failure-mode issue) — no reconciliation reports, balance-attestation, or audit mechanism between Increase's API records and the partner bank's (First Internet Bank/Blue Ridge Bank) core ledger is mentioned. Missing for 10: documented reconciliation cadence/process, bank-core balance verification API or report, any third-party audit or attestation of ledger accuracy.", "evidenceIds": [ "increase-docs-10", "increase-comm-1" ] }, { "productId": "increase", "storyId": "limits-holds-controls", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Increase documents holds on accounts to reserve funds (docs-14), optional approval holds on transfers (docs-8), real-time card authorization decisions (docs-15), and entity/compliance validations (docs-12), which together support some risk-control primitives. However there is no explicit documentation of configurable transaction/velocity limits per account or program, nor documented account-freeze and reinstatement workflows. Missing for 10: explicit velocity/transaction limit configuration, documented account freeze mechanism, and reinstatement path documentation.", "evidenceIds": [ "increase-docs-14", "increase-docs-8", "increase-docs-15", "increase-docs-12", "increase-docs-5" ] }, { "productId": "increase", "storyId": "onboarding-review-controls", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence shows only an API for Entity validations (increase-docs-12) that developers must poll and follow up on, but no evidence of an ops-facing queue/dashboard where a human operator can see why an application is pending, request/upload documents, or see a clear division between Increase's automated decisions and the bank's own decisions. This is a plausible axis for a banking-onboarding platform, but nothing in the pack demonstrates such an ops workflow tool exists.", "evidenceIds": [ "increase-docs-12" ] }, { "productId": "increase", "storyId": "openness-api-parity", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Increase's docs explicitly state that 'Every API and dashboard feature is available in Sandbox,' and the extensive first-party API coverage (transfers, approvals, holds, entity validation, webhooks, account numbers) mirrors dashboard functionality, indicating strong API/UI parity by design as an API-first banking platform. missing for 10: independent/hands-on confirmation that literally every dashboard feature (e.g., admin/user management, reporting UI) has a 1:1 API equivalent, and no explicit statement of full parity outside Sandbox context.", "evidenceIds": [ "increase-docs-6", "increase-docs-1", "increase-docs-2", "increase-docs-7", "increase-docs-8", "increase-docs-14", "increase-probe-3" ] }, { "productId": "increase", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence shows Increase exposes account, transfer, and entity data via a REST/JSON API and webhooks, but there is no documented bulk data-export feature, open-format data dump, or migration/offboarding tooling that would let a customer pull all their data and leave. Banking data portability is a fair axis for a financial API platform, so absence of such evidence is 'none' rather than 'na'.", "evidenceIds": [ "increase-docs-6", "increase-docs-7", "increase-probe-2" ] }, { "productId": "increase", "storyId": "openness-open-license", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Increase is a closed-source banking API platform; there is no evidence of an open-source license for its core product source. Source availability under open license is not a fair axis for a proprietary SaaS banking API—only its CLI/SDKs might be open, but no such claim is made here.", "evidenceIds": [] }, { "productId": "increase", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Increase is a hosted banking-as-a-service API built on regulated bank partnerships (First Internet Bank, Blue Ridge Bank); self-hosting a banking core infrastructure is not a meaningful capability for this product category, unlike self-hostable software tools.", "evidenceIds": [ "increase-comm-1" ] }, { "productId": "increase", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Increase is a banking/payments API; the evidence pack contains no mention of data residency/region selection controls for stored data. Missing for 10: any documentation of regional data storage options, residency guarantees, or geographic controls over where account/customer data is held.", "evidenceIds": [] }, { "productId": "increase", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Increase is a banking/payments API platform, not an AI model or AI product with training data policies; this AI-training-data opt-out story is a category error for this product type.", "evidenceIds": [] }, { "productId": "increase", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers Increase's banking/payments API features (transfers, webhooks, sandbox, compliance validations) but contains no mention of data retention policies, data deletion controls, or any privacy-posture controls for customers to manage their own data lifecycle. As a platform handling sensitive financial and entity data, this axis is a fair question, but no evidence shows Increase offers retention/deletion controls.", "evidenceIds": [] }, { "productId": "increase", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Increase is a banking/payments API platform, not an AI agent or dev tool with client-side telemetry concerns; opt-out of telemetry/usage tracking is not a relevant axis for this kind of product's evidence pack, which focuses on payment rails and compliance.", "evidenceIds": [] }, { "productId": "increase", "storyId": "program-limits-scaling", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Increase documents an approval-hold feature for transfers (a team-member approval stage) and compliance/entity validation, but there is no evidence of documented program-level transaction/volume limits or a defined process for raising them as growth scales. missing for 10: explicit documentation of program-level limits (transaction/volume caps), and a documented escalation/raise-limit process.", "evidenceIds": [ "increase-docs-8", "increase-docs-12" ] }, { "productId": "increase", "storyId": "realtime-balances-events", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Increase documents holds that reduce available balance without moving money (real-time balance reflecting pending activity) and a webhooks system that fires for transaction events, including real-time decision webhooks for card authorizations. However, evidence doesn't explicitly confirm webhooks cover 'every transaction state change' comprehensively or that balance reads are guaranteed real-time/event-driven at the API level beyond the holds mechanism. missing for 10: explicit documentation of webhook event catalog per transfer/transaction type, confirmation of real-time balance API semantics, independent/hands-on verification that webhooks reliably mirror bank state changes.", "evidenceIds": [ "increase-docs-14", "increase-docs-15", "increase-docs-5", "increase-docs-6" ] }, { "productId": "increase", "storyId": "statements-tax-documents", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack mentions monthly account statements or 1099-INT tax document generation/retrieval via API; the documentation covers transfers, holds, webhooks, and compliance validations but not statements or tax forms. Missing for 10: any mention of statement generation, statement retrieval endpoints, or 1099-INT/tax document APIs.", "evidenceIds": [] }, { "productId": "increase", "storyId": "transaction-data-quality", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Increase provides transfer creation with recipient data, stable Account Numbers for reconciliation, real-time decision/webhook events, entity validation, and rail-specific metadata (ACH, wire, RTP, FedNow, check) — supporting rich transaction context for in-product use. However, evidence doesn't show detailed counterparty enrichment (e.g., merchant category codes, geolocation, standardized counterparty profiles) or explicit transaction-level enrichment beyond basic transfer/account data. missing for 10: explicit counterparty enrichment fields (merchant/category data), documented transaction object schema showing enrichment depth, independent developer confirmation of data richness beyond transfer creation.", "evidenceIds": [ "increase-docs-1", "increase-docs-2", "increase-docs-3", "increase-docs-7", "increase-docs-10", "increase-docs-12", "increase-docs-15", "increase-docs-11" ] }, { "productId": "increase", "storyId": "virtual-account-numbers", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Increase's docs confirm the core capability: instantly creating multiple Account Numbers per Account, programmatically, and explicitly for per-investor/per-customer reconciliation across payment rails — matching the virtual-account/reconciliation use case well. However, evidence does not clearly address 'sub-accounts under a master structure' at scale (e.g., hierarchical account structures beyond multiple account numbers on one account), nor bulk/scale provisioning details or limits. missing for 10: explicit documentation of hierarchical sub-account/master-account structures, bulk-issuance scale limits, and independent/hands-on validation of the reconciliation workflow at scale.", "evidenceIds": [ "increase-docs-7", "increase-docs-10", "increase-docs-14" ] }, { "productId": "increase", "storyId": "wires-instant-rails", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Docs show wire transfers (POST /wire_transfers), RTP with instant settlement and reachability checks, and FedNow origination with reachability/fallback logic, all through the same REST API, plus receipt support via multi-rail Account Numbers (wire, RTP, ACH, check) confirming both origination and receipt paths. Missing for 10: explicit FedNow receipt-specific docs and independent hands-on confirmation of FedNow/RTP receipt flows beyond the account-number mention.", "evidenceIds": [ "increase-docs-2", "increase-docs-3", "increase-docs-9", "increase-docs-11", "increase-docs-10", "increase-comm-3" ] }, { "productId": "increase", "storyId": "yield-interest-options", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers transfers, holds, FDIC insurance via IntraFi network, and compliance, but contains no mention of interest-bearing accounts, sweep programs, rate mechanics, or spread-sharing arrangements for idle balances.", "evidenceIds": [] }, { "productId": "stripe-treasury", "storyId": "account-opening-api", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Docs confirm financial accounts can be created and funded via API (money_manager configuration, OutboundPayments, Connect flows), but the evidence pack never states that these accounts are FDIC-insured deposit accounts, nor does it mention any sandbox/test-mode parity for the Treasury account-opening flow. missing for 10: explicit FDIC/insurance documentation, sandbox-vs-production parity evidence, full automated 'application to active account' onboarding details.", "evidenceIds": [ "stripe-treasury-docs-2", "stripe-treasury-docs-7", "stripe-treasury-docs-9", "stripe-treasury-docs-3" ] }, { "productId": "stripe-treasury", "storyId": "ach-origination", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence describes Treasury's general money-movement objects (OutboundPayment, ReceivedDebit, financial accounts, transactions) but never mentions ACH-specific mechanics like same-day windows, NOCs, or return/reversal objects with webhooks — the core of this story's ask is unaddressed.", "evidenceIds": [ "stripe-treasury-docs-10", "stripe-treasury-docs-11", "stripe-treasury-docs-13" ] }, { "productId": "stripe-treasury", "storyId": "agent-operated-account", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack documents Treasury's financial-account, Connect, and OutboundPayment features and even an MCP server listing, but nothing describes scoped credentials for agents with amount caps or counterparty allowlists, nor any vendor-named 'agent banking' use case. missing for 10: documentation of agent-scoped API keys/permissions, amount-cap enforcement, counterparty allowlist controls, and an explicit vendor-named agentic banking use case.", "evidenceIds": [ "stripe-treasury-docs-10", "stripe-treasury-probe-4" ] }, { "productId": "stripe-treasury", "storyId": "agent-reads-banking-state", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Stripe Treasury exposes a documented API for financial accounts, transactions, outbound/inbound payments, and received debits (docs-2,7,10,11,13), and Stripe has an official MCP server (probe-4), giving agents programmatic access without dashboard scraping. However, no evidence covers document retrieval (e.g., statements) via API/MCP, and no OpenAPI spec was found (probe-3), and it's unclear the MCP surface specifically exposes Treasury endpoints. Missing for 10: explicit document/statement API coverage, confirmation that the MCP server exposes Treasury-specific resources, and independent hands-on confirmation of MCP usage for banking data.", "evidenceIds": [ "stripe-treasury-docs-2", "stripe-treasury-docs-7", "stripe-treasury-docs-10", "stripe-treasury-docs-11", "stripe-treasury-docs-13", "stripe-treasury-probe-4", "stripe-treasury-probe-3" ] }, { "productId": "stripe-treasury", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe's shared docs platform confirms llms.txt exists at docs.stripe.com/llms.txt (HTTP 200) and per-page markdown versions (e.g., treasury.md) are served for agent consumption, which covers Treasury docs. Missing for 10: Treasury-specific llms.txt content (rather than site-wide) and independent confirmation an agent has successfully used it.", "evidenceIds": [ "stripe-treasury-probe-1", "stripe-treasury-probe-2" ] }, { "productId": "stripe-treasury", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence covers Treasury's banking-as-a-service features (financial accounts, payments, disclosures, fraud controls) but nothing about AI-generated insights or suggestions surfaced from user data within the product. missing for 10: any mention of AI/ML-driven analytics, insight generation, or in-product suggestions from financial data.", "evidenceIds": [] }, { "productId": "stripe-treasury", "storyId": "agentic-autonomous-automation", "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-treasury", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Treasury is a banking-as-a-service infrastructure product for building financial accounts, not a consumer-facing tool with a built-in AI assistant; delegating tasks to an embedded assistant is a category mismatch for this kind of API/backend product.", "evidenceIds": [] }, { "productId": "stripe-treasury", "storyId": "agentic-headless", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Treasury is exposed as a set of API objects (financial accounts, OutboundPayments, transactions) that can in principle be scripted/automated, and Stripe provides an official CLI, implying headless/API-driven usage is possible. However there is no evidence specifically addressing running Treasury in CI pipelines or headless automation workflows. missing for 10: explicit CI/automation documentation, examples of scripted/headless Treasury operations, evidence of CLI use for Treasury objects specifically.", "evidenceIds": [ "stripe-treasury-probe-5", "stripe-treasury-docs-10", "stripe-treasury-docs-13" ] }, { "productId": "stripe-treasury", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Treasury is a financial-account/banking-as-a-service API and dashboard product, not an agent, IDE, or assistant host that would consume external MCP servers to gain new tool capabilities. The evidence only shows Stripe exposing its own MCP server for others to connect to (probe-4), which is the opposite (server) role, not evidence of Treasury acting as an MCP client/host.", "evidenceIds": [ "stripe-treasury-probe-4" ] }, { "productId": "stripe-treasury", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 6, "confidence": "medium", "rationale": "Stripe documents an official MCP server at docs.stripe.com/mcp, which spans Stripe's platform including Treasury APIs, though Treasury-specific MCP tooling isn't separately detailed. Missing for 10: Treasury-specific MCP tool examples, independent/hands-on confirmation of MCP server usage with Treasury endpoints.", "evidenceIds": [ "stripe-treasury-probe-4" ] }, { "productId": "stripe-treasury", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "The only agenticness-relevant evidence is a probe confirming Stripe hosts an official MCP server (docs.stripe.com/mcp), which could in principle let an AI agent issue natural-language-driven commands against Stripe APIs, but no evidence ties this specifically to Treasury operations (financial accounts, OutboundPayments, etc.) or shows a working example of natural-language control of Treasury features. Missing for 10: Treasury-specific MCP tool coverage, documented natural-language examples/use cases, and independent confirmation that Treasury actions can be driven conversationally.", "evidenceIds": [ "stripe-treasury-probe-4" ] }, { "productId": "stripe-treasury", "storyId": "agentic-official-cli", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Stripe documents an official CLI at docs.stripe.com/stripe-cli, which applies platform-wide including Treasury's API. missing for 10: Treasury-specific CLI examples/workflows and independent hands-on confirmation of CLI usage with Treasury endpoints.", "evidenceIds": [ "stripe-treasury-probe-5" ] }, { "productId": "stripe-treasury", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe Treasury is accessed entirely through Stripe's documented REST API (financial accounts, OutboundPayments, transactions, received debits, etc.), with machine-readable docs (.md endpoints, llms.txt) and an official CLI, indicating a mature, documented public API surface suitable for AI-native/agentic consumption. Missing for 10: no discoverable OpenAPI/swagger spec was found (404s), and no independent hands-on developer report specifically validating AI-driven API usage.", "evidenceIds": [ "stripe-treasury-docs-7", "stripe-treasury-docs-10", "stripe-treasury-docs-11", "stripe-treasury-docs-13", "stripe-treasury-probe-1", "stripe-treasury-probe-2", "stripe-treasury-probe-3", "stripe-treasury-probe-5" ] }, { "productId": "stripe-treasury", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack contains no mention of scoped or restricted API keys, OAuth scopes, or any mechanism for issuing least-privilege credentials for agents within Stripe Treasury's documentation or community discussion. While such a capability is plausible for an API-driven financial product, nothing in the provided evidence demonstrates it.", "evidenceIds": [] }, { "productId": "stripe-treasury", "storyId": "agentic-sdks", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "The evidence pack only hints at an SDK ecosystem via a stray note about checking npm registry for 'Stripe packages' (stripe-treasury-probe-1); there is no dedicated documentation of official SDKs, language coverage, or Treasury-specific SDK usage. Missing for 10: explicit official SDK docs (e.g., stripe-node, stripe-python), Treasury-specific SDK code samples, and independent corroboration of SDK quality/coverage.", "evidenceIds": [ "stripe-treasury-probe-1" ] }, { "productId": "stripe-treasury", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack describes Treasury's financial-account features, money movement, and transaction tracking but never mentions webhooks, event objects, or event subscription mechanisms for Treasury activity. missing for 10: any documentation of Treasury-specific webhook events, event types (e.g., financial_account.updated, treasury.*), or subscription setup instructions.", "evidenceIds": [ "stripe-treasury-docs-13", "stripe-treasury-docs-14" ] }, { "productId": "stripe-treasury", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack includes general Treasury docs, llms.txt/docs-md probes, and CLI/MCP mentions, but nothing describes an interactive API reference with runnable/executable code examples for Treasury endpoints. The openapi.json probe even returned 404, suggesting no discoverable spec-driven reference was found in this pack.", "evidenceIds": [ "stripe-treasury-probe-3", "stripe-treasury-probe-2", "stripe-treasury-probe-1" ] }, { "productId": "stripe-treasury", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack explicitly probes for an OpenAPI/Swagger spec at all standard locations and finds only 404s, and no other evidence pack item links to a downloadable machine-readable API spec for Treasury; the docs offer markdown/llms.txt versions but not a formal OpenAPI schema.", "evidenceIds": [ "stripe-treasury-probe-3" ] }, { "productId": "stripe-treasury", "storyId": "api-sandbox", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Stripe generally offers test-mode/sandbox environments across its API, but no evidence in this pack specifically documents a Treasury sandbox or test-mode capability that isolates test data from production for financial account testing. Missing for 10: any documentation of Treasury-specific test mode, sandbox API keys, or test financial accounts.", "evidenceIds": [] }, { "productId": "stripe-treasury", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence pack items mention API versioning schemes or a documented deprecation policy for Stripe Treasury's APIs; docs cover product features, and probes find no OpenAPI spec, changelog, or version policy reference.", "evidenceIds": [] }, { "productId": "stripe-treasury", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack describes individual Treasury operations (fund accounts, outbound payments, received debits, transactions) but contains no mention of batch/bulk endpoints or multi-item operations for AI-native or programmatic bulk processing.", "evidenceIds": [] }, { "productId": "stripe-treasury", "storyId": "automation-rules-engine", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers financial-account creation, fund movement, transactions, and fraud controls, but nowhere describes a rules engine or event-triggered automation (e.g., 'if X happens, do Y automatically') configurable by users; automatic risk controls are pre-set by Stripe, not user-defined rules. Missing for 10: any documentation of user-defined conditional rules/triggers, an automation/rules API or webhook-based rule builder, or evidence of event-driven action configuration.", "evidenceIds": [ "stripe-treasury-docs-14", "stripe-treasury-docs-13" ] }, { "productId": "stripe-treasury", "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-treasury", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Treasury is a banking-as-a-service infrastructure product for storing/moving money, not an automation-building or workflow tool; versioning, reviewing, and rolling back 'automations' is not a concept that applies to this product category.", "evidenceIds": [] }, { "productId": "stripe-treasury", "storyId": "builtin-ai-banking-ops", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack describes built-in AI features for banking operations—no natural-language transaction search, no drafted dispute/alert responses, no anomaly summaries. The documentation only covers financial account management, connect integrations, fraud risk controls (automatic, non-AI-described), and money movement, none of which mention AI/LLM-based ops tooling. Missing for 10: any mention of natural-language search, AI-drafted dispute responses, anomaly summaries, or any AI/ML-powered ops feature.", "evidenceIds": [ "stripe-treasury-docs-14", "stripe-treasury-docs-13" ] }, { "productId": "stripe-treasury", "storyId": "card-disputes-rege", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack covers Treasury's account structure, connect integration, money movement, and fraud controls, but contains no mention of dispute handling, Reg E investigation timelines, provisional credit mechanics, or documented operational responsibilities for card/ACH disputes.", "evidenceIds": [] }, { "productId": "stripe-treasury", "storyId": "check-support", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence pack items mention check issuance, check deposit, or image capture capabilities within Stripe Treasury; documentation focuses on ACH, wires, card issuing, and internal transfers, not paper check handling.", "evidenceIds": [] }, { "productId": "stripe-treasury", "storyId": "compliance-program-tooling", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers automatic fraud/risk controls and disclosure requirements, but there is no mention of transaction monitoring workflows, sanctions/OFAC screening tooling, case management for compliance alerts, or SAR-filing support with defined ops/platform/bank duties. missing for 10: transaction monitoring, sanctions screening, alert case management, SAR-filing support/duty split.", "evidenceIds": [ "stripe-treasury-docs-14", "stripe-treasury-docs-12" ] }, { "productId": "stripe-treasury", "storyId": "debit-card-issuance", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Evidence confirms Stripe Issuing is integrated alongside Treasury (fraud controls cover 'Treasury and Issuing', and embedded UI can render 'bill pay, issuing, and cash rewards'), implying cards can be tied to Treasury financial accounts, but no documentation details virtual/physical card issuance flow, spend controls, or digital wallet support specifically for Treasury accounts. Missing for 10: explicit docs on issuing virtual/physical cards via API tied to a Treasury account, spend-control configuration, and digital wallet (Apple/Google Pay) provisioning details.", "evidenceIds": [ "stripe-treasury-docs-8", "stripe-treasury-docs-14" ] }, { "productId": "stripe-treasury", "storyId": "direct-bank-relationship", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Stripe documents a mandatory 'Treasury disclosure component' for compliance transparency (docs-12) and community discussion confirms partner-bank relationships (e.g., Goldman Sachs) exist and are scrutinized (comm-6), and the Evolve Bank breach thread shows real customer impact when a partner bank had problems (comm-1). However, there is no first-party documentation naming the specific sponsor bank(s), explaining FDIC pass-through insurance mechanics, or detailing what happens to end-customer funds if the platform or partner bank fails. missing for 10: explicit documentation of the sponsor-bank identity/relationship, FDIC insurance pass-through terms, and a documented failure/wind-down process for customer funds.", "evidenceIds": [ "stripe-treasury-docs-12", "stripe-treasury-comm-6", "stripe-treasury-comm-1" ] }, { "productId": "stripe-treasury", "storyId": "fbo-structure-transparency", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence covers general Treasury features (balances, funding flows, disclosures) but contains no documentation addressing FBO pooling vs individual account structure, where FDIC insurance attaches, or who has ledger visibility — the specific transparency the finance lead is asking about is absent.", "evidenceIds": [] }, { "productId": "stripe-treasury", "storyId": "fraud-loss-allocation", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Docs mention that Stripe runs automatic risk controls for fraud exposure within Treasury/Issuing, but there is no evidence documenting an explicit liability split for who bears ACH return fraud, card dispute losses, or account takeover losses. Missing for 10: explicit liability-split documentation for ACH return fraud, card disputes, and ATO losses; any first-party or independent confirmation of how losses are allocated between Stripe, the platform, and connected accounts.", "evidenceIds": [ "stripe-treasury-docs-14" ] }, { "productId": "stripe-treasury", "storyId": "international-payments", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence shows Treasury supports multi-currency balances (USD, EUR, GBP) and USDC, but there is no documentation of international wire/SWIFT transfers, FX rate transparency, or a coverage map of currencies/corridors. Missing for 10: cross-border wire/SWIFT transfer documentation, FX rate/spread transparency, and a documented list of supported currency corridors.", "evidenceIds": [ "stripe-treasury-docs-2" ] }, { "productId": "stripe-treasury", "storyId": "kyc-kyb-onboarding", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers Treasury's account funding, money movement, disclosures, and fraud controls, but never mentions KYC/KYB flows, document collection, watchlist screening, or application state modeling for verifying individuals or businesses onboarding to Treasury. This is a fair axis for a banking product since Treasury requires verified connected accounts, but no supporting evidence exists here.", "evidenceIds": [] }, { "productId": "stripe-treasury", "storyId": "ledger-bank-reconciliation", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence only shows Stripe Treasury lets platforms reconcile their own internal systems against Treasury's transaction feed (docs-13), not documented evidence that Stripe's ledger itself reconciles daily against the underlying partner bank's core records — the exact failure mode that broke Synapse-era programs. No first-party or independent evidence describes a bank-to-API reconciliation process, audit, or guarantee.", "evidenceIds": [ "stripe-treasury-docs-13" ] }, { "productId": "stripe-treasury", "storyId": "limits-holds-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The only relevant evidence describes Stripe's own automatic, built-in fraud/risk controls for Treasury and Issuing that 'do not require action to enable' — this is the opposite of what the story asks for (ops-configurable per-account/per-program transaction and velocity limits, manual holds, account freezes, and documented reinstatement paths). No documentation shows ops-facing controls for setting limits, freezing accounts, or reinstatement workflows. Missing for 10: any API/dashboard capability to set per-account transaction/velocity limits, manually place holds, freeze/unfreeze accounts, or documented reinstatement procedures.", "evidenceIds": [ "stripe-treasury-docs-14" ] }, { "productId": "stripe-treasury", "storyId": "onboarding-review-controls", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers financial account creation, money movement, disclosures, and fraud controls, but contains no mention of an onboarding queue, reasons for pending applications, document collection workflows, or a clear delineation between platform/ops decisions and the partner bank's decisions. This is a plausible axis for a banking-as-a-service product, but nothing in the docs or community evidence addresses it.", "evidenceIds": [] }, { "productId": "stripe-treasury", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Treasury is fundamentally API-first: financial accounts, OutboundPayments, ReceivedDebits, transactions, and disclosures are all API objects, and the Dashboard/mobile app view is described as just one access point built on top of these APIs (docs-4, docs-9, docs-10, docs-13). Platforms can even render Stripe-hosted UI components (bill pay, issuing) driven entirely by the API (docs-8), suggesting strong API/UI parity, but no evidence explicitly confirms every Dashboard action (e.g., manual account configuration, dispute handling, fraud review tools) has a corresponding API endpoint. missing for 10: explicit documentation enumerating full UI-to-API parity, independent confirmation that dashboard-only features (e.g., risk controls in docs-14) are also API-exposed.", "evidenceIds": [ "stripe-treasury-docs-4", "stripe-treasury-docs-8", "stripe-treasury-docs-9", "stripe-treasury-docs-10", "stripe-treasury-docs-13", "stripe-treasury-docs-14" ] }, { "productId": "stripe-treasury", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any data export, data portability tools, or open-format export functionality for Stripe Treasury; docs cover money movement, financial accounts, and compliance but nothing about exporting account/transaction data in open formats or an account-closure export path.", "evidenceIds": [] }, { "productId": "stripe-treasury", "storyId": "openness-open-license", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Treasury is a closed, proprietary banking-as-a-service product, not an open-source project; source code availability under an open license is not a fair axis for this kind of commercial financial API.", "evidenceIds": [] }, { "productId": "stripe-treasury", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Treasury is a regulated banking-as-a-service financial infrastructure product built on partner bank relationships; self-hosting a banking core is a category error, not a fair question for this product type.", "evidenceIds": [] }, { "productId": "stripe-treasury", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack addresses data residency, regional data storage choices, or geographic control over where customer/financial data is stored; documentation focuses on financial account features, money movement, and Connect integration rather than data-location controls.", "evidenceIds": [] }, { "productId": "stripe-treasury", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Treasury is a banking-as-a-service financial infrastructure product for storing/moving money, not an AI model or AI product with training data policies; opting out of AI training data usage is a category error for this product type.", "evidenceIds": [] }, { "productId": "stripe-treasury", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses data retention policies, deletion controls, or privacy/data-lifecycle management for Stripe Treasury; the documentation focuses on financial account features, money movement, and platform integration, not data governance controls for AI-native users.", "evidenceIds": [] }, { "productId": "stripe-treasury", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Treasury is a banking-as-a-service financial infrastructure product, not an AI agent/tool whose telemetry or usage-tracking opt-out would be relevant to an 'AI-native' user's privacy posture; this axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "stripe-treasury", "storyId": "program-limits-scaling", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack documents program-level limits, approval stages, or a documented path to raising limits — docs cover account features, money movement, and disclosures but not risk/limit escalation processes. One HN comment even highlights the landing page 'doesn't really explain' the underlying constraints, and another surfaces surprise breach notifications rather than transparent limit documentation, reinforcing the absence of documented escalation paths.", "evidenceIds": [ "stripe-treasury-comm-5", "stripe-treasury-comm-1" ] }, { "productId": "stripe-treasury", "storyId": "realtime-balances-events", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Docs mention using 'transactions' to build account activity feeds and reconcile against internal systems, implying a transaction-log based ledger, but there is no explicit documentation of webhook events for transaction state changes or of balance reads that reflect holds/pending activity as described in the story. missing for 10: explicit webhook event types for Treasury transaction lifecycle, documentation of balance fields showing holds/pending vs settled amounts, and any independent/hands-on confirmation of real-time event delivery.", "evidenceIds": [ "stripe-treasury-docs-13" ] }, { "productId": "stripe-treasury", "storyId": "statements-tax-documents", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence in the pack mentions monthly statement generation or 1099-INT tax document production/retrieval via API for Treasury financial accounts; docs cover fund movement, disclosures, fraud controls, and connect features but not statements or tax forms.", "evidenceIds": [] }, { "productId": "stripe-treasury", "storyId": "transaction-data-quality", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Docs mention that Treasury transactions can be used to build account activity feeds and reconcile against internal systems, implying transaction records exist, but there is no detail on counterparty data, rail-specific metadata, stable identifiers, or enrichment fields. missing for 10: documentation of transaction object schema (counterparty fields, rail metadata like ACH/wire trace numbers, stable IDs), examples of enrichment/categorization, independent developer corroboration of usability of raw feed data.", "evidenceIds": [ "stripe-treasury-docs-13" ] }, { "productId": "stripe-treasury", "storyId": "virtual-account-numbers", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs confirm Stripe Treasury lets platforms create per-connected-account financial accounts (money_manager configuration) that can hold funds, move money, and be used for reconciliation via transactions/activity feeds — supporting sub-account and per-customer account provisioning at scale. However, the evidence never explicitly confirms that each financial account gets unique account and routing numbers, nor details on bulk/programmatic issuance mechanics beyond account creation. Missing for 10: explicit documentation of unique account/routing number assignment per financial account, and evidence of scale/bulk provisioning workflows or API rate/volume specifics.", "evidenceIds": [ "stripe-treasury-docs-7", "stripe-treasury-docs-9", "stripe-treasury-docs-13", "stripe-treasury-docs-5" ] }, { "productId": "stripe-treasury", "storyId": "wires-instant-rails", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack never mentions domestic wires, RTP, or FedNow, nor any per-rail origination/receipt documentation—only generic OutboundPayment/ReceivedDebit constructs are described without rail specifics. missing for 10: any mention of wire, RTP, or FedNow rails, per-rail capability docs, and origination/receipt distinctions.", "evidenceIds": [ "stripe-treasury-docs-10", "stripe-treasury-docs-11", "stripe-treasury-docs-13" ] }, { "productId": "stripe-treasury", "storyId": "yield-interest-options", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack describes Treasury's account-holding, fund-movement, disclosure, and fraud-control features but contains no mention of interest-bearing balances, sweep programs, yield rates, or how any spread is split between Stripe/partner banks and the customer. Since financial-account products could plausibly offer this, the axis applies, but there is no evidence it delivers it.", "evidenceIds": [ "stripe-treasury-docs-2", "stripe-treasury-docs-3", "stripe-treasury-docs-9" ] }, { "productId": "synctera", "storyId": "account-opening-api", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Docs show a full programmatic path — customer creation (personal/business), KYC/watchlist verification, account creation, cards, transfers/wires, webhooks — and confirm sandbox API keys work immediately with the same API surface as production (synctera-docs-1/2/3/9/10/14, synctera-probe-1/2). However, the pack never explicitly states the accounts are FDIC-insured deposit accounts or confirms sandbox truly mirrors bank-approval/production parity beyond key issuance, so the specific 'insured deposit account' and full sandbox-to-prod fidelity claims are not directly evidenced. Missing for 10: explicit FDIC/insurance confirmation, and independent/hands-on confirmation of sandbox-to-production parity for the full account-opening flow.", "evidenceIds": [ "synctera-docs-1", "synctera-docs-2", "synctera-docs-3", "synctera-docs-9", "synctera-docs-14", "synctera-probe-1", "synctera-probe-2", "synctera-docs-17" ] }, { "productId": "synctera", "storyId": "ach-origination", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers internal transfers, domestic wires, scheduled payments, and webhooks generally, but contains no mention of ACH origination, credit/debit ACH types, same-day ACH windows, or ACH-specific unhappy-path objects like returns, NOCs, or reversals. Since Synctera is a banking-as-a-service platform where ACH is a plausible core money-movement capability, absence of evidence means this axis is unmet rather than inapplicable.", "evidenceIds": [] }, { "productId": "synctera", "storyId": "agent-operated-account", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Synctera's docs cover accounts, transfers, cards, KYC, and APIs generally, but there is no evidence of agent-specific scoped credentials, amount caps, counterparty allowlists, or any vendor-documented named feature for AI agents operating within policy. Missing for 10: named agent/AI credential scoping feature, amount cap enforcement docs, counterparty allowlist mechanism, any mention of AI agents at all.", "evidenceIds": [ "synctera-docs-5", "synctera-docs-14" ] }, { "productId": "synctera", "storyId": "agent-reads-banking-state", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Synctera exposes a broad REST/OpenAPI surface covering accounts, transactions, transfers, cards, external account balance/transaction retrieval, document verification, and webhook-driven event/pending-activity feeds, plus an llms.txt for AI discoverability — strongly supporting agent-readable banking data without screen-scraping. However there is no evidence of a dedicated MCP server or agent-specific read surface, only a general OpenAPI/webhook API. Missing for 10: explicit MCP server/tool endpoint, unified 'read full picture' aggregation endpoint, independent confirmation of AI-agent usage in production.", "evidenceIds": [ "synctera-docs-3", "synctera-docs-5", "synctera-docs-12", "synctera-docs-10", "synctera-docs-13", "synctera-probe-1", "synctera-probe-2" ] }, { "productId": "synctera", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "A direct probe confirms Synctera serves a valid llms.txt at docs.synctera.com/llms.txt listing structured doc bundles (v2, v0) for agent consumption, plus a machine-readable OpenAPI spec, matching the agent-oriented docs story. Missing for 10: no independent/community confirmation of agents actually using it successfully.", "evidenceIds": [ "synctera-probe-1", "synctera-probe-2" ] }, { "productId": "synctera", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Synctera is a banking-as-a-service API platform for core banking operations; evidence pack shows no AI-generated insights, analytics, or suggestion features derived from customer data. This is an applicable axis for a fintech data platform, but no evidence of any AI-driven insight capability exists.", "evidenceIds": [] }, { "productId": "synctera", "storyId": "agentic-autonomous-automation", "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": "synctera", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Synctera is a banking-as-a-service API/platform for building financial products, not a product with a built-in AI assistant persona for end users; the evidence pack covers banking APIs (accounts, cards, transfers, KYC) with no mention of any AI assistant feature. This axis is a category error for this type of infrastructure/API product.", "evidenceIds": [] }, { "productId": "synctera", "storyId": "agentic-headless", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Synctera is API-first (OpenAPI spec, sandbox API keys) which inherently supports programmatic/headless calls, and docs show you can call APIs immediately after obtaining a sandbox key. However there is no explicit CI/CD guidance, CLI tool, or automation example (e.g., GitHub Actions, test harness) showing headless operation in a pipeline. Missing for 10: explicit CI/automation documentation, CLI or SDK examples for pipeline integration, and confirmation of non-interactive auth flows suited for CI.", "evidenceIds": [ "synctera-docs-14", "synctera-probe-2", "synctera-probe-1" ] }, { "productId": "synctera", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Synctera is a banking-as-a-service platform, not an AI agent product; the evidence pack shows only banking/API documentation with no mention of MCP client capability. Plugging MCP servers into a product to extend its own agentic tool use is not a relevant axis for a BaaS platform's core offering.", "evidenceIds": [] }, { "productId": "synctera", "storyId": "agentic-mcp-server", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Synctera is a banking-as-a-service platform, so an official MCP server is a plausible axis, but the evidence pack shows only API docs, OpenAPI spec, and llms.txt — no mention of an MCP server or agent-connection capability.", "evidenceIds": [ "synctera-probe-1", "synctera-probe-2" ] }, { "productId": "synctera", "storyId": "agentic-nl-commands", "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": "synctera", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Synctera is a banking-as-a-service API platform; evidence shows API docs, OpenAPI spec, and llms.txt but no mention of an official CLI tool for interacting with the platform. missing for 10: any CLI product, CLI documentation, or install instructions.", "evidenceIds": [] }, { "productId": "synctera", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Synctera exposes a comprehensive, well-documented public REST API (customers, accounts, cards, transfers, KYC, webhooks) confirmed by a live OpenAPI spec and llms.txt discovery, with a sandbox API key flow for immediate programmatic access — clear evidence of driving the product entirely via documented API. Missing for 10: independent third-party developer confirmation/hands-on usage reports beyond vendor docs and automated probes.", "evidenceIds": [ "synctera-docs-14", "synctera-docs-7", "synctera-docs-13", "synctera-probe-1", "synctera-probe-2" ] }, { "productId": "synctera", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Synctera is an API platform where scoped credentials would be a fair axis to ask about, but the evidence only shows generic API key issuance for Sandbox with no mention of scopes, permission levels, or least-privilege credential issuance for agents.", "evidenceIds": [ "synctera-docs-14" ] }, { "productId": "synctera", "storyId": "agentic-sdks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows extensive API documentation, an OpenAPI spec, and an llms.txt for AI consumption, but there is no mention of official client SDKs (e.g., Python, JS, Java libraries) that developers could build against directly. Missing for 10: any evidence of official language-specific SDKs, SDK versioning, or SDK code samples.", "evidenceIds": [] }, { "productId": "synctera", "storyId": "agentic-webhooks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Synctera provides a dedicated Webhook API letting integrators subscribe to specific platform events, documented in a first-party guide. Missing for 10: independent/hands-on corroboration of webhook reliability and richer detail on event types/payload structure beyond the single guide reference.", "evidenceIds": [ "synctera-docs-13" ] }, { "productId": "synctera", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows Synctera has API documentation, an OpenAPI spec, and llms.txt for docs discovery, but nothing indicates an interactive API reference with runnable/try-it-out examples (e.g., Swagger UI, Postman collections, live sandbox console). missing for 10: interactive explorer UI, runnable code samples, live 'try it' console evidence.", "evidenceIds": [ "synctera-probe-2", "synctera-probe-1", "synctera-docs-14" ] }, { "productId": "synctera", "storyId": "api-machine-spec", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Probe confirms a live, machine-readable OpenAPI spec at docs.synctera.com/openapi.json returning a valid 'openapi' key, and docs also expose an llms.txt index for machine consumption. Missing for 10: no independent third-party corroboration of spec completeness/versioning beyond the probe.", "evidenceIds": [ "synctera-probe-2", "synctera-probe-1" ] }, { "productId": "synctera", "storyId": "api-sandbox", "verdict": "full", "quality": 6, "confidence": "medium", "rationale": "Synctera's own docs describe a distinct Sandbox environment where an API key can be issued and used to call APIs immediately, implying a separate environment from production. Missing for 10: explicit documentation of sandbox data isolation guarantees, sample sandbox test data, and independent/hands-on confirmation that sandbox never touches production data.", "evidenceIds": [ "synctera-docs-14" ] }, { "productId": "synctera", "storyId": "api-versioning-policy", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Evidence confirms Synctera has versioned API documentation (v0 and v2 exist per llms.txt) and a public OpenAPI spec, showing some API versioning discipline, but there is no mention of a documented deprecation policy, sunset timelines, or migration guidance between versions. missing for 10: explicit deprecation policy documentation, version sunset/migration guides, changelog or breaking-change notices.", "evidenceIds": [ "synctera-probe-1", "synctera-probe-2" ] }, { "productId": "synctera", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers individual resource APIs (customers, accounts, cards, transfers, verification) but never mentions batch/bulk endpoints, multi-item operations, or async bulk job APIs. Missing for 10: any documented bulk/batch API, bulk import/export tooling, or evidence of processing multiple records in a single call.", "evidenceIds": [] }, { "productId": "synctera", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Synctera's Webhook API lets integrators subscribe to platform events, which is the foundation for event-driven automation, but there's no evidence of a rules engine or declarative 'if event then action' capability built into the platform. Missing for 10: documented rule-definition interface, conditional logic/action mapping, and evidence of automated actions triggering without custom integrator code.", "evidenceIds": [ "synctera-docs-13" ] }, { "productId": "synctera", "storyId": "automation-scheduled-jobs", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Synctera exposes a 'scheduled payments' API to create and manage recurring payment schedules, which is the only evidence of any recurring/scheduled execution capability. There is no evidence of a general-purpose job/workflow scheduler, cron-like automation, or orchestration engine that an AI-native user could use to schedule arbitrary recurring workflows beyond payments. Missing for 10: general recurring workflow/job scheduling API, agent/automation orchestration support, and independent confirmation of scheduling reliability.", "evidenceIds": [ "synctera-docs-6" ] }, { "productId": "synctera", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Synctera is a banking-as-a-service API platform, not an automation/workflow builder with a versionable automation concept; version/review/rollback of automations is a category error for this product type.", "evidenceIds": [] }, { "productId": "synctera", "storyId": "builtin-ai-banking-ops", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any built-in AI features—natural-language transaction search, dispute/alert drafting, or anomaly summaries—anywhere in the docs; the evidence pack only covers core banking-as-a-service APIs (accounts, cards, transfers, KYC, webhooks). This is an applicable axis for a banking platform but nothing supports it.", "evidenceIds": [] }, { "productId": "synctera", "storyId": "card-disputes-rege", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack shows card issuance, account management, transfers, KYC, webhooks, and disclosures, but contains no mention of dispute management, Reg E investigation timelines, provisional credit mechanics, or ops tooling/responsibilities for chargebacks/disputes. This is a fair axis for a card/BaaS issuing platform, but no supporting evidence exists.", "evidenceIds": [] }, { "productId": "synctera", "storyId": "check-support", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Synctera explicitly documents remote deposit capture (RDC) handling and card issuance, indicating check deposit capability, but there is no direct evidence of programmatic check issuance (printing/mailing physical checks) or details on the image capture API/workflow. missing for 10: explicit check-issuance API docs, image capture endpoint/schema details, independent or hands-on confirmation of RDC workflow.", "evidenceIds": [ "synctera-docs-8", "synctera-docs-4" ] }, { "productId": "synctera", "storyId": "compliance-program-tooling", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Docs show KYC/KYB verification with watchlist checks (implying sanctions screening) and a general claim of centralized operational tooling with bank-partner collaboration, suggesting some duty-split framework exists. However, there is no explicit evidence of transaction monitoring, alert case management, or SAR-filing support tooling. missing for 10: transaction monitoring tooling, case management for alerts, SAR-filing support, explicit description of duty split between ops/platform/bank for compliance workflows.", "evidenceIds": [ "synctera-docs-9", "synctera-docs-16", "synctera-docs-11" ] }, { "productId": "synctera", "storyId": "debit-card-issuance", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs confirm card issuance and management is part of the same API platform as accounts (synctera-docs-4, synctera-docs-7), consistent with the story's core ask. However, there's no explicit evidence distinguishing virtual vs. physical card issuance, spend controls, or digital wallet (Apple/Google Pay) provisioning. Missing for 10: explicit virtual/physical card type documentation, spend control API details, digital wallet tokenization/push-provisioning support.", "evidenceIds": [ "synctera-docs-4", "synctera-docs-7", "synctera-docs-3" ] }, { "productId": "synctera", "storyId": "direct-bank-relationship", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Docs confirm Synctera's sponsor-bank model — it explicitly connects founders with partner banks and provides collaboration tools 'between you and your bank partner' (synctera-docs-16, synctera-docs-17), making clear it is middleware rather than a chartered bank itself. However, there is no evidence addressing what happens to customer funds/accounts if Synctera itself fails or is wound down, which is a core part of this story. Missing for 10: explicit disclosure of failure/wind-down protections for end customers, clarity on which specific bank charter backs a given program, and any independent/regulatory confirmation of the sponsor relationship.", "evidenceIds": [ "synctera-docs-16", "synctera-docs-17" ] }, { "productId": "synctera", "storyId": "fbo-structure-transparency", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "While Synctera's docs cover customer account creation, cards, transfers, and bank-partner collaboration tools, none of the evidence addresses FBO pooled vs individual account structuring, where FDIC insurance actually attaches, or ledger visibility/access-control documentation — the specific transparency concerns a finance lead would need. This is a fair axis for a BaaS/bank-partner platform, but no supporting evidence exists.", "evidenceIds": [ "synctera-docs-3", "synctera-docs-16", "synctera-docs-17" ] }, { "productId": "synctera", "storyId": "fraud-loss-allocation", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows Synctera's KYC/verification, payments, and card issuing docs, but nothing addresses fraud-loss liability allocation (who bears ACH return fraud, card dispute, or ATO losses) or documents prevention tooling alongside a liability split — the core of this story.", "evidenceIds": [] }, { "productId": "synctera", "storyId": "international-payments", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence only documents domestic wires explicitly scoped to transfers 'between 2 US based accounts' (synctera-docs-15), plus internal transfers between Synctera accounts (synctera-docs-5). There is no mention anywhere in the pack of international wires, SWIFT, FX rates, or a coverage map of currencies/corridors, suggesting Synctera is US-domestic focused.", "evidenceIds": [ "synctera-docs-15", "synctera-docs-5" ] }, { "productId": "synctera", "storyId": "kyc-kyb-onboarding", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Synctera has documented KYC/KYB verification objects covering personal and business customers, watchlist screening, and document verification, plus customer record management APIs. However, evidence does not explicitly show a modeled application/verification state machine (e.g., pending/approved/rejected/manual-review states) or detailed document collection workflow specifics. missing for 10: explicit documentation of verification application state model/lifecycle, document collection API details, and independent/hands-on corroboration of KYC/KYB flows.", "evidenceIds": [ "synctera-docs-1", "synctera-docs-2", "synctera-docs-9", "synctera-docs-10" ] }, { "productId": "synctera", "storyId": "ledger-bank-reconciliation", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no documentation of a reconciliation process, ledger-to-bank-core matching, or any daily reconciliation reporting mechanism — only vague references to 'complete data visibility' and general product features (customer/card/transfer APIs). Given the sponsor-bank model risk highlighted by Synapse's collapse, this is a fair and material axis for a BaaS platform, but no concrete evidence shows Synctera documents or automates ledger reconciliation with bank partners.", "evidenceIds": [] }, { "productId": "synctera", "storyId": "limits-holds-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers customer/account creation, cards, transfers, KYC/KYB, webhooks, and general 'operational workflows' but contains no specific mention of transaction/velocity limits, suspicious-activity holds, account freeze mechanisms, or documented reinstatement paths.", "evidenceIds": [ "synctera-docs-16", "synctera-docs-9" ] }, { "productId": "synctera", "storyId": "onboarding-review-controls", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Synctera exposes KYC/KYB verification objects, document verification, and an operational workflow platform pitched as offering 'complete data visibility and seamless collaboration' with bank partners, which touches on the onboarding-queue and bank/program collaboration themes. However, there is no concrete evidence of a queue UI showing why an application is pending, a document-upload workflow for ops, or an explicit description of which decisions belong to ops versus the bank. missing for 10: pending-reason visibility in a queue UI, ops-driven document request/upload flow, explicit ops-vs-bank decision boundaries.", "evidenceIds": [ "synctera-docs-16", "synctera-docs-9", "synctera-docs-10", "synctera-docs-11" ] }, { "productId": "synctera", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Synctera's docs describe an extensive, well-documented REST API (OpenAPI spec, llms.txt) covering nearly all core banking operations—customers, accounts, cards, transfers, KYC, webhooks, disclosures—suggesting broad API-first coverage. However, the evidence also references a separate 'centralized platform' with UI tools for bank-partner collaboration (synctera-docs-16), and there is no explicit claim or verification that every UI-only workflow (e.g., dashboard operations, partner collaboration tools) is fully mirrored in the API. Missing for 10: explicit parity statement or audit confirming UI-exclusive features (e.g., operational dashboards) are also API-accessible, and independent/hands-on confirmation of full parity.", "evidenceIds": [ "synctera-docs-16", "synctera-probe-2", "synctera-probe-1", "synctera-docs-14", "synctera-docs-7" ] }, { "productId": "synctera", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows Synctera's API and webhook documentation (docs-13, probe-1, probe-2) but no mention of a bulk data export feature, open-format data portability, or account-closure data extraction for customers. This is a fair axis for a BaaS platform handling customer financial data, but no evidence supports it.", "evidenceIds": [] }, { "productId": "synctera", "storyId": "openness-open-license", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Synctera is a proprietary banking-as-a-service platform; there is no evidence of an open-source codebase, and source availability is not a relevant axis for a closed banking API product. This is a category mismatch, not an absence of evidence for an applicable capability.", "evidenceIds": [] }, { "productId": "synctera", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Synctera is a banking-as-a-service platform delivered as a hosted API/cloud service tied to bank partnerships; self-hosting a core banking-as-a-service product is a category error since it inherently depends on regulated bank infrastructure, not deployable software.", "evidenceIds": [] }, { "productId": "synctera", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Synctera is a banking-as-a-service API platform for fintech products (accounts, cards, payments, KYC); data residency/region selection is not addressed anywhere and is not a feature category this type of product typically exposes to end users. This is a category mismatch rather than a missing feature.", "evidenceIds": [] }, { "productId": "synctera", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Synctera is a banking-as-a-service platform for financial products, not an AI model or AI-training data product; controlling AI-training data usage is outside its category.", "evidenceIds": [] }, { "productId": "synctera", "storyId": "privacy-retention-controls", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Synctera is a banking-as-a-service platform for building financial products, not an AI-native tool where users control model/data retention or deletion of AI-processed data. This axis (AI data retention/deletion controls) is a category error for a BaaS API provider.", "evidenceIds": [] }, { "productId": "synctera", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Synctera is a banking-as-a-service API platform for fintech infrastructure, not an AI agent/tool whose telemetry-opt-out is a fair comparison axis; no evidence pack content relates to telemetry or usage tracking.", "evidenceIds": [] }, { "productId": "synctera", "storyId": "program-limits-scaling", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence pack item documents program-level limits, approval-stage thresholds, or a defined process for raising limits; documentation covers API features (accounts, cards, transfers, KYC) but not growth-limit governance or escalation paths.", "evidenceIds": [] }, { "productId": "synctera", "storyId": "realtime-balances-events", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Synctera documents a Webhook API for subscribing to platform events and real-time internal transfers, which supports event-driven notification of transaction state changes, but the evidence pack does not explicitly confirm real-time balance reads reflecting holds/pending activity or an exhaustive webhook-to-ledger-state mapping. missing for 10: explicit documentation of hold/pending balance semantics in balance reads, confirmation that webhooks fire for every transaction state transition (not just select events), and independent/hands-on verification that the ledger mirrors bank state in real time.", "evidenceIds": [ "synctera-docs-5", "synctera-docs-13" ] }, { "productId": "synctera", "storyId": "statements-tax-documents", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence in the pack mentions monthly statement generation or 1099-INT tax document production/retrieval via API; coverage includes accounts, cards, payments, KYC, and disclosures but nothing on statements or tax forms.", "evidenceIds": [] }, { "productId": "synctera", "storyId": "transaction-data-quality", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Synctera exposes distinct transaction guides (domestic wires, internal transfers, external account linking via Plaid/Finicity, RDC) and a webhook API for event data, suggesting a structured transaction model, but no evidence explicitly documents counterparty detail fields, rail-specific metadata schemas, stable transaction identifiers, or enrichment logic that would make raw feeds directly usable in-product. missing for 10: explicit transaction object schema showing counterparty fields, rail metadata, stable IDs, and enrichment/categorization documentation.", "evidenceIds": [ "synctera-docs-15", "synctera-docs-5", "synctera-docs-12", "synctera-docs-13", "synctera-docs-8" ] }, { "productId": "synctera", "storyId": "virtual-account-numbers", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Synctera's docs confirm it creates and manages customer accounts and supports internal transfers, which is consistent with account-provisioning capability for a BaaS platform, but there is no explicit evidence of issuing unique routing numbers, virtual accounts for reconciliation, per-customer collection accounts, or sub-account/master-account hierarchies. missing for 10: explicit routing-number issuance, virtual account/reconciliation feature docs, per-customer collection account docs, master/sub-account hierarchy docs.", "evidenceIds": [ "synctera-docs-3", "synctera-docs-5", "synctera-docs-7" ] }, { "productId": "synctera", "storyId": "wires-instant-rails", "verdict": "partial", "quality": 3, "confidence": "medium", "rationale": "Docs confirm domestic wire origination/receipt via API (synctera-docs-15) and general money-movement APIs (synctera-docs-5, synctera-docs-6, synctera-docs-7), but there is no evidence of RTP or FedNow rails, per-rail capability documentation, or same-API origination/receipt for those faster rails. Missing for 10: RTP support, FedNow support, per-rail capability docs, and origination vs receipt distinctions for faster payments.", "evidenceIds": [ "synctera-docs-15", "synctera-docs-5", "synctera-docs-6", "synctera-docs-7" ] }, { "productId": "synctera", "storyId": "yield-interest-options", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers customer accounts, cards, transfers, wires, KYC, webhooks, but nothing on interest-bearing accounts, sweep programs, or rate/spread mechanics between Synctera and bank partners. No documentation addresses idle balance yield or spread ownership.", "evidenceIds": [] }, { "productId": "treasury-prime", "storyId": "account-opening-api", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Docs show a clear API-driven account opening flow (Person → Business → Account Application) with KYC/KYB integration, plus a Developer Sandbox with API keys and Postman collection for pre-launch testing (treasury-prime-docs-4, treasury-prime-docs-5, treasury-prime-docs-1, treasury-prime-docs-12). However, there is no explicit documentation confirming FDIC/NCUA deposit insurance status or an end-to-end 'application to active account' status confirmation step, and no independent/hands-on corroboration of sandbox-to-production parity. Missing for 10: explicit insured-deposit language, documented account-activation/status lifecycle, and third-party verification of sandbox parity.", "evidenceIds": [ "treasury-prime-docs-1", "treasury-prime-docs-4", "treasury-prime-docs-5", "treasury-prime-docs-12" ] }, { "productId": "treasury-prime", "storyId": "ach-origination", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs confirm ACH credits and debits (push/pull) and returns handled via an 'Update an ACH endpoint' pattern suggesting first-class transfer objects, but there's no evidence of same-day ACH windows, NOC (notification of change) handling, reversals, or webhook events tied to ACH lifecycle changes. missing for 10: same-day ACH window support, NOC objects/webhooks, reversal handling, explicit webhook event documentation for ACH status changes.", "evidenceIds": [ "treasury-prime-docs-7", "treasury-prime-docs-8" ] }, { "productId": "treasury-prime", "storyId": "agent-operated-account", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack shows standard API key auth (API Key ID/Secret) and general account/transfer endpoints, but nothing about scoped credentials, per-transaction amount caps, counterparty allowlists, or any agent/AI-specific access model documented by name. This is a fair axis for a banking API platform, but no evidence supports it.", "evidenceIds": [ "treasury-prime-docs-2", "treasury-prime-docs-3", "treasury-prime-docs-7", "treasury-prime-docs-9", "treasury-prime-docs-11" ] }, { "productId": "treasury-prime", "storyId": "agent-reads-banking-state", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Treasury Prime offers a clean REST API to list accounts, transactions, ACH/wire/book transfers, and statements, avoiding screen-scraping, and provides an llms.txt for AI discoverability. However, there is no evidence of a documented MCP server, no consolidated 'pending activity' or document-retrieval endpoint explicitly described, and the OpenAPI spec probe returned 404s, suggesting no easily machine-consumable schema for agents. Missing for 10: an official MCP surface or agent-native integration, explicit endpoints for pending transactions/documents, and a working OpenAPI/swagger spec for automated discovery.", "evidenceIds": [ "treasury-prime-docs-3", "treasury-prime-docs-9", "treasury-prime-docs-13", "treasury-prime-probe-1", "treasury-prime-probe-2" ] }, { "productId": "treasury-prime", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "A probe confirms Treasury Prime hosts a valid llms.txt file returning HTTP 200 with structured links to its developer docs, directly satisfying the story of pointing an agent at an llms.txt/agent-oriented doc index. Missing for 10: no independent third-party confirmation of agent usage or OpenAPI spec discoverability (openapi.json probes 404).", "evidenceIds": [ "treasury-prime-probe-1", "treasury-prime-probe-2" ] }, { "productId": "treasury-prime", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of AI-generated insights, analytics, or suggestions surfaced within the product; documentation covers banking-as-a-service APIs (accounts, ACH, wires, KYC) but nothing about AI-driven data insights.", "evidenceIds": [] }, { "productId": "treasury-prime", "storyId": "agentic-autonomous-automation", "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": "treasury-prime", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Treasury Prime is a banking-as-a-service API platform for account opening, payments, and KYC; it has no built-in AI assistant persona for users to delegate tasks to. This axis is a category error for this type of product.", "evidenceIds": [] }, { "productId": "treasury-prime", "storyId": "agentic-headless", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Treasury Prime is an API-first banking platform, so its REST API can be called headlessly/in CI via HTTP Basic Auth (sandbox + ping/account endpoints, command-line or Postman testing), which supports automation-style usage. However there is no evidence of CI-specific tooling, an official SDK/CLI, webhooks for async automation, or a public OpenAPI spec (probe found 404s), so full headless/CI suitability is not demonstrated. Missing for 10: official CLI/SDK for CI pipelines, documented OpenAPI/machine-readable spec, CI examples or automation guides, and evidence of non-interactive auth flows beyond basic API key testing.", "evidenceIds": [ "treasury-prime-docs-2", "treasury-prime-docs-12", "treasury-prime-probe-2" ] }, { "productId": "treasury-prime", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Treasury Prime is a banking-as-a-service API platform, not an AI agent or assistant that consumes external tools; plugging MCP servers into it to extend its own tool-use is a category error for this product type.", "evidenceIds": [] }, { "productId": "treasury-prime", "storyId": "agentic-mcp-server", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Treasury Prime is a banking-as-a-service API platform; no evidence of an official MCP server or agent-connectivity offering is present in the evidence pack, only REST API docs.", "evidenceIds": [ "treasury-prime-probe-1", "treasury-prime-probe-2" ] }, { "productId": "treasury-prime", "storyId": "agentic-nl-commands", "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": "treasury-prime", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Treasury Prime is a banking-as-a-service API platform; no evidence of an official CLI tool exists—only mentions of API testing via command line (curl) or Postman, not a dedicated CLI product. No CLI documentation, package, or download is referenced anywhere in the evidence.", "evidenceIds": [ "treasury-prime-docs-12" ] }, { "productId": "treasury-prime", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Treasury Prime is fundamentally an API-first banking platform with extensive documented REST endpoints (accounts, ACH, wires, book transfers, KYC, applications), Basic Auth API keys, a free Developer Sandbox, and a Postman collection for testing — clearly enabling programmatic, AI-native usage. Missing for 10: a discoverable machine-readable OpenAPI/swagger spec (probe returned 404s) and independent/hands-on corroboration beyond vendor docs.", "evidenceIds": [ "treasury-prime-docs-1", "treasury-prime-docs-2", "treasury-prime-docs-3", "treasury-prime-docs-12", "treasury-prime-probe-1", "treasury-prime-probe-2" ] }, { "productId": "treasury-prime", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows Treasury Prime issues API Key ID/Secret Key pairs via HTTP Basic Auth for sandbox and production access, but there is no mention of scopes, roles, permission levels, or least-privilege credential configuration, nor anything AI-agent-specific.", "evidenceIds": [ "treasury-prime-docs-1", "treasury-prime-docs-2" ] }, { "productId": "treasury-prime", "storyId": "agentic-sdks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers REST API endpoints, a Postman collection, and a sandbox, but contains no mention of official client SDKs in any language, and OpenAPI spec probes all returned 404s. Missing for 10: any documented official SDK (e.g., Python, Node, Java client libraries), SDK installation/usage guides, or GitHub SDK repos.", "evidenceIds": [ "treasury-prime-docs-12", "treasury-prime-probe-2" ] }, { "productId": "treasury-prime", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers onboarding, KYC, ACH, wires, book transfers, and account statements, but contains no mention of webhooks or event subscription mechanisms anywhere in the docs or probes. Since webhook support is a plausible and common feature for a banking-as-a-service API platform, its complete absence from the evidence means the story is unmet rather than out-of-scope.", "evidenceIds": [] }, { "productId": "treasury-prime", "storyId": "api-interactive-docs", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Docs mention a Postman Collection and sandbox for testing API calls, which offers some runnable-example capability, but there's no evidence of an interactive in-browser API reference (e.g., Swagger/OpenAPI explorer) — a probe for openapi.json/swagger.json returned 404s. missing for 10: interactive embedded API reference UI, OpenAPI/Swagger spec, in-browser runnable code snippets.", "evidenceIds": [ "treasury-prime-docs-12", "treasury-prime-probe-2" ] }, { "productId": "treasury-prime", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Probe explicitly checked common OpenAPI/swagger paths and all returned 404, and no docs reference a downloadable machine-readable spec (only a Postman Collection is mentioned, which is not OpenAPI/equivalent).", "evidenceIds": [ "treasury-prime-probe-2", "treasury-prime-docs-12" ] }, { "productId": "treasury-prime", "storyId": "api-sandbox", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Treasury Prime provides a free Developer Sandbox for creating API keys and testing endpoints (ping, accounts) separately from production, plus a documented \"Testing in Sandbox\" guide with a Postman Collection for exploration. This directly enables development/testing without touching production data. Missing for 10: independent/hands-on confirmation of sandbox fidelity and explicit documentation of sandbox-to-production promotion workflow.", "evidenceIds": [ "treasury-prime-docs-1", "treasury-prime-docs-2", "treasury-prime-docs-3", "treasury-prime-docs-12" ] }, { "productId": "treasury-prime", "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; OpenAPI spec probes all 404, and no changelog or version-lifecycle documentation is cited.", "evidenceIds": [ "treasury-prime-probe-2" ] }, { "productId": "treasury-prime", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of any batch/bulk endpoints (e.g., bulk ACH, bulk transfers, or list-mutation APIs) in the docs pack; all endpoints described are single-item (single account, single ACH, single wire). Bulk operations are a plausible axis for a banking API platform, so absence of evidence yields 'none'.", "evidenceIds": [ "treasury-prime-docs-7", "treasury-prime-docs-9", "treasury-prime-docs-11" ] }, { "productId": "treasury-prime", "storyId": "automation-rules-engine", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Treasury Prime's evidence pack covers account opening, KYC, ACH/wire/book transfers, and sandbox testing, but contains no mention of webhooks, event subscriptions, or a rules/automation engine that lets users define triggers for automatic actions. Given BaaS platforms commonly expose event-driven webhooks, this axis is a fair question, but no supporting evidence exists in the pack.", "evidenceIds": [] }, { "productId": "treasury-prime", "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": "treasury-prime", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Treasury Prime is a banking-as-a-service API for account opening, ACH/wire transfers, and KYC — not a workflow/automation builder with versioned, reviewable automations. Versioning, reviewing, and rolling back 'automations' is a category mismatch for this kind of product; the axis does not apply.", "evidenceIds": [] }, { "productId": "treasury-prime", "storyId": "builtin-ai-banking-ops", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any built-in AI features for banking operations—no natural-language transaction search, dispute/alert response drafting, or anomaly summaries are mentioned anywhere in the docs pack, which instead covers standard banking-as-a-service API functionality (accounts, ACH, wires, KYC).", "evidenceIds": [] }, { "productId": "treasury-prime", "storyId": "card-disputes-rege", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence covers ACH/wire/book transfer mechanics and returns but contains no mention of Reg E dispute investigation timelines, provisional credit mechanics, or documented ops responsibilities for card/ACH disputes.", "evidenceIds": [] }, { "productId": "treasury-prime", "storyId": "check-support", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers ACH, wire, FedNow, book transfers, cash deposits, and account statements, but contains no mention of check issuance or check deposit/RDC (remote deposit capture with image capture) anywhere in the docs.", "evidenceIds": [] }, { "productId": "treasury-prime", "storyId": "compliance-program-tooling", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence only covers KYC/KYB during account opening; there is no mention of transaction monitoring, sanctions screening, alert case management, or SAR-filing support, nor any description of duty splits between ops/platform/bank for these compliance functions.", "evidenceIds": [ "treasury-prime-docs-5", "treasury-prime-docs-6" ] }, { "productId": "treasury-prime", "storyId": "debit-card-issuance", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers account opening, KYC, ACH, wire, book transfers, and cash deposits, but contains no mention of debit card issuance, physical/virtual cards, spend controls, or digital wallet support anywhere in the docs or probes.", "evidenceIds": [] }, { "productId": "treasury-prime", "storyId": "direct-bank-relationship", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "None of the evidence addresses which bank holds the charter, how Treasury Prime's middleware role relates to a named sponsor bank, or what happens to end customers if Treasury Prime fails — the docs only cover API mechanics (KYC, ACH, wires, account opening) with no sponsor-bank disclosure or failure/continuity language.", "evidenceIds": [] }, { "productId": "treasury-prime", "storyId": "fbo-structure-transparency", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence covers account creation, KYC, ACH/wire/book transfers, and statements, but nowhere documents FBO pool vs individual account structure, where FDIC insurance attaches, or who can view the ledger. This is a fair and material question for a banking-as-a-service platform, so the axis applies, but no supporting evidence exists.", "evidenceIds": [] }, { "productId": "treasury-prime", "storyId": "fraud-loss-allocation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence shows ACH return handling mechanics (initiating returns) and general product docs, but nothing addresses who bears financial liability for ACH return fraud, card disputes, or account takeover losses, nor any documented liability split alongside fraud prevention tooling.", "evidenceIds": [] }, { "productId": "treasury-prime", "storyId": "international-payments", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence covers only US-domestic rails (ACH, domestic wires, FedNow, book transfers, cash deposits); there is no mention of international wires/SWIFT, FX rates, or a currency/corridor coverage map.", "evidenceIds": [] }, { "productId": "treasury-prime", "storyId": "kyc-kyb-onboarding", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm a programmatic application flow (Person/Business/Account Application) and third-party KYC/KYB vendor integration, plus an Incremental KYC mode that runs KYC outside account opening — supporting the core 'programmatic verification' story. However, evidence does not show explicit document collection endpoints, watchlist screening details, or a full state-machine model of application statuses. missing for 10: explicit document upload/collection API details, watchlist/OFAC screening specifics, documented application state enumeration and transitions.", "evidenceIds": [ "treasury-prime-docs-4", "treasury-prime-docs-5", "treasury-prime-docs-6" ] }, { "productId": "treasury-prime", "storyId": "ledger-bank-reconciliation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers account opening, KYC, ACH/wire/book transfers, and statements, but there is no mention of ledger-to-bank-core reconciliation, daily reconciliation reports, or any process for verifying API-reported balances against actual bank holdings — the exact failure mode referenced in the story. Nothing in the docs addresses reconciliation guarantees or audit processes for sponsor-bank programs.", "evidenceIds": [] }, { "productId": "treasury-prime", "storyId": "limits-holds-controls", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence pack items mention transaction/velocity limits, suspicious-activity holds, account freezes, or reinstatement workflows; documentation covers account opening, KYC, ACH/wire/book transfers, and statements but nothing about risk-control configuration. Missing for 10: any documentation of per-account/program limit settings, hold/freeze mechanisms, or reinstatement procedures.", "evidenceIds": [ "treasury-prime-docs-4", "treasury-prime-docs-5", "treasury-prime-docs-7", "treasury-prime-docs-8", "treasury-prime-docs-13" ] }, { "productId": "treasury-prime", "storyId": "onboarding-review-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack only documents developer API endpoints for creating Person/Business/Account applications and KYC/KYB integration hooks — it never describes an ops-facing queue UI showing why an application is pending, a way to request/upload additional documents, or any distinction between platform-owned vs. bank-owned decisions. This is a plausible axis for a bank-partner onboarding platform, but nothing in the evidence shows such an ops console or decision-attribution feature.", "evidenceIds": [ "treasury-prime-docs-4", "treasury-prime-docs-5", "treasury-prime-docs-6" ] }, { "productId": "treasury-prime", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Treasury Prime's docs show broad API coverage across core banking workflows (account opening, KYC, ACH, wires, book transfers, statements, cash deposits), consistent with an API-first BaaS platform, but there is no explicit claim of full UI/API feature parity and the OpenAPI/swagger spec could not be located (404s), making it hard to verify completeness. missing for 10: explicit parity statement, discoverable OpenAPI spec, independent confirmation that dashboard-only actions (e.g. admin/dashboard configuration) are also API-exposed.", "evidenceIds": [ "treasury-prime-docs-4", "treasury-prime-docs-5", "treasury-prime-docs-6", "treasury-prime-docs-7", "treasury-prime-docs-9", "treasury-prime-docs-11", "treasury-prime-docs-13", "treasury-prime-docs-14", "treasury-prime-probe-2" ] }, { "productId": "treasury-prime", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Treasury Prime is a banking-as-a-service API; there is no evidence of a data export/portability feature for account or transaction data in open formats, nor any documented account-closure/data-export process. This is a fair axis for a data-holding platform, but nothing in the evidence shows such capability.", "evidenceIds": [] }, { "productId": "treasury-prime", "storyId": "openness-open-license", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Treasury Prime is a proprietary banking-as-a-service API platform, not open-source software; source code availability under an open license is not a relevant axis for this kind of commercial financial infrastructure product.", "evidenceIds": [] }, { "productId": "treasury-prime", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Treasury Prime is a banking-as-a-service API platform, not software distributed for self-hosting; self-hosting a hosted financial infrastructure service is a category error, not an unmet capability.", "evidenceIds": [] }, { "productId": "treasury-prime", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack addresses data residency, regional storage options, or any data-location controls; Treasury Prime's docs focus entirely on banking/API functionality with no mention of data residency choices.", "evidenceIds": [] }, { "productId": "treasury-prime", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Treasury Prime is a banking-as-a-service/API platform, not an AI model or AI product that trains on user data; opting out of AI training data usage is not a relevant axis for this product category.", "evidenceIds": [] }, { "productId": "treasury-prime", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack addresses data retention or deletion controls for AI-native users; the documentation covers banking APIs, KYC, ACH/wire transfers, and account statements but nothing about data lifecycle management or deletion policies.", "evidenceIds": [] }, { "productId": "treasury-prime", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses telemetry, usage tracking, or opt-out mechanisms for Treasury Prime; the documentation focuses entirely on banking API functionality (accounts, ACH, wires, KYC) with no mention of privacy/telemetry controls.", "evidenceIds": [] }, { "productId": "treasury-prime", "storyId": "program-limits-scaling", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence covers API onboarding, KYC, account opening, ACH/wire/book transfers, and statements, but nothing addresses program-level transaction/volume limits, approval stages, or a documented process for raising limits as growth occurs.", "evidenceIds": [] }, { "productId": "treasury-prime", "storyId": "realtime-balances-events", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows account, ACH, wire, and book-transfer status fields (e.g., wire 'status' attribute) but contains no mention of webhooks, event notifications, or real-time balance/hold semantics reflecting pending activity — core to this story. missing for 10: webhook/event API docs, balance endpoint showing holds/pending distinctions, any real-time push notification mechanism.", "evidenceIds": [ "treasury-prime-docs-9", "treasury-prime-docs-3", "treasury-prime-docs-7" ] }, { "productId": "treasury-prime", "storyId": "statements-tax-documents", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Monthly account statements are documented as generated and retrievable via API (\"Generate and retrieve branded monthly account statements\"), but there is no evidence of 1099-INT tax document generation or retrieval anywhere in the pack. missing for 10: 1099-INT tax document generation/retrieval via API, any tax-reporting endpoint documentation, independent confirmation of statement/tax automation in production.", "evidenceIds": [ "treasury-prime-docs-13" ] }, { "productId": "treasury-prime", "storyId": "transaction-data-quality", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Docs describe transaction types (ACH credit/debit, wire with status tracking, book transfers) and basic account data, implying some structured metadata exists, but there is no explicit documentation of counterparty detail fields, rail-specific metadata enrichment, or stable identifier schemes that would let a developer build rich in-product transaction views. missing for 10: explicit counterparty/beneficiary data fields, rail-specific metadata (e.g., ACH company entry description, wire OBI/BBI fields), stable identifier documentation, and any enrichment/categorization features.", "evidenceIds": [ "treasury-prime-docs-7", "treasury-prime-docs-9", "treasury-prime-docs-11", "treasury-prime-docs-8" ] }, { "productId": "treasury-prime", "storyId": "virtual-account-numbers", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence confirms Treasury Prime supports creating bank accounts via Person/Business/Account Applications and listing accounts, but there is no mention of issuing unique routing numbers, virtual accounts for reconciliation, or sub-account/master-account hierarchies anywhere in the docs pack. Since Treasury Prime is a banking-as-a-service platform, this capability is a fair and expected axis, but no evidence substantiates it here.", "evidenceIds": [ "treasury-prime-docs-3", "treasury-prime-docs-4" ] }, { "productId": "treasury-prime", "storyId": "wires-instant-rails", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm wire transfer status tracking and FedNow instant settlement (24/7/365) through the API, and ACH/book transfer rails are documented, suggesting multi-rail origination exists. However, there's no explicit mention of RTP (Real-Time Payments) origination/receipt, no clear per-rail capability comparison table, and no confirmation of wire/FedNow receipt (only origination-side details are shown). missing for 10: explicit RTP documentation, per-rail capability matrix, wire/FedNow receipt confirmation, and independent corroboration beyond vendor docs.", "evidenceIds": [ "treasury-prime-docs-9", "treasury-prime-docs-10", "treasury-prime-docs-7", "treasury-prime-docs-11" ] }, { "productId": "treasury-prime", "storyId": "yield-interest-options", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence pack item mentions interest-bearing accounts, sweep programs, yield/rate mechanics, or spread-sharing arrangements for idle balances; documentation covers account opening, ACH/wire/book transfers, KYC, and statements only.", "evidenceIds": [] }, { "productId": "unit", "storyId": "account-opening-api", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Unit's docs confirm programmatic creation of deposit accounts (including FBO structures) via API, which is the core capability, but the evidence pack contains no mention of a sandbox/test environment for parity testing, no explicit FDIC-insurance language, and probes show API reference/OpenAPI endpoints returning 404s, undermining confidence in full self-serve API documentation. missing for 10: sandbox environment documentation, explicit insured-deposit (FDIC) claims, working API reference/OpenAPI spec.", "evidenceIds": [ "unit-docs-1", "unit-docs-6", "unit-probe-2", "unit-probe-3" ] }, { "productId": "unit", "storyId": "ach-origination", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Unit's docs confirm ACH is supported as a payment rail with transaction visibility, but there is no evidence of same-day ACH windows, or of returns, NOCs, and reversals modeled as first-class API objects with dedicated webhooks. missing for 10: same-day ACH windows, ACH return/NOC/reversal objects, webhook event documentation for these unhappy paths, and any API/OpenAPI reference confirming these fields.", "evidenceIds": [ "unit-docs-2", "unit-docs-5" ] }, { "productId": "unit", "storyId": "agent-operated-account", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Unit's evidence describes general banking-as-a-service capabilities (accounts, payments, cards) but contains no mention of AI agents, scoped credentials, amount caps, counterparty allowlists, or any agent-specific access model named by the vendor.", "evidenceIds": [] }, { "productId": "unit", "storyId": "agent-reads-banking-state", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Unit's docs claim broad API access to accounts, balances, transactions, cards, and payments data (unit-docs-1,2,3,5), which covers much of the 'banking picture' via API rather than screen-scraping. However, there is no mention of an MCP surface, and probes show no discoverable OpenAPI/swagger spec or docs.md (unit-probe-2, unit-probe-3), and no evidence of document retrieval (e.g., statements) via API. Missing for 10: MCP server/tool surface, verifiable OpenAPI spec, document/statement API endpoints, and independent corroboration beyond vendor llms.txt claims.", "evidenceIds": [ "unit-docs-1", "unit-docs-2", "unit-docs-3", "unit-docs-5", "unit-probe-2", "unit-probe-3" ] }, { "productId": "unit", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Unit hosts a live llms.txt (confirmed HTTP 200 via probe) with structured agent-oriented documentation covering accounts, payments, cards, credit products, and infrastructure details, which an AI agent can be pointed at directly. Missing for 10: independent/third-party confirmation of agent usage in practice and absence of a discoverable OpenAPI/machine-readable API spec (openapi.json/swagger.json returned 404s) to complement the llms.txt.", "evidenceIds": [ "unit-probe-1", "unit-docs-1", "unit-docs-5", "unit-probe-3" ] }, { "productId": "unit", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Unit is a banking-as-a-service infrastructure platform; evidence covers accounts, payments, cards, and credit products with dashboard/API data access, but nothing describes AI-generated insights or suggestions surfaced from customer data. Missing for 10: any mention of AI/ML-driven analytics, anomaly detection, or suggestion features within the dashboard or API.", "evidenceIds": [ "unit-docs-5", "unit-docs-10" ] }, { "productId": "unit", "storyId": "agentic-autonomous-automation", "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": "unit", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Unit is a banking-as-a-service/financial infrastructure API platform, not an AI assistant product; there is no built-in AI assistant concept applicable here — this is a wrong-axis question for this product category.", "evidenceIds": [] }, { "productId": "unit", "storyId": "agentic-headless", "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": "unit", "storyId": "agentic-mcp-client", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Unit is a banking-as-a-service/fintech infrastructure platform; no evidence of any MCP server support or integration for plugging tools into an AI agent. This is an applicable axis for a modern API platform, but nothing in the evidence pack mentions MCP.", "evidenceIds": [] }, { "productId": "unit", "storyId": "agentic-mcp-server", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Unit is a banking-as-a-service platform (not itself an agent), so an official MCP server for connecting agents is a fair axis to expect, but the evidence pack contains no mention of MCP, agent connectivity, or any such server—only standard API/docs content and failed probes for API specs. Missing for 10: any documentation of an MCP server, agent integration tooling, or even an OpenAPI spec that could underpin one.", "evidenceIds": [ "unit-probe-2", "unit-probe-3" ] }, { "productId": "unit", "storyId": "agentic-nl-commands", "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": "unit", "storyId": "agentic-official-cli", "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": "unit", "storyId": "agentic-public-api", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Unit's marketing/llms.txt content repeatedly references building via 'APIs' for accounts, payments, cards, and credit products (unit-docs-1 through unit-docs-5, unit-docs-9), implying a documented public API exists, but the evidence pack's own probes failed to locate any actual API documentation or OpenAPI/Swagger spec (unit-probe-2, unit-probe-3), leaving the claim unverified. Missing for 10: a working link to actual API reference docs, an OpenAPI/Swagger spec, or independent developer corroboration that the API is usable/documented in practice.", "evidenceIds": [ "unit-docs-1", "unit-docs-2", "unit-docs-5", "unit-docs-9", "unit-probe-2", "unit-probe-3" ] }, { "productId": "unit", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Unit's evidence pack describes banking/payments infrastructure capabilities (accounts, payments, cards, credit) but contains no mention of API key scoping, credential permissions, or any mechanism for issuing least-privilege credentials for AI agents. This is a fair axis for an API platform, but no evidence supports it.", "evidenceIds": [] }, { "productId": "unit", "storyId": "agentic-sdks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack describes Unit's banking/payments/card capabilities and API access via a Dashboard, but never mentions official SDKs (e.g., language-specific client libraries) for developers to build against. Probes even show 404s for OpenAPI/Swagger specs and a docs .md endpoint, further undermining any claim of accessible, well-documented programmatic tooling.", "evidenceIds": [ "unit-docs-5", "unit-probe-2", "unit-probe-3" ] }, { "productId": "unit", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no mention of webhooks or event subscription capabilities anywhere in Unit's documentation excerpts; only general product/banking-infrastructure descriptions and failed probes for API specs are present.", "evidenceIds": [] }, { "productId": "unit", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of an interactive API reference or runnable examples; probes for docs/openapi endpoints returned 404s, and no docs mention a sandbox/console for testing API calls.", "evidenceIds": [ "unit-probe-2", "unit-probe-3" ] }, { "productId": "unit", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Probes explicitly show no OpenAPI/swagger file at any candidate path (all 404), and no docs-md export exists either; no evidence of a downloadable machine-readable API spec.", "evidenceIds": [ "unit-probe-3", "unit-probe-2" ] }, { "productId": "unit", "storyId": "api-sandbox", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Unit is a banking-as-a-service API platform, and sandbox/test environments are a standard, fair expectation for such a product, but none of the evidence mentions a sandbox environment, test mode, or separation from production data. Missing for 10: any mention of a sandbox/test environment, test API keys, or documentation describing safe non-production testing.", "evidenceIds": [] }, { "productId": "unit", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of API versioning scheme or a documented deprecation policy; OpenAPI spec and docs endpoints were not found (404s), and no changelog or version policy is mentioned anywhere in the pack.", "evidenceIds": [ "unit-probe-2", "unit-probe-3" ] }, { "productId": "unit", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence describes Unit's account, payment, card, and credit APIs but never mentions batch/bulk endpoints, multi-item operations, or automation-scale processing across many records at once. Missing for 10: any documentation of batch APIs, bulk create/update endpoints, or evidence of automation-depth features letting an AI agent act on many items in one call.", "evidenceIds": [ "unit-docs-1", "unit-docs-2", "unit-docs-5" ] }, { "productId": "unit", "storyId": "automation-rules-engine", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Unit is banking infrastructure where event-driven automation (e.g., webhooks triggering actions on transactions/payments) would be a reasonable capability, but the evidence pack contains no mention of webhooks, event triggers, or rule-based automation—only account, payment, card, and dashboard descriptions. Missing for 10: any documentation of webhook/event subscription system, rule definition interface, or automated action triggers.", "evidenceIds": [] }, { "productId": "unit", "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": "unit", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Unit is a banking/financial infrastructure API platform, not an automation-building tool; versioning, reviewing, and rolling back 'automations' is not a relevant axis for this product category.", "evidenceIds": [] }, { "productId": "unit", "storyId": "builtin-ai-banking-ops", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence describes Unit as banking infrastructure (accounts, payments, cards, credit) but contains no mention of any built-in AI features such as natural-language transaction search, drafted dispute responses, or anomaly summaries.", "evidenceIds": [] }, { "productId": "unit", "storyId": "card-disputes-rege", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence only shows generic marketing claims about card issuance, ACH payments, and dashboard access — nothing addresses dispute handling, Reg E investigation timelines, provisional credit mechanics, or documented ops responsibilities for disputes.", "evidenceIds": [] }, { "productId": "unit", "storyId": "check-support", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Unit's docs list 'checks' as one of several payment rails alongside ACH, wires, and RTP, but there is no detail on check issuance workflows or remote deposit capture with image upload/processing. Missing for 10: specific API/endpoint documentation for check issuance, check printing/mailing, and deposit capture with image capture and verification.", "evidenceIds": [ "unit-docs-2" ] }, { "productId": "unit", "storyId": "compliance-program-tooling", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence only mentions generic 'compliance data' access via dashboard/APIs, with no mention of transaction monitoring, sanctions screening, alert case management, SAR-filing support, or a defined split of compliance duties between ops, platform, and bank.", "evidenceIds": [ "unit-docs-5" ] }, { "productId": "unit", "storyId": "debit-card-issuance", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Unit's docs explicitly confirm issuing both physical and virtual cards via API with configurable controls, real-time authorization, and lifecycle management, tied to accounts (unit-docs-3, unit-docs-10). However, no evidence in the pack mentions digital wallet (Apple Pay/Google Pay) provisioning support. Missing for 10: explicit digital wallet/tokenization support, independent/hands-on corroboration of card issuance API.", "evidenceIds": [ "unit-docs-3", "unit-docs-10", "unit-docs-5" ] }, { "productId": "unit", "storyId": "direct-bank-relationship", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Docs confirm Unit operates as middleware working through 'one or multiple Unit bank partners' and is a Federal Reserve service provider on behalf of partner banks, establishing that Unit itself is not the chartered bank. However, there is no evidence naming specific partner banks per customer, no disclosure of FBO/pass-through insurance mechanics, and nothing addressing what happens to end-customers' funds if Unit itself fails or a program winds down. Missing for 10: named partner bank identification per account, FDIC pass-through insurance details, and explicit platform-failure/customer-protection disclosures.", "evidenceIds": [ "unit-docs-6", "unit-docs-7", "unit-docs-1" ] }, { "productId": "unit", "storyId": "fbo-structure-transparency", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Unit's docs mention FBO deposit account structures and dashboard/API visibility into accounts and compliance data, but there's no plain documentation of where FDIC insurance actually attaches (pass-through vs individual), no explicit ledger access-control model, and no clear breakdown of pooled vs individual account structures for finance leads. missing for 10: explicit FDIC insurance attachment documentation, ledger visibility/permission model, clear FBO-vs-individual account structural disclosure.", "evidenceIds": [ "unit-docs-1", "unit-docs-5", "unit-docs-6" ] }, { "productId": "unit", "storyId": "fraud-loss-allocation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence describes Unit's banking, payments, and card infrastructure features but contains no discussion of who bears ACH return fraud, card dispute, or ATO losses, nor any liability-split documentation alongside fraud prevention tooling.", "evidenceIds": [] }, { "productId": "unit", "storyId": "international-payments", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Unit's docs mention 'international payments' as one of its payment capabilities, implying cross-border money movement exists, but there is no documentation of FX rate transparency, SWIFT specifics, or a coverage map of supported currencies/corridors. missing for 10: FX rate transparency details, SWIFT/wire specifics, currency and corridor coverage map.", "evidenceIds": [ "unit-docs-2" ] }, { "productId": "unit", "storyId": "kyc-kyb-onboarding", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack only vaguely references 'compliance' data access (unit-docs-5) but contains no specifics on programmatic KYC/KYB flows, document collection, watchlist screening, or modeled application states — capabilities Unit is known to offer but which are unevidenced here.", "evidenceIds": [ "unit-docs-5" ] }, { "productId": "unit", "storyId": "ledger-bank-reconciliation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of documented daily reconciliation processes, ledger-to-bank-core matching, or any explicit reconciliation guarantee; evidence only covers general account/payment/card capabilities and real-time balances, not reconciliation controls addressing the Synapse-style failure mode.", "evidenceIds": [] }, { "productId": "unit", "storyId": "limits-holds-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence only shows generic 'configurable card controls' and general compliance/operational data access; there is no mention of transaction or velocity limits, suspicious-activity holds, account freezes, or documented reinstatement paths at the account/program level. missing for 10: velocity/transaction limit configuration, hold/freeze workflow documentation, reinstatement process details.", "evidenceIds": [ "unit-docs-3", "unit-docs-5" ] }, { "productId": "unit", "storyId": "onboarding-review-controls", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack covers account, payment, card, and credit infrastructure plus general Dashboard/API access to 'compliance and operational data' (unit-docs-5), but nothing describes an onboarding queue, reasons for pending applications, document collection workflows, or a clear delineation of ops-vs-bank decision authority. This is a plausible axis for a BaaS platform handling KYC/onboarding, but no evidence substantiates the specific capability.", "evidenceIds": [] }, { "productId": "unit", "storyId": "openness-api-parity", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Unit is API-first infrastructure with a Dashboard described as accessing the same customer/account/payment/card data as the APIs (unit-docs-5), suggesting reasonable UI-API parity, but there is no explicit claim that every dashboard action is API-exposed, and probes show missing OpenAPI spec and machine-readable docs (unit-probe-2, unit-probe-3), undermining verifiability for an AI-native consumer. Missing for 10: explicit parity statement, discoverable OpenAPI/API reference, and evidence of AI-agent-friendly API consumption.", "evidenceIds": [ "unit-docs-5", "unit-probe-2", "unit-probe-3" ] }, { "productId": "unit", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence describes Unit's banking infrastructure capabilities (accounts, payments, cards, credit) and API/dashboard access to data, but nothing indicates a data export feature in open formats or any mechanism for a customer to extract and leave with their data. Missing for 10: any documented export/download feature, open-format data export (CSV/JSON dumps), or portability/exit tooling.", "evidenceIds": [ "unit-docs-5" ] }, { "productId": "unit", "storyId": "openness-open-license", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Unit is a fintech/banking infrastructure API platform, not an open-source project; there is no indication its core source code is meant to be published under any license. Asking to read the product's source under an open license is a category error for this kind of closed commercial financial platform.", "evidenceIds": [] }, { "productId": "unit", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Unit is a Banking-as-a-Service/financial infrastructure platform delivered as a hosted API/dashboard tied to bank partnerships and Federal Reserve connectivity; self-hosting the 'core product' is a category error since the core value depends on regulated banking relationships and infrastructure that cannot be run by a customer.", "evidenceIds": [] }, { "productId": "unit", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Unit is a banking-as-a-service/financial infrastructure platform, not an AI product or data-processing tool where 'AI-native user' data residency choice is a meaningful axis; no evidence pack content relates to AI data storage location or region selection for AI workloads.", "evidenceIds": [] }, { "productId": "unit", "storyId": "privacy-no-training", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack contains no mention of AI model training, data usage policies for AI, or opt-out mechanisms; Unit's documentation focuses entirely on banking infrastructure (accounts, payments, cards, credit). No evidence supports this capability.", "evidenceIds": [] }, { "productId": "unit", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack describes Unit's banking/payments infrastructure features (accounts, payments, cards, credit products, dashboard) but contains no mention of data retention policies, deletion controls, or privacy/data lifecycle management capabilities. This axis is plausible for a platform handling customer financial data, but no evidence supports it. Missing for 10: any documentation of data retention periods, customer data deletion/export mechanisms, or privacy compliance controls (e.g., GDPR/CCPA support).", "evidenceIds": [] }, { "productId": "unit", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Unit is a banking-as-a-service financial infrastructure platform, not an AI agent/tool whose telemetry or usage tracking an AI-native user would opt out of; this axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "unit", "storyId": "program-limits-scaling", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence pack item discusses program-level limits, underwriting/approval stages, or a documented process for raising limits; docs only describe product capabilities (accounts, payments, cards, credit products) without disclosing risk thresholds or escalation paths. This is a fair question for a BaaS platform since program limits and approval stages are core to bank-partner risk programs, so absence of evidence yields 'none' rather than 'na'.", "evidenceIds": [] }, { "productId": "unit", "storyId": "realtime-balances-events", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Unit's docs mention real-time balances and transaction data across accounts, payments, and cards (unit-docs-1, unit-docs-2, unit-docs-3), suggesting some real-time ledger visibility, but there is no mention of holds/pending balance mechanics or of webhooks for transaction state changes anywhere in the evidence pack. missing for 10: explicit documentation of webhook events per transaction state change, explicit handling of holds/pending balances in real-time reads, independent/hands-on confirmation of event-driven architecture.", "evidenceIds": [ "unit-docs-1", "unit-docs-2", "unit-docs-3" ] }, { "productId": "unit", "storyId": "statements-tax-documents", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence pack item mentions monthly statement generation or 1099-INT tax document production/retrieval via API; docs cover accounts, payments, cards, credit, and dashboard access but never statements or tax forms.", "evidenceIds": [] }, { "productId": "unit", "storyId": "transaction-data-quality", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Docs confirm Unit exposes transaction data via API/dashboard with settlement-level visibility for payments, cards, and accounts (unit-docs-1, unit-docs-2, unit-docs-3, unit-docs-5), but none of the evidence specifically describes counterparty detail fields, rail-specific metadata schemas, stable transaction identifiers, or enrichment logic that would make a raw bank feed usable in-product. missing for 10: explicit documentation of counterparty data fields, rail-specific metadata, stable/idempotent transaction IDs, and enrichment/categorization features.", "evidenceIds": [ "unit-docs-1", "unit-docs-2", "unit-docs-3", "unit-docs-5" ] }, { "productId": "unit", "storyId": "virtual-account-numbers", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Unit's docs confirm deposit/wallet accounts, sub-accounts, and multi-party fund flows suitable for per-customer collection and reconciliation use cases, but there is no explicit mention of programmatic bulk issuance of unique account/routing numbers at scale or dedicated virtual-account reconciliation features. Missing for 10: explicit API documentation on bulk/at-scale account+routing number issuance, virtual account numbering scheme details, and independent/hands-on confirmation of scale performance.", "evidenceIds": [ "unit-docs-1", "unit-docs-6", "unit-probe-1" ] }, { "productId": "unit", "storyId": "wires-instant-rails", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Unit's docs mention wires and 'real-time payments' (implying RTP) alongside ACH and checks, and claims direct Fed Reserve connectivity, but there is no explicit mention of FedNow origination/receipt, and no per-rail documentation of capabilities (limits, cutoffs, originate vs receive) is evidenced — in fact the docs/OpenAPI probes returned 404s, so detailed rail-specific documentation can't be confirmed. missing for 10: explicit FedNow support, per-rail capability tables (limits/cutoffs/origination vs receipt), and accessible detailed API docs confirming rail parity.", "evidenceIds": [ "unit-docs-2", "unit-docs-7", "unit-probe-2", "unit-probe-3" ] }, { "productId": "unit", "storyId": "yield-interest-options", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers deposit accounts, payments, cards, and credit products but contains no mention of interest-bearing accounts, sweep programs, rate mechanics, or spread-sharing arrangements for idle balances.", "evidenceIds": [] } ]