Stripe Treasury vs Unit

Account opening

1. developerOpen a real, insured deposit account through the API — application to active account fully programmatic, with sandbox parity so the flow is tested before launch

   weight 3 · round drawn
   Stripe Treasury~partialclaimed4/10

   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.

   • [claimed-docs] “A financial account can hold fiat balances such as USD, EUR, and GBP, and eligible businesses can also hold a stablecoin balance in USDC.”
   • [claimed-docs] “Create financial accounts that can hold funds (`money_manager` configuration)”
   • [claimed-docs] “As the platform, you can move money from your payments [Balance] to your financial accounts or from your connected accounts’ payments balanc…”
   • [claimed-docs] “There are no monthly fees or minimum balance requirements to open or maintain a financial account.”

   proof ↗⚑ flag

   Unit~partialprobed4/10

   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.

   • [claimed-docs] “Create deposit accounts and wallet accounts held in FBO structures. Support use cases including operating accounts, customer wallets, sub-ac…”
   • [claimed-docs] “Companies can work with one or multiple Unit bank partners through the same infrastructure.”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.unit.co/docs/api/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.unit.co/openapi.json, https://www.unit.co/swagger.json, https://www.unit.co/api/openapi.…”

   proof ↗⚑ flag

Fbo structures

1. finance leadThe account structure is transparent — whether funds sit in FBO pools or individual accounts, where FDIC insurance actually attaches, and who can see the ledger, all documented plainly

   weight 3 · round to Unit
   Stripe Treasury—none0/10

   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.

   ⚑ flag

   Unit~partialclaimed4/10

   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.

   • [claimed-docs] “Create deposit accounts and wallet accounts held in FBO structures. Support use cases including operating accounts, customer wallets, sub-ac…”
   • [claimed-docs] “The Unit Dashboard and APIs provide teams with access to customer, account, payment, card, transaction, compliance, and operational data.”
   • [claimed-docs] “Companies can work with one or multiple Unit bank partners through the same infrastructure.”

   proof ↗⚑ flag

Virtual accounts

1. developerIssue unique account and routing numbers at scale — virtual accounts for reconciliation, per-customer collection accounts, and sub-accounts under a master structure

   weight 2 · round drawn
   Stripe Treasury~partialclaimed5/10

   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.

   • [claimed-docs] “Create financial accounts that can hold funds (`money_manager` configuration)”
   • [claimed-docs] “As the platform, you can move money from your payments [Balance] to your financial accounts or from your connected accounts’ payments balanc…”
   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”
   • [claimed-docs] “allows Connect platforms to offer financial services, such as funds separation and storage, bill pay, and cash flow management, to eligible …”

   proof ↗⚑ flag

   Unit~partialprobed5/10

   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.

   • [claimed-docs] “Create deposit accounts and wallet accounts held in FBO structures. Support use cases including operating accounts, customer wallets, sub-ac…”
   • [claimed-docs] “Companies can work with one or multiple Unit bank partners through the same infrastructure.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://www.unit.co/llms.txt # Unit > **Unit is a financial infrastructure platform for technology companies th…”

   proof ↗⚑ flag

Yield

1. finance leadIdle balances can earn — interest-bearing accounts or documented sweep options, with the rate mechanics and who keeps the spread spelled out

   weight 2 · round drawn
   Stripe Treasury—none0/10

   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.

   • [claimed-docs] “A financial account can hold fiat balances such as USD, EUR, and GBP, and eligible businesses can also hold a stablecoin balance in USDC.”
   • [claimed-docs] “There are no monthly fees or minimum balance requirements to open or maintain a financial account.”
   • [claimed-docs] “As the platform, you can move money from your payments [Balance] to your financial accounts or from your connected accounts’ payments balanc…”

   proof ↗⚑ flag

   Unit—none0/10

   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.

   ⚑ flag

