Increase vs Column

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

   Increase documents FDIC-insured deposit accounts at partner banks (increase-docs-13), full Sandbox parity for testing before launch (increase-docs-6), and API-driven account/entity workflows including compliance validations and programmatic account number issuance (increase-docs-12, increase-docs-7). Community evidence corroborates the white-label bank-partner insured account model (increase-comm-1). Missing for 10: explicit end-to-end documentation of the entity/application submission and account-activation API calls (KYC/KYB flow) and independent confirmation that sandbox behavior exactly mirrors production account approval outcomes.

   • [claimed-docs] “Access multi-million-dollar FDIC insurance at participating IntraFi network banks directly in Increase.”
   • [claimed-docs] “Every API and dashboard feature is available in Sandbox. ... you can use special Simulation APIs, which are only available in Sandbox.”
   • [claimed-docs] “Increase makes Entity validations available via the API for each version of the data. You should follow up with your customer when the valid…”
   • [claimed-docs] “You can instantly create multiple Account Numbers for a single Account and manage them programmatically.”
   • [community] “Accounts are with First Internet Bank or Blue Ridge Bank, not Increase itself: https://increase.com/terms - it's white-label banking API, no…”

   proof ↗⚑ flag

   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

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

   Increase documents some structural transparency — accounts are held at partner banks (First Internet Bank/Blue Ridge Bank) rather than Increase itself, and FDIC insurance is available via participating IntraFi network banks — plus features like unique Account Numbers per counterparty for reconciliation. However, there's no explicit documentation of FBO pooled vs individual account structure, or of who can access/view the ledger. Missing for 10: explicit FBO-pool vs individual-account structural documentation, detailed FDIC insurance attachment mechanics, and ledger visibility/access-control documentation.

   • [claimed-docs] “Access multi-million-dollar FDIC insurance at participating IntraFi network banks directly in Increase.”
   • [claimed-docs] “You can instantly create multiple Account Numbers for a single Account and manage them programmatically.”
   • [claimed-docs] “With Increase, you can issue each investor a unique Account Number. This allows for automatic reconciliation of any received funds from that…”
   • [community] “Accounts are with First Internet Bank or Blue Ridge Bank, not Increase itself: https://increase.com/terms - it's white-label banking API, no…”

   proof ↗⚑ flag

   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

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

   Increase's docs confirm the core capability: instantly creating multiple Account Numbers per Account, programmatically, and explicitly for per-investor/per-customer reconciliation across payment rails — matching the virtual-account/reconciliation use case well. However, evidence does not clearly address 'sub-accounts under a master structure' at scale (e.g., hierarchical account structures beyond multiple account numbers on one account), nor bulk/scale provisioning details or limits. missing for 10: explicit documentation of hierarchical sub-account/master-account structures, bulk-issuance scale limits, and independent/hands-on validation of the reconciliation workflow at scale.

   • [claimed-docs] “You can instantly create multiple Account Numbers for a single Account and manage them programmatically.”
   • [claimed-docs] “With Increase, you can issue each investor a unique Account Number. This allows for automatic reconciliation of any received funds from that…”
   • [claimed-docs] “Increase lets you place a hold on an Account to reserve funds for known future activity. Holds reduce the available balance without moving m…”

   proof ↗⚑ flag

   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

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

   The evidence pack covers transfers, holds, FDIC insurance via IntraFi network, and compliance, but contains no mention of interest-bearing accounts, sweep programs, rate mechanics, or spread-sharing arrangements for idle balances.

   ⚑ flag

   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

