Synctera vs Treasury Prime

Account opening

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

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

   Treasury Prime~partialclaimed7/10

   Docs show a clear API-driven account opening flow (Person → Business → Account Application) with KYC/KYB integration, plus a Developer Sandbox with API keys and Postman collection for pre-launch testing (treasury-prime-docs-4, treasury-prime-docs-5, treasury-prime-docs-1, treasury-prime-docs-12). However, there is no explicit documentation confirming FDIC/NCUA deposit insurance status or an end-to-end 'application to active account' status confirmation step, and no independent/hands-on corroboration of sandbox-to-production parity. Missing for 10: explicit insured-deposit language, documented account-activation/status lifecycle, and third-party verification of sandbox parity.

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

   proof ↗⚑ flag

Fbo structures

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

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

   Treasury Prime—none0/10

   The evidence covers account creation, KYC, ACH/wire/book transfers, and statements, but nowhere documents FBO pool vs individual account structure, where FDIC insurance attaches, or who can view the ledger. This is a fair and material question for a banking-as-a-service platform, so the axis applies, but no supporting evidence exists.

   ⚑ flag

Virtual accounts

1. developerIssue unique account and routing numbers at scale — virtual accounts for reconciliation, per-customer collection accounts, and sub-accounts under a master structure

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

   Treasury Prime—none0/10

   Evidence confirms Treasury Prime supports creating bank accounts via Person/Business/Account Applications and listing accounts, but there is no mention of issuing unique routing numbers, virtual accounts for reconciliation, or sub-account/master-account hierarchies anywhere in the docs pack. Since Treasury Prime is a banking-as-a-service platform, this capability is a fair and expected axis, but no evidence substantiates it here.

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

   proof ↗⚑ flag

Yield

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

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

   Treasury Prime—none0/10

   No evidence pack item mentions interest-bearing accounts, sweep programs, yield/rate mechanics, or spread-sharing arrangements for idle balances; documentation covers account opening, ACH/wire/book transfers, KYC, and statements only.

   ⚑ flag

Agent access

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

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

   Treasury Prime✓fullprobed9/10

   A probe confirms Treasury Prime hosts a valid llms.txt file returning HTTP 200 with structured links to its developer docs, directly satisfying the story of pointing an agent at an llms.txt/agent-oriented doc index. Missing for 10: no independent third-party confirmation of agent usage or OpenAPI spec discoverability (openapi.json probes 404).

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

   proof ↗⚑ flag

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

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

   Treasury Prime~partialprobed4/10

   Treasury Prime is an API-first banking platform, so its REST API can be called headlessly/in CI via HTTP Basic Auth (sandbox + ping/account endpoints, command-line or Postman testing), which supports automation-style usage. However there is no evidence of CI-specific tooling, an official SDK/CLI, webhooks for async automation, or a public OpenAPI spec (probe found 404s), so full headless/CI suitability is not demonstrated. Missing for 10: official CLI/SDK for CI pipelines, documented OpenAPI/machine-readable spec, CI examples or automation guides, and evidence of non-interactive auth flows beyond basic API key testing.

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

   proof ↗⚑ flag

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

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

   Treasury Prime—none0/10

   Treasury Prime is a banking-as-a-service API platform; no evidence of an official MCP server or agent-connectivity offering is present in the evidence pack, only REST API docs.

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

   proof ↗⚑ flag

4. ai-native userUse an official CLI

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

   Treasury Prime—none0/10

   Treasury Prime is a banking-as-a-service API platform; no evidence of an official CLI tool exists—only mentions of API testing via command line (curl) or Postman, not a dedicated CLI product. No CLI documentation, package, or download is referenced anywhere in the evidence.

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

   proof ↗⚑ flag

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

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

   Treasury Prime✓fullprobed8/10

   Treasury Prime is fundamentally an API-first banking platform with extensive documented REST endpoints (accounts, ACH, wires, book transfers, KYC, applications), Basic Auth API keys, a free Developer Sandbox, and a Postman collection for testing — clearly enabling programmatic, AI-native usage. Missing for 10: a discoverable machine-readable OpenAPI/swagger spec (probe returned 404s) and independent/hands-on corroboration beyond vendor docs.

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

   proof ↗⚑ flag

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

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

   Treasury Prime—none0/10

   Evidence shows Treasury Prime issues API Key ID/Secret Key pairs via HTTP Basic Auth for sandbox and production access, but there is no mention of scopes, roles, permission levels, or least-privilege credential configuration, nor anything AI-agent-specific.

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

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

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

   Treasury Prime—none0/10

   The evidence pack covers REST API endpoints, a Postman collection, and a sandbox, but contains no mention of official client SDKs in any language, and OpenAPI spec probes all returned 404s. Missing for 10: any documented official SDK (e.g., Python, Node, Java client libraries), SDK installation/usage guides, or GitHub SDK repos.

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

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

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

   Treasury Prime—none0/10

   The evidence pack covers onboarding, KYC, ACH, wires, book transfers, and account statements, but contains no mention of webhooks or event subscription mechanisms anywhere in the docs or probes. Since webhook support is a plausible and common feature for a banking-as-a-service API platform, its complete absence from the evidence means the story is unmet rather than out-of-scope.

   ⚑ flag