Agent access

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

   weight 2 · round drawn
   Stripe Treasury✓fullprobed8/10

   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.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stripe.com/llms.txt # Stripe Documentation When installing Stripe packages, always check the npm r…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/treasury.md # Treasury Learn how to securely manage money with a financial account. Loo…”

   proof ↗⚑ flag

   Unit✓fullprobed8/10

   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.

   • [probe] “PROBE llms.txt: HTTP 200 at https://www.unit.co/llms.txt # Unit > **Unit is a financial infrastructure platform for technology companies th…”
   • [claimed-docs] “Create deposit accounts and wallet accounts held in FBO structures. Support use cases including operating accounts, customer wallets, sub-ac…”
   • [claimed-docs] “The Unit Dashboard and APIs provide teams with access to customer, account, payment, card, transaction, compliance, and operational data.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.unit.co/openapi.json, https://www.unit.co/swagger.json, https://www.unit.co/api/openapi.…”

   proof ↗⚑ flag

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

   weight 2 · round to Stripe Treasury
   Stripe Treasury~partialprobed3/10

   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.

   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”
   • [claimed-docs] “OutboundPayment objects represent push-based transfers from: A platform’s financial accounts to a financial account owned by connected accou…”
   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”

   proof ↗⚑ flag

   Unit—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

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

   weight 3 · round to Stripe Treasury
   Stripe Treasury✓fullprobed6/10

   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.

   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   proof ↗⚑ flag

   Unit—none0/10

   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.

   • [probe] “PROBE docs-md: HTTP 404 at https://www.unit.co/docs/api/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.unit.co/openapi.json, https://www.unit.co/swagger.json, https://www.unit.co/api/openapi.…”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Stripe Treasury
   Stripe Treasury✓fullprobed7/10

   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.

   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”

   proof ↗⚑ flag

   Unit—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

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

   weight 3 · round to Stripe Treasury
   Stripe Treasury✓fullprobed8/10

   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.

   • [claimed-docs] “Create financial accounts that can hold funds (`money_manager` configuration)”
   • [claimed-docs] “OutboundPayment objects represent push-based transfers from: A platform’s financial accounts to a financial account owned by connected accou…”
   • [claimed-docs] “You can authorize third parties to debit funds from a financial account.”
   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stripe.com/llms.txt # Stripe Documentation When installing Stripe packages, always check the npm r…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/treasury.md # Treasury Learn how to securely manage money with a financial account. Loo…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”

   proof ↗⚑ flag

   Unit~partialprobed5/10

   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.

   • [claimed-docs] “Create deposit accounts and wallet accounts held in FBO structures. Support use cases including operating accounts, customer wallets, sub-ac…”
   • [claimed-docs] “Send and receive money using payment capabilities including ACH, wires, real-time payments, checks, and international payments, with settlem…”
   • [claimed-docs] “The Unit Dashboard and APIs provide teams with access to customer, account, payment, card, transaction, compliance, and operational data.”
   • [claimed-docs] “Direct, bare-metal access to the Federal Reserve, the card networks, and bank partners.”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.unit.co/docs/api/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.unit.co/openapi.json, https://www.unit.co/swagger.json, https://www.unit.co/api/openapi.…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Stripe Treasury—none0/10

   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.

   ⚑ flag

   Unit—none0/10

   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.

   ⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Stripe Treasury
   Stripe Treasury~partialprobed3/10

   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.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stripe.com/llms.txt # Stripe Documentation When installing Stripe packages, always check the npm r…”

   proof ↗⚑ flag

   Unit—none0/10

   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.

   • [claimed-docs] “The Unit Dashboard and APIs provide teams with access to customer, account, payment, card, transaction, compliance, and operational data.”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.unit.co/docs/api/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.unit.co/openapi.json, https://www.unit.co/swagger.json, https://www.unit.co/api/openapi.…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Stripe Treasury—none0/10

   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.

   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”
   • [claimed-docs] “Stripe runs automatic risk controls that help reduce your fraud exposure within Treasury and Issuing without requiring action to enable.”

   proof ↗⚑ flag

   Unit—none0/10

   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.

   ⚑ flag

Agentic features

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

   weight 2 · round drawn
   Stripe Treasury—none0/10

   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.

   ⚑ flag

   Unit—none0/10

   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.

   • [claimed-docs] “The Unit Dashboard and APIs provide teams with access to customer, account, payment, card, transaction, compliance, and operational data.”
   • [claimed-docs] “Store, move, spend, and lend money inside your product.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Stripe Treasury—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Unit—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

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

   weight 2 · round to Stripe Treasury
   Stripe Treasury~partialprobed4/10

   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.

   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   proof ↗⚑ flag

   Unit—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