Agent access

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

   weight 2 · round to Column
   Increase✓fullprobed8/10

   Increase directly hosts an llms.txt file (HTTP 200 confirmed) and full markdown-formatted documentation (documentation.md) alongside a machine-readable OpenAPI spec, giving agents multiple structured entry points. Missing for 10: independent/community confirmation that agents actually consume these files successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://increase.com/llms.txt # Increase > Increase builds modern banking APIs that enable technology companies…”
   • [probe] “PROBE docs-md: HTTP 200 at https://increase.com/documentation.md # Increase Documentation ## Products ### Cards - [3D Secure](https://inc…”
   • [probe] “PROBE openapi: HTTP 200 at https://increase.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Column
   Increase~partialprobed5/10

   Increase is a REST/API-first banking platform with a documented OpenAPI spec, sandbox with simulation APIs, and a CLI (increase-cli), all of which support headless/CI-style automation. However, there is no explicit evidence of CI-specific tooling (e.g., GitHub Actions, CI recipes), automated testing pipelines, or documentation framing the CLI/API for CI/automation workflows specifically. missing for 10: CI/CD integration examples, automated testing docs in CI, evidence the CLI is designed for pipeline/scripted use beyond ad hoc manual invocation.

   • [claimed-docs] “Every API and dashboard feature is available in Sandbox. ... you can use special Simulation APIs, which are only available in Sandbox.”
   • [probe] “PROBE openapi: HTTP 200 at https://increase.com/openapi.json — contains "openapi" key”
   • [probe] “official CLI documented at https://github.com/Increase/increase-cli”

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Increase—none0/10

   Increase is a banking-API platform, so publishing an official MCP server for agent connectivity is a fair question, but the evidence pack shows only REST API docs, an OpenAPI spec, a CLI, and webhooks—no mention of an MCP server or MCP integration anywhere.

   ⚑ flag

   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

4. ai-native userUse an official CLI

   weight 2 · round to Increase
   Increase~partialprobed5/10

   There is a probe indicating an official GitHub repo for an Increase CLI (increase-cli), suggesting a first-party CLI exists, but no docs pack content describes its features, installation, or AI-native/agentic usage. Missing for 10: detailed documentation of the CLI's capabilities, examples of agentic/AI-native use, and independent corroboration of its functionality.

   • [probe] “official CLI documented at https://github.com/Increase/increase-cli”

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Increase✓fullprobed9/10

   Increase is fundamentally API-first: full documented REST endpoints for transfers, accounts, webhooks, sandbox/simulation, and OpenAPI spec are published (increase-docs-1..15, increase-probe-3), plus an official CLI (increase-probe-4) and llms.txt discovery endpoint aimed at AI-native consumption. Community feedback corroborates strong API design quality relative to peers (increase-comm-3,5,7). Missing for 10: independent hands-on report specifically confirming AI-agent-driven API usage rather than general developer usage.

   • [claimed-docs] “You make a `POST /ach_transfers` call with the details of how much you'd like to send and data about the recipient.”
   • [claimed-docs] “Increase can reach out to your application so that you can take action (such as sending an email alert about the transaction to your user) a…”
   • [claimed-docs] “Every API and dashboard feature is available in Sandbox. ... you can use special Simulation APIs, which are only available in Sandbox.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://increase.com/llms.txt # Increase > Increase builds modern banking APIs that enable technology companies…”
   • [probe] “PROBE docs-md: HTTP 200 at https://increase.com/documentation.md # Increase Documentation ## Products ### Cards - [3D Secure](https://inc…”
   • [probe] “PROBE openapi: HTTP 200 at https://increase.com/openapi.json — contains "openapi" key”
   • [probe] “official CLI documented at https://github.com/Increase/increase-cli”
   • [community] “User considering Increase for freelancer payments noted appeal: "it says 'ACH transfers', 'Wire transfers', and 'Real-Time Payments'. That c…”
   • [community] “"I think this is better than Stripe's abstract everything approach even for people who are not into payments. Stripe has built a very leaky …”
   • [community] “Increase employee explains value-add: "The actual mechanics of integrating with, say, FedACH... doesn't have a REST API" - Increase builds a…”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Increase—none0/10

   No evidence of scoped or least-privilege API key/credential issuance for agents (e.g., granular permission scopes, per-agent API keys, or role-based access controls); evidence covers transfers, webhooks, sandbox, and general API design but nothing about credential scoping. Missing for 10: scoped API key creation, permission/role-based access controls, agent-specific credential issuance documentation.

   ⚑ flag

   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

