Stripe Treasury 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 Synctera
   Stripe Treasury~partialclaimed4/10

   Docs confirm financial accounts can be created and funded via API (money_manager configuration, OutboundPayments, Connect flows), but the evidence pack never states that these accounts are FDIC-insured deposit accounts, nor does it mention any sandbox/test-mode parity for the Treasury account-opening flow. missing for 10: explicit FDIC/insurance documentation, sandbox-vs-production parity evidence, full automated 'application to active account' onboarding details.

   • [claimed-docs] “A financial account can hold fiat balances such as USD, EUR, and GBP, and eligible businesses can also hold a stablecoin balance in USDC.”
   • [claimed-docs] “Create financial accounts that can hold funds (`money_manager` configuration)”
   • [claimed-docs] “As the platform, you can move money from your payments [Balance] to your financial accounts or from your connected accounts’ payments balanc…”
   • [claimed-docs] “There are no monthly fees or minimum balance requirements to open or maintain a financial account.”

   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 drawn
   Stripe Treasury—none0/10

   The evidence covers general Treasury features (balances, funding flows, disclosures) but contains no documentation addressing FBO pooling vs individual account structure, where FDIC insurance attaches, or who has ledger visibility — the specific transparency the finance lead is asking about is absent.

   ⚑ 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 Stripe Treasury
   Stripe Treasury~partialclaimed5/10

   Docs confirm Stripe Treasury lets platforms create per-connected-account financial accounts (money_manager configuration) that can hold funds, move money, and be used for reconciliation via transactions/activity feeds — supporting sub-account and per-customer account provisioning at scale. However, the evidence never explicitly confirms that each financial account gets unique account and routing numbers, nor details on bulk/programmatic issuance mechanics beyond account creation. Missing for 10: explicit documentation of unique account/routing number assignment per financial account, and evidence of scale/bulk provisioning workflows or API rate/volume specifics.

   • [claimed-docs] “Create financial accounts that can hold funds (`money_manager` configuration)”
   • [claimed-docs] “As the platform, you can move money from your payments [Balance] to your financial accounts or from your connected accounts’ payments balanc…”
   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”
   • [claimed-docs] “allows Connect platforms to offer financial services, such as funds separation and storage, bill pay, and cash flow management, to eligible …”

   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 drawn
   Stripe Treasury—none0/10

   The evidence pack describes Treasury's account-holding, fund-movement, disclosure, and fraud-control features but contains no mention of interest-bearing balances, sweep programs, yield rates, or how any spread is split between Stripe/partner banks and the customer. Since financial-account products could plausibly offer this, the axis applies, but there is no evidence it delivers it.

   • [claimed-docs] “A financial account can hold fiat balances such as USD, EUR, and GBP, and eligible businesses can also hold a stablecoin balance in USDC.”
   • [claimed-docs] “There are no monthly fees or minimum balance requirements to open or maintain a financial account.”
   • [claimed-docs] “As the platform, you can move money from your payments [Balance] to your financial accounts or from your connected accounts’ payments balanc…”

   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 to Synctera
   Stripe Treasury✓fullprobed8/10

   Stripe's shared docs platform confirms llms.txt exists at docs.stripe.com/llms.txt (HTTP 200) and per-page markdown versions (e.g., treasury.md) are served for agent consumption, which covers Treasury docs. Missing for 10: Treasury-specific llms.txt content (rather than site-wide) and independent confirmation an agent has successfully used it.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stripe.com/llms.txt # Stripe Documentation When installing Stripe packages, always check the npm r…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/treasury.md # Treasury Learn how to securely manage money with a financial account. Loo…”

   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 Synctera
   Stripe Treasury~partialprobed3/10

   Treasury is exposed as a set of API objects (financial accounts, OutboundPayments, transactions) that can in principle be scripted/automated, and Stripe provides an official CLI, implying headless/API-driven usage is possible. However there is no evidence specifically addressing running Treasury in CI pipelines or headless automation workflows. missing for 10: explicit CI/automation documentation, examples of scripted/headless Treasury operations, evidence of CLI use for Treasury objects specifically.

   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”
   • [claimed-docs] “OutboundPayment objects represent push-based transfers from: A platform’s financial accounts to a financial account owned by connected accou…”
   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”

   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 to Stripe Treasury
   Stripe Treasury✓fullprobed6/10

   Stripe documents an official MCP server at docs.stripe.com/mcp, which spans Stripe's platform including Treasury APIs, though Treasury-specific MCP tooling isn't separately detailed. Missing for 10: Treasury-specific MCP tool examples, independent/hands-on confirmation of MCP server usage with Treasury endpoints.

   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   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 to Stripe Treasury
   Stripe Treasury✓fullprobed7/10

   Stripe documents an official CLI at docs.stripe.com/stripe-cli, which applies platform-wide including Treasury's API. missing for 10: Treasury-specific CLI examples/workflows and independent hands-on confirmation of CLI usage with Treasury endpoints.

   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”

   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 drawn
   Stripe Treasury✓fullprobed8/10

   Stripe Treasury is accessed entirely through Stripe's documented REST API (financial accounts, OutboundPayments, transactions, received debits, etc.), with machine-readable docs (.md endpoints, llms.txt) and an official CLI, indicating a mature, documented public API surface suitable for AI-native/agentic consumption. Missing for 10: no discoverable OpenAPI/swagger spec was found (404s), and no independent hands-on developer report specifically validating AI-driven API usage.

   • [claimed-docs] “Create financial accounts that can hold funds (`money_manager` configuration)”
   • [claimed-docs] “OutboundPayment objects represent push-based transfers from: A platform’s financial accounts to a financial account owned by connected accou…”
   • [claimed-docs] “You can authorize third parties to debit funds from a financial account.”
   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stripe.com/llms.txt # Stripe Documentation When installing Stripe packages, always check the npm r…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/treasury.md # Treasury Learn how to securely manage money with a financial account. Loo…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”

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

   The evidence pack contains no mention of scoped or restricted API keys, OAuth scopes, or any mechanism for issuing least-privilege credentials for agents within Stripe Treasury's documentation or community discussion. While such a capability is plausible for an API-driven financial product, nothing in the provided evidence demonstrates it.

   ⚑ 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 Stripe Treasury
   Stripe Treasury~partialprobed3/10

   The evidence pack only hints at an SDK ecosystem via a stray note about checking npm registry for 'Stripe packages' (stripe-treasury-probe-1); there is no dedicated documentation of official SDKs, language coverage, or Treasury-specific SDK usage. Missing for 10: explicit official SDK docs (e.g., stripe-node, stripe-python), Treasury-specific SDK code samples, and independent corroboration of SDK quality/coverage.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stripe.com/llms.txt # Stripe Documentation When installing Stripe packages, always check the npm r…”

   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 to Synctera
   Stripe Treasury—none0/10

   The evidence pack describes Treasury's financial-account features, money movement, and transaction tracking but never mentions webhooks, event objects, or event subscription mechanisms for Treasury activity. missing for 10: any documentation of Treasury-specific webhook events, event types (e.g., financial_account.updated, treasury.*), or subscription setup instructions.

   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”
   • [claimed-docs] “Stripe runs automatic risk controls that help reduce your fraud exposure within Treasury and Issuing without requiring action to enable.”

   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 userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round drawn
   Stripe Treasury—none0/10

   Evidence covers Treasury's banking-as-a-service features (financial accounts, payments, disclosures, fraud controls) but nothing about AI-generated insights or suggestions surfaced from user data within the product. missing for 10: any mention of AI/ML-driven analytics, insight generation, or in-product suggestions from financial data.

   ⚑ flag

   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

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

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

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

   weight 2 · round to Stripe Treasury
   Stripe Treasury~partialprobed4/10

   The only agenticness-relevant evidence is a probe confirming Stripe hosts an official MCP server (docs.stripe.com/mcp), which could in principle let an AI agent issue natural-language-driven commands against Stripe APIs, but no evidence ties this specifically to Treasury operations (financial accounts, OutboundPayments, etc.) or shows a working example of natural-language control of Treasury features. Missing for 10: Treasury-specific MCP tool coverage, documented natural-language examples/use cases, and independent confirmation that Treasury actions can be driven conversationally.

   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   proof ↗⚑ 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 drawn
   Stripe Treasury—none0/10

   The evidence pack includes general Treasury docs, llms.txt/docs-md probes, and CLI/MCP mentions, but nothing describes an interactive API reference with runnable/executable code examples for Treasury endpoints. The openapi.json probe even returned 404, suggesting no discoverable spec-driven reference was found in this pack.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/treasury.md # Treasury Learn how to securely manage money with a financial account. Loo…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stripe.com/llms.txt # Stripe Documentation When installing Stripe packages, always check the npm r…”

   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 to Synctera
   Stripe Treasury—none0/10

   The evidence pack explicitly probes for an OpenAPI/Swagger spec at all standard locations and finds only 404s, and no other evidence pack item links to a downloadable machine-readable API spec for Treasury; the docs offer markdown/llms.txt versions but not a formal OpenAPI schema.

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

   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 Synctera
   Stripe Treasury—none0/10

   Stripe generally offers test-mode/sandbox environments across its API, but no evidence in this pack specifically documents a Treasury sandbox or test-mode capability that isolates test data from production for financial account testing. Missing for 10: any documentation of Treasury-specific test mode, sandbox API keys, or test financial accounts.

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

   No evidence pack items mention API versioning schemes or a documented deprecation policy for Stripe Treasury's APIs; docs cover product features, and probes find no OpenAPI spec, changelog, or version policy reference.

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

   The evidence pack describes individual Treasury operations (fund accounts, outbound payments, received debits, transactions) but contains no mention of batch/bulk endpoints or multi-item operations for AI-native or programmatic bulk processing.

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

   The evidence pack covers financial-account creation, fund movement, transactions, and fraud controls, but nowhere describes a rules engine or event-triggered automation (e.g., 'if X happens, do Y automatically') configurable by users; automatic risk controls are pre-set by Stripe, not user-defined rules. Missing for 10: any documentation of user-defined conditional rules/triggers, an automation/rules API or webhook-based rule builder, or evidence of event-driven action configuration.

   • [claimed-docs] “Stripe runs automatic risk controls that help reduce your fraud exposure within Treasury and Issuing without requiring action to enable.”
   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”

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

   The evidence pack documents Treasury's financial-account, Connect, and OutboundPayment features and even an MCP server listing, but nothing describes scoped credentials for agents with amount caps or counterparty allowlists, nor any vendor-named 'agent banking' use case. missing for 10: documentation of agent-scoped API keys/permissions, amount-cap enforcement, counterparty allowlist controls, and an explicit vendor-named agentic banking use case.

   • [claimed-docs] “OutboundPayment objects represent push-based transfers from: A platform’s financial accounts to a financial account owned by connected accou…”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   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 drawn
   Stripe Treasury~partialprobed6/10

   Stripe Treasury exposes a documented API for financial accounts, transactions, outbound/inbound payments, and received debits (docs-2,7,10,11,13), and Stripe has an official MCP server (probe-4), giving agents programmatic access without dashboard scraping. However, no evidence covers document retrieval (e.g., statements) via API/MCP, and no OpenAPI spec was found (probe-3), and it's unclear the MCP surface specifically exposes Treasury endpoints. Missing for 10: explicit document/statement API coverage, confirmation that the MCP server exposes Treasury-specific resources, and independent hands-on confirmation of MCP usage for banking data.

   • [claimed-docs] “A financial account can hold fiat balances such as USD, EUR, and GBP, and eligible businesses can also hold a stablecoin balance in USDC.”
   • [claimed-docs] “Create financial accounts that can hold funds (`money_manager` configuration)”
   • [claimed-docs] “OutboundPayment objects represent push-based transfers from: A platform’s financial accounts to a financial account owned by connected accou…”
   • [claimed-docs] “You can authorize third parties to debit funds from a financial account.”
   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”

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

   No evidence in the pack describes built-in AI features for banking operations—no natural-language transaction search, no drafted dispute/alert responses, no anomaly summaries. The documentation only covers financial account management, connect integrations, fraud risk controls (automatic, non-AI-described), and money movement, none of which mention AI/LLM-based ops tooling. Missing for 10: any mention of natural-language search, AI-drafted dispute responses, anomaly summaries, or any AI/ML-powered ops feature.

   • [claimed-docs] “Stripe runs automatic risk controls that help reduce your fraud exposure within Treasury and Issuing without requiring action to enable.”
   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”

   proof ↗⚑ 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 to Synctera
   Stripe Treasury~partialclaimed4/10

   Evidence confirms Stripe Issuing is integrated alongside Treasury (fraud controls cover 'Treasury and Issuing', and embedded UI can render 'bill pay, issuing, and cash rewards'), implying cards can be tied to Treasury financial accounts, but no documentation details virtual/physical card issuance flow, spend controls, or digital wallet support specifically for Treasury accounts. Missing for 10: explicit docs on issuing virtual/physical cards via API tied to a Treasury account, spend-control configuration, and digital wallet (Apple/Google Pay) provisioning details.

   • [claimed-docs] “Render Stripe financial account features such as bill pay, issuing, and cash rewards as a branded UI in your platform application while avoi…”
   • [claimed-docs] “Stripe runs automatic risk controls that help reduce your fraud exposure within Treasury and Issuing without requiring action to enable.”

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

   The evidence pack covers Treasury's account structure, connect integration, money movement, and fraud controls, but contains no mention of dispute handling, Reg E investigation timelines, provisional credit mechanics, or documented operational responsibilities for card/ACH disputes.

   ⚑ 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 Synctera
   Stripe Treasury~partialclaimed3/10

   Docs mention using 'transactions' to build account activity feeds and reconcile against internal systems, implying a transaction-log based ledger, but there is no explicit documentation of webhook events for transaction state changes or of balance reads that reflect holds/pending activity as described in the story. missing for 10: explicit webhook event types for Treasury transaction lifecycle, documentation of balance fields showing holds/pending vs settled amounts, and any independent/hands-on confirmation of real-time event delivery.

   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”

   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 drawn
   Stripe Treasury~partialclaimed3/10

   Docs mention that Treasury transactions can be used to build account activity feeds and reconcile against internal systems, implying transaction records exist, but there is no detail on counterparty data, rail-specific metadata, stable identifiers, or enrichment fields. missing for 10: documentation of transaction object schema (counterparty fields, rail metadata like ACH/wire trace numbers, stable IDs), examples of enrichment/categorization, independent developer corroboration of usability of raw feed data.

   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”

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

   No evidence in the pack mentions monthly statement generation or 1099-INT tax document production/retrieval via API for Treasury financial accounts; docs cover fund movement, disclosures, fraud controls, and connect features but 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
   Stripe Treasury—none0/10

   The evidence pack covers Treasury's account funding, money movement, disclosures, and fraud controls, but never mentions KYC/KYB flows, document collection, watchlist screening, or application state modeling for verifying individuals or businesses onboarding to Treasury. This is a fair axis for a banking product since Treasury requires verified connected accounts, but no supporting evidence exists here.

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

   The evidence pack covers financial account creation, money movement, disclosures, and fraud controls, but contains no mention of an onboarding queue, reasons for pending applications, document collection workflows, or a clear delineation between platform/ops decisions and the partner bank's decisions. This is a plausible axis for a banking-as-a-service product, but nothing in the docs or community evidence addresses it.

   ⚑ 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 drawn
   Stripe Treasury—none0/10

   The only relevant evidence describes Stripe's own automatic, built-in fraud/risk controls for Treasury and Issuing that 'do not require action to enable' — this is the opposite of what the story asks for (ops-configurable per-account/per-program transaction and velocity limits, manual holds, account freezes, and documented reinstatement paths). No documentation shows ops-facing controls for setting limits, freezing accounts, or reinstatement workflows. Missing for 10: any API/dashboard capability to set per-account transaction/velocity limits, manually place holds, freeze/unfreeze accounts, or documented reinstatement procedures.

   • [claimed-docs] “Stripe runs automatic risk controls that help reduce your fraud exposure within Treasury and Issuing without requiring action to enable.”

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

   Docs mention that Stripe runs automatic risk controls for fraud exposure within Treasury/Issuing, but there is no evidence documenting an explicit liability split for who bears ACH return fraud, card dispute losses, or account takeover losses. Missing for 10: explicit liability-split documentation for ACH return fraud, card disputes, and ATO losses; any first-party or independent confirmation of how losses are allocated between Stripe, the platform, and connected accounts.

   • [claimed-docs] “Stripe runs automatic risk controls that help reduce your fraud exposure within Treasury and Issuing without requiring action to enable.”

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

   No evidence in the pack documents program-level limits, approval stages, or a documented path to raising limits — docs cover account features, money movement, and disclosures but not risk/limit escalation processes. One HN comment even highlights the landing page 'doesn't really explain' the underlying constraints, and another surfaces surprise breach notifications rather than transparent limit documentation, reinforcing the absence of documented escalation paths.

   • [community] “A commenter noted the Treasury landing page "doesn’t really explain what kinds of problems Treasury solves," and asked for clarity on target…”
   • [community] “HN thread reports that the Evolve Bank and Trust hack impacted both Mercury and Stripe Treasury customers; a user confirmed receiving a noti…”

   proof ↗⚑ 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 drawn
   Stripe Treasury—none0/10

   The evidence describes Treasury's general money-movement objects (OutboundPayment, ReceivedDebit, financial accounts, transactions) but never mentions ACH-specific mechanics like same-day windows, NOCs, or return/reversal objects with webhooks — the core of this story's ask is unaddressed.

   • [claimed-docs] “OutboundPayment objects represent push-based transfers from: A platform’s financial accounts to a financial account owned by connected accou…”
   • [claimed-docs] “You can authorize third parties to debit funds from a financial account.”
   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”

   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 to Synctera
   Stripe Treasury—none0/10

   No evidence pack items mention check issuance, check deposit, or image capture capabilities within Stripe Treasury; documentation focuses on ACH, wires, card issuing, and internal transfers, not paper check handling.

   ⚑ 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 Synctera
   Stripe Treasury—none0/10

   The evidence pack never mentions domestic wires, RTP, or FedNow, nor any per-rail origination/receipt documentation—only generic OutboundPayment/ReceivedDebit constructs are described without rail specifics. missing for 10: any mention of wire, RTP, or FedNow rails, per-rail capability docs, and origination/receipt distinctions.

   • [claimed-docs] “OutboundPayment objects represent push-based transfers from: A platform’s financial accounts to a financial account owned by connected accou…”
   • [claimed-docs] “You can authorize third parties to debit funds from a financial account.”
   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”

   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 drawn
   Stripe Treasury—none0/10

   The evidence shows Treasury supports multi-currency balances (USD, EUR, GBP) and USDC, but there is no documentation of international wire/SWIFT transfers, FX rate transparency, or a coverage map of currencies/corridors. Missing for 10: cross-border wire/SWIFT transfer documentation, FX rate/spread transparency, and a documented list of supported currency corridors.

   • [claimed-docs] “A financial account can hold fiat balances such as USD, EUR, and GBP, and eligible businesses can also hold a stablecoin balance in USDC.”

   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 drawn
   Stripe Treasury~partialclaimed6/10

   Treasury is fundamentally API-first: financial accounts, OutboundPayments, ReceivedDebits, transactions, and disclosures are all API objects, and the Dashboard/mobile app view is described as just one access point built on top of these APIs (docs-4, docs-9, docs-10, docs-13). Platforms can even render Stripe-hosted UI components (bill pay, issuing) driven entirely by the API (docs-8), suggesting strong API/UI parity, but no evidence explicitly confirms every Dashboard action (e.g., manual account configuration, dispute handling, fraud review tools) has a corresponding API endpoint. missing for 10: explicit documentation enumerating full UI-to-API parity, independent confirmation that dashboard-only features (e.g., risk controls in docs-14) are also API-exposed.

   • [claimed-docs] “you can access your financial account on the Treasury page in the Stripe Dashboard or from the Dashboard mobile app”
   • [claimed-docs] “Render Stripe financial account features such as bill pay, issuing, and cash rewards as a branded UI in your platform application while avoi…”
   • [claimed-docs] “As the platform, you can move money from your payments [Balance] to your financial accounts or from your connected accounts’ payments balanc…”
   • [claimed-docs] “OutboundPayment objects represent push-based transfers from: A platform’s financial accounts to a financial account owned by connected accou…”
   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”
   • [claimed-docs] “Stripe runs automatic risk controls that help reduce your fraud exposure within Treasury and Issuing without requiring action to enable.”

   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 drawn
   Stripe Treasury—none0/10

   No evidence of any data export, data portability tools, or open-format export functionality for Stripe Treasury; docs cover money movement, financial accounts, and compliance but nothing about exporting account/transaction data in open formats or an account-closure export path.

   ⚑ 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 drawn
   Stripe Treasury~partialcommunity4/10

   Stripe documents a mandatory 'Treasury disclosure component' for compliance transparency (docs-12) and community discussion confirms partner-bank relationships (e.g., Goldman Sachs) exist and are scrutinized (comm-6), and the Evolve Bank breach thread shows real customer impact when a partner bank had problems (comm-1). However, there is no first-party documentation naming the specific sponsor bank(s), explaining FDIC pass-through insurance mechanics, or detailing what happens to end-customer funds if the platform or partner bank fails. missing for 10: explicit documentation of the sponsor-bank identity/relationship, FDIC insurance pass-through terms, and a documented failure/wind-down process for customer funds.

   • [claimed-docs] “You can embed the Treasury disclosure component directly on your website to automatically display currently compliant disclosure information…”
   • [community] “A user questioned the optics of Stripe Treasury's bank partnerships: "Partnering with companies such as Goldman Sachs is typically not a goo…”
   • [community] “HN thread reports that the Evolve Bank and Trust hack impacted both Mercury and Stripe Treasury customers; a user confirmed receiving a noti…”

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

   Evidence covers automatic fraud/risk controls and disclosure requirements, but there is no mention of transaction monitoring workflows, sanctions/OFAC screening tooling, case management for compliance alerts, or SAR-filing support with defined ops/platform/bank duties. missing for 10: transaction monitoring, sanctions screening, alert case management, SAR-filing support/duty split.

   • [claimed-docs] “Stripe runs automatic risk controls that help reduce your fraud exposure within Treasury and Issuing without requiring action to enable.”
   • [claimed-docs] “You can embed the Treasury disclosure component directly on your website to automatically display currently compliant disclosure information…”

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

   Evidence only shows Stripe Treasury lets platforms reconcile their own internal systems against Treasury's transaction feed (docs-13), not documented evidence that Stripe's ledger itself reconciles daily against the underlying partner bank's core records — the exact failure mode that broke Synapse-era programs. No first-party or independent evidence describes a bank-to-API reconciliation process, audit, or guarantee.

   • [claimed-docs] “Use transactions to build account activity feeds, reconcile against your internal systems, and track money movement through your platform.”

   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