Api quality

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

   weight 2 · round drawn
   Stripe Treasury—none0/10

   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.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/treasury.md # Treasury Learn how to securely manage money with a financial account. Loo…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stripe.com/llms.txt # Stripe Documentation When installing Stripe packages, always check the npm r…”

   proof ↗⚑ flag

   Unit—none0/10

   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.

   • [probe] “PROBE docs-md: HTTP 404 at https://www.unit.co/docs/api/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.unit.co/openapi.json, https://www.unit.co/swagger.json, https://www.unit.co/api/openapi.…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Stripe Treasury—none0/10

   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.

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

   proof ↗⚑ flag

   Unit—none0/10

   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.

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.unit.co/openapi.json, https://www.unit.co/swagger.json, https://www.unit.co/api/openapi.…”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.unit.co/docs/api/.md”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   Stripe Treasury—none0/10

   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.

   ⚑ flag

   Unit—none0/10

   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.

   ⚑ flag

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

   weight 2 · round drawn
   Stripe Treasury—none0/10

   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.

   ⚑ flag

   Unit—none0/10

   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.

   • [probe] “PROBE docs-md: HTTP 404 at https://www.unit.co/docs/api/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.unit.co/openapi.json, https://www.unit.co/swagger.json, https://www.unit.co/api/openapi.…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Stripe Treasury—none0/10

   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.

   ⚑ flag

   Unit—none0/10

   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.

   • [claimed-docs] “Create deposit accounts and wallet accounts held in FBO structures. Support use cases including operating accounts, customer wallets, sub-ac…”
   • [claimed-docs] “Send and receive money using payment capabilities including ACH, wires, real-time payments, checks, and international payments, with settlem…”
   • [claimed-docs] “The Unit Dashboard and APIs provide teams with access to customer, account, payment, card, transaction, compliance, and operational data.”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Stripe Treasury—none0/10

   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.

   • [claimed-docs] “Stripe runs automatic risk controls that help reduce your fraud exposure within Treasury and Issuing without requiring action to enable.”
   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”

   proof ↗⚑ flag

   Unit—none0/10

   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.

   ⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   Stripe Treasury—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Unit—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

Agent operations

1. ai-native userAn agent can operate an account within policy — scoped credentials that let it read balances and initiate transfers under amount caps and counterparty allowlists, a use the vendor documents by name

   weight 3 · round drawn
   Stripe Treasury—none0/10

   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.

   • [claimed-docs] “OutboundPayment objects represent push-based transfers from: A platform’s financial accounts to a financial account owned by connected accou…”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   proof ↗⚑ flag

   Unit—none0/10

   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.

   ⚑ flag

Agent visibility

1. ai-native userAn agent can read the full banking picture — accounts, transactions, pending activity, documents — through a clean API or MCP surface without screen-scraping a dashboard

   weight 2 · round to Stripe Treasury
   Stripe Treasury~partialprobed6/10

   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.

   • [claimed-docs] “A financial account can hold fiat balances such as USD, EUR, and GBP, and eligible businesses can also hold a stablecoin balance in USDC.”
   • [claimed-docs] “Create financial accounts that can hold funds (`money_manager` configuration)”
   • [claimed-docs] “OutboundPayment objects represent push-based transfers from: A platform’s financial accounts to a financial account owned by connected accou…”
   • [claimed-docs] “You can authorize third parties to debit funds from a financial account.”
   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”

   proof ↗⚑ flag

   Unit~partialprobed5/10

   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.

   • [claimed-docs] “Create deposit accounts and wallet accounts held in FBO structures. Support use cases including operating accounts, customer wallets, sub-ac…”
   • [claimed-docs] “Send and receive money using payment capabilities including ACH, wires, real-time payments, checks, and international payments, with settlem…”
   • [claimed-docs] “Issue physical and virtual cards with configurable controls, real-time authorization capabilities, transaction data, and card lifecycle mana…”
   • [claimed-docs] “The Unit Dashboard and APIs provide teams with access to customer, account, payment, card, transaction, compliance, and operational data.”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.unit.co/docs/api/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.unit.co/openapi.json, https://www.unit.co/swagger.json, https://www.unit.co/api/openapi.…”

   proof ↗⚑ flag

Builtin ai

1. ops userThe product ships its own AI for banking operations — natural-language search over transactions, drafted responses to disputes and alerts, anomaly summaries — built in, not bolted on

   weight 2 · round drawn
   Stripe Treasury—none0/10

   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.

   • [claimed-docs] “Stripe runs automatic risk controls that help reduce your fraud exposure within Treasury and Issuing without requiring action to enable.”
   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”

   proof ↗⚑ flag

   Unit—none0/10

   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.

   ⚑ flag

