Unit vs Column
usage-based
·usage-based
Column wins · 1–23 (19 drawn)
Account provisioning — stories about account provisioning in this arenaAccount provisioning
Stories about account provisioning in this arena
Account opening
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 ColumnUnit'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.…”
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…”
Fbo structures
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 ColumnUnit'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.”
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…”
Virtual accounts
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 ColumnUnit'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…”
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.”
Yield
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 ColumnUnitnone0/10Evidence 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.
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…”
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
Agent access
ai-native userPoint an agent at llms.txt or agent-oriented docs
weight 2 · round to ColumnUnit 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.…”
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”
ai-native userRun the product headlessly / in CI for automation
weight 2 · round to ColumnUnitnone0/10The 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.)
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 …”
ai-native userConnect an agent via an official MCP server
weight 3 · round drawnUnitnone0/10Unit 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.
Columnnone0/10Column 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”
ai-native userUse an official CLI
weight 2 · round drawnUnitnone0/10The 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.)
Columnnone0/10Column 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 …”
ai-native userDrive the product through a documented public API
weight 3 · round to ColumnUnit'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.…”
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 …”
ai-native userIssue scoped/least-privilege API credentials for an agent
weight 2 · round drawnUnitnone0/10Unit'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.
Columnnone0/10Column 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.
ai-native userBuild against official SDKs
weight 2 · round to ColumnUnitnone0/10The 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.…”
Columndisputedcontradicted3/10Docs 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 …”
ai-native userSubscribe to events via webhooks
weight 2 · round to ColumnUnitnone0/10The 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.
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.”
Agentic features
ai-native userSet up automations that run autonomously in the background
weight 2 · round drawnUnitnone0/10The 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.)
ai-native userOperate the product with natural-language commands
weight 2 · round drawnUnitnone0/10The 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.)
Api quality
ai-native userExplore an interactive API reference with runnable examples
weight 2 · round to ColumnUnitnone0/10No 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.
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…”
ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)
weight 2 · round to ColumnUnitnone0/10Probes 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.
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”
ai-native userTest against a sandbox environment without touching production data
weight 1 · round to ColumnUnitnone0/10Unit 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.
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…”
ai-native userRely on versioned APIs with a documented deprecation policy
weight 2 · round drawnUnitnone0/10No 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.
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
ai-native userPerform bulk operations across many items at once
weight 2 · round drawnUnitnone0/10The 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.”
ai-native userDefine rules that trigger actions automatically on events
weight 3 · round drawnUnitnone0/10Unit 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.
Columnnone0/10Column 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.”
ai-native userSchedule recurring jobs or workflows
weight 2 · round drawnUnitnone0/10The 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.)
Banking agent access — stories about banking agent access in this arenaBanking agent access
Stories about banking agent access in this arena
Agent operations
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 drawnUnitnone0/10Unit'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.
Columnnone0/10Column'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.”
Agent visibility
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 ColumnUnit'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.…”
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 …”
Builtin ai
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 drawnUnitnone0/10Evidence 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.
Columnnone0/10Column'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.
Banking cards — stories about banking cards in this arenaBanking cards
Stories about banking cards in this arena
Card issuance
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 UnitUnit'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.”
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…”
Disputes
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 drawnUnitnone0/10Evidence 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.
Banking ledger — stories about banking ledger in this arenaBanking ledger
Stories about banking ledger in this arena
Balances events
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 ColumnUnit'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…”
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…”
Data quality
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 ColumnDocs 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.”
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.”
Statements
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 drawnUnitnone0/10No 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.
Banking onboarding — stories about banking onboarding in this arenaBanking onboarding
Stories about banking onboarding in this arena
Kyc kyb
developerCustomer verification is programmatic — KYC for individuals and KYB for businesses with document collection, watchlist screening, and clearly modeled application states
weight 3 · round drawnUnitnone0/10The 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.”
Review queues
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 drawnUnitnone0/10The 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.
Banking risk controls — stories about banking risk controls in this arenaBanking risk controls
Stories about banking risk controls in this arena
Limits holds
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 ColumnUnitnone0/10Evidence 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.”
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…”
Loss allocation
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 drawnUnitnone0/10Evidence 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.
Columnnone0/10No 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.
Program scaling
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 drawnUnitnone0/10No 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'.
Columnnone0/10No 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.
Money movement — stories about money movement in this arenaMoney movement
Stories about money movement in this arena
Ach
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 ColumnUnit'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.”
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.”
Checks
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 ColumnUnit'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…”
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…”
Instant rails
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 ColumnUnit'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.…”
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”
International
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 ColumnUnit'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…”
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”
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
ai-native userDo everything through the API that I can do in the UI
weight 2 · round to ColumnUnit 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.…”
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 …”
ai-native userExport all of my data in open formats and leave
weight 3 · round to ColumnUnitnone0/10The 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.”
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.”
Sponsor model — stories about sponsor model in this arenaSponsor model
Stories about sponsor model in this arena
Charter clarity
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 ColumnDocs 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…”
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…”
Compliance tooling
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 drawnUnitnone0/10Evidence 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.”
Columnnone0/10Evidence 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.
Reconciliation
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 drawnUnitnone0/10No 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.
Columnnone0/10Column 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…”
Not comparable on these axes
ai-native userPlug MCP servers into this product so it can use their tools
weight 3 · not comparableUnitnone0/10Unit is a banking-as-a-service/fintech infrastructure platform; no evidence of any MCP server support or integration for plugging tools into an AI agent. This is an applicable axis for a modern API platform, but nothing in the evidence pack mentions MCP.
ai-native userGet AI-generated insights and suggestions from my data inside the product
weight 2 · not comparableUnitnone0/10Unit 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.”
ai-native userDelegate tasks to a built-in AI assistant inside the product
weight 3 · not comparableUnitn/aUnit is a banking-as-a-service/financial infrastructure API platform, not an AI assistant product; there is no built-in AI assistant concept applicable here — this is a wrong-axis question for this product category.
ai-native userVersion, review, and roll back my automations
weight 1 · not comparableUnitn/aUnit is a banking/financial infrastructure API platform, not an automation-building tool; versioning, reviewing, and rolling back 'automations' is not a relevant axis for this product category.
ai-native userRead the product's source under an open license
weight 2 · not comparableUnitn/aUnit is a fintech/banking infrastructure API platform, not an open-source project; there is no indication its core source code is meant to be published under any license. Asking to read the product's source under an open license is a category error for this kind of closed commercial financial platform.
ai-native userSelf-host the core product
weight 3 · not comparableUnitn/aUnit is a Banking-as-a-Service/financial infrastructure platform delivered as a hosted API/dashboard tied to bank partnerships and Federal Reserve connectivity; self-hosting the 'core product' is a category error since the core value depends on regulated banking relationships and infrastructure that cannot be run by a customer.
ai-native userChoose where my data is stored (region/residency)
weight 2 · not comparableUnitn/aUnit is a banking-as-a-service/financial infrastructure platform, not an AI product or data-processing tool where 'AI-native user' data residency choice is a meaningful axis; no evidence pack content relates to AI data storage location or region selection for AI workloads.
ai-native userPrevent my data from being used to train AI models
weight 3 · not comparableUnitnone0/10The evidence pack contains no mention of AI model training, data usage policies for AI, or opt-out mechanisms; Unit's documentation focuses entirely on banking infrastructure (accounts, payments, cards, credit). No evidence supports this capability.
ai-native userControl data retention and deletion
weight 2 · not comparableUnitnone0/10The 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).
ai-native userOpt out of telemetry and usage tracking
weight 2 · not comparableUnitn/aUnit is a banking-as-a-service financial infrastructure platform, not an AI agent/tool whose telemetry or usage tracking an AI-native user would opt out of; this axis is a category error for this product type.