Stripe Treasury vs Increase

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

   Increase✓fullcommunity7/10

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

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

   proof ↗⚑ flag

Fbo structures

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

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

   Increase~partialcommunity5/10

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

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

   proof ↗⚑ flag

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

   Increase~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

   Increase—none0/10

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

   ⚑ flag

Agent access

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

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

   Increase✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

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

   Increase~partialprobed5/10

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

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

   proof ↗⚑ flag

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

   Increase—none0/10

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

   ⚑ flag

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

   Increase~partialprobed5/10

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

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

   proof ↗⚑ flag

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

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

   Increase✓fullprobed9/10

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

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

   proof ↗⚑ flag

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

   Increase—none0/10

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

   ⚑ flag

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

   Increase—none0/10

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

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

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

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

   Increase✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Agentic features

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

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

   Increase~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

   Increase—none0/10

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

   ⚑ flag

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

   Increase—none0/10

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

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

   proof ↗⚑ flag

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

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

   Increase✓fullprobed9/10

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

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

   proof ↗⚑ flag

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

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

   Increase✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

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

   Increase—none0/10

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

   ⚑ flag

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

   Increase—none0/10

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

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

   proof ↗⚑ flag

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

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

   Increase~partialclaimed4/10

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

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

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   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

   Increase—none0/10

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

   ⚑ flag

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

   Increase—none0/10

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

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

   proof ↗⚑ flag

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

   Increase~partialprobed6/10

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

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

   proof ↗⚑ flag

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

   Increase—none0/10

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

   ⚑ flag

Card issuance

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

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

   Increase~partialprobed4/10

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

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

   proof ↗⚑ flag

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

   Increase—none0/10

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

   ⚑ flag

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

   Increase~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

   Increase~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

   Increase—none0/10

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

   ⚑ flag

Kyc kyb

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

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

   Increase~partialclaimed3/10

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

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

   proof ↗⚑ flag

Review queues

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

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

   Increase—none0/10

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

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

   proof ↗⚑ flag

Limits holds

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

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

   Increase~partialclaimed4/10

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

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

   proof ↗⚑ flag

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

   Increase—none0/10

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

   ⚑ flag

Program scaling

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

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

   Increase~partialclaimed3/10

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

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

   proof ↗⚑ flag

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

   Increase~partialclaimed4/10

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

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

   proof ↗⚑ flag

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

   Increase~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

   Increase✓fullcommunity8/10

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

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

   proof ↗⚑ flag

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

   Increase—none0/10

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

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

   proof ↗⚑ flag

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

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

   Increase✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

   Increase—none0/10

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

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

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   Stripe Treasury—none0/10

   No evidence in the pack addresses data residency, regional data storage choices, or geographic control over where customer/financial data is stored; documentation focuses on financial account features, money movement, and Connect integration rather than data-location controls.

   ⚑ flag

   Increase—none0/10

   Increase is a banking/payments API; the evidence pack contains no mention of data residency/region selection controls for stored data. Missing for 10: any documentation of regional data storage options, residency guarantees, or geographic controls over where account/customer data is held.

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Stripe Treasury—none0/10

   No evidence in the pack addresses data retention policies, deletion controls, or privacy/data-lifecycle management for Stripe Treasury; the documentation focuses on financial account features, money movement, and platform integration, not data governance controls for AI-native users.

   ⚑ flag

   Increase—none0/10

   The evidence pack covers Increase's banking/payments API features (transfers, webhooks, sandbox, compliance validations) but contains no mention of data retention policies, data deletion controls, or any privacy-posture controls for customers to manage their own data lifecycle. As a platform handling sensitive financial and entity data, this axis is a fair question, but no evidence shows Increase offers retention/deletion controls.

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

   Increase~partialcommunity5/10

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

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

   proof ↗⚑ flag

Compliance tooling

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

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

   Increase~partialclaimed3/10

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

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

   proof ↗⚑ flag

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

   Increase—none0/10

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

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

   proof ↗⚑ flag