Card issuance

1. developerAccounts come with cards — issue virtual and physical debit cards tied to the account through the same API, with spend controls and digital wallet support

   weight 2 · round to Unit
   Stripe Treasury~partialclaimed4/10

   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.

   • [claimed-docs] “Render Stripe financial account features such as bill pay, issuing, and cash rewards as a branded UI in your platform application while avoi…”
   • [claimed-docs] “Stripe runs automatic risk controls that help reduce your fraud exposure within Treasury and Issuing without requiring action to enable.”

   proof ↗⚑ flag

   Unit~partialclaimed6/10

   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.

   • [claimed-docs] “Issue physical and virtual cards with configurable controls, real-time authorization capabilities, transaction data, and card lifecycle mana…”
   • [claimed-docs] “Store, move, spend, and lend money inside your product.”
   • [claimed-docs] “The Unit Dashboard and APIs provide teams with access to customer, account, payment, card, transaction, compliance, and operational data.”

   proof ↗⚑ flag

Disputes

1. ops userCard and ACH disputes are handled properly — Reg E investigation timelines, provisional credit mechanics, and my operational responsibilities documented and tooled

   weight 2 · round drawn
   Stripe Treasury—none0/10

   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.

   ⚑ flag

   Unit—none0/10

   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.

   ⚑ flag

Balances events

1. developerThe ledger is real-time and event-driven — balance reads that reflect holds and pending activity, and webhooks for every transaction state change so my system mirrors the bank exactly

   weight 3 · round drawn
   Stripe Treasury~partialclaimed3/10

   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.

   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”

   proof ↗⚑ flag

   Unit~partialclaimed3/10

   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.

   • [claimed-docs] “Create deposit accounts and wallet accounts held in FBO structures. Support use cases including operating accounts, customer wallets, sub-ac…”
   • [claimed-docs] “Send and receive money using payment capabilities including ACH, wires, real-time payments, checks, and international payments, with settlem…”
   • [claimed-docs] “Issue physical and virtual cards with configurable controls, real-time authorization capabilities, transaction data, and card lifecycle mana…”

   proof ↗⚑ flag

Data quality

1. developerTransaction data is rich enough to build on — counterparty details, rail-specific metadata, stable identifiers, and enrichment that makes a raw bank feed usable in-product

   weight 2 · round to Unit
   Stripe Treasury~partialclaimed3/10

   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.

   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”

   proof ↗⚑ flag

   Unit~partialclaimed4/10

   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.

   • [claimed-docs] “Create deposit accounts and wallet accounts held in FBO structures. Support use cases including operating accounts, customer wallets, sub-ac…”
   • [claimed-docs] “Send and receive money using payment capabilities including ACH, wires, real-time payments, checks, and international payments, with settlem…”
   • [claimed-docs] “Issue physical and virtual cards with configurable controls, real-time authorization capabilities, transaction data, and card lifecycle mana…”
   • [claimed-docs] “The Unit Dashboard and APIs provide teams with access to customer, account, payment, card, transaction, compliance, and operational data.”

   proof ↗⚑ flag

Statements

1. ops userThe paper obligations are automated — monthly statements generated per account, and tax documents (1099-INT) produced and retrievable through the API

   weight 2 · round drawn
   Stripe Treasury—none0/10

   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.

   ⚑ flag

   Unit—none0/10

   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.

   ⚑ flag

Kyc kyb

1. developerCustomer verification is programmatic — KYC for individuals and KYB for businesses with document collection, watchlist screening, and clearly modeled application states

   weight 3 · round drawn
   Stripe Treasury—none0/10

   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.

   ⚑ flag

   Unit—none0/10

   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.

   • [claimed-docs] “The Unit Dashboard and APIs provide teams with access to customer, account, payment, card, transaction, compliance, and operational data.”

   proof ↗⚑ flag

Review queues

1. ops userWork the onboarding queue — see why an application is pending, supply additional documents, and understand which decisions are mine versus the bank's

   weight 2 · round drawn
   Stripe Treasury—none0/10

   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.

   ⚑ flag

   Unit—none0/10

   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.

   ⚑ flag

