Column 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 Column
   Column✓fullcommunity8/10

   Docs confirm programmatic FDIC-insured account opening/management (column-docs-2) and a full sandbox environment with simulate endpoints for wires/ACH (column-docs-3), matching the story's application-to-active-account and sandbox parity requirements. Community feedback corroborates a smooth signup/setup flow (column-comm-5) and strong documentation quality (column-comm-8). Missing for 10: independent hands-on confirmation that the entire account application/approval step (not just account management) is fully API-driven without manual review, and explicit sandbox-to-production parity testing evidence beyond simulate endpoints.

   • [claimed-docs] “Programmatically open and manage FDIC insured bank accounts at Column on behalf of your customers. We support FBO, sweep, clearing and custo…”
   • [claimed-docs] “To simulate an incoming transfer, or just to set an initial balance on your account, you can use the `/simulate/receive-wire` endpoint. To s…”
   • [community] “User: 'I created an account just to check it out and the signup and initial setup flow is very well done. Nice work.'”
   • [community] “User noted the business model implication: 'looks like there is basically one really rich guy self-funding for a couple of years' to build c…”

   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 Column
   Column~partialcommunity5/10

   Column's docs explicitly state accounts are FDIC insured and describe support for FBO, sweep, clearing, and custom account types, giving some transparency into account structure (column-docs-2). However there is no explicit documentation on how FDIC pass-through insurance attaches to underlying customers, nor on ledger access controls/who can view sub-ledger data — these are not addressed in the evidence pack. missing for 10: explicit FDIC pass-through insurance mechanics, documentation on ledger visibility/access permissions, and independent confirmation of these structural details.

   • [claimed-docs] “Programmatically open and manage FDIC insured bank accounts at Column on behalf of your customers. We support FBO, sweep, clearing and custo…”
   • [community] “Commenter praised Column's ACH permissioning feature: 'Create account numbers that point to a single bank account and create specific permis…”

   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 Column
   Column✓fullcommunity8/10

   Column's docs explicitly support programmatic bank account creation including FBO, sweep, clearing and custom account types (column-docs-2), and community evidence confirms per-account-number permissioning ('Create account numbers that point to a single bank account and create specific permissions and limits for each one') which maps to virtual/sub-account use cases (column-comm-7). This directly supports issuing unique account/routing numbers at scale for reconciliation and sub-account structures. Missing for 10: explicit documentation of routing-number issuance mechanics and a dedicated 'virtual accounts' or 'sub-accounts' product page with scale/rate-limit details.

   • [claimed-docs] “Programmatically open and manage FDIC insured bank accounts at Column on behalf of your customers. We support FBO, sweep, clearing and custo…”
   • [community] “Commenter praised Column's ACH permissioning feature: 'Create account numbers that point to a single bank account and create specific permis…”
   • [claimed-docs] “Query transfers across all payment types from a single unified endpoint.”

   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 to Column
   Column~partialcommunity3/10

   Column documents that it supports 'sweep' as one of its bank account types (alongside FBO, clearing, custom), which addresses the 'documented sweep options' half of the story, but there is no mention anywhere of interest-bearing accounts, rate mechanics, or who keeps the spread. Missing for 10: interest rate documentation, spread/economics disclosure, and any explanation of how sweep proceeds are shared.

   • [claimed-docs] “Programmatically open and manage FDIC insured bank accounts at Column on behalf of your customers. We support FBO, sweep, clearing and custo…”
   • [community] “Feedback to Column: nit that the uptime status page (status.column.com) defaults to 'Sandbox' instead of Production, which 'can mislead a re…”

   proof ↗⚑ 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 drawn
   Column✓fullprobed9/10

   Column serves a live llms.txt file (HTTP 200, confirmed by direct probe) plus markdown-rendered agent-friendly docs pages (e.g. .md versions of guides) and an OpenAPI spec, all of which an agent could be pointed at directly. This is concrete first-party evidence of agent-oriented documentation delivery. Missing for 10: independent/community confirmation that an agent was actually pointed at llms.txt and successfully used it.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.column.com/llms.txt # Column Documentation > Column N.A. is the first nationally chartered bank cr…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.column.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “we are going to build a basic payment workflow consisting of a wire, a book transfer, and an ACH credit”
   • [claimed-docs] “Column's API is defined by an OpenAPI spec (also available as JSON). Use it to generate type-safe client SDKs in any language”

   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 Column
   Column~partialprobed6/10

   Column is a pure HTTP API/banking platform with an OpenAPI spec, sandbox simulate endpoints, and webhooks — all of which are usable in headless, scripted, or CI-driven workflows without any UI dependency. However, there is no explicit documentation or example of running Column in a CI pipeline, and the company notes it deliberately provides no first-party SDKs, relying on customers to generate their own from the OpenAPI spec. Missing for 10: explicit CI/CD examples or guides, first-party SDKs/tooling for automated test pipelines, and any community confirmation of headless/CI usage.

   • [claimed-docs] “To simulate an incoming transfer, or just to set an initial balance on your account, you can use the `/simulate/receive-wire` endpoint. To s…”
   • [claimed-docs] “Column's API is defined by an OpenAPI spec (also available as JSON). Use it to generate type-safe client SDKs in any language”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.column.com/openapi.json — contains "openapi" key”
   • [community] “Engineer at Column: 'we have definitely considered creating SDK's but most of our customers prefer the HTTP API's, which will likely remain …”

   proof ↗⚑ 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
   Column—none0/10

   Column is a banking-as-a-service API platform; no evidence of an official MCP server for agent connectivity is present, only a REST API with OpenAPI spec. This axis applies since a developer-facing API platform could plausibly ship an MCP server, but absence of any such evidence yields none. missing for 10: any mention of an MCP server, agent integration, or AI-native tooling.

   • [claimed-docs] “Column's API is defined by an OpenAPI spec (also available as JSON). Use it to generate type-safe client SDKs in any language”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.column.com/openapi.json — contains "openapi" key”

   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
   Column—none0/10

   Column is a banking API platform with no evidence of an official CLI; in fact a Column engineer explicitly states they don't even provide SDKs, only HTTP APIs, and no CLI is mentioned anywhere in docs or community evidence.

   • [community] “Engineer at Column: 'we have definitely considered creating SDK's but most of our customers prefer the HTTP API's, which will likely remain …”

   proof ↗⚑ 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 Column
   Column✓fullprobed9/10

   Column is API-first: extensive first-party docs cover a full public API for payments, accounts, wires, ACH, cards, checks, webhooks, and reporting, backed by a documented OpenAPI spec (confirmed live at openapi.json) usable to generate client SDKs, plus a verified llms.txt for AI-native consumption. Community corroboration from a Column engineer confirms HTTP API is the primary supported interface. Missing for 10: no independent third-party audit of API completeness or hands-on agent-driven integration report.

   • [claimed-docs] “Query transfers across all payment types from a single unified endpoint.”
   • [claimed-docs] “Column's API is defined by an OpenAPI spec (also available as JSON). Use it to generate type-safe client SDKs in any language”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.column.com/llms.txt # Column Documentation > Column N.A. is the first nationally chartered bank cr…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.column.com/openapi.json — contains "openapi" key”
   • [community] “Engineer at Column: 'we have definitely considered creating SDK's but most of our customers prefer the HTTP API's, which will likely remain …”

   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
   Column—none0/10

   Column is a banking/payments API platform; there is no evidence of scoped or least-privilege API credential issuance for agents specifically (no API key scoping, permission roles, or agent-specific credential management mentioned). The ACH account-number permissioning feature (column-comm-7) relates to bank account routing limits, not API credential scoping for AI agents. Missing for 10: any documentation of API key/token scoping, role-based access control, or agent-specific credential issuance.

   ⚑ 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 to Column
   Column!disputedcontradicted3/10

   Docs point to an OpenAPI spec that can be used to 'generate type-safe client SDKs in any language' (column-docs-10), but this is code-gen from a spec, not official first-party SDKs. A Column engineer directly contradicts any SDK-first narrative, stating 'we have definitely considered creating SDK's but most of our customers prefer the HTTP API's' (column-comm-1), confirming no official SDKs exist. Missing for 10: actual first-party maintained SDKs in specific languages, official SDK repos/docs, and any retraction of the engineer's statement.

   • [claimed-docs] “Column's API is defined by an OpenAPI spec (also available as JSON). Use it to generate type-safe client SDKs in any language”
   • [community] “Engineer at Column: 'we have definitely considered creating SDK's but most of our customers prefer the HTTP API's, which will likely remain …”

   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 to Column
   Column✓fullclaimed8/10

   Column's docs explicitly document webhook subscription for events, configurable via API or Dashboard (column-docs-7), enabling programmatic/agentic consumption of platform events. missing for 10: no independent/hands-on confirmation of webhook reliability or payload schema details, and no mention of event types or filtering granularity.

   • [claimed-docs] “You can configure webhook endpoints via APIs or Dashboard in your platform to be notified about events from Column.”

   proof ↗⚑ 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 userSet up automations that run autonomously in the background

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

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

   weight 2 · round drawn
   Column—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 Column
   Column~partialprobed5/10

   Column publishes an OpenAPI spec and markdown docs (docs.column.com) plus a sandbox environment with simulate endpoints for testing payment flows, which supports some hands-on exploration, but there is no direct evidence of an interactive in-docs API console or embedded runnable code examples typical of 'try it now' reference UIs. missing for 10: explicit interactive API explorer/try-it-out UI, embedded runnable code snippets, independent confirmation of an interactive reference experience.

   • [claimed-docs] “To simulate an incoming transfer, or just to set an initial balance on your account, you can use the `/simulate/receive-wire` endpoint. To s…”
   • [claimed-docs] “Column's API is defined by an OpenAPI spec (also available as JSON). Use it to generate type-safe client SDKs in any language”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.column.com/openapi.json — contains "openapi" key”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.column.com/llms.txt # Column Documentation > Column N.A. is the first nationally chartered bank cr…”

   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 to Column
   Column✓fullprobed9/10

   Column explicitly documents an OpenAPI spec available as JSON for generating client SDKs, and a live probe confirms the openapi.json endpoint returns HTTP 200 with a valid 'openapi' key, directly corroborating the vendor claim. missing for 10: no independent third-party review specifically validating the spec's completeness/usability beyond the probe.

   • [claimed-docs] “Column's API is defined by an OpenAPI spec (also available as JSON). Use it to generate type-safe client SDKs in any language”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.column.com/openapi.json — contains "openapi" key”

   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 drawn
   Column✓fullcommunity8/10

   Column's docs explicitly describe a sandbox environment with simulate endpoints (receive-wire, receive-ach-credit/debit) to test payment flows without touching production data, and community mentions confirm a separate Sandbox status page exists distinct from Production. missing for 10: no independent hands-on account of using the sandbox for a full workflow, and no explicit statement about data isolation guarantees between sandbox and production.

   • [claimed-docs] “To simulate an incoming transfer, or just to set an initial balance on your account, you can use the `/simulate/receive-wire` endpoint. To s…”
   • [community] “Feedback to Column: nit that the uptime status page (status.column.com) defaults to 'Sandbox' instead of Production, which 'can mislead a re…”

   proof ↗⚑ 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
   Column—none0/10

   Evidence shows Column has an OpenAPI spec and SDK generation, but there is no mention of API versioning scheme or a documented deprecation policy anywhere in the docs or community discussion.

   ⚑ 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
   Column—none0/10

   The evidence covers many individual payment rails, reporting, and a unified query endpoint, but no documentation mentions batch/bulk operations (e.g., submitting many transfers or account actions in a single call) that an AI-native user could invoke for bulk automation.

   ⚑ 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
   Column—none0/10

   Column exposes webhooks so external systems can be notified of events (column-docs-7), but there is no evidence of a native rules/automation engine within Column that lets a user define conditions and have Column itself trigger actions automatically — building on the webhook would require external logic. Missing for 10: any documented in-product rule/trigger definition, conditional action execution, or automation workflow builder.

   • [claimed-docs] “You can configure webhook endpoints via APIs or Dashboard in your platform to be notified about events from Column.”

   proof ↗⚑ 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
   Column—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
   Column—none0/10

   Column's docs describe general API capabilities (transfers, account permissioning, webhooks) and one community mention of per-account-number permissions/limits, but nothing documents scoped credentials, amount caps, or counterparty allowlists specifically for an AI agent use case by name. missing for 10: any mention of 'agent' or AI-native access patterns, documented amount-cap/allowlist controls tied to agent credentials, and a named agent-banking product or guide.

   • [community] “Commenter praised Column's ACH permissioning feature: 'Create account numbers that point to a single bank account and create specific permis…”
   • [claimed-docs] “Programmatically open and manage FDIC insured bank accounts at Column on behalf of your customers. We support FBO, sweep, clearing and custo…”
   • [claimed-docs] “Query transfers across all payment types from a single unified endpoint.”

   proof ↗⚑ 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 to Column
   Column~partialcommunity7/10

   Column exposes a comprehensive REST/OpenAPI surface covering accounts, transactions, transfers (including pending/status), wires, checks, and reporting (CSV/JSON/Parquet), letting an agent programmatically read the full banking picture instead of scraping a dashboard. However, there is no evidence of an MCP server or agent-native surface — only a standard HTTP API with OpenAPI spec for SDK generation, and the company explicitly says most customers use raw HTTP APIs, not SDKs or agent tooling. Missing for 10: MCP server/tool-calling interface, explicit 'documents' retrieval endpoint beyond checks, and any AI-agent-specific integration evidence.

   • [claimed-docs] “Programmatically open and manage FDIC insured bank accounts at Column on behalf of your customers. We support FBO, sweep, clearing and custo…”
   • [claimed-docs] “Column provides the following reports: `bank_account_transaction` and `bank_account_summary`. All reports are available in CSV, JSON, and Pa…”
   • [claimed-docs] “Query transfers across all payment types from a single unified endpoint.”
   • [claimed-docs] “we receive full raw data for all domestic and international wires. You can access the raw message for domestic wires using our get wire tran…”
   • [claimed-docs] “Column's API is defined by an OpenAPI spec (also available as JSON). Use it to generate type-safe client SDKs in any language”
   • [community] “Engineer at Column: 'we have definitely considered creating SDK's but most of our customers prefer the HTTP API's, which will likely remain …”

   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
   Column—none0/10

   Column's evidence pack is entirely about banking-as-a-service APIs (wires, ACH, cards, reporting, webhooks) with no mention of any built-in AI features like natural-language transaction search, dispute drafting, or anomaly summaries. missing for 10: any AI/NLP capability, dispute-response drafting, anomaly detection or summarization features, natural-language search over transactions.

   ⚑ 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 Column
   Column~partialcommunity5/10

   Column docs confirm a card program supporting both physical and virtual cards via major networks/issuer processors, and a Column engineer corroborates issuing bank/card program status. However, evidence lacks detail on spend controls (limits, MCC restrictions) and digital wallet (Apple/Google Pay) provisioning specifics. missing for 10: documented spend control APIs, digital wallet tokenization/push-provisioning support, independent hands-on confirmation of card issuance flow.

   • [claimed-docs] “Build a card program with Column to offer your customers any type of card. We work with all major networks and issuer processors.”
   • [community] “Column engineer: 'We're an issuing bank and sponsor card programs on Visa & Mastercard. Our partners can offer both physical and virtual car…”

   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
   Column—none0/10

   No evidence in the pack addresses Reg E dispute handling, provisional credit timelines, or ops responsibilities for card/ACH disputes; docs cover payment rails, reporting, webhooks, and card issuing but nothing about dispute/chargeback investigation workflows.

   ⚑ 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 Column
   Column~partialclaimed6/10

   Column documents configurable webhooks for transaction/event notifications and a unified endpoint to query transfers across payment types, supporting an event-driven integration pattern, but there is no explicit documentation of balance reads reflecting holds/pending activity or a full enumeration of webhook events per transaction state change. missing for 10: explicit balance-with-holds/pending semantics, a complete list of webhook events per state transition, and independent confirmation of real-time accuracy.

   • [claimed-docs] “You can configure webhook endpoints via APIs or Dashboard in your platform to be notified about events from Column.”
   • [claimed-docs] “Query transfers across all payment types from a single unified endpoint.”
   • [claimed-docs] “Column provides the following reports: `bank_account_transaction` and `bank_account_summary`. All reports are available in CSV, JSON, and Pa…”

   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 to Column
   Column~partialclaimed6/10

   Column documents raw rail-level data access (full raw wire messages), a unified cross-rail transfers endpoint, and structured reporting/webhooks, suggesting transaction data goes beyond a raw bank feed. However, there is no explicit documentation of counterparty enrichment fields, stable transaction identifiers across rails, or a described enrichment/categorization layer for building customer-facing product experiences. Missing for 10: explicit counterparty detail schema, documented stable identifier scheme across payment rails, and independent/hands-on verification of enrichment depth beyond raw message passthrough.

   • [claimed-docs] “we receive full raw data for all domestic and international wires. You can access the raw message for domestic wires using our get wire tran…”
   • [claimed-docs] “Query transfers across all payment types from a single unified endpoint.”
   • [claimed-docs] “Column provides the following reports: `bank_account_transaction` and `bank_account_summary`. All reports are available in CSV, JSON, and Pa…”
   • [claimed-docs] “You can configure webhook endpoints via APIs or Dashboard in your platform to be notified about events from Column.”

   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
   Column—none0/10

   No evidence in the pack mentions monthly statement generation or 1099-INT tax document production/retrieval via API; reports mentioned are transaction/summary CSV/JSON/Parquet exports, not statements or tax forms.

   ⚑ 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
   Column—none0/10

   The evidence pack covers Column's payments, accounts, cards, checks, wires, and reporting APIs, but nowhere mentions KYC/KYB identity verification, document collection, watchlist/OFAC screening, or application state modeling for onboarding customers programmatically.

   ⚑ 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
   Column—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 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 to Column
   Column~partialcommunity2/10

   Only a single thin community mention (comm-7) references per-account-number permissions and limits, hinting at some risk-control primitives, but there is no documentation of transaction/velocity limit configuration, holds on suspicious activity, account freezes, or reinstatement paths. missing for 10: documented velocity/transaction limit APIs, hold/freeze mechanisms, reinstatement workflow documentation, per-program risk configuration.

   • [community] “Commenter praised Column's ACH permissioning feature: 'Create account numbers that point to a single bank account and create specific permis…”

   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
   Column—none0/10

   No evidence in the pack addresses fraud liability allocation for ACH returns, card disputes, or account takeover losses, nor any documentation pairing prevention tooling with a stated liability split. Docs cover payment rails, reporting, webhooks, and account features but never discuss fraud economics or who bears losses.

   ⚑ 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
   Column—none0/10

   No evidence pack item documents program-level transaction/volume limits, approval or underwriting stages, or a defined process for raising limits as a growing customer scales; docs cover product features (wires, ACH, cards, checks) but not risk/compliance limit governance. Community threads mention account permissioning per sub-account but not program-wide growth limits or escalation paths.

   ⚑ 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 drawn
   Column~partialclaimed5/10

   Column's docs confirm ACH credit/debit origination via API, sandbox simulation of incoming ACH credits/debits, and general webhook event support, plus a unified transfers endpoint that would include ACH. However, there's no direct evidence of same-day ACH windows, or first-class objects/webhooks for returns, NOCs, or reversals — the specific 'unhappy path' modeling the story asks for is unaddressed. Missing for 10: explicit documentation of same-day ACH windows, return/NOC/reversal objects, and webhook events tied to those unhappy paths.

   • [claimed-docs] “we are going to build a basic payment workflow consisting of a wire, a book transfer, and an ACH credit”
   • [claimed-docs] “To simulate an incoming transfer, or just to set an initial balance on your account, you can use the `/simulate/receive-wire` endpoint. To s…”
   • [claimed-docs] “You can configure webhook endpoints via APIs or Dashboard in your platform to be notified about events from Column.”
   • [claimed-docs] “Query transfers across all payment types from a single unified endpoint.”

   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 Column
   Column~partialcommunity5/10

   Column's docs confirm check issuance and deposit via API (column-docs-4), but there is no explicit mention of image capture mechanics, and a Column engineer noted in community discussion that 'Checks are currently in beta' (column-comm-2), suggesting immaturity. missing for 10: explicit image-capture/deposit workflow details, confirmation of GA (non-beta) status, and independent hands-on verification of check deposit reliability.

   • [claimed-docs] “Column provides customers the ability to issue and deposit checks through our APIs.”
   • [community] “Column engineer: 'We're an issuing bank and sponsor card programs on Visa & Mastercard. Our partners can offer both physical and virtual car…”

   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 Column
   Column✓fullprobed8/10

   Column's docs explicitly cover domestic wires (with raw message access), RTP and FedNow send/receive/RFP through unified APIs, plus a unified transfers query endpoint across payment types, all under one OpenAPI-defined API surface. Per-rail nuances (e.g., wire raw data, simulate endpoints for sandbox testing) are documented, meeting the developer story well. Missing for 10: independent hands-on verification of RTP/FedNow origination beyond docs, and more granular per-rail limits/SLA documentation.

   • [claimed-docs] “Column enables you to immediately send funds, receive funds, and request payment (RFP) through both the Federal Reserve's FedNow Service and…”
   • [claimed-docs] “Query transfers across all payment types from a single unified endpoint.”
   • [claimed-docs] “we receive full raw data for all domestic and international wires. You can access the raw message for domestic wires using our get wire tran…”
   • [claimed-docs] “To simulate an incoming transfer, or just to set an initial balance on your account, you can use the `/simulate/receive-wire` endpoint. To s…”
   • [claimed-docs] “Column's API is defined by an OpenAPI spec (also available as JSON). Use it to generate type-safe client SDKs in any language”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.column.com/openapi.json — contains "openapi" key”

   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 Column
   Column~partialclaimed4/10

   Column documents sending/receiving international transfers via SWIFT and full raw wire message access, showing genuine cross-border wire capability, but there is no evidence of transparent FX rate disclosure or a documented map of supported currencies/corridors. missing for 10: FX rate transparency/pricing details, list of supported currencies and corridors, independent confirmation of SWIFT reliability.

   • [claimed-docs] “Via our APIs, you can send and receive international transfers through the SWIFT network.”
   • [claimed-docs] “we receive full raw data for all domestic and international wires. You can access the raw message for domestic wires using our get wire tran…”
   • [claimed-docs] “we are going to build a basic payment workflow consisting of a wire, a book transfer, and an ACH credit”

   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 Column
   Column✓fullcommunity7/10

   Column's documentation shows an extensive, comprehensive API surface (accounts, wires, ACH, checks, SWIFT, real-time payments, cards, reporting, webhooks) with OpenAPI spec for SDK generation, and explicitly notes some features like webhooks can be configured 'via APIs or Dashboard' implying parity; a Column engineer also states most customers prefer raw HTTP APIs over SDKs, reinforcing API-first design. Missing for 10: an explicit statement or audit confirming every dashboard-only admin/config feature has an API equivalent, and independent verification of full UI-API parity beyond webhooks.

   • [claimed-docs] “Programmatically open and manage FDIC insured bank accounts at Column on behalf of your customers. We support FBO, sweep, clearing and custo…”
   • [claimed-docs] “Column provides customers the ability to issue and deposit checks through our APIs.”
   • [claimed-docs] “Via our APIs, you can send and receive international transfers through the SWIFT network.”
   • [claimed-docs] “Column enables you to immediately send funds, receive funds, and request payment (RFP) through both the Federal Reserve's FedNow Service and…”
   • [claimed-docs] “You can configure webhook endpoints via APIs or Dashboard in your platform to be notified about events from Column.”
   • [claimed-docs] “Query transfers across all payment types from a single unified endpoint.”
   • [claimed-docs] “Column's API is defined by an OpenAPI spec (also available as JSON). Use it to generate type-safe client SDKs in any language”
   • [community] “Engineer at Column: 'we have definitely considered creating SDK's but most of our customers prefer the HTTP API's, which will likely remain …”

   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 to Column
   Column~partialclaimed6/10

   Column documents open, standard export formats for account data (CSV, JSON, Parquet reports) and API access to raw transaction/wire message data, plus a public OpenAPI spec for building custom integrations, which supports data portability for an AI-native user. However there is no explicit documentation of a full account-data export or an account-closure/migration workflow addressing 'leaving' the platform. Missing for 10: explicit full-account export/backup feature, documented account closure/data migration process, independent confirmation of export completeness.

   • [claimed-docs] “Column provides the following reports: `bank_account_transaction` and `bank_account_summary`. All reports are available in CSV, JSON, and Pa…”
   • [claimed-docs] “we receive full raw data for all domestic and international wires. You can access the raw message for domestic wires using our get wire tran…”
   • [claimed-docs] “Column's API is defined by an OpenAPI spec (also available as JSON). Use it to generate type-safe client SDKs in any language”
   • [claimed-docs] “Query transfers across all payment types from a single unified endpoint.”

   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

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 Column
   Column~partialprobed6/10

   Column clearly discloses it is itself a nationally chartered bank (not a middleware or partner-bank model) via its docs tagline 'Column N.A. is the first nationally chartered bank created to serve developers and builders' and confirms FDIC-insured accounts and being 'an issuing bank' sponsoring card programs directly. This answers 'who holds the charter' clearly, but the evidence pack has no explicit statement on what happens to customer funds/accounts in a failure/receivership scenario beyond the general FDIC-insurance mention. Missing for 10: explicit failure/receivership disclosure, pass-through insurance mechanics, and independent verification of charter claims beyond Column's own docs/HN comments.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.column.com/llms.txt # Column Documentation > Column N.A. is the first nationally chartered bank cr…”
   • [claimed-docs] “Programmatically open and manage FDIC insured bank accounts at Column on behalf of your customers. We support FBO, sweep, clearing and custo…”
   • [community] “Column engineer: 'We're an issuing bank and sponsor card programs on Visa & Mastercard. Our partners can offer both physical and virtual car…”

   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
   Column—none0/10

   Evidence covers payment rails, account management, reporting, and webhooks, but there is no mention of transaction monitoring tooling, sanctions screening, alert case management, or SAR-filing support/workflow for ops users. Missing for 10: transaction monitoring dashboard/API, sanctions screening tooling, case management for compliance alerts, SAR filing workflow, and documented division of compliance duties between platform/bank/customer.

   ⚑ 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
   Column—none0/10

   Column is a chartered bank itself and provides reporting/transaction query APIs (bank_account_transaction, bank_account_summary, unified transfer endpoint), but there is no documentation or community evidence describing an explicit daily reconciliation process between the ledger/API and actual held bank funds — the exact assurance a finance lead burned by Synapse would need. Missing for 10: any explicit reconciliation SLA/process documentation, third-party audit or attestation of ledger-to-bank-balance matching, and any commentary addressing the Synapse-style failure mode directly.

   • [claimed-docs] “Column provides the following reports: `bank_account_transaction` and `bank_account_summary`. All reports are available in CSV, JSON, and Pa…”
   • [claimed-docs] “Query transfers across all payment types from a single unified endpoint.”
   • [claimed-docs] “Programmatically open and manage FDIC insured bank accounts at Column on behalf of your customers. We support FBO, sweep, clearing and custo…”

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