Column vs Synctera

Account opening

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

   weight 3 · round to Column
   Column✓fullcommunity8/10

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

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

   proof ↗⚑ flag

   Synctera~partialprobed7/10

   Docs show a full programmatic path — customer creation (personal/business), KYC/watchlist verification, account creation, cards, transfers/wires, webhooks — and confirm sandbox API keys work immediately with the same API surface as production (synctera-docs-1/2/3/9/10/14, synctera-probe-1/2). However, the pack never explicitly states the accounts are FDIC-insured deposit accounts or confirms sandbox truly mirrors bank-approval/production parity beyond key issuance, so the specific 'insured deposit account' and full sandbox-to-prod fidelity claims are not directly evidenced. Missing for 10: explicit FDIC/insurance confirmation, and independent/hands-on confirmation of sandbox-to-production parity for the full account-opening flow.

   • [claimed-docs] “Creates and manages records for personal customers”
   • [claimed-docs] “Creates and manages records for business customers”
   • [claimed-docs] “Creates and manages customer accounts”
   • [claimed-docs] “Synctera's verification solution runs identity and watchlist checks for personal and business customers and records the results as `verifica…”
   • [claimed-docs] “Once an API key is issued in Sandbox, you can immediately start calling the APIs below.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.synctera.com/llms.txt # Synctera - [v2 (658 pages)](https://docs.synctera.com/_llms/v2.md): Docume…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.synctera.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Synctera connects you with the banks in our network that best align with your product vision and timeline.”

   proof ↗⚑ flag

Fbo structures

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

   weight 3 · round to Column
   Column~partialcommunity5/10

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

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

   proof ↗⚑ flag

   Synctera—none0/10

   While Synctera's docs cover customer account creation, cards, transfers, and bank-partner collaboration tools, none of the evidence addresses FBO pooled vs individual account structuring, where FDIC insurance actually attaches, or ledger visibility/access-control documentation — the specific transparency concerns a finance lead would need. This is a fair axis for a BaaS/bank-partner platform, but no supporting evidence exists.

   • [claimed-docs] “Creates and manages customer accounts”
   • [claimed-docs] “Manage all operational workflows in a centralized platform with a set of tools that provide complete data visibility and seamless collaborat…”
   • [claimed-docs] “Synctera connects you with the banks in our network that best align with your product vision and timeline.”

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

   Synctera~partialclaimed3/10

   Synctera's docs confirm it creates and manages customer accounts and supports internal transfers, which is consistent with account-provisioning capability for a BaaS platform, but there is no explicit evidence of issuing unique routing numbers, virtual accounts for reconciliation, per-customer collection accounts, or sub-account/master-account hierarchies. missing for 10: explicit routing-number issuance, virtual account/reconciliation feature docs, per-customer collection account docs, master/sub-account hierarchy docs.

   • [claimed-docs] “Creates and manages customer accounts”
   • [claimed-docs] “The Internal Transfer API allows you to transfer funds between two Synctera accounts, in real-time.”
   • [claimed-docs] “Issue cards, accept payments, and transfer money between accounts”

   proof ↗⚑ flag

Yield

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

   weight 2 · round to Column
   Column~partialcommunity3/10

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

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

   proof ↗⚑ flag

   Synctera—none0/10

   Evidence covers customer accounts, cards, transfers, wires, KYC, webhooks, but nothing on interest-bearing accounts, sweep programs, or rate/spread mechanics between Synctera and bank partners. No documentation addresses idle balance yield or spread ownership.

   ⚑ flag