Limits holds

1. ops userSet risk controls per account and per program — transaction and velocity limits, holds on suspicious activity, and account freezes with documented reinstatement paths

   weight 2 · round drawn
   Stripe Treasury—none0/10

   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.

   • [claimed-docs] “Stripe runs automatic risk controls that help reduce your fraud exposure within Treasury and Issuing without requiring action to enable.”

   proof ↗⚑ flag

   Unit—none0/10

   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.

   • [claimed-docs] “Issue physical and virtual cards with configurable controls, real-time authorization capabilities, transaction data, and card lifecycle mana…”
   • [claimed-docs] “The Unit Dashboard and APIs provide teams with access to customer, account, payment, card, transaction, compliance, and operational data.”

   proof ↗⚑ flag

Loss allocation

1. finance leadFraud economics are explicit — who eats ACH return fraud, card disputes, and account takeover losses, with the platform's prevention tooling documented alongside the liability split

   weight 2 · round drawn
   Stripe Treasury—none0/10

   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.

   • [claimed-docs] “Stripe runs automatic risk controls that help reduce your fraud exposure within Treasury and Issuing without requiring action to enable.”

   proof ↗⚑ flag

   Unit—none0/10

   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.

   ⚑ flag

Program scaling

1. founderGrowth doesn't hit invisible walls — program-level limits, approval stages, and the path to raising them are documented rather than discovered in an email from the bank

   weight 2 · round drawn
   Stripe Treasury—none0/10

   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.

   • [community] “A commenter noted the Treasury landing page "doesn’t really explain what kinds of problems Treasury solves," and asked for clarity on target…”
   • [community] “HN thread reports that the Evolve Bank and Trust hack impacted both Mercury and Stripe Treasury customers; a user confirmed receiving a noti…”

   proof ↗⚑ flag

   Unit—none0/10

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

   ⚑ flag

Ach

1. developerOriginate ACH through the API — credits and debits, same-day windows, and the unhappy paths (returns, NOCs, reversals) modeled as first-class objects with webhooks

   weight 3 · round to Unit
   Stripe Treasury—none0/10

   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.

   • [claimed-docs] “OutboundPayment objects represent push-based transfers from: A platform’s financial accounts to a financial account owned by connected accou…”
   • [claimed-docs] “You can authorize third parties to debit funds from a financial account.”
   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”

   proof ↗⚑ flag

   Unit~partialclaimed3/10

   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.

   • [claimed-docs] “Send and receive money using payment capabilities including ACH, wires, real-time payments, checks, and international payments, with settlem…”
   • [claimed-docs] “The Unit Dashboard and APIs provide teams with access to customer, account, payment, card, transaction, compliance, and operational data.”

   proof ↗⚑ flag

Checks

1. ops userChecks still work — programmatic check issuance and check deposit with image capture, because real businesses still receive and send paper

   weight 2 · round to Unit
   Stripe Treasury—none0/10

   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.

   ⚑ flag

   Unit~partialclaimed3/10

   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.

   • [claimed-docs] “Send and receive money using payment capabilities including ACH, wires, real-time payments, checks, and international payments, with settlem…”

   proof ↗⚑ flag

Instant rails

1. developerThe faster rails are there when I need them — domestic wires, RTP, and FedNow origination and receipt through the same API, with per-rail capabilities documented

   weight 2 · round to Unit
   Stripe Treasury—none0/10

   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.

   • [claimed-docs] “OutboundPayment objects represent push-based transfers from: A platform’s financial accounts to a financial account owned by connected accou…”
   • [claimed-docs] “You can authorize third parties to debit funds from a financial account.”
   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”

   proof ↗⚑ flag

   Unit~partialprobed4/10

   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.

   • [claimed-docs] “Send and receive money using payment capabilities including ACH, wires, real-time payments, checks, and international payments, with settlem…”
   • [claimed-docs] “Unit is a registered Federal Reserve service provider with direct connectivity to Federal Reserve systems on behalf of partner banks.”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.unit.co/docs/api/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.unit.co/openapi.json, https://www.unit.co/swagger.json, https://www.unit.co/api/openapi.…”

   proof ↗⚑ flag

International