7. ai-native userBuild against official SDKs

   weight 2 · round to Column
   Increase—none0/10

   Evidence shows an OpenAPI spec, a CLI, and llms.txt/docs, but nothing in the pack documents official client SDKs (e.g., Python, Ruby, Node libraries) that AI-native developers could build against beyond the CLI tool.

   • [probe] “PROBE openapi: HTTP 200 at https://increase.com/openapi.json — contains "openapi" key”
   • [probe] “official CLI documented at https://github.com/Increase/increase-cli”

   proof ↗⚑ flag

   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

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Increase✓fullclaimed8/10

   Increase's docs explicitly describe a webhooks system for subscribing to events (transaction updates, real-time decisions) so applications can programmatically react, and this is corroborated by the docs.md overview mentioning real-time webhooks for card authorizations. Missing for 10: no explicit webhook subscription management API details (e.g., listing/creating subscriptions) or independent third-party confirmation of webhook reliability.

   • [claimed-docs] “Increase can reach out to your application so that you can take action (such as sending an email alert about the transaction to your user) a…”
   • [claimed-docs] “When a user tries to use their card and Increase has to decide to approve the authorization or not... we'll create a Real-Time Decision obje…”
   • [claimed-docs] “Every API and dashboard feature is available in Sandbox. ... you can use special Simulation APIs, which are only available in Sandbox.”

   proof ↗⚑ flag

   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

Agentic features

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

   weight 2 · round to Increase
   Increase~partialclaimed5/10

   Increase's webhook system and Real-Time Decision objects let a developer's application react automatically to transfers, card authorizations, and compliance events without manual polling (increase-docs-5, increase-docs-15), and holds/approval workflows (increase-docs-8, increase-docs-14) support autonomous background processes. However, there is no evidence of a dedicated automation/rules engine, scheduled or recurring transfer automation, or any AI-agent-specific orchestration—only generic webhook callbacks. Missing for 10: native scheduling/recurring automation features, AI-agent-specific automation tooling, and independent evidence of autonomous background automation working reliably in production.

   • [claimed-docs] “Increase can reach out to your application so that you can take action (such as sending an email alert about the transaction to your user) a…”
   • [claimed-docs] “When a user tries to use their card and Increase has to decide to approve the authorization or not... we'll create a Real-Time Decision obje…”
   • [claimed-docs] “Optionally, transfers can be held for approval by another team member.”
   • [claimed-docs] “Increase lets you place a hold on an Account to reserve funds for known future activity. Holds reduce the available balance without moving m…”
   • [claimed-docs] “Every API and dashboard feature is available in Sandbox. ... you can use special Simulation APIs, which are only available in Sandbox.”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Increase—none0/10

   Evidence shows Increase is a REST/JSON banking API with docs, OpenAPI spec, and a CLI, but nothing indicates a natural-language command interface, chat/agent layer, or NL-to-API translation capability.

   ⚑ flag

   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