Agent access

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

   weight 2 · round drawn
   Column✓fullprobed9/10

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

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

   proof ↗⚑ flag

   Synctera✓fullprobed9/10

   A direct probe confirms Synctera serves a valid llms.txt at docs.synctera.com/llms.txt listing structured doc bundles (v2, v0) for agent consumption, plus a machine-readable OpenAPI spec, matching the agent-oriented docs story. Missing for 10: no independent/community confirmation of agents actually using it successfully.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.synctera.com/llms.txt # Synctera - [v2 (658 pages)](https://docs.synctera.com/_llms/v2.md): Docume…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.synctera.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

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

   weight 2 · round to Column
   Column~partialprobed6/10

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

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

   proof ↗⚑ flag

   Synctera~partialprobed4/10

   Synctera is API-first (OpenAPI spec, sandbox API keys) which inherently supports programmatic/headless calls, and docs show you can call APIs immediately after obtaining a sandbox key. However there is no explicit CI/CD guidance, CLI tool, or automation example (e.g., GitHub Actions, test harness) showing headless operation in a pipeline. Missing for 10: explicit CI/automation documentation, CLI or SDK examples for pipeline integration, and confirmation of non-interactive auth flows suited for CI.

   • [claimed-docs] “Once an API key is issued in Sandbox, you can immediately start calling the APIs below.”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.synctera.com/openapi.json — contains "openapi" key”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.synctera.com/llms.txt # Synctera - [v2 (658 pages)](https://docs.synctera.com/_llms/v2.md): Docume…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Column—none0/10

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

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

   proof ↗⚑ flag

   Synctera—none0/10

   Synctera is a banking-as-a-service platform, so an official MCP server is a plausible axis, but the evidence pack shows only API docs, OpenAPI spec, and llms.txt — no mention of an MCP server or agent-connection capability.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.synctera.com/llms.txt # Synctera - [v2 (658 pages)](https://docs.synctera.com/_llms/v2.md): Docume…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.synctera.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Column—none0/10

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

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

   proof ↗⚑ flag

   Synctera—none0/10

   Synctera is a banking-as-a-service API platform; evidence shows API docs, OpenAPI spec, and llms.txt but no mention of an official CLI tool for interacting with the platform. missing for 10: any CLI product, CLI documentation, or install instructions.

   ⚑ flag

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

   weight 3 · round to Column
   Column✓fullprobed9/10

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

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

   proof ↗⚑ flag

   Synctera✓fullprobed8/10

   Synctera exposes a comprehensive, well-documented public REST API (customers, accounts, cards, transfers, KYC, webhooks) confirmed by a live OpenAPI spec and llms.txt discovery, with a sandbox API key flow for immediate programmatic access — clear evidence of driving the product entirely via documented API. Missing for 10: independent third-party developer confirmation/hands-on usage reports beyond vendor docs and automated probes.

   • [claimed-docs] “Once an API key is issued in Sandbox, you can immediately start calling the APIs below.”
   • [claimed-docs] “Issue cards, accept payments, and transfer money between accounts”
   • [claimed-docs] “The Webhook API enables integrators to subscribe to specific events on the Synctera platform.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.synctera.com/llms.txt # Synctera - [v2 (658 pages)](https://docs.synctera.com/_llms/v2.md): Docume…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.synctera.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Column—none0/10

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

   ⚑ flag

   Synctera—none0/10

   Synctera is an API platform where scoped credentials would be a fair axis to ask about, but the evidence only shows generic API key issuance for Sandbox with no mention of scopes, permission levels, or least-privilege credential issuance for agents.

   • [claimed-docs] “Once an API key is issued in Sandbox, you can immediately start calling the APIs below.”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Column
   Column!disputedcontradicted3/10

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

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

   proof ↗⚑ flag

   Synctera—none0/10

   Evidence shows extensive API documentation, an OpenAPI spec, and an llms.txt for AI consumption, but there is no mention of official client SDKs (e.g., Python, JS, Java libraries) that developers could build against directly. Missing for 10: any evidence of official language-specific SDKs, SDK versioning, or SDK code samples.

   ⚑ flag