1. founderMoney can cross borders — international wires or SWIFT, FX with transparent rates, and the coverage map of currencies and corridors documented

   weight 2 · round to Unit
   Stripe Treasury—none0/10

   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.

   • [claimed-docs] “A financial account can hold fiat balances such as USD, EUR, and GBP, and eligible businesses can also hold a stablecoin balance in USDC.”

   proof ↗⚑ flag

   Unit~partialclaimed3/10

   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.

   • [claimed-docs] “Send and receive money using payment capabilities including ACH, wires, real-time payments, checks, and international payments, with settlem…”

   proof ↗⚑ flag

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

   weight 2 · round to Stripe Treasury
   Stripe Treasury~partialclaimed6/10

   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.

   • [claimed-docs] “you can access your financial account on the Treasury page in the Stripe Dashboard or from the Dashboard mobile app”
   • [claimed-docs] “Render Stripe financial account features such as bill pay, issuing, and cash rewards as a branded UI in your platform application while avoi…”
   • [claimed-docs] “As the platform, you can move money from your payments [Balance] to your financial accounts or from your connected accounts’ payments balanc…”
   • [claimed-docs] “OutboundPayment objects represent push-based transfers from: A platform’s financial accounts to a financial account owned by connected accou…”
   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”
   • [claimed-docs] “Stripe runs automatic risk controls that help reduce your fraud exposure within Treasury and Issuing without requiring action to enable.”

   proof ↗⚑ flag

   Unit~partialprobed4/10

   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.

   • [claimed-docs] “The Unit Dashboard and APIs provide teams with access to customer, account, payment, card, transaction, compliance, and operational data.”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.unit.co/docs/api/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.unit.co/openapi.json, https://www.unit.co/swagger.json, https://www.unit.co/api/openapi.…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Stripe Treasury—none0/10

   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.

   ⚑ flag

   Unit—none0/10

   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.

   • [claimed-docs] “The Unit Dashboard and APIs provide teams with access to customer, account, payment, card, transaction, compliance, and operational data.”

   proof ↗⚑ flag

1. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Stripe Treasury—none0/10

   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.

   ⚑ flag

   Unit—none0/10

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

   ⚑ flag

Charter clarity

1. founderExactly who holds the charter — whether the platform is a bank, a direct program with a named partner bank, or middleware between me and someone else's sponsor — and what happens to my customers if the platform fails

   weight 3 · round to Stripe Treasury
   Stripe Treasury~partialcommunity4/10

   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.

   • [claimed-docs] “You can embed the Treasury disclosure component directly on your website to automatically display currently compliant disclosure information…”
   • [community] “A user questioned the optics of Stripe Treasury's bank partnerships: "Partnering with companies such as Goldman Sachs is typically not a goo…”
   • [community] “HN thread reports that the Evolve Bank and Trust hack impacted both Mercury and Stripe Treasury customers; a user confirmed receiving a noti…”

   proof ↗⚑ flag

   Unit~partialclaimed3/10

   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.

   • [claimed-docs] “Companies can work with one or multiple Unit bank partners through the same infrastructure.”
   • [claimed-docs] “Unit is a registered Federal Reserve service provider with direct connectivity to Federal Reserve systems on behalf of partner banks.”
   • [claimed-docs] “Create deposit accounts and wallet accounts held in FBO structures. Support use cases including operating accounts, customer wallets, sub-ac…”

   proof ↗⚑ flag

Compliance tooling

1. ops userThe compliance workload is tooled — transaction monitoring, sanctions screening, case management for alerts, and SAR-filing support with a clear split of duties between me, the platform, and the bank

   weight 2 · round drawn
   Stripe Treasury—none0/10

   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.

   • [claimed-docs] “Stripe runs automatic risk controls that help reduce your fraud exposure within Treasury and Issuing without requiring action to enable.”
   • [claimed-docs] “You can embed the Treasury disclosure component directly on your website to automatically display currently compliant disclosure information…”

   proof ↗⚑ flag

   Unit—none0/10

   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.

   • [claimed-docs] “The Unit Dashboard and APIs provide teams with access to customer, account, payment, card, transaction, compliance, and operational data.”

   proof ↗⚑ flag

Reconciliation

1. finance leadThe platform ledger reconciles to the bank core — documented daily reconciliation between what the API reports and what the bank holds, the failure that sank Synapse-era programs

   weight 3 · round drawn
   Stripe Treasury—none0/10

   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.

   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”

   proof ↗⚑ flag

   Unit—none0/10

   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.

   ⚑ flag