Agentic features

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

   weight 2 · round drawn
   Synctera—none0/10

   Synctera is a banking-as-a-service API platform for core banking operations; evidence pack shows no AI-generated insights, analytics, or suggestion features derived from customer data. This is an applicable axis for a fintech data platform, but no evidence of any AI-driven insight capability exists.

   ⚑ flag

   Treasury Prime—none0/10

   No evidence of AI-generated insights, analytics, or suggestions surfaced within the product; documentation covers banking-as-a-service APIs (accounts, ACH, wires, KYC) but nothing about AI-driven data insights.

   ⚑ flag

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

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

   Treasury Prime—none0/10

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

   ⚑ flag

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

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

   Treasury Prime—none0/10

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

   ⚑ flag

Api quality

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

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

   Treasury Prime~partialprobed4/10

   Docs mention a Postman Collection and sandbox for testing API calls, which offers some runnable-example capability, but there's no evidence of an interactive in-browser API reference (e.g., Swagger/OpenAPI explorer) — a probe for openapi.json/swagger.json returned 404s. missing for 10: interactive embedded API reference UI, OpenAPI/Swagger spec, in-browser runnable code snippets.

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

   proof ↗⚑ flag

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

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

   Treasury Prime—none0/10

   Probe explicitly checked common OpenAPI/swagger paths and all returned 404, and no docs reference a downloadable machine-readable spec (only a Postman Collection is mentioned, which is not OpenAPI/equivalent).

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

   proof ↗⚑ flag

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

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

   Treasury Prime✓fullclaimed8/10

   Treasury Prime provides a free Developer Sandbox for creating API keys and testing endpoints (ping, accounts) separately from production, plus a documented "Testing in Sandbox" guide with a Postman Collection for exploration. This directly enables development/testing without touching production data. Missing for 10: independent/hands-on confirmation of sandbox fidelity and explicit documentation of sandbox-to-production promotion workflow.

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

   proof ↗⚑ flag

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

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

   Treasury Prime—none0/10

   No evidence of API versioning scheme or a documented deprecation policy anywhere in the docs; OpenAPI spec probes all 404, and no changelog or version-lifecycle documentation is cited.

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

   proof ↗⚑ flag

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

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

   Treasury Prime—none0/10

   No evidence of any batch/bulk endpoints (e.g., bulk ACH, bulk transfers, or list-mutation APIs) in the docs pack; all endpoints described are single-item (single account, single ACH, single wire). Bulk operations are a plausible axis for a banking API platform, so absence of evidence yields 'none'.

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

   proof ↗⚑ flag

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

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

   Treasury Prime—none0/10

   Treasury Prime's evidence pack covers account opening, KYC, ACH/wire/book transfers, and sandbox testing, but contains no mention of webhooks, event subscriptions, or a rules/automation engine that lets users define triggers for automatic actions. Given BaaS platforms commonly expose event-driven webhooks, this axis is a fair question, but no supporting evidence exists in the pack.

   ⚑ flag

3. ai-native userSchedule recurring jobs or workflows

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

   Treasury Prime—none0/10

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

   ⚑ flag

Agent operations

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

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

   Treasury Prime—none0/10

   The evidence pack shows standard API key auth (API Key ID/Secret) and general account/transfer endpoints, but nothing about scoped credentials, per-transaction amount caps, counterparty allowlists, or any agent/AI-specific access model documented by name. This is a fair axis for a banking API platform, but no evidence supports it.

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

   proof ↗⚑ flag