8. ai-native userSubscribe to events via webhooks

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

   Synctera✓fullclaimed8/10

   Synctera provides a dedicated Webhook API letting integrators subscribe to specific platform events, documented in a first-party guide. Missing for 10: independent/hands-on corroboration of webhook reliability and richer detail on event types/payload structure beyond the single guide reference.

   • [claimed-docs] “The Webhook API enables integrators to subscribe to specific events on the Synctera platform.”

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round drawn
   Column—none0/10

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

   ⚑ flag

   Synctera—none0/10

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

   ⚑ flag

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

   weight 2 · round drawn
   Column—none0/10

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

   ⚑ flag

   Synctera—none0/10

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

   ⚑ flag

Api quality

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

   weight 2 · round to Column
   Column~partialprobed5/10

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

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

   proof ↗⚑ flag

   Synctera—none0/10

   Evidence shows Synctera has API documentation, an OpenAPI spec, and llms.txt for docs discovery, but nothing indicates an interactive API reference with runnable/try-it-out examples (e.g., Swagger UI, Postman collections, live sandbox console). missing for 10: interactive explorer UI, runnable code samples, live 'try it' console evidence.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.synctera.com/openapi.json — contains "openapi" key”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.synctera.com/llms.txt # Synctera - [v2 (658 pages)](https://docs.synctera.com/_llms/v2.md): Docume…”
   • [claimed-docs] “Once an API key is issued in Sandbox, you can immediately start calling the APIs below.”

   proof ↗⚑ flag

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

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

   Synctera✓fullprobed9/10

   Probe confirms a live, machine-readable OpenAPI spec at docs.synctera.com/openapi.json returning a valid 'openapi' key, and docs also expose an llms.txt index for machine consumption. Missing for 10: no independent third-party corroboration of spec completeness/versioning beyond the probe.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.synctera.com/openapi.json — contains "openapi" key”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.synctera.com/llms.txt # Synctera - [v2 (658 pages)](https://docs.synctera.com/_llms/v2.md): Docume…”

   proof ↗⚑ flag

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

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

   Synctera✓fullclaimed6/10

   Synctera's own docs describe a distinct Sandbox environment where an API key can be issued and used to call APIs immediately, implying a separate environment from production. Missing for 10: explicit documentation of sandbox data isolation guarantees, sample sandbox test data, and independent/hands-on confirmation that sandbox never touches production data.

   • [claimed-docs] “Once an API key is issued in Sandbox, you can immediately start calling the APIs below.”

   proof ↗⚑ flag

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

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

   Synctera~partialprobed4/10

   Evidence confirms Synctera has versioned API documentation (v0 and v2 exist per llms.txt) and a public OpenAPI spec, showing some API versioning discipline, but there is no mention of a documented deprecation policy, sunset timelines, or migration guidance between versions. missing for 10: explicit deprecation policy documentation, version sunset/migration guides, changelog or breaking-change notices.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.synctera.com/llms.txt # Synctera - [v2 (658 pages)](https://docs.synctera.com/_llms/v2.md): Docume…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.synctera.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Column—none0/10

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

   ⚑ flag

   Synctera—none0/10

   The evidence pack covers individual resource APIs (customers, accounts, cards, transfers, verification) but never mentions batch/bulk endpoints, multi-item operations, or async bulk job APIs. Missing for 10: any documented bulk/batch API, bulk import/export tooling, or evidence of processing multiple records in a single call.

   ⚑ flag

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

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

   Synctera~partialclaimed3/10

   Synctera's Webhook API lets integrators subscribe to platform events, which is the foundation for event-driven automation, but there's no evidence of a rules engine or declarative 'if event then action' capability built into the platform. Missing for 10: documented rule-definition interface, conditional logic/action mapping, and evidence of automated actions triggering without custom integrator code.

   • [claimed-docs] “The Webhook API enables integrators to subscribe to specific events on the Synctera platform.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

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

   Synctera~partialclaimed3/10

   Synctera exposes a 'scheduled payments' API to create and manage recurring payment schedules, which is the only evidence of any recurring/scheduled execution capability. There is no evidence of a general-purpose job/workflow scheduler, cron-like automation, or orchestration engine that an AI-native user could use to schedule arbitrary recurring workflows beyond payments. Missing for 10: general recurring workflow/job scheduling API, agent/automation orchestration support, and independent confirmation of scheduling reliability.

   • [claimed-docs] “Create and manage scheduled payments for customers”

   proof ↗⚑ flag