Api quality

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

   weight 2 · round to Column
   Increase—none0/10

   Evidence shows only static markdown documentation and a raw OpenAPI spec, with no mention of an interactive API reference or runnable/try-it-out examples anywhere in the pack.

   • [probe] “PROBE openapi: HTTP 200 at https://increase.com/openapi.json — contains "openapi" key”
   • [probe] “PROBE docs-md: HTTP 200 at https://increase.com/documentation.md # Increase Documentation ## Products ### Cards - [3D Secure](https://inc…”
   • [claimed-docs] “You make a `POST /ach_transfers` call with the details of how much you'd like to send and data about the recipient.”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Increase✓fullprobed9/10

   The evidence pack directly confirms a machine-readable OpenAPI spec is publicly downloadable at https://increase.com/openapi.json (HTTP 200, contains 'openapi' key), plus an llms.txt and full documentation.md index for AI-native discovery. Missing for 10: no independent/community confirmation of spec usage or completeness details beyond the probe check.

   • [probe] “PROBE openapi: HTTP 200 at https://increase.com/openapi.json — contains "openapi" key”
   • [probe] “PROBE llms.txt: HTTP 200 at https://increase.com/llms.txt # Increase > Increase builds modern banking APIs that enable technology companies…”
   • [probe] “PROBE docs-md: HTTP 200 at https://increase.com/documentation.md # Increase Documentation ## Products ### Cards - [3D Secure](https://inc…”

   proof ↗⚑ flag

   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

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

   weight 1 · round drawn
   Increase✓fullclaimed8/10

   Increase's official docs state every API and dashboard feature is available in Sandbox, including Simulation APIs only available there, letting developers test transfers, cards, webhooks, etc. without touching production/real money. missing for 10: independent hands-on confirmation of sandbox fidelity and no explicit mention of test-data isolation guarantees beyond docs.

   • [claimed-docs] “Every API and dashboard feature is available in Sandbox. ... you can use special Simulation APIs, which are only available in Sandbox.”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Increase—none0/10

   The evidence pack has extensive API documentation, an OpenAPI spec, and a CLI, but contains no mention of API versioning strategy or a documented deprecation policy for endpoints. Missing for 10: explicit API versioning scheme, deprecation policy documentation, changelog/migration guides for breaking changes.

   ⚑ flag

   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

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

   weight 2 · round drawn
   Increase—none0/10

   Increase's docs describe individual transfer creation endpoints (ACH, wire, RTP, checks) and the ability to instantly create multiple account numbers, but there is no evidence of a batch/bulk API endpoint (e.g., submitting many transfers in a single call) or bulk listing/processing operations across many items at once.

   • [claimed-docs] “You make a `POST /ach_transfers` call with the details of how much you'd like to send and data about the recipient.”
   • [claimed-docs] “You make a `POST /wire_transfers` call with the details of how much you'd like to send and data about the recipient.”
   • [claimed-docs] “You can instantly create multiple Account Numbers for a single Account and manage them programmatically.”
   • [claimed-docs] “Every API and dashboard feature is available in Sandbox. ... you can use special Simulation APIs, which are only available in Sandbox.”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Increase
   Increase~partialclaimed4/10

   Increase supports event-driven automation via webhooks and Real-Time Decisions, letting external code react to transaction events, and approval holds add a manual gating rule, but there's no evidence of a built-in rule engine where users define declarative 'if event X then action Y' automation inside Increase itself — it always requires custom code on the receiving end. Missing for 10: native rule/condition builder, in-platform automation logic beyond webhooks, and evidence of complex multi-condition triggers.

   • [claimed-docs] “Increase can reach out to your application so that you can take action (such as sending an email alert about the transaction to your user) a…”
   • [claimed-docs] “When a user tries to use their card and Increase has to decide to approve the authorization or not... we'll create a Real-Time Decision obje…”
   • [claimed-docs] “Optionally, transfers can be held for approval by another team member.”

   proof ↗⚑ flag

   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

