Unit vs Treasury Prime

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 to Treasury Prime
   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

   Treasury Prime~partialclaimed7/10

   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.

   • [claimed-docs] “create a free Developer Sandbox account. This provides access to the Developer Sandbox where you can create and manage API keys, and safely …”
   • [claimed-docs] “To apply to open a new bank account 1. Create a Person Application 2. Create a Business Application ... 5. Create an Account Application”
   • [claimed-docs] “Programs can seamlessly integrate their bank-approved third-party KYC/KYB vendor into the account opening process.”
   • [claimed-docs] “you can do your testing as in command line or using our Postman Collection to speed up your initial exploration of our APIs.”

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

   Treasury Prime—none0/10

   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.

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

   Treasury Prime—none0/10

   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.

   • [claimed-docs] “Get a list of all the available accounts using the `account` endpoint.”
   • [claimed-docs] “To apply to open a new bank account 1. Create a Person Application 2. Create a Business Application ... 5. Create an Account Application”

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

   Treasury Prime—none0/10

   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.

   ⚑ flag

Agent access

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

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

   Treasury Prime✓fullprobed9/10

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

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.treasuryprime.com/llms.txt # Treasury Prime Developer Documentation - [Getting Started](https://do…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.treasuryprime.com/openapi.json, https://docs.treasuryprime.com/swagger.json, https://do…”

   proof ↗⚑ flag

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

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

   Treasury Prime~partialprobed4/10

   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.

   • [claimed-docs] “Call the `ping` endpoint using HTTP Basic Auth, providing your API Key ID as the username, and the API Secret Key as the password.”
   • [claimed-docs] “you can do your testing as in command line or using our Postman Collection to speed up your initial exploration of our APIs.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.treasuryprime.com/openapi.json, https://docs.treasuryprime.com/swagger.json, https://do…”

   proof ↗⚑ flag

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

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

   Treasury Prime—none0/10

   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.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.treasuryprime.com/llms.txt # Treasury Prime Developer Documentation - [Getting Started](https://do…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.treasuryprime.com/openapi.json, https://docs.treasuryprime.com/swagger.json, https://do…”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

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

   Treasury Prime—none0/10

   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.

   • [claimed-docs] “you can do your testing as in command line or using our Postman Collection to speed up your initial exploration of our APIs.”

   proof ↗⚑ flag

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

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

   Treasury Prime✓fullprobed8/10

   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.

   • [claimed-docs] “create a free Developer Sandbox account. This provides access to the Developer Sandbox where you can create and manage API keys, and safely …”
   • [claimed-docs] “Call the `ping` endpoint using HTTP Basic Auth, providing your API Key ID as the username, and the API Secret Key as the password.”
   • [claimed-docs] “Get a list of all the available accounts using the `account` endpoint.”
   • [claimed-docs] “you can do your testing as in command line or using our Postman Collection to speed up your initial exploration of our APIs.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.treasuryprime.com/llms.txt # Treasury Prime Developer Documentation - [Getting Started](https://do…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.treasuryprime.com/openapi.json, https://docs.treasuryprime.com/swagger.json, https://do…”

   proof ↗⚑ flag

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

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

   Treasury Prime—none0/10

   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.

   • [claimed-docs] “create a free Developer Sandbox account. This provides access to the Developer Sandbox where you can create and manage API keys, and safely …”
   • [claimed-docs] “Call the `ping` endpoint using HTTP Basic Auth, providing your API Key ID as the username, and the API Secret Key as the password.”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

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

   Treasury Prime—none0/10

   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.

   • [claimed-docs] “you can do your testing as in command line or using our Postman Collection to speed up your initial exploration of our APIs.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.treasuryprime.com/openapi.json, https://docs.treasuryprime.com/swagger.json, https://do…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

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

   Treasury Prime—none0/10

   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.

   ⚑ flag