Agent operations

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

   weight 3 · round drawn
   Column—none0/10

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

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

   proof ↗⚑ flag

   Synctera—none0/10

   Synctera's docs cover accounts, transfers, cards, KYC, and APIs generally, but there is no evidence of agent-specific scoped credentials, amount caps, counterparty allowlists, or any vendor-documented named feature for AI agents operating within policy. Missing for 10: named agent/AI credential scoping feature, amount cap enforcement docs, counterparty allowlist mechanism, any mention of AI agents at all.

   • [claimed-docs] “The Internal Transfer API allows you to transfer funds between two Synctera accounts, in real-time.”
   • [claimed-docs] “Once an API key is issued in Sandbox, you can immediately start calling the APIs below.”

   proof ↗⚑ flag

Agent visibility

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

   weight 2 · round to Column
   Column~partialcommunity7/10

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

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

   proof ↗⚑ flag

   Synctera~partialprobed6/10

   Synctera exposes a broad REST/OpenAPI surface covering accounts, transactions, transfers, cards, external account balance/transaction retrieval, document verification, and webhook-driven event/pending-activity feeds, plus an llms.txt for AI discoverability — strongly supporting agent-readable banking data without screen-scraping. However there is no evidence of a dedicated MCP server or agent-specific read surface, only a general OpenAPI/webhook API. Missing for 10: explicit MCP server/tool endpoint, unified 'read full picture' aggregation endpoint, independent confirmation of AI-agent usage in production.

   • [claimed-docs] “Creates and manages customer accounts”
   • [claimed-docs] “The Internal Transfer API allows you to transfer funds between two Synctera accounts, in real-time.”
   • [claimed-docs] “Synctera has partnered with Plaid and Finicity to verify ownership and retrieve balance and transaction information.”
   • [claimed-docs] “Verify documentation for a customer”
   • [claimed-docs] “The Webhook API enables integrators to subscribe to specific events on the Synctera platform.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.synctera.com/llms.txt # Synctera - [v2 (658 pages)](https://docs.synctera.com/_llms/v2.md): Docume…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.synctera.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

Builtin ai

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

   weight 2 · round drawn
   Column—none0/10

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

   ⚑ flag

   Synctera—none0/10

   No evidence of any built-in AI features—natural-language transaction search, dispute/alert drafting, or anomaly summaries—anywhere in the docs; the evidence pack only covers core banking-as-a-service APIs (accounts, cards, transfers, KYC, webhooks). This is an applicable axis for a banking platform but nothing supports it.

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

   Synctera~partialclaimed5/10

   Docs confirm card issuance and management is part of the same API platform as accounts (synctera-docs-4, synctera-docs-7), consistent with the story's core ask. However, there's no explicit evidence distinguishing virtual vs. physical card issuance, spend controls, or digital wallet (Apple/Google Pay) provisioning. Missing for 10: explicit virtual/physical card type documentation, spend control API details, digital wallet tokenization/push-provisioning support.

   • [claimed-docs] “Issues, activates, and manages cards for customers”
   • [claimed-docs] “Issue cards, accept payments, and transfer money between accounts”
   • [claimed-docs] “Creates and manages customer accounts”

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

   Synctera—none0/10

   The evidence pack shows card issuance, account management, transfers, KYC, webhooks, and disclosures, but contains no mention of dispute management, Reg E investigation timelines, provisional credit mechanics, or ops tooling/responsibilities for chargebacks/disputes. This is a fair axis for a card/BaaS issuing platform, but no supporting evidence exists.

   ⚑ flag