3. ai-native userSchedule recurring jobs or workflows

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

   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

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

   Increase's docs show general transfer APIs, holds, and optional human approval for transfers, but there is no evidence of a named feature for AI-agent scoped credentials with amount caps and counterparty allowlists — the story's specific banking-agent-access capability is unevidenced.

   • [claimed-docs] “You make a `POST /ach_transfers` call with the details of how much you'd like to send and data about the recipient.”
   • [claimed-docs] “Optionally, transfers can be held for approval by another team member.”
   • [claimed-docs] “Increase lets you place a hold on an Account to reserve funds for known future activity. Holds reduce the available balance without moving m…”

   proof ↗⚑ flag

   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

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

   Increase offers a full REST/JSON API (with OpenAPI spec) covering accounts, account numbers, transfers (ACH/wire/RTP/check), holds, webhooks for real-time events, and sandbox simulation — a clean programmatic surface well-suited to agentic access rather than dashboard scraping. However, there is no explicit MCP server offering, and no direct evidence of a unified 'documents' or transaction-history read endpoint being called out, nor confirmation of an agent-specific integration pattern. missing for 10: dedicated MCP server/tooling, explicit documents/statements API evidence, and independent hands-on confirmation of agent-based read access.

   • [claimed-docs] “You make a `POST /ach_transfers` call with the details of how much you'd like to send and data about the recipient.”
   • [claimed-docs] “You can instantly create multiple Account Numbers for a single Account and manage them programmatically.”
   • [claimed-docs] “Increase lets you place a hold on an Account to reserve funds for known future activity. Holds reduce the available balance without moving m…”
   • [claimed-docs] “Increase can reach out to your application so that you can take action (such as sending an email alert about the transaction to your user) a…”
   • [claimed-docs] “Every API and dashboard feature is available in Sandbox. ... you can use special Simulation APIs, which are only available in Sandbox.”
   • [probe] “PROBE openapi: HTTP 200 at https://increase.com/openapi.json — contains "openapi" key”
   • [probe] “PROBE docs-md: HTTP 200 at https://increase.com/documentation.md # Increase Documentation ## Products ### Cards - [3D Secure](https://inc…”

   proof ↗⚑ flag

   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

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

   No evidence Increase ships built-in AI features like natural-language transaction search, drafted dispute/alert responses, or anomaly summaries; all evidence covers banking-rail APIs (ACH, wire, RTP, checks), compliance, and webhooks with no AI/NLP capability mentioned.

   ⚑ flag

   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

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
   Increase~partialprobed4/10

   The docs index (probe-2) lists a 'Cards' product category with a '3D Secure' page, and increase-docs-15 confirms real-time authorization decisioning for card transactions, indicating Increase does issue cards through its API. However, the evidence pack contains no explicit confirmation of virtual vs. physical card issuance, spend control mechanisms, or digital wallet (Apple Pay/Google Pay) provisioning. Missing for 10: documentation on physical card issuance/shipping, spend limit/control APIs, and digital wallet tokenization support.

   • [probe] “PROBE docs-md: HTTP 200 at https://increase.com/documentation.md # Increase Documentation ## Products ### Cards - [3D Secure](https://inc…”
   • [claimed-docs] “When a user tries to use their card and Increase has to decide to approve the authorization or not... we'll create a Real-Time Decision obje…”

   proof ↗⚑ flag

   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

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

   The evidence pack covers transfers, accounts, holds, webhooks, compliance validations, and card authorization decisions, but contains no mention of dispute handling, Reg E investigation timelines, provisional credit mechanics, or documented ops responsibilities for card/ACH disputes. Since Increase issues cards and ACH transfers, this is a fair axis, but no supporting evidence exists.

   ⚑ flag

   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

Balances events

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

   weight 3 · round drawn
   Increase~partialclaimed6/10

   Increase documents holds that reduce available balance without moving money (real-time balance reflecting pending activity) and a webhooks system that fires for transaction events, including real-time decision webhooks for card authorizations. However, evidence doesn't explicitly confirm webhooks cover 'every transaction state change' comprehensively or that balance reads are guaranteed real-time/event-driven at the API level beyond the holds mechanism. missing for 10: explicit documentation of webhook event catalog per transfer/transaction type, confirmation of real-time balance API semantics, independent/hands-on verification that webhooks reliably mirror bank state changes.

   • [claimed-docs] “Increase lets you place a hold on an Account to reserve funds for known future activity. Holds reduce the available balance without moving m…”
   • [claimed-docs] “When a user tries to use their card and Increase has to decide to approve the authorization or not... we'll create a Real-Time Decision obje…”
   • [claimed-docs] “Increase can reach out to your application so that you can take action (such as sending an email alert about the transaction to your user) a…”
   • [claimed-docs] “Every API and dashboard feature is available in Sandbox. ... you can use special Simulation APIs, which are only available in Sandbox.”

   proof ↗⚑ flag

   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

Data quality

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

   weight 2 · round drawn
   Increase~partialclaimed6/10

   Increase provides transfer creation with recipient data, stable Account Numbers for reconciliation, real-time decision/webhook events, entity validation, and rail-specific metadata (ACH, wire, RTP, FedNow, check) — supporting rich transaction context for in-product use. However, evidence doesn't show detailed counterparty enrichment (e.g., merchant category codes, geolocation, standardized counterparty profiles) or explicit transaction-level enrichment beyond basic transfer/account data. missing for 10: explicit counterparty enrichment fields (merchant/category data), documented transaction object schema showing enrichment depth, independent developer confirmation of data richness beyond transfer creation.

   • [claimed-docs] “You make a `POST /ach_transfers` call with the details of how much you'd like to send and data about the recipient.”
   • [claimed-docs] “You make a `POST /wire_transfers` call with the details of how much you'd like to send and data about the recipient.”
   • [claimed-docs] “Real-Time Payments can be sent at any time during the day and funds will settle instantly.”
   • [claimed-docs] “You can instantly create multiple Account Numbers for a single Account and manage them programmatically.”
   • [claimed-docs] “With Increase, you can issue each investor a unique Account Number. This allows for automatic reconciliation of any received funds from that…”
   • [claimed-docs] “Increase makes Entity validations available via the API for each version of the data. You should follow up with your customer when the valid…”
   • [claimed-docs] “When a user tries to use their card and Increase has to decide to approve the authorization or not... we'll create a Real-Time Decision obje…”
   • [claimed-docs] “Sending FedNow transfers covers how to check reachability with the Routing Number endpoint and fall back to ACH or a wire.”

   proof ↗⚑ flag

   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