Agentic features

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

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

   Treasury Prime—none0/10

   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.

   ⚑ flag

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

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

   Treasury Prime—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 drawn
   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

   Treasury Prime—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 to Treasury Prime
   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

   Treasury Prime~partialprobed4/10

   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.

   • [claimed-docs] “you can do your testing as in command line or using our Postman Collection to speed up your initial exploration of our APIs.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.treasuryprime.com/openapi.json, https://docs.treasuryprime.com/swagger.json, https://do…”

   proof ↗⚑ flag

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

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

   Treasury Prime—none0/10

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

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.treasuryprime.com/openapi.json, https://docs.treasuryprime.com/swagger.json, https://do…”
   • [claimed-docs] “you can do your testing as in command line or using our Postman Collection to speed up your initial exploration of our APIs.”

   proof ↗⚑ flag

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

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

   Treasury Prime✓fullclaimed8/10

   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.

   • [claimed-docs] “create a free Developer Sandbox account. This provides access to the Developer Sandbox where you can create and manage API keys, and safely …”
   • [claimed-docs] “Call the `ping` endpoint using HTTP Basic Auth, providing your API Key ID as the username, and the API Secret Key as the password.”
   • [claimed-docs] “Get a list of all the available accounts using the `account` endpoint.”
   • [claimed-docs] “you can do your testing as in command line or using our Postman Collection to speed up your initial exploration of our APIs.”

   proof ↗⚑ flag

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

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

   Treasury Prime—none0/10

   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.

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

   proof ↗⚑ flag

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

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

   Treasury Prime—none0/10

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

   • [claimed-docs] “An ACH credit is used when you wish to send or "push" funds to a recipient. ... An ACH debit is used when you wish to "pull" funds from an e…”
   • [claimed-docs] “You can track the progress of a wire by checking the `status` attribute on the Wire Transfer object.”
   • [claimed-docs] “A book transfer is an electronic funds transfer between two accounts at the same bank... Book transfers are the fastest and cheapest type of…”

   proof ↗⚑ flag

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

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

   Treasury Prime—none0/10

   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.

   ⚑ flag