Balances events

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

   weight 3 · round to Column
   Column~partialclaimed6/10

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

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

   proof ↗⚑ flag

   Synctera~partialclaimed5/10

   Synctera documents a Webhook API for subscribing to platform events and real-time internal transfers, which supports event-driven notification of transaction state changes, but the evidence pack does not explicitly confirm real-time balance reads reflecting holds/pending activity or an exhaustive webhook-to-ledger-state mapping. missing for 10: explicit documentation of hold/pending balance semantics in balance reads, confirmation that webhooks fire for every transaction state transition (not just select events), and independent/hands-on verification that the ledger mirrors bank state in real time.

   • [claimed-docs] “The Internal Transfer API allows you to transfer funds between two Synctera accounts, in real-time.”
   • [claimed-docs] “The Webhook API enables integrators to subscribe to specific events on the Synctera platform.”

   proof ↗⚑ flag

Data quality

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

   weight 2 · round to Column
   Column~partialclaimed6/10

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

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

   proof ↗⚑ flag

   Synctera~partialclaimed3/10

   Synctera exposes distinct transaction guides (domestic wires, internal transfers, external account linking via Plaid/Finicity, RDC) and a webhook API for event data, suggesting a structured transaction model, but no evidence explicitly documents counterparty detail fields, rail-specific metadata schemas, stable transaction identifiers, or enrichment logic that would make raw feeds directly usable in-product. missing for 10: explicit transaction object schema showing counterparty fields, rail metadata, stable IDs, and enrichment/categorization documentation.

   • [claimed-docs] “Domestic wires refer to the transfer of funds between 2 US based accounts.”
   • [claimed-docs] “The Internal Transfer API allows you to transfer funds between two Synctera accounts, in real-time.”
   • [claimed-docs] “Synctera has partnered with Plaid and Finicity to verify ownership and retrieve balance and transaction information.”
   • [claimed-docs] “The Webhook API enables integrators to subscribe to specific events on the Synctera platform.”
   • [claimed-docs] “Handles remote deposit capture (RDC) transactions”

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

   Synctera—none0/10

   No evidence in the pack mentions monthly statement generation or 1099-INT tax document production/retrieval via API; coverage includes accounts, cards, payments, KYC, and disclosures but nothing on 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 Synctera
   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

   Synctera~partialclaimed6/10

   Synctera has documented KYC/KYB verification objects covering personal and business customers, watchlist screening, and document verification, plus customer record management APIs. However, evidence does not explicitly show a modeled application/verification state machine (e.g., pending/approved/rejected/manual-review states) or detailed document collection workflow specifics. missing for 10: explicit documentation of verification application state model/lifecycle, document collection API details, and independent/hands-on corroboration of KYC/KYB flows.

   • [claimed-docs] “Creates and manages records for personal customers”
   • [claimed-docs] “Creates and manages records for business customers”
   • [claimed-docs] “Synctera's verification solution runs identity and watchlist checks for personal and business customers and records the results as `verifica…”
   • [claimed-docs] “Verify documentation for a customer”

   proof ↗⚑ flag

Review queues

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

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

   Synctera~partialclaimed4/10

   Synctera exposes KYC/KYB verification objects, document verification, and an operational workflow platform pitched as offering 'complete data visibility and seamless collaboration' with bank partners, which touches on the onboarding-queue and bank/program collaboration themes. However, there is no concrete evidence of a queue UI showing why an application is pending, a document-upload workflow for ops, or an explicit description of which decisions belong to ops versus the bank. missing for 10: pending-reason visibility in a queue UI, ops-driven document request/upload flow, explicit ops-vs-bank decision boundaries.

   • [claimed-docs] “Manage all operational workflows in a centralized platform with a set of tools that provide complete data visibility and seamless collaborat…”
   • [claimed-docs] “Synctera's verification solution runs identity and watchlist checks for personal and business customers and records the results as `verifica…”
   • [claimed-docs] “Verify documentation for a customer”
   • [claimed-docs] “Handles legally required disclosures to customers”

   proof ↗⚑ flag