Statements

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

   weight 2 · round drawn
   Increase—none0/10

   No evidence in the pack mentions monthly account statements or 1099-INT tax document generation/retrieval via API; the documentation covers transfers, holds, webhooks, and compliance validations but not statements or tax forms. Missing for 10: any mention of statement generation, statement retrieval endpoints, or 1099-INT/tax document APIs.

   ⚑ flag

   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

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 Increase
   Increase~partialclaimed3/10

   Only compliance-overview.md is cited, noting that 'Entity validations' are available via the API and developers should follow up on data issues — implying some identity verification API exists, but there's no detail on document collection, watchlist/AML screening, or an explicit application state model for KYC/KYB. Missing for 10: explicit KYC vs KYB entity types, document upload/collection API, watchlist screening details, and documented application state machine (e.g. pending_review, requires_information, approved).

   • [claimed-docs] “Increase makes Entity validations available via the API for each version of the data. You should follow up with your customer when the valid…”

   proof ↗⚑ flag

   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

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

   The evidence shows only an API for Entity validations (increase-docs-12) that developers must poll and follow up on, but no evidence of an ops-facing queue/dashboard where a human operator can see why an application is pending, request/upload documents, or see a clear division between Increase's automated decisions and the bank's own decisions. This is a plausible axis for a banking-onboarding platform, but nothing in the pack demonstrates such an ops workflow tool exists.

   • [claimed-docs] “Increase makes Entity validations available via the API for each version of the data. You should follow up with your customer when the valid…”

   proof ↗⚑ flag

   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

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

   Increase documents holds on accounts to reserve funds (docs-14), optional approval holds on transfers (docs-8), real-time card authorization decisions (docs-15), and entity/compliance validations (docs-12), which together support some risk-control primitives. However there is no explicit documentation of configurable transaction/velocity limits per account or program, nor documented account-freeze and reinstatement workflows. Missing for 10: explicit velocity/transaction limit configuration, documented account freeze mechanism, and reinstatement path documentation.

   • [claimed-docs] “Increase lets you place a hold on an Account to reserve funds for known future activity. Holds reduce the available balance without moving m…”
   • [claimed-docs] “Optionally, transfers can be held for approval by another team member.”
   • [claimed-docs] “When a user tries to use their card and Increase has to decide to approve the authorization or not... we'll create a Real-Time Decision obje…”
   • [claimed-docs] “Increase makes Entity validations available via the API for each version of the data. You should follow up with your customer when the valid…”
   • [claimed-docs] “Increase can reach out to your application so that you can take action (such as sending an email alert about the transaction to your user) a…”

   proof ↗⚑ flag

   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

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

   Evidence covers ACH/wire/RTP transfer mechanics, entity validation, holds, and real-time card decisioning, but nowhere states who bears financial liability for ACH return fraud, card disputes, or account takeover losses. No documented liability split or fraud-loss allocation is present alongside the prevention tooling.

   ⚑ flag

   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

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 to Increase
   Increase~partialclaimed3/10

   Increase documents an approval-hold feature for transfers (a team-member approval stage) and compliance/entity validation, but there is no evidence of documented program-level transaction/volume limits or a defined process for raising them as growth scales. missing for 10: explicit documentation of program-level limits (transaction/volume caps), and a documented escalation/raise-limit process.

   • [claimed-docs] “Optionally, transfers can be held for approval by another team member.”
   • [claimed-docs] “Increase makes Entity validations available via the API for each version of the data. You should follow up with your customer when the valid…”

   proof ↗⚑ flag

   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