Agent visibility

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

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

   Treasury Prime~partialprobed5/10

   Treasury Prime offers a clean REST API to list accounts, transactions, ACH/wire/book transfers, and statements, avoiding screen-scraping, and provides an llms.txt for AI discoverability. However, there is no evidence of a documented MCP server, no consolidated 'pending activity' or document-retrieval endpoint explicitly described, and the OpenAPI spec probe returned 404s, suggesting no easily machine-consumable schema for agents. Missing for 10: an official MCP surface or agent-native integration, explicit endpoints for pending transactions/documents, and a working OpenAPI/swagger spec for automated discovery.

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

   proof ↗⚑ flag

Builtin ai

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

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

   Treasury Prime—none0/10

   No evidence of any built-in AI features for banking operations—no natural-language transaction search, dispute/alert response drafting, or anomaly summaries are mentioned anywhere in the docs pack, which instead covers standard banking-as-a-service API functionality (accounts, ACH, wires, KYC).

   ⚑ flag

Card issuance

1. developerAccounts come with cards — issue virtual and physical debit cards tied to the account through the same API, with spend controls and digital wallet support

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

   Treasury Prime—none0/10

   The evidence pack covers account opening, KYC, ACH, wire, book transfers, and cash deposits, but contains no mention of debit card issuance, physical/virtual cards, spend controls, or digital wallet support anywhere in the docs or probes.

   ⚑ flag

Disputes

1. ops userCard and ACH disputes are handled properly — Reg E investigation timelines, provisional credit mechanics, and my operational responsibilities documented and tooled

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

   Treasury Prime—none0/10

   Evidence covers ACH/wire/book transfer mechanics and returns but contains no mention of Reg E dispute investigation timelines, provisional credit mechanics, or documented ops responsibilities for card/ACH disputes.

   ⚑ flag

Balances events

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

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

   Treasury Prime—none0/10

   The evidence pack shows account, ACH, wire, and book-transfer status fields (e.g., wire 'status' attribute) but contains no mention of webhooks, event notifications, or real-time balance/hold semantics reflecting pending activity — core to this story. missing for 10: webhook/event API docs, balance endpoint showing holds/pending distinctions, any real-time push notification mechanism.

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

   proof ↗⚑ flag

Data quality

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

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

   Treasury Prime~partialclaimed4/10

   Docs describe transaction types (ACH credit/debit, wire with status tracking, book transfers) and basic account data, implying some structured metadata exists, but there is no explicit documentation of counterparty detail fields, rail-specific metadata enrichment, or stable identifier schemes that would let a developer build rich in-product transaction views. missing for 10: explicit counterparty/beneficiary data fields, rail-specific metadata (e.g., ACH company entry description, wire OBI/BBI fields), stable identifier documentation, and any enrichment/categorization features.

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

   proof ↗⚑ flag

Statements

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

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

   Treasury Prime~partialclaimed4/10

   Monthly account statements are documented as generated and retrievable via API ("Generate and retrieve branded monthly account statements"), but there is no evidence of 1099-INT tax document generation or retrieval anywhere in the pack. missing for 10: 1099-INT tax document generation/retrieval via API, any tax-reporting endpoint documentation, independent confirmation of statement/tax automation in production.

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

   proof ↗⚑ flag

Kyc kyb

1. developerCustomer verification is programmatic — KYC for individuals and KYB for businesses with document collection, watchlist screening, and clearly modeled application states

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

   Treasury Prime~partialclaimed6/10

   Docs confirm a programmatic application flow (Person/Business/Account Application) and third-party KYC/KYB vendor integration, plus an Incremental KYC mode that runs KYC outside account opening — supporting the core 'programmatic verification' story. However, evidence does not show explicit document collection endpoints, watchlist screening details, or a full state-machine model of application statuses. missing for 10: explicit document upload/collection API details, watchlist/OFAC screening specifics, documented application state enumeration and transitions.

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

   proof ↗⚑ flag

Review queues

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

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

   Treasury Prime—none0/10

   The evidence pack only documents developer API endpoints for creating Person/Business/Account applications and KYC/KYB integration hooks — it never describes an ops-facing queue UI showing why an application is pending, a way to request/upload additional documents, or any distinction between platform-owned vs. bank-owned decisions. This is a plausible axis for a bank-partner onboarding platform, but nothing in the evidence shows such an ops console or decision-attribution feature.

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

   proof ↗⚑ flag

Limits holds

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

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

   Treasury Prime—none0/10

   No evidence pack items mention transaction/velocity limits, suspicious-activity holds, account freezes, or reinstatement workflows; documentation covers account opening, KYC, ACH/wire/book transfers, and statements but nothing about risk-control configuration. Missing for 10: any documentation of per-account/program limit settings, hold/freeze mechanisms, or reinstatement procedures.

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

   proof ↗⚑ flag