Limits holds

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

   weight 2 · round to Column
   Column~partialcommunity2/10

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

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

   proof ↗⚑ flag

   Synctera—none0/10

   The evidence pack covers customer/account creation, cards, transfers, KYC/KYB, webhooks, and general 'operational workflows' but contains no specific mention of transaction/velocity limits, suspicious-activity holds, account freeze mechanisms, or documented reinstatement paths.

   • [claimed-docs] “Manage all operational workflows in a centralized platform with a set of tools that provide complete data visibility and seamless collaborat…”
   • [claimed-docs] “Synctera's verification solution runs identity and watchlist checks for personal and business customers and records the results as `verifica…”

   proof ↗⚑ flag

Loss allocation

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

   weight 2 · round drawn
   Column—none0/10

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

   ⚑ flag

   Synctera—none0/10

   Evidence shows Synctera's KYC/verification, payments, and card issuing docs, but nothing addresses fraud-loss liability allocation (who bears ACH return fraud, card dispute, or ATO losses) or documents prevention tooling alongside a liability split — the core of this story.

   ⚑ flag

Program scaling

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

   weight 2 · round drawn
   Column—none0/10

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

   ⚑ flag

   Synctera—none0/10

   No evidence pack item documents program-level limits, approval-stage thresholds, or a defined process for raising limits; documentation covers API features (accounts, cards, transfers, KYC) but not growth-limit governance 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
   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

   Synctera—none0/10

   The evidence pack covers internal transfers, domestic wires, scheduled payments, and webhooks generally, but contains no mention of ACH origination, credit/debit ACH types, same-day ACH windows, or ACH-specific unhappy-path objects like returns, NOCs, or reversals. Since Synctera is a banking-as-a-service platform where ACH is a plausible core money-movement capability, absence of evidence means this axis is unmet rather than inapplicable.

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

   Synctera~partialclaimed5/10

   Synctera explicitly documents remote deposit capture (RDC) handling and card issuance, indicating check deposit capability, but there is no direct evidence of programmatic check issuance (printing/mailing physical checks) or details on the image capture API/workflow. missing for 10: explicit check-issuance API docs, image capture endpoint/schema details, independent or hands-on confirmation of RDC workflow.

   • [claimed-docs] “Handles remote deposit capture (RDC) transactions”
   • [claimed-docs] “Issues, activates, and manages cards for customers”

   proof ↗⚑ flag

Instant rails

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

   weight 2 · round to Column
   Column✓fullprobed8/10

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

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

   proof ↗⚑ flag

   Synctera~partialclaimed3/10

   Docs confirm domestic wire origination/receipt via API (synctera-docs-15) and general money-movement APIs (synctera-docs-5, synctera-docs-6, synctera-docs-7), but there is no evidence of RTP or FedNow rails, per-rail capability documentation, or same-API origination/receipt for those faster rails. Missing for 10: RTP support, FedNow support, per-rail capability docs, and origination vs receipt distinctions for faster payments.

   • [claimed-docs] “Domestic wires refer to the transfer of funds between 2 US based accounts.”
   • [claimed-docs] “The Internal Transfer API allows you to transfer funds between two Synctera accounts, in real-time.”
   • [claimed-docs] “Create and manage scheduled payments for customers”
   • [claimed-docs] “Issue cards, accept payments, and transfer money between accounts”

   proof ↗⚑ flag