Ach

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

   weight 3 · round to Column
   Increase~partialclaimed4/10

   Docs confirm ACH transfer origination via POST /ach_transfers, approval holds, and webhooks for real-time events, showing the core API-first-class credit path with async notifications. However, the evidence pack contains no mention of debit-side ACH, same-day ACH windows, or return/NOC/reversal objects as first-class API entities with webhooks, which are central to the story. missing for 10: same-day ACH window support, explicit ACH debit examples, return/NOC/reversal object modeling and their webhook events.

   • [claimed-docs] “You make a `POST /ach_transfers` call with the details of how much you'd like to send and data about the recipient.”
   • [claimed-docs] “Increase can reach out to your application so that you can take action (such as sending an email alert about the transaction to your user) a…”
   • [claimed-docs] “Optionally, transfers can be held for approval by another team member.”
   • [claimed-docs] “Every API and dashboard feature is available in Sandbox. ... you can use special Simulation APIs, which are only available in Sandbox.”

   proof ↗⚑ flag

   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

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

   Increase supports programmatic check issuance (Check Transfers via API, with printing/mailing/tracking handled by Increase) per increase-docs-4, but there is no evidence in the pack of check deposit or image capture (e.g., check deposit/RDC endpoints) functionality. missing for 10: check deposit API/image capture documentation, evidence of inbound check image submission, independent confirmation of check deposit workflow.

   • [claimed-docs] “Check Transfers let you send a physical check without operating a printer or a mailroom. Increase prints and mails the check on your behalf,…”
   • [claimed-docs] “With Increase, you can issue each investor a unique Account Number. This allows for automatic reconciliation of any received funds from that…”

   proof ↗⚑ flag

   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

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

   Docs show wire transfers (POST /wire_transfers), RTP with instant settlement and reachability checks, and FedNow origination with reachability/fallback logic, all through the same REST API, plus receipt support via multi-rail Account Numbers (wire, RTP, ACH, check) confirming both origination and receipt paths. Missing for 10: explicit FedNow receipt-specific docs and independent hands-on confirmation of FedNow/RTP receipt flows beyond the account-number mention.

   • [claimed-docs] “You make a `POST /wire_transfers` call with the details of how much you'd like to send and data about the recipient.”
   • [claimed-docs] “Real-Time Payments can be sent at any time during the day and funds will settle instantly.”
   • [claimed-docs] “You can use the Routing Numbers API to confirm whether an institution supports Real-Time Payments.”
   • [claimed-docs] “Sending FedNow transfers covers how to check reachability with the Routing Number endpoint and fall back to ACH or a wire.”
   • [claimed-docs] “With Increase, you can issue each investor a unique Account Number. This allows for automatic reconciliation of any received funds from that…”
   • [community] “User considering Increase for freelancer payments noted appeal: "it says 'ACH transfers', 'Wire transfers', and 'Real-Time Payments'. That c…”

   proof ↗⚑ flag

   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

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

   All evidence describes US domestic rails only (ACH, domestic wire, RTP, FedNow, checks) with no mention of SWIFT, international wires, FX rates, or a currency/corridor coverage map. Missing for 10: any documentation of cross-border wire/SWIFT support, FX rate transparency, or supported currencies/corridors.

   • [claimed-docs] “You make a `POST /wire_transfers` call with the details of how much you'd like to send and data about the recipient.”
   • [claimed-docs] “Real-Time Payments can be sent at any time during the day and funds will settle instantly.”
   • [claimed-docs] “Sending FedNow transfers covers how to check reachability with the Routing Number endpoint and fall back to ACH or a wire.”
   • [claimed-docs] “Access multi-million-dollar FDIC insurance at participating IntraFi network banks directly in Increase.”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Increase
   Increase✓fullprobed8/10

   Increase's docs explicitly state that 'Every API and dashboard feature is available in Sandbox,' and the extensive first-party API coverage (transfers, approvals, holds, entity validation, webhooks, account numbers) mirrors dashboard functionality, indicating strong API/UI parity by design as an API-first banking platform. missing for 10: independent/hands-on confirmation that literally every dashboard feature (e.g., admin/user management, reporting UI) has a 1:1 API equivalent, and no explicit statement of full parity outside Sandbox context.

   • [claimed-docs] “Every API and dashboard feature is available in Sandbox. ... you can use special Simulation APIs, which are only available in Sandbox.”
   • [claimed-docs] “You make a `POST /ach_transfers` call with the details of how much you'd like to send and data about the recipient.”
   • [claimed-docs] “You make a `POST /wire_transfers` call with the details of how much you'd like to send and data about the recipient.”
   • [claimed-docs] “You can instantly create multiple Account Numbers for a single Account and manage them programmatically.”
   • [claimed-docs] “Optionally, transfers can be held for approval by another team member.”
   • [claimed-docs] “Increase lets you place a hold on an Account to reserve funds for known future activity. Holds reduce the available balance without moving m…”
   • [probe] “PROBE openapi: HTTP 200 at https://increase.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Column
   Increase—none0/10

   The evidence shows Increase exposes account, transfer, and entity data via a REST/JSON API and webhooks, but there is no documented bulk data-export feature, open-format data dump, or migration/offboarding tooling that would let a customer pull all their data and leave. Banking data portability is a fair axis for a financial API platform, so absence of such evidence is 'none' rather than 'na'.

   • [claimed-docs] “Every API and dashboard feature is available in Sandbox. ... you can use special Simulation APIs, which are only available in Sandbox.”
   • [claimed-docs] “You can instantly create multiple Account Numbers for a single Account and manage them programmatically.”
   • [probe] “PROBE docs-md: HTTP 200 at https://increase.com/documentation.md # Increase Documentation ## Products ### Cards - [3D Secure](https://inc…”

   proof ↗⚑ flag

   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

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

   Community evidence confirms Increase is a middleware/BaaS layer with named partner banks (First Internet Bank, Blue Ridge Bank) holding customer funds, and docs mention FDIC insurance via IntraFi network banks, giving founders some clarity on the sponsor-model structure. However, the evidence pack lacks explicit first-party documentation on failure scenarios (what happens to customer funds/accounts if Increase itself fails), lacks a clear charter/entity org chart, and doesn't address pass-through deposit insurance mechanics in depth. missing for 10: first-party docs on platform-failure contingency for customers, explicit charter/entity disclosure page, detail on pass-through insurance mechanics beyond one line, independent verification of bank-failure handling.

   • [community] “Accounts are with First Internet Bank or Blue Ridge Bank, not Increase itself: https://increase.com/terms - it's white-label banking API, no…”
   • [claimed-docs] “Access multi-million-dollar FDIC insurance at participating IntraFi network banks directly in Increase.”

   proof ↗⚑ flag

   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

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 to Increase
   Increase~partialclaimed3/10

   Evidence shows Increase provides entity validation data via API and flags data issues for follow-up (compliance-overview.md), implying some compliance tooling and a duty split with the platform, but there's no evidence of dedicated transaction monitoring, sanctions screening, case management for alerts, or SAR-filing support tools. missing for 10: transaction monitoring tooling, sanctions screening workflow, alert case management UI, SAR filing support, explicit ops-role division documentation.

   • [claimed-docs] “Increase makes Entity validations available via the API for each version of the data. You should follow up with your customer when the valid…”

   proof ↗⚑ flag

   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

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

   The evidence pack shows Increase's transfer/account APIs and general banking features, but contains no documentation of a formal daily ledger-to-bank-core reconciliation process (the Synapse-failure-mode issue) — no reconciliation reports, balance-attestation, or audit mechanism between Increase's API records and the partner bank's (First Internet Bank/Blue Ridge Bank) core ledger is mentioned. Missing for 10: documented reconciliation cadence/process, bank-core balance verification API or report, any third-party audit or attestation of ledger accuracy.

   • [claimed-docs] “With Increase, you can issue each investor a unique Account Number. This allows for automatic reconciliation of any received funds from that…”
   • [community] “Accounts are with First Internet Bank or Blue Ridge Bank, not Increase itself: https://increase.com/terms - it's white-label banking API, no…”

   proof ↗⚑ flag

   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