Loss allocation

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

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

   Treasury Prime—none0/10

   Evidence shows ACH return handling mechanics (initiating returns) and general product docs, but nothing addresses who bears financial liability for ACH return fraud, card disputes, or account takeover losses, nor any documented liability split alongside fraud prevention tooling.

   ⚑ flag

Program scaling

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

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

   Treasury Prime—none0/10

   The evidence covers API onboarding, KYC, account opening, ACH/wire/book transfers, and statements, but nothing addresses program-level transaction/volume limits, approval stages, or a documented process for raising limits as growth occurs.

   ⚑ flag

Ach

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

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

   Treasury Prime~partialclaimed5/10

   Docs confirm ACH credits and debits (push/pull) and returns handled via an 'Update an ACH endpoint' pattern suggesting first-class transfer objects, but there's no evidence of same-day ACH windows, NOC (notification of change) handling, reversals, or webhook events tied to ACH lifecycle changes. missing for 10: same-day ACH window support, NOC objects/webhooks, reversal handling, explicit webhook event documentation for ACH status changes.

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

   proof ↗⚑ flag

Checks

1. ops userChecks still work — programmatic check issuance and check deposit with image capture, because real businesses still receive and send paper

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

   Treasury Prime—none0/10

   The evidence pack covers ACH, wire, FedNow, book transfers, cash deposits, and account statements, but contains no mention of check issuance or check deposit/RDC (remote deposit capture with image capture) anywhere in the docs.

   ⚑ flag

Instant rails

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

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

   Treasury Prime~partialclaimed6/10

   Docs confirm wire transfer status tracking and FedNow instant settlement (24/7/365) through the API, and ACH/book transfer rails are documented, suggesting multi-rail origination exists. However, there's no explicit mention of RTP (Real-Time Payments) origination/receipt, no clear per-rail capability comparison table, and no confirmation of wire/FedNow receipt (only origination-side details are shown). missing for 10: explicit RTP documentation, per-rail capability matrix, wire/FedNow receipt confirmation, and independent corroboration beyond vendor docs.

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

   proof ↗⚑ flag

International

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

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

   Treasury Prime—none0/10

   Evidence covers only US-domestic rails (ACH, domestic wires, FedNow, book transfers, cash deposits); there is no mention of international wires/SWIFT, FX rates, or a currency/corridor coverage map.

   ⚑ flag

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

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

   Treasury Prime~partialprobed6/10

   Treasury Prime's docs show broad API coverage across core banking workflows (account opening, KYC, ACH, wires, book transfers, statements, cash deposits), consistent with an API-first BaaS platform, but there is no explicit claim of full UI/API feature parity and the OpenAPI/swagger spec could not be located (404s), making it hard to verify completeness. missing for 10: explicit parity statement, discoverable OpenAPI spec, independent confirmation that dashboard-only actions (e.g. admin/dashboard configuration) are also API-exposed.

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

   proof ↗⚑ flag

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

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

   Treasury Prime—none0/10

   Treasury Prime is a banking-as-a-service API; there is no evidence of a data export/portability feature for account or transaction data in open formats, nor any documented account-closure/data-export process. This is a fair axis for a data-holding platform, but nothing in the evidence shows such capability.

   ⚑ flag

Charter clarity

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

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

   Treasury Prime—none0/10

   None of the evidence addresses which bank holds the charter, how Treasury Prime's middleware role relates to a named sponsor bank, or what happens to end customers if Treasury Prime fails — the docs only cover API mechanics (KYC, ACH, wires, account opening) with no sponsor-bank disclosure or failure/continuity language.

   ⚑ flag

Compliance tooling

1. ops userThe compliance workload is tooled — transaction monitoring, sanctions screening, case management for alerts, and SAR-filing support with a clear split of duties between me, the platform, and the bank

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

   Treasury Prime—none0/10

   Evidence only covers KYC/KYB during account opening; there is no mention of transaction monitoring, sanctions screening, alert case management, or SAR-filing support, nor any description of duty splits between ops/platform/bank for these compliance functions.

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

   proof ↗⚑ flag

Reconciliation

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

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

   Treasury Prime—none0/10

   The evidence pack covers account opening, KYC, ACH/wire/book transfers, and statements, but there is no mention of ledger-to-bank-core reconciliation, daily reconciliation reports, or any process for verifying API-reported balances against actual bank holdings — the exact failure mode referenced in the story. Nothing in the docs addresses reconciliation guarantees or audit processes for sponsor-bank programs.

   ⚑ flag