International

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

   weight 2 · round to Column
   Column~partialclaimed4/10

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

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

   proof ↗⚑ flag

   Synctera—none0/10

   Evidence only documents domestic wires explicitly scoped to transfers 'between 2 US based accounts' (synctera-docs-15), plus internal transfers between Synctera accounts (synctera-docs-5). There is no mention anywhere in the pack of international wires, SWIFT, FX rates, or a coverage map of currencies/corridors, suggesting Synctera is US-domestic focused.

   • [claimed-docs] “Domestic wires refer to the transfer of funds between 2 US based accounts.”
   • [claimed-docs] “The Internal Transfer API allows you to transfer funds between two Synctera accounts, in real-time.”

   proof ↗⚑ flag

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

   weight 2 · round to Column
   Column✓fullcommunity7/10

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

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

   proof ↗⚑ flag

   Synctera~partialprobed6/10

   Synctera's docs describe an extensive, well-documented REST API (OpenAPI spec, llms.txt) covering nearly all core banking operations—customers, accounts, cards, transfers, KYC, webhooks, disclosures—suggesting broad API-first coverage. However, the evidence also references a separate 'centralized platform' with UI tools for bank-partner collaboration (synctera-docs-16), and there is no explicit claim or verification that every UI-only workflow (e.g., dashboard operations, partner collaboration tools) is fully mirrored in the API. Missing for 10: explicit parity statement or audit confirming UI-exclusive features (e.g., operational dashboards) are also API-accessible, and independent/hands-on confirmation of full parity.

   • [claimed-docs] “Manage all operational workflows in a centralized platform with a set of tools that provide complete data visibility and seamless collaborat…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.synctera.com/openapi.json — contains "openapi" key”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.synctera.com/llms.txt # Synctera - [v2 (658 pages)](https://docs.synctera.com/_llms/v2.md): Docume…”
   • [claimed-docs] “Once an API key is issued in Sandbox, you can immediately start calling the APIs below.”
   • [claimed-docs] “Issue cards, accept payments, and transfer money between accounts”

   proof ↗⚑ flag

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

   weight 3 · round to Column
   Column~partialclaimed6/10

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

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

   proof ↗⚑ flag

   Synctera—none0/10

   The evidence pack shows Synctera's API and webhook documentation (docs-13, probe-1, probe-2) but no mention of a bulk data export feature, open-format data portability, or account-closure data extraction for customers. This is a fair axis for a BaaS platform handling customer financial data, but no evidence supports it.

   ⚑ flag

Charter clarity

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

   weight 3 · round to Column
   Column~partialprobed6/10

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

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

   proof ↗⚑ flag

   Synctera~partialclaimed4/10

   Docs confirm Synctera's sponsor-bank model — it explicitly connects founders with partner banks and provides collaboration tools 'between you and your bank partner' (synctera-docs-16, synctera-docs-17), making clear it is middleware rather than a chartered bank itself. However, there is no evidence addressing what happens to customer funds/accounts if Synctera itself fails or is wound down, which is a core part of this story. Missing for 10: explicit disclosure of failure/wind-down protections for end customers, clarity on which specific bank charter backs a given program, and any independent/regulatory confirmation of the sponsor relationship.

   • [claimed-docs] “Manage all operational workflows in a centralized platform with a set of tools that provide complete data visibility and seamless collaborat…”
   • [claimed-docs] “Synctera connects you with the banks in our network that best align with your product vision and timeline.”

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

   Synctera~partialclaimed4/10

   Docs show KYC/KYB verification with watchlist checks (implying sanctions screening) and a general claim of centralized operational tooling with bank-partner collaboration, suggesting some duty-split framework exists. However, there is no explicit evidence of transaction monitoring, alert case management, or SAR-filing support tooling. missing for 10: transaction monitoring tooling, case management for alerts, SAR-filing support, explicit description of duty split between ops/platform/bank for compliance workflows.

   • [claimed-docs] “Synctera's verification solution runs identity and watchlist checks for personal and business customers and records the results as `verifica…”
   • [claimed-docs] “Manage all operational workflows in a centralized platform with a set of tools that provide complete data visibility and seamless collaborat…”
   • [claimed-docs] “Handles legally required disclosures to customers”

   proof ↗⚑ flag

Reconciliation

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

   weight 3 · round drawn
   Column—none0/10

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

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

   proof ↗⚑ flag

   Synctera—none0/10

   The evidence pack contains no documentation of a reconciliation process, ledger-to-bank-core matching, or any daily reconciliation reporting mechanism — only vague references to 'complete data visibility' and general product features (customer/card/transfer APIs). Given the sponsor-bank model risk highlighted by Synapse's collapse, this is a fair and material axis for a BaaS platform, but no concrete evidence shows Synctera documents or automates ledger reconciliation with bank partners.

   ⚑ flag