3. ai-native userSchedule recurring jobs or workflows

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

   Treasury Prime—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
   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

   Treasury Prime—none0/10

   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.

   • [claimed-docs] “Call the `ping` endpoint using HTTP Basic Auth, providing your API Key ID as the username, and the API Secret Key as the password.”
   • [claimed-docs] “Get a list of all the available accounts using the `account` endpoint.”
   • [claimed-docs] “An ACH credit is used when you wish to send or "push" funds to a recipient. ... An ACH debit is used when you wish to "pull" funds from an e…”
   • [claimed-docs] “You can track the progress of a wire by checking the `status` attribute on the Wire Transfer object.”
   • [claimed-docs] “A book transfer is an electronic funds transfer between two accounts at the same bank... Book transfers are the fastest and cheapest type of…”

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

   Treasury Prime~partialprobed5/10

   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.

   • [claimed-docs] “Get a list of all the available accounts using the `account` endpoint.”
   • [claimed-docs] “You can track the progress of a wire by checking the `status` attribute on the Wire Transfer object.”
   • [claimed-docs] “Generate and retrieve branded monthly account statements for your customers.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.treasuryprime.com/llms.txt # Treasury Prime Developer Documentation - [Getting Started](https://do…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.treasuryprime.com/openapi.json, https://docs.treasuryprime.com/swagger.json, https://do…”

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

   Treasury Prime—none0/10

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

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

   Treasury Prime—none0/10

   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.

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

   Treasury Prime—none0/10

   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.

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

   Treasury Prime—none0/10

   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.

   • [claimed-docs] “You can track the progress of a wire by checking the `status` attribute on the Wire Transfer object.”
   • [claimed-docs] “Get a list of all the available accounts using the `account` endpoint.”
   • [claimed-docs] “An ACH credit is used when you wish to send or "push" funds to a recipient. ... An ACH debit is used when you wish to "pull" funds from an e…”

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

   Treasury Prime~partialclaimed4/10

   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.

   • [claimed-docs] “An ACH credit is used when you wish to send or "push" funds to a recipient. ... An ACH debit is used when you wish to "pull" funds from an e…”
   • [claimed-docs] “You can track the progress of a wire by checking the `status` attribute on the Wire Transfer object.”
   • [claimed-docs] “A book transfer is an electronic funds transfer between two accounts at the same bank... Book transfers are the fastest and cheapest type of…”
   • [claimed-docs] “To return an ACH transfer you originated, use the Update an ACH endpoint.”

   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 to Treasury Prime
   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

   Treasury Prime~partialclaimed4/10

   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.

   • [claimed-docs] “Generate and retrieve branded monthly account statements for your customers.”

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

   Treasury Prime~partialclaimed6/10

   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.

   • [claimed-docs] “To apply to open a new bank account 1. Create a Person Application 2. Create a Business Application ... 5. Create an Account Application”
   • [claimed-docs] “Programs can seamlessly integrate their bank-approved third-party KYC/KYB vendor into the account opening process.”
   • [claimed-docs] “Incremental KYC lets you run KYC **without opening an account**.”

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

   Treasury Prime—none0/10

   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.

   • [claimed-docs] “To apply to open a new bank account 1. Create a Person Application 2. Create a Business Application ... 5. Create an Account Application”
   • [claimed-docs] “Programs can seamlessly integrate their bank-approved third-party KYC/KYB vendor into the account opening process.”
   • [claimed-docs] “Incremental KYC lets you run KYC **without opening an account**.”

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

   Treasury Prime—none0/10

   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.

   • [claimed-docs] “To apply to open a new bank account 1. Create a Person Application 2. Create a Business Application ... 5. Create an Account Application”
   • [claimed-docs] “Programs can seamlessly integrate their bank-approved third-party KYC/KYB vendor into the account opening process.”
   • [claimed-docs] “An ACH credit is used when you wish to send or "push" funds to a recipient. ... An ACH debit is used when you wish to "pull" funds from an e…”
   • [claimed-docs] “To return an ACH transfer you originated, use the Update an ACH endpoint.”
   • [claimed-docs] “Generate and retrieve branded monthly account statements for your customers.”

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

   Treasury Prime—none0/10

   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.

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

   Treasury Prime—none0/10

   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.

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

   Treasury Prime~partialclaimed5/10

   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.

   • [claimed-docs] “An ACH credit is used when you wish to send or "push" funds to a recipient. ... An ACH debit is used when you wish to "pull" funds from an e…”
   • [claimed-docs] “To return an ACH transfer you originated, use the Update an ACH endpoint.”

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

   Treasury Prime—none0/10

   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.

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

   Treasury Prime~partialclaimed6/10

   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.

   • [claimed-docs] “You can track the progress of a wire by checking the `status` attribute on the Wire Transfer object.”
   • [claimed-docs] “Instant Settlement: Payments settle within seconds, 24/7/365”
   • [claimed-docs] “An ACH credit is used when you wish to send or "push" funds to a recipient. ... An ACH debit is used when you wish to "pull" funds from an e…”
   • [claimed-docs] “A book transfer is an electronic funds transfer between two accounts at the same bank... Book transfers are the fastest and cheapest type of…”

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

   Treasury Prime—none0/10

   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.

   ⚑ flag

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

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

   Treasury Prime~partialprobed6/10

   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.

   • [claimed-docs] “To apply to open a new bank account 1. Create a Person Application 2. Create a Business Application ... 5. Create an Account Application”
   • [claimed-docs] “Programs can seamlessly integrate their bank-approved third-party KYC/KYB vendor into the account opening process.”
   • [claimed-docs] “Incremental KYC lets you run KYC **without opening an account**.”
   • [claimed-docs] “An ACH credit is used when you wish to send or "push" funds to a recipient. ... An ACH debit is used when you wish to "pull" funds from an e…”
   • [claimed-docs] “You can track the progress of a wire by checking the `status` attribute on the Wire Transfer object.”
   • [claimed-docs] “A book transfer is an electronic funds transfer between two accounts at the same bank... Book transfers are the fastest and cheapest type of…”
   • [claimed-docs] “Generate and retrieve branded monthly account statements for your customers.”
   • [claimed-docs] “Enable customers to add funds to their accounts using cash at 90,000+ retail locations nationwide”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.treasuryprime.com/openapi.json, https://docs.treasuryprime.com/swagger.json, https://do…”

   proof ↗⚑ flag

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

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

   Treasury Prime—none0/10

   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.

   ⚑ flag

1. ai-native userControl data retention and deletion

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

   Treasury Prime—none0/10

   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.

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

   Treasury Prime—none0/10

   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.

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

   Treasury Prime—none0/10

   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.

   • [claimed-docs] “Programs can seamlessly integrate their bank-approved third-party KYC/KYB vendor into the account opening process.”
   • [claimed-docs] “Incremental KYC lets you run KYC **without opening an account**.”

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

   Treasury Prime—none0/10

   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.

   ⚑ flag