Plaid vs Teller

Hosted flows

1. developerLet a user connect their bank with a drop-in hosted flow — create a session server-side, open the widget, and get back a token for the connected account — without building institution UI myself

   weight 3 · round to Plaid
   Plaid✓fullclaimed8/10

   Plaid Link is explicitly documented as the client-side hosted widget that lets users connect their bank without the developer building institution UI, paired with server-side session/token creation (public_token/access_token flow) shown in SDKs and Sandbox docs. missing for 10: no independent/hands-on developer report confirming the end-to-end token exchange experience, and no explicit token-exchange code snippet in this pack (only Sandbox/public_token creation and general Link description).

   • [claimed-docs] “Plaid Link is the client-side component that your users will interact with in order to link their accounts to Plaid and allow you to access …”
   • [claimed-docs] “You can customize parts of Link's flow straight from the Dashboard. You can preview your changes in real time and then publish them instantl…”
   • [claimed-docs] “you can also create Items in Sandbox via the API, using a special Sandbox-only endpoint, /sandbox/public_token/create. This endpoint allows …”
   • [claimed-docs] “The Plaid Sandbox is a free and fully-featured environment for application development and testing. All Plaid functionality of both the Plai…”
   • [claimed-docs] “Let's test out running Plaid locally by cloning the Quickstart app. You'll need API keys, which you can receive by signing up in the Dashboa…”
   • [github] “try { await plaidClient.transactionsSync(request); } catch (error) { const err = error.response.data; }”

   proof ↗⚑ flag

   Teller~partialclaimed6/10

   Teller has a documented Connect widget (React SDK, teller-connect-react) and quickstart flow that lets users link accounts, plus a sandbox environment for testing enrollments and OTP flows, matching the drop-in hosted-flow story. However, evidence lacks explicit detail on server-side session creation and the exact token exchange flow, and no independent hands-on account of the widget UX beyond first-party docs. missing for 10: explicit session-creation API docs, independent/hands-on verification of the widget flow, and detail on token retrieval mechanics.

   • [claimed-docs] “Learn about Teller Connect and how to integrate and customize it for you application.”
   • [claimed-docs] “finish up by linking your first financial accounts to Teller.”
   • [github] “React hook and component for integrating with Teller Connect”
   • [claimed-docs] “`otp` () - Will follow an OTP MFA flow whereby the user will be asked to select a contact to send an OTP code. The correct code is `0000`”
   • [claimed-docs] “The sandbox environment uses simulated data and never connects to real financial institutions.”
   • [claimed-docs] “Connect instantly with more than 7,000 financial institutions and fall back to same-day ACH microdeposit verification for everyone else.”

   proof ↗⚑ flag

Oauth

1. developerConnections to major institutions use bank-hosted OAuth rather than screen-scraped credentials — the platform documents its OAuth coverage and how legacy credential flows are being retired

   weight 2 · round drawn
   Plaid—none0/10

   The evidence pack contains no Plaid documentation describing OAuth coverage for institutions or a plan to retire legacy credential/screen-scraping flows; docs only describe Auth/Balance/Identity/Transactions products generically. Community evidence in fact describes Plaid using screen-scraped credentials and even mimicking bank login pages, reinforcing the absence of documented OAuth-first coverage.

   • [community] “Plaid is terrible! Both Wells Fargo and Bank of America support API integration, but Plaid chooses to screen-scrape and does not work if you…”
   • [community] “Slightly off topic... Privacy virtual card use Plaid... The integration was extremely questionable. They were faking the bank's login page. …”
   • [community] “Teller does not use screen scraping. They reverse engineer each bank's mobile APIs — contrasted favorably against Plaid's approach in discus…”
   • [claimed-docs] “Plaid Link is the client-side component that your users will interact with in order to link their accounts to Plaid and allow you to access …”

   proof ↗⚑ flag

   Teller—none0/10

   Teller's docs describe connecting via 'Verify Account Details via Microdeposit' and general account-linking language, but nowhere document OAuth coverage of major institutions or a retirement plan for legacy credential-based flows. Community evidence actually points the other way — the founder compares Teller's terms to 'incumbent screen-scrapers in the market, e.g. Yodlee and Plaid,' and users note banks disclaim liability 'if you give your online banking credentials to a third party,' indicating credential-based (not bank-hosted OAuth) connections were in use historically.

   • [community] “Founder response: 'FWIW it is not currently possible for users to move money with Teller... Our terms are comparable to the incumbent screen…”
   • [community] “UK banks don't accept any liability if you give your online banking credentials to a third party. If some fraud was to come about as a resul…”
   • [claimed-docs] “To access account details from these institutions, you can implement the 'Verify Account Details via Microdeposit' flow.”
   • [claimed-docs] “Connect instantly with more than 7,000 financial institutions and fall back to same-day ACH microdeposit verification for everyone else.”

   proof ↗⚑ flag

Repair

1. ops leadBroken connections are repairable — expired or revoked links surface as documented statuses, and users can re-authenticate in an update flow without starting over

   weight 2 · round to Plaid
   Plaid~partialclaimed3/10

   Plaid's webhook docs mention that webhooks inform developers about 'changes to Plaid Items or the status of asynchronous processes' (plaid-docs-8), which touches on connection status changes, and Link (plaid-docs-5, plaid-docs-11) is the client-side re-linking component. However, the evidence pack never explicitly documents the specific re-authentication 'update mode' flow, named error statuses like ITEM_LOGIN_REQUIRED, or confirmation that re-auth avoids re-onboarding from scratch. Missing for 10: explicit documentation of update-mode Link flow, named broken-connection status codes/webhooks, and confirmation users don't restart the full linking process.

   • [claimed-docs] “Plaid sends webhooks to programmatically inform you about changes to Plaid Items or the status of asynchronous processes.”
   • [claimed-docs] “Plaid Link is the client-side component that your users will interact with in order to link their accounts to Plaid and allow you to access …”
   • [claimed-docs] “You can customize parts of Link's flow straight from the Dashboard. You can preview your changes in real time and then publish them instantl…”

   proof ↗⚑ flag

   Teller—none0/10

   The evidence covers enrollment webhooks, MFA/OTP sandbox flows, and microdeposit verification, but nowhere documents a specific 'broken connection' status taxonomy or a re-authentication/update flow for expired or revoked links. Webhook docs mention 'changes in user enrollments' generically but don't detail reconnect/repair UX.

   • [claimed-docs] “To register a new webhook, you need to have a URL in your app that Teller can call. You can configure a new webhook from the Teller Dashboar…”
   • [claimed-docs] “Teller sends webhook events when specific conditions or changes are detected in user enrollments or their financial data.”
   • [claimed-docs] “`otp` () - Will follow an OTP MFA flow whereby the user will be asked to select a contact to send an OTP code. The correct code is `0000`”

   proof ↗⚑ flag

Agent access

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

   weight 2 · round to Plaid
   Plaid~partialprobed6/10

   Plaid has a live llms.txt at plaid.com/llms.txt (HTTP 200) confirming basic agent-oriented discovery, but the content is minimal (a short description, not a full doc index), the /docs/.md and openapi.json probes 404 rather than exposing machine-readable docs, and there's no independent corroboration of agents actually consuming these successfully. missing for 10: richer llms.txt content indexing full doc set, working markdown/OpenAPI endpoints, independent/hands-on evidence of an agent successfully using these to navigate docs.

   • [probe] “PROBE llms.txt: HTTP 200 at https://plaid.com/llms.txt # Plaid > Plaid helps all companies build fintech solutions by making it easy, safe …”
   • [probe] “PROBE docs-md: HTTP 404 at https://plaid.com/docs/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://plaid.com/openapi.json, https://plaid.com/swagger.json, https://plaid.com/api/openapi.json, …”

   proof ↗⚑ flag

   Teller—none0/10

   Probes directly show no llms.txt, no docs.md, and no OpenAPI file at expected locations (all 404), and no evidence of any agent-oriented documentation format elsewhere in the pack.

   • [probe] “PROBE llms.txt: HTTP 404 at https://teller.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://teller.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://teller.io/openapi.json, https://teller.io/swagger.json, https://teller.io/api/openapi.json, …”

   proof ↗⚑ flag

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

   weight 2 · round to Plaid
   Plaid~partialclaimed6/10

   Plaid's Sandbox exposes a special API endpoint (/sandbox/public_token/create) that lets developers generate test Items and public tokens purely via API calls, without any UI, which supports scripted/headless testing suitable for CI (plaid-docs-14, plaid-docs-13). The Node SDK further demonstrates programmatic, promise-based server-side calls (plaid-gh-1, plaid-gh-2) that can run in automated pipelines. However, real (non-sandbox) account linking still requires the client-side Plaid Link UI component, so full production automation isn't headless, and no explicit CI/automation documentation or examples are provided. missing for 10: explicit CI/headless automation guide, confirmation that production flows can bypass Link UI, independent evidence of running Plaid in automated pipelines.

   • [claimed-docs] “you can also create Items in Sandbox via the API, using a special Sandbox-only endpoint, /sandbox/public_token/create. This endpoint allows …”
   • [claimed-docs] “The Plaid Sandbox is a free and fully-featured environment for application development and testing. All Plaid functionality of both the Plai…”
   • [github] “try { await plaidClient.transactionsSync(request); } catch (error) { const err = error.response.data; }”
   • [github] “All errors can now be caught using try/catch with async/await or through promise chaining.”
   • [claimed-docs] “Let's test out running Plaid locally by cloning the Quickstart app. You'll need API keys, which you can receive by signing up in the Dashboa…”

   proof ↗⚑ flag

   Teller~partialcommunity5/10

   Teller is an API-first product (mTLS-authenticated REST API with a sandbox environment) that is inherently callable headlessly from scripts, and a community example shows a script consuming the API to export data. However there is no explicit documentation of CI integration, a CLI, or automation-specific guidance/examples for headless pipelines. Missing for 10: explicit CI/CD documentation, CLI or SDK examples for automated pipelines, and any first-party guidance on non-interactive/headless usage patterns.

   • [claimed-docs] “The Teller API uses mTLS to authenticate the API caller. Teller issues client certificates that you use to connect to the Teller API.”
   • [claimed-docs] “The sandbox environment uses simulated data and never connects to real financial institutions.”
   • [claimed-docs] “`otp` () - Will follow an OTP MFA flow whereby the user will be asked to select a contact to send an OTP code. The correct code is `0000`”
   • [community] “I built a little script to export my accounts to CSV/QIF. Super easy to use API! https://github.com/scottrobertson/teller-export”

   proof ↗⚑ flag

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

   weight 3 · round to Plaid
   Plaid~partialprobed7/10

   Plaid documents an official 'Dashboard MCP server' hosted by Plaid providing Production diagnostics and analytics tools (debugging Items, Link conversion data, usage metrics), confirmed by both docs and a probe hit. However, this MCP server is scoped only to dashboard/analytics functions rather than full API/product access (Auth, Transactions, Identity, etc.), so an agent cannot use it to perform general Plaid operations via MCP. Missing for 10: MCP coverage of core Plaid API functionality (Auth, Transactions, Payments) and independent/community corroboration of real-world MCP usage.

   • [claimed-docs] “The Dashboard MCP server is a remote MCP server hosted by Plaid. It provides Production diagnostics and analytics tools, including tools for…”
   • [probe] “official MCP server documented at https://plaid.com/docs/resources/mcp/”

   proof ↗⚑ flag

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

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Plaid—none0/10

   Evidence shows Plaid SDKs (e.g., plaid-node), Quickstart apps, and a hosted MCP server, but no mention anywhere of an official CLI tool for interacting with Plaid's API or dashboard.

   ⚑ flag

   Teller—none0/10

   No evidence of an official CLI for Teller; only a REST API, SDKs, and a React connect component are documented, and probes for llms.txt/openapi/docs.md all 404. Missing for 10: any mention of a CLI tool, package, or command-line workflow for AI-native/agentic use.

   • [probe] “PROBE llms.txt: HTTP 404 at https://teller.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://teller.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://teller.io/openapi.json, https://teller.io/swagger.json, https://teller.io/api/openapi.json, …”
   • [github] “React hook and component for integrating with Teller Connect”

   proof ↗⚑ flag

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

   weight 3 · round to Plaid
   Plaid~partialprobed7/10

   Plaid provides extensive public API documentation (Auth, Balance, Identity, Transactions, Payment Initiation), SDKs (plaid-node), webhooks, and a Sandbox for programmatic testing, all of which let a developer (including an AI agent) drive the product via documented endpoints. However, there's no discoverable OpenAPI/Swagger spec (404s on all candidate paths) and no llms.txt-style machine-readable API map beyond a generic landing page, which limits pure agentic/machine-driven discovery. missing for 10: publicly discoverable OpenAPI/machine-readable spec, evidence of AI-agent-specific API tooling beyond the separate Dashboard MCP server.

   • [claimed-docs] “Auth allows you to request a user's checking, savings, or cash management account and routing number, making it easy for you to initiate cre…”
   • [claimed-docs] “Balance is Plaid's product for receiving real-time balance information. This data is commonly used to tell if an account has sufficient fund…”
   • [claimed-docs] “Plaid's Identity product helps you verify users' identities by accessing information on file with their financial institution.”
   • [claimed-docs] “Retrieve up to 24 months of transaction data and stay up-to-date with webhooks”
   • [claimed-docs] “The Plaid Sandbox is a free and fully-featured environment for application development and testing... you can create an unlimited number of …”
   • [claimed-docs] “Plaid sends webhooks to programmatically inform you about changes to Plaid Items or the status of asynchronous processes.”
   • [claimed-docs] “you can also create Items in Sandbox via the API, using a special Sandbox-only endpoint, /sandbox/public_token/create. This endpoint allows …”
   • [github] “try { await plaidClient.transactionsSync(request); } catch (error) { const err = error.response.data; }”
   • [github] “All errors can now be caught using try/catch with async/await or through promise chaining.”
   • [probe] “PROBE docs-md: HTTP 404 at https://plaid.com/docs/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://plaid.com/openapi.json, https://plaid.com/swagger.json, https://plaid.com/api/openapi.json, …”

   proof ↗⚑ flag

   Teller~partialprobed6/10

   Teller documents a full REST API (accounts, balances, transactions, identity, payments, webhooks, mTLS auth, pagination, idempotency) that a developer or agent can drive programmatically, and a community member confirms it as an 'easy to use API' for scripting exports. However, probes show no OpenAPI/Swagger spec or llms.txt/docs.md machine-readable format, which limits easy AI-native discovery/automation of the API surface. missing for 10: OpenAPI/Swagger spec, llms.txt or docs.md for agent-friendly discovery, broader independent evidence of agentic/automated API usage beyond one CSV-export script.

   • [claimed-docs] “The account balances API provides your application with live, real-time account balances.”
   • [claimed-docs] “The transactions API exposes the ledger transactions of a financial account.”
   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”
   • [claimed-docs] “The payments resource allows you to send payments to yourself or a 3rd party on behalf of the end-user from their account. Currently the onl…”
   • [claimed-docs] “The Teller API uses mTLS to authenticate the API caller. Teller issues client certificates that you use to connect to the Teller API.”
   • [claimed-docs] “This endpoint supports idempotent requests.”
   • [claimed-docs] “the transactions list endpoint supports pagination controls.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://teller.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://teller.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://teller.io/openapi.json, https://teller.io/swagger.json, https://teller.io/api/openapi.json, …”
   • [community] “I built a little script to export my accounts to CSV/QIF. Super easy to use API! https://github.com/scottrobertson/teller-export”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Plaid—none0/10

   Plaid's evidence covers products (Auth, Balance, Identity, Transactions), Sandbox testing, Link, and a read-only diagnostics MCP server, but nothing describes issuing scoped or least-privilege API credentials/tokens specifically for an agent or any granular permissioning model for AI-native use. Missing for 10: any documentation of scoped API keys, credential minimization, or agent-specific access tokens.

   • [claimed-docs] “The Dashboard MCP server is a remote MCP server hosted by Plaid. It provides Production diagnostics and analytics tools, including tools for…”
   • [claimed-docs] “Let's test out running Plaid locally by cloning the Quickstart app. You'll need API keys, which you can receive by signing up in the Dashboa…”
   • [claimed-docs] “The Plaid Sandbox is a free and fully-featured environment for application development and testing... you can create an unlimited number of …”

   proof ↗⚑ flag

   Teller—none0/10

   Teller's docs describe mTLS client-certificate authentication and per-enrollment user consent, but there is no evidence of any mechanism to mint scoped, least-privilege API credentials specifically for delegating access to an AI agent (e.g., granular permission scopes, agent-specific keys, or revocable sub-credentials). Missing for 10: any documentation of scoped/limited-permission credential issuance, agent-specific key management, or fine-grained access control beyond whole-enrollment consent.

   • [claimed-docs] “The Teller API uses mTLS to authenticate the API caller. Teller issues client certificates that you use to connect to the Teller API.”
   • [claimed-docs] “The Teller API uses mTLS to authenticate the API caller”
   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”
   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”
   • [claimed-docs] “**100 enrollment limit** — An enrollment represents one bank login, which may include multiple accounts”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Plaid
   Plaid~partialclaimed6/10

   Plaid ships an official Node.js SDK (plaid-node) with documented async/await error-handling patterns and a quickstart guide showing API-key based setup, which supports building integrations programmatically. However, the evidence pack only shows one language SDK, no explicit mention of other official SDKs (Python, Java, Go, etc.) or SDK features tailored to AI-native/agentic workflows, and no independent corroboration of SDK quality. missing for 10: evidence of multi-language official SDKs, AI-specific SDK tooling or agent integration guides, independent developer corroboration of SDK usability.

   • [github] “try { await plaidClient.transactionsSync(request); } catch (error) { const err = error.response.data; }”
   • [github] “All errors can now be caught using try/catch with async/await or through promise chaining.”
   • [claimed-docs] “Let's test out running Plaid locally by cloning the Quickstart app. You'll need API keys, which you can receive by signing up in the Dashboa…”

   proof ↗⚑ flag

   Teller~partialprobed5/10

   Teller provides an official REST API with documented endpoints and a first-party React SDK (teller-connect-react) for integrating Teller Connect, giving developers something concrete to build against. However, probes show no OpenAPI/swagger spec or llms.txt for machine-readable discovery, and there's no evidence of official SDKs beyond the single React component (e.g., no Python/Node/mobile SDKs), limiting AI-native tooling support. Missing for 10: multi-language official SDKs, machine-readable OpenAPI spec, llms.txt or other AI-agent-friendly documentation.

   • [github] “React hook and component for integrating with Teller Connect”
   • [claimed-docs] “Learn about Teller Connect and how to integrate and customize it for you application.”
   • [claimed-docs] “The Teller API uses mTLS to authenticate the API caller. Teller issues client certificates that you use to connect to the Teller API.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://teller.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://teller.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://teller.io/openapi.json, https://teller.io/swagger.json, https://teller.io/api/openapi.json, …”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Plaid✓fullclaimed7/10

   Plaid documents a first-class webhooks system that notifies subscribers of Item/product state changes (e.g., new transactions), which any AI-native integration could consume just like a human-built app. Missing for 10: independent/hands-on corroboration of webhook reliability and any agent-specific guidance for consuming webhooks programmatically.

   • [claimed-docs] “Plaid sends webhooks to programmatically inform you about changes to Plaid Items or the status of asynchronous processes.”
   • [claimed-docs] “Retrieve up to 24 months of transaction data and stay up-to-date with webhooks”

   proof ↗⚑ flag

   Teller✓fullclaimed7/10

   Teller documents a webhooks API where users register a URL to receive events for enrollment/data changes, configurable via the Dashboard, covering the core subscribe-to-events capability. missing for 10: no documented event type catalog/payload schema, no independent/hands-on confirmation of webhook reliability, and no AI-agent-specific integration pattern beyond generic docs.

   • [claimed-docs] “To register a new webhook, you need to have a URL in your app that Teller can call. You can configure a new webhook from the Teller Dashboar…”
   • [claimed-docs] “Teller sends webhook events when specific conditions or changes are detected in user enrollments or their financial data.”

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round drawn
   Plaid—none0/10

   No evidence that Plaid generates AI-driven insights or suggestions from a user's financial data; the closest item (Dashboard MCP server) only exposes diagnostics/analytics tools for developers, not AI-generated insights delivered to end users. Missing for 10: any AI/ML insight-generation feature, natural-language summarization of transactions/balances, or user-facing recommendation engine.

   • [claimed-docs] “The Dashboard MCP server is a remote MCP server hosted by Plaid. It provides Production diagnostics and analytics tools, including tools for…”

   proof ↗⚑ flag

   Teller—none0/10

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

   ⚑ flag

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

   weight 2 · round to Teller
   Plaid~partialclaimed3/10

   Plaid provides webhooks and transactionsSync for asynchronous, background processing of financial data changes (docs-8, gh-1), which could underpin automations, but there is no evidence of any AI-native automation/agent orchestration capability, scheduling, or autonomous workflow builder — the Dashboard MCP server is limited to diagnostics/analytics, not automation setup. Missing for 10: explicit automation/agent framework, scheduling or trigger-action tooling, and any AI-native framing of background autonomy beyond generic webhooks.

   • [claimed-docs] “Plaid sends webhooks to programmatically inform you about changes to Plaid Items or the status of asynchronous processes.”
   • [github] “try { await plaidClient.transactionsSync(request); } catch (error) { const err = error.response.data; }”
   • [claimed-docs] “The Dashboard MCP server is a remote MCP server hosted by Plaid. It provides Production diagnostics and analytics tools, including tools for…”

   proof ↗⚑ flag

   Teller~partialclaimed4/10

   Teller offers webhooks that fire on enrollment/data changes, enabling event-driven background processing without polling, which is the closest analog to autonomous automation for this financial-data API. However there's no evidence of an AI-agent framework, scheduling/orchestration engine, or any AI-native automation tooling — webhooks are a generic API feature, not an agentic automation capability. Missing for 10: AI agent orchestration support, scheduled/recurring automation tooling, explicit AI-native automation framework or examples.

   • [claimed-docs] “To register a new webhook, you need to have a URL in your app that Teller can call. You can configure a new webhook from the Teller Dashboar…”
   • [claimed-docs] “Teller sends webhook events when specific conditions or changes are detected in user enrollments or their financial data.”

   proof ↗⚑ flag

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

   weight 2 · round to Plaid
   Plaid~partialprobed4/10

   Plaid documents an official 'Dashboard MCP server' that exposes diagnostics/analytics tools (debugging Items, Link conversion data, usage metrics) which an AI agent could invoke via natural language, but this only covers dashboard operations, not the core product functionality (Auth, Transactions, Identity, Payments) — there is no broader natural-language interface for operating Plaid's main capabilities. Missing for 10: NL control over core Plaid products (linking, transactions, payments), independent/hands-on confirmation of MCP usability, and any conversational agent interface beyond dashboard diagnostics.

   • [claimed-docs] “The Dashboard MCP server is a remote MCP server hosted by Plaid. It provides Production diagnostics and analytics tools, including tools for…”
   • [probe] “official MCP server documented at https://plaid.com/docs/resources/mcp/”

   proof ↗⚑ flag

   Teller—none0/10

   Teller is a banking-data API/SDK product with no evidence of a natural-language command interface, chatbot, or AI-native interaction layer; probes for llms.txt/docs.md/openapi also failed, and no docs mention NL commands or agent interfaces.

   • [probe] “PROBE llms.txt: HTTP 404 at https://teller.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://teller.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://teller.io/openapi.json, https://teller.io/swagger.json, https://teller.io/api/openapi.json, …”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   Plaid—none0/10

   Evidence shows only static docs pages, a Quickstart sample app to clone locally, and a Sandbox test environment, but no interactive API reference (e.g., try-it console, embedded runnable code snippets) — probes for an OpenAPI spec and docs-as-markdown interactive surface both returned 404s, suggesting no such interactive reference exists.

   • [claimed-docs] “Let's test out running Plaid locally by cloning the Quickstart app. You'll need API keys, which you can receive by signing up in the Dashboa…”
   • [probe] “PROBE docs-md: HTTP 404 at https://plaid.com/docs/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://plaid.com/openapi.json, https://plaid.com/swagger.json, https://plaid.com/api/openapi.json, …”

   proof ↗⚑ flag

   Teller—none0/10

   Teller has extensive markdown-based API documentation but no evidence of an interactive reference with runnable examples (e.g., Swagger/OpenAPI explorer). Probes for openapi.json/swagger.json all returned 404, and no docs mention a try-it-now console or code sandbox.

   • [probe] “PROBE openapi: all candidate paths 404 (https://teller.io/openapi.json, https://teller.io/swagger.json, https://teller.io/api/openapi.json, …”
   • [claimed-docs] “Learn about Teller Connect and how to integrate and customize it for you application.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Plaid—none0/10

   Direct probes for OpenAPI/swagger spec files at standard paths all returned 404, and no documentation references a downloadable machine-readable API spec; only an llms.txt marketing page was found, not an OpenAPI/equivalent spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://plaid.com/openapi.json, https://plaid.com/swagger.json, https://plaid.com/api/openapi.json, …”
   • [probe] “PROBE docs-md: HTTP 404 at https://plaid.com/docs/.md”
   • [probe] “PROBE llms.txt: HTTP 200 at https://plaid.com/llms.txt # Plaid > Plaid helps all companies build fintech solutions by making it easy, safe …”

   proof ↗⚑ flag

   Teller—none0/10

   Probes for llms.txt, docs.md, and common OpenAPI/swagger paths all return 404, and no evidence pack item references a downloadable machine-readable spec; documentation is only in prose/markdown form.

   • [probe] “PROBE llms.txt: HTTP 404 at https://teller.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://teller.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://teller.io/openapi.json, https://teller.io/swagger.json, https://teller.io/api/openapi.json, …”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   Plaid✓fullclaimed8/10

   Plaid provides a dedicated, fully-featured Sandbox environment supporting all API/Link functionality with unlimited test Items and test credentials, plus a special sandbox-only endpoint for programmatic Item creation, clearly separating test from production data. missing for 10: no independent/hands-on developer corroboration of sandbox fidelity, and no explicit mention of AI-agent-specific sandbox testing workflows.

   • [claimed-docs] “The Plaid Sandbox is a free and fully-featured environment for application development and testing... you can create an unlimited number of …”
   • [claimed-docs] “The Plaid Sandbox is a free and fully-featured environment for application development and testing. All Plaid functionality of both the Plai…”
   • [claimed-docs] “you can also create Items in Sandbox via the API, using a special Sandbox-only endpoint, /sandbox/public_token/create. This endpoint allows …”
   • [claimed-docs] “Let's test out running Plaid locally by cloning the Quickstart app. You'll need API keys, which you can receive by signing up in the Dashboa…”

   proof ↗⚑ flag

   Teller✓fullclaimed8/10

   Teller documents a dedicated sandbox environment using simulated data that never connects to real financial institutions, with defined test flows (e.g., OTP MFA with code 0000), letting developers test integrations without touching production data or real accounts. Missing for 10: independent/hands-on developer confirmation of sandbox fidelity and no mention of sandbox-specific rate limits or data reset options.

   • [claimed-docs] “The sandbox environment uses simulated data and never connects to real financial institutions.”
   • [claimed-docs] “`otp` () - Will follow an OTP MFA flow whereby the user will be asked to select a contact to send an OTP code. The correct code is `0000`”
   • [claimed-docs] “**100 enrollment limit** — An enrollment represents one bank login, which may include multiple accounts”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Plaid—none0/10

   The evidence pack contains no documentation of API versioning scheme or a deprecation policy — no changelog, version headers, or sunset timeline are mentioned anywhere, only product feature docs (Auth, Balance, Identity, Transactions) and SDK error-handling snippets.

   ⚑ flag

   Teller—none0/10

   No evidence of API versioning scheme or a documented deprecation policy anywhere in the docs pack; probes for llms.txt/openapi spec also failed, suggesting no machine-readable API contract either.

   • [probe] “PROBE llms.txt: HTTP 404 at https://teller.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://teller.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://teller.io/openapi.json, https://teller.io/swagger.json, https://teller.io/api/openapi.json, …”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Plaid—none0/10

   Plaid's docs describe per-Item operations (Auth, Balance, Identity, Transactions, sandbox item creation) and webhooks, but no evidence shows a bulk/batch API for operating across many Items simultaneously (e.g., no bulk sync, bulk webhook re-fire, or multi-item query endpoint documented).

   ⚑ flag

   Teller—none0/10

   Teller's docs describe per-item endpoints (single account balances, single transaction list with pagination, single payment with idempotency) but there is no evidence of any batch/bulk endpoint for operating across many accounts, transactions, or payments at once. Pagination controls exist for reading a transaction list, but that is not a bulk operation on multiple items simultaneously.

   • [claimed-docs] “the transactions list endpoint supports pagination controls.”
   • [claimed-docs] “This endpoint supports idempotent requests.”
   • [claimed-docs] “The payments resource allows you to send payments to yourself or a 3rd party on behalf of the end-user from their account. Currently the onl…”
   • [claimed-docs] “The transactions API exposes the ledger transactions of a financial account.”

   proof ↗⚑ flag

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

   weight 3 · round to Plaid
   Plaid~partialclaimed4/10

   Plaid provides webhooks that notify developers of events (item changes, transaction updates, async completions), which can be used to build automated reactions, but there is no evidence of a declarative rules engine where an AI-native user defines 'if event X then action Y' logic directly within Plaid—developers must write their own handling code. Missing for 10: a native rule/condition-action builder, AI-triggered automation config, or no-code trigger definitions beyond raw webhook payloads.

   • [claimed-docs] “Plaid sends webhooks to programmatically inform you about changes to Plaid Items or the status of asynchronous processes.”
   • [claimed-docs] “Retrieve up to 24 months of transaction data and stay up-to-date with webhooks”
   • [github] “try { await plaidClient.transactionsSync(request); } catch (error) { const err = error.response.data; }”

   proof ↗⚑ flag

   Teller—none0/10

   Teller offers webhooks for event notifications (teller-docs-7, teller-docs-17), but there is no evidence of a rules engine or automation-configuration capability where users can define conditional actions triggered by events — webhook delivery only notifies an external app, it doesn't let a user define trigger-action rules within Teller itself. missing for 10: any rule/condition builder, action templates, or automation configuration UI/API beyond raw webhook event delivery.

   • [claimed-docs] “To register a new webhook, you need to have a URL in your app that Teller can call. You can configure a new webhook from the Teller Dashboar…”
   • [claimed-docs] “Teller sends webhook events when specific conditions or changes are detected in user enrollments or their financial data.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

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

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

Ach details

1. developerObtain verified account and routing numbers (or tokenized equivalents) from a linked account to fund ACH or bank-debit payments without micro-deposits

   weight 3 · round to Plaid
   Plaid✓fullclaimed8/10

   Plaid Auth explicitly provides checking/savings/cash management account and routing numbers to initiate ACH/wire debits/credits without micro-deposits, and is paired with Balance and Identity for verification, with Sandbox/Link supporting full dev testing. missing for 10: no independent/hands-on corroboration of micro-deposit-free instant verification success rate, and no explicit mention of tokenized-equivalent output formats.

   • [claimed-docs] “Auth allows you to request a user's checking, savings, or cash management account and routing number, making it easy for you to initiate cre…”
   • [claimed-docs] “Balance is Plaid's product for receiving real-time balance information. This data is commonly used to tell if an account has sufficient fund…”
   • [claimed-docs] “Plaid's Identity product helps you verify users' identities by accessing information on file with their financial institution.”
   • [claimed-docs] “Plaid Link is the client-side component that your users will interact with in order to link their accounts to Plaid and allow you to access …”
   • [claimed-docs] “The Plaid Sandbox is a free and fully-featured environment for application development and testing. All Plaid functionality of both the Plai…”

   proof ↗⚑ flag

   Teller~partialclaimed7/10

   Teller's docs describe an account-details endpoint providing verified account/routing numbers with instant verification for 7,000+ institutions, explicitly positioned to avoid microdeposits, with balances API used to confirm funds before ACH debit. However the same docs show a same-day microdeposit fallback is still required for institutions outside instant coverage, and there is no independent/hands-on confirmation of the instant-verification success rate or that routing numbers are tokenized rather than plaintext. missing for 10: independent corroboration of instant verification working in practice, clarity on tokenization vs raw account/routing number exposure, and confirmation that non-covered institutions aren't a common real-world limitation.

   • [claimed-docs] “To access account details from these institutions, you can implement the 'Verify Account Details via Microdeposit' flow.”
   • [claimed-docs] “Connect instantly with more than 7,000 financial institutions and fall back to same-day ACH microdeposit verification for everyone else.”
   • [claimed-docs] “Guaranteed live account balances. Used for underwriting or ensuring sufficient funds are available before submitting an ACH debit.”
   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”

   proof ↗⚑ flag

Balances

1. developerFetch a real-time balance for a connected account before initiating a payment — a documented balance endpoint intended for NSF and risk checks

   weight 3 · round to Teller
   Plaid✓fullclaimed8/10

   Plaid's Balance product is explicitly documented as a real-time balance endpoint used to check sufficient funds before using an account as a payment funding source, directly matching the NSF/risk-check use case. missing for 10: independent hands-on developer confirmation of the /accounts/balance/get endpoint behavior and no explicit mention of latency/SLA guarantees for pre-payment checks.

   • [claimed-docs] “Balance is Plaid's product for receiving real-time balance information. This data is commonly used to tell if an account has sufficient fund…”

   proof ↗⚑ flag

   Teller✓fullclaimed9/10

   Teller's docs explicitly provide a dedicated real-time balances API endpoint, and marketing/docs copy directly frames it for underwriting/NSF risk checks before submitting an ACH debit, matching the story precisely. Missing for 10: no independent/hands-on developer confirmation of the balance endpoint's real-time accuracy or latency in production.

   • [claimed-docs] “The account balances API provides your application with live, real-time account balances.”
   • [claimed-docs] “Guaranteed live account balances. Used for underwriting or ensuring sufficient funds are available before submitting an ACH debit.”
   • [claimed-docs] “Teller lets users connect their accounts in seconds, and you verify account ownership, ACH details, balances, and transactions with ease.”

   proof ↗⚑ flag

Ownership

1. ops leadRetrieve account-holder details — names, addresses, contact data on file at the bank — to match the account owner against my customer

   weight 2 · round drawn
   Plaid✓fullclaimed8/10

   Plaid's Identity product is explicitly documented to return name, phone, email, and mailing address on file with the account holder's financial institution, directly matching the ops-lead need to verify account-owner identity against a customer record. Missing for 10: no independent/hands-on corroboration of match-accuracy or match-rate quality, and no explicit description of a 'match' scoring feature (e.g., identity match API) beyond raw data retrieval.

   • [claimed-docs] “Plaid's Identity product helps you verify users' identities by accessing information on file with their financial institution.”
   • [claimed-docs] “Plaid's Identity product helps you verify users' identities by accessing information on file with their financial institution. Using Identit…”

   proof ↗⚑ flag

   Teller✓fullclaimed8/10

   Teller's Identity API explicitly returns beneficial owner identity information for each authorized account, directly matching the story's need to retrieve account-holder names/identity data for owner matching (teller-docs-4, teller-docs-19), and the docs message frames account ownership verification as a core use case (teller-docs-1). Missing for 10: explicit confirmation that address/contact fields (not just legal name) are included in the Identity payload, and independent/hands-on corroboration beyond vendor docs.

   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”
   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”
   • [claimed-docs] “Teller lets users connect their accounts in seconds, and you verify account ownership, ACH details, balances, and transactions with ease.”

   proof ↗⚑ flag

Processor tokens

1. developerLinked accounts plug into my payment processor — documented integrations or token exchange that hand verified account credentials to third-party processors and platforms

   weight 2 · round to Plaid
   Plaid✓fullclaimed8/10

   Plaid's Auth product explicitly hands over verified account and routing numbers to enable third-party ACH/wire debits/credits, and Payment Initiation extends this to real-time European bank transfers without manual entry, with Balance/Identity supplementing verification data used by payment processors. This is documented as a core first-party capability (token exchange via Link → API access to account credentials for downstream money movement). missing for 10: named case studies/integrations with specific processors (e.g., Stripe), independent technical corroboration of the token-exchange flow beyond docs.

   • [claimed-docs] “Auth allows you to request a user's checking, savings, or cash management account and routing number, making it easy for you to initiate cre…”
   • [claimed-docs] “Balance is Plaid's product for receiving real-time balance information. This data is commonly used to tell if an account has sufficient fund…”
   • [claimed-docs] “Plaid's European Payments suite enables your users to make real-time payments without manually entering their account details or leaving you…”
   • [claimed-docs] “Plaid's European Payments suite enables your users to make real-time payments without manually entering their account details or leaving you…”
   • [claimed-docs] “Plaid Link is the client-side component that your users will interact with in order to link their accounts to Plaid and allow you to access …”

   proof ↗⚑ flag

   Teller—none0/10

   Teller's docs describe its own Payments resource (Zelle transfers) and Identity/Balances APIs, but there is no documented processor-token exchange or integration flow that hands verified account credentials to third-party payment processors/platforms (e.g., a Stripe/Dwolla-style processor token). Community threads even confirm Teller does not enable moving money to arbitrary third parties beyond its own Zelle feature.

   • [claimed-docs] “The payments resource allows you to send payments to yourself or a 3rd party on behalf of the end-user from their account. Currently the onl…”
   • [claimed-docs] “The payments resource allows you to send payments to yourself or a 3rd party on behalf of the end-user from their account.”
   • [community] “Founder response: 'FWIW it is not currently possible for users to move money with Teller... Our terms are comparable to the incumbent screen…”

   proof ↗⚑ flag

Agent data

1. ai-native userThe data comes back agent-consumable — clean structured JSON, documented schemas, and enrichment an automated financial workflow can reason over without heuristic parsing

   weight 2 · round to Teller
   Plaid~partialprobed5/10

   Plaid's docs describe structured JSON products (Auth, Balance, Identity, Transactions) with clear semantics and webhooks for async updates, and SDKs show typed request/response handling with try/catch error parsing, suggesting machine-consumable output. However, there's no evidence of a public OpenAPI/JSON-schema spec (probe explicitly found 404s for openapi.json/swagger.json), and no documentation of transaction enrichment/categorization features an agent could reason over without extra parsing logic. Missing for 10: published OpenAPI or JSON schema definitions, explicit enrichment/categorization documentation, and independent confirmation that outputs require no heuristic post-processing.

   • [claimed-docs] “Auth allows you to request a user's checking, savings, or cash management account and routing number, making it easy for you to initiate cre…”
   • [claimed-docs] “Balance is Plaid's product for receiving real-time balance information. This data is commonly used to tell if an account has sufficient fund…”
   • [claimed-docs] “Retrieve up to 24 months of transaction data and stay up-to-date with webhooks”
   • [claimed-docs] “Plaid sends webhooks to programmatically inform you about changes to Plaid Items or the status of asynchronous processes.”
   • [github] “try { await plaidClient.transactionsSync(request); } catch (error) { const err = error.response.data; }”
   • [github] “All errors can now be caught using try/catch with async/await or through promise chaining.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://plaid.com/openapi.json, https://plaid.com/swagger.json, https://plaid.com/api/openapi.json, …”

   proof ↗⚑ flag

   Teller~partialprobed6/10

   Teller's docs describe a REST API with well-defined resources (balances, transactions, identity, payments) and some enrichment like transaction categorization, pagination, and idempotency, suggesting structured, documented data an app could parse programmatically. However, there is no evidence of a machine-readable schema (OpenAPI/swagger) or llms.txt for agent discovery—probes show all such endpoints 404—so an AI agent would have to rely on human-oriented docs rather than a formal schema. missing for 10: machine-readable OpenAPI/schema files, llms.txt or agent-specific docs, richer enrichment metadata (e.g., merchant/location tags) beyond basic categorization.

   • [claimed-docs] “The account balances API provides your application with live, real-time account balances.”
   • [claimed-docs] “The transactions API exposes the ledger transactions of a financial account.”
   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”
   • [claimed-docs] “the category that the transaction belongs to. Teller uses the following values for categorization”
   • [claimed-docs] “This endpoint supports idempotent requests.”
   • [claimed-docs] “the transactions list endpoint supports pagination controls.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://teller.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://teller.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://teller.io/openapi.json, https://teller.io/swagger.json, https://teller.io/api/openapi.json, …”

   proof ↗⚑ flag

Agent operations

1. ai-native userAn agent can operate the platform — create link sessions, retrieve balances and transactions, and manage connections through the API or an MCP surface with scoped credentials

   weight 3 · round to Plaid
   Plaid~partialprobed6/10

   Plaid's REST API comprehensively covers the core story — creating Link sessions (plaid-docs-5), retrieving balances (plaid-docs-2), pulling transactions (plaid-docs-4, plaid-gh-1), and managing connections/Items via webhooks (plaid-docs-8) — and SDKs like plaid-node make this scriptable by an agent. However, the only documented MCP surface is the Dashboard MCP server, which is scoped to Production diagnostics/analytics (debugging Items, Link conversion, usage metrics) rather than operational banking actions like initiating Link or pulling balances/transactions (plaid-docs-9, plaid-probe-4). Missing for 10: an MCP surface (or equivalent agent-native interface) that actually performs Link session creation/balance/transaction retrieval, and explicit documentation of scoped/limited credentials designed for autonomous agent use rather than server-side API keys.

   • [claimed-docs] “Plaid Link is the client-side component that your users will interact with in order to link their accounts to Plaid and allow you to access …”
   • [claimed-docs] “Balance is Plaid's product for receiving real-time balance information. This data is commonly used to tell if an account has sufficient fund…”
   • [claimed-docs] “Retrieve up to 24 months of transaction data and stay up-to-date with webhooks”
   • [claimed-docs] “Plaid sends webhooks to programmatically inform you about changes to Plaid Items or the status of asynchronous processes.”
   • [github] “try { await plaidClient.transactionsSync(request); } catch (error) { const err = error.response.data; }”
   • [claimed-docs] “The Dashboard MCP server is a remote MCP server hosted by Plaid. It provides Production diagnostics and analytics tools, including tools for…”
   • [probe] “official MCP server documented at https://plaid.com/docs/resources/mcp/”

   proof ↗⚑ flag

   Teller~partialprobed4/10

   Teller's REST API supports the core primitives (balances, transactions, identity, connect/link sessions via Teller Connect, mTLS-scoped credentials) that an agent could call, but there is no evidence of an MCP server, agent-oriented SDK, or machine-readable API spec — probes for llms.txt, docs.md, and openapi.json all returned 404, indicating no first-class AI-agent integration surface. missing for 10: an MCP server or agent tool-calling interface, machine-readable OpenAPI/llms.txt discovery, and any documentation framing agent-driven scoped access.

   • [claimed-docs] “Teller lets users connect their accounts in seconds, and you verify account ownership, ACH details, balances, and transactions with ease.”
   • [claimed-docs] “The account balances API provides your application with live, real-time account balances.”
   • [claimed-docs] “The transactions API exposes the ledger transactions of a financial account.”
   • [claimed-docs] “The Teller API uses mTLS to authenticate the API caller. Teller issues client certificates that you use to connect to the Teller API.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://teller.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://teller.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://teller.io/openapi.json, https://teller.io/swagger.json, https://teller.io/api/openapi.json, …”

   proof ↗⚑ flag

Consent

1. ops leadEnd users can see and revoke what they've shared — a documented consent surface or portal where a user manages which apps hold access to their bank data

   weight 2 · round drawn
   Plaid—none0/10

   The evidence pack contains no documentation of a Plaid-hosted consent management portal or dashboard where end users can view or revoke connected apps' access to their bank data; Plaid Link (docs-5) only covers the initial linking/consent flow, not ongoing management or revocation. Community comments even show a user explicitly asking how to revoke Plaid's access with no clear answer, reinforcing the absence of a documented self-service revocation surface.

   • [claimed-docs] “Plaid Link is the client-side component that your users will interact with in order to link their accounts to Plaid and allow you to access …”
   • [community] “I gave them access to my bank via coinbase. If I change my bank password would they lose access to my account? If not, what do I need to do …”

   proof ↗⚑ flag

   Teller—none0/10

   No evidence of an end-user consent dashboard or portal where users can view or revoke third-party app access to their bank data; docs cover enrollment, data APIs, webhooks, and auth but nothing about consent management/revocation UI. Missing for 10: a documented end-user consent portal, revocation flow/API, and any independent confirmation of such a surface.

   • [claimed-docs] “finish up by linking your first financial accounts to Teller.”
   • [claimed-docs] “**100 enrollment limit** — An enrollment represents one bank login, which may include multiple accounts”
   • [claimed-docs] “Learn about Teller Connect and how to integrate and customize it for you application.”

   proof ↗⚑ flag

Deletion

1. ops leadSever and clean up — a documented way to delete a connection or user and have the platform stop collecting and purge held data

   weight 2 · round drawn
   Plaid—none0/10

   The evidence pack contains no documentation of an item/access-token deletion endpoint, account disconnection flow, or data purge/retention policy — only product feature docs (Auth, Balance, Identity, Transactions) and Sandbox/dashboard mentions. A community comment even shows a user asking how to revoke Plaid's bank access with no clear answer surfaced, reinforcing the absence of a documented sever-and-purge mechanism in the pack.

   • [community] “I gave them access to my bank via coinbase. If I change my bank password would they lose access to my account? If not, what do I need to do …”
   • [claimed-docs] “Retrieve up to 24 months of transaction data and stay up-to-date with webhooks”
   • [claimed-docs] “Plaid sends webhooks to programmatically inform you about changes to Plaid Items or the status of asynchronous processes.”

   proof ↗⚑ flag

   Teller—none0/10

   No evidence in the pack documents a deletion/disconnection flow, data purge process, or user/connection removal API — the docs focus on connecting, verifying, and retrieving financial data (balances, transactions, identity, payments) with no mention of offboarding or data deletion mechanics.

   ⚑ flag

Scopes

1. developerI request only the data scopes I need — product-scoped consents and documented data-minimization controls, not an all-or-nothing grant

   weight 2 · round to Plaid
   Plaid!disputedcontradicted4/10

   Plaid's docs show genuinely separate, scopeable products (Auth, Balance, Identity, Transactions, Payment Initiation) that a developer can choose to request individually rather than one monolithic grant, which supports a product-scoped consent model. However, independent/community reports concretely contradict the 'data-minimization by design' claim: users report Plaid flows give 'no indication... you're likely giving away much more than just the bare minimum' and that dark patterns lead to over-broad grants (transaction, identity, balance data) beyond what the integrating app needs. Missing for 10: first-party documentation of a scoped-consent UI/permission screen, independent audit confirming least-privilege enforcement, and no rebuttal to the dark-pattern complaints.

   • [claimed-docs] “Auth allows you to request a user's checking, savings, or cash management account and routing number, making it easy for you to initiate cre…”
   • [claimed-docs] “Balance is Plaid's product for receiving real-time balance information. This data is commonly used to tell if an account has sufficient fund…”
   • [claimed-docs] “Plaid's Identity product helps you verify users' identities by accessing information on file with their financial institution.”
   • [claimed-docs] “Retrieve up to 24 months of transaction data and stay up-to-date with webhooks”
   • [claimed-docs] “Plaid's European Payments suite enables your users to make real-time payments without manually entering their account details or leaving you…”
   • [community] “Have to say I'm not a fan of Plaid at all. Dark patterns galore. Absolutely no indication when you go through a Plaid flow that you're likel…”
   • [community] “Plaid is a terrible company. Their main product scrapes financial data from unsuspecting users that simply think they're making a bank trans…”

   proof ↗⚑ flag

   Teller—none0/10

   The evidence describes separate API resources (balances, transactions, identity, payments) but there is no documentation of a consent flow where developers can request only specific scopes or where end-users see a product-scoped grant rather than an all-or-nothing authorization. No mention of a 'products' parameter, granular permission toggles, or data-minimization consent screen in Teller Connect.

   • [claimed-docs] “Teller lets users connect their accounts in seconds, and you verify account ownership, ACH details, balances, and transactions with ease.”
   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”
   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”
   • [claimed-docs] “Learn about Teller Connect and how to integrate and customize it for you application.”

   proof ↗⚑ flag

Refresh

1. developerTrigger an on-demand refresh of a connected account's data through the API when my use case needs now-fresh data, with the refresh semantics documented

   weight 2 · round drawn
   Plaid~partialclaimed4/10

   The evidence shows Plaid supports webhook-based updates (plaid-docs-8, plaid-docs-4) and an API-driven `transactionsSync` call (plaid-gh-1, plaid-gh-2) that developers can invoke to pull current data, which is adjacent to an on-demand refresh trigger, but the pack never cites Plaid's dedicated refresh endpoint (e.g. /transactions/refresh) or documents its specific semantics (timing, cost, which products support it). Missing for 10: explicit documentation of a refresh-on-demand endpoint and its semantics, confirmation of which products it applies to, and any independent/hands-on confirmation of its behavior.

   • [claimed-docs] “Plaid sends webhooks to programmatically inform you about changes to Plaid Items or the status of asynchronous processes.”
   • [claimed-docs] “Retrieve up to 24 months of transaction data and stay up-to-date with webhooks”
   • [github] “try { await plaidClient.transactionsSync(request); } catch (error) { const err = error.response.data; }”
   • [github] “All errors can now be caught using try/catch with async/await or through promise chaining.”

   proof ↗⚑ flag

   Teller~partialclaimed4/10

   Teller's balances API is documented as returning "live, real-time account balances" (teller-docs-2, teller-docs-22), implying each API call effectively refreshes data on demand, and webhooks fire on data changes (teller-docs-7, teller-docs-17). However, there is no dedicated refresh/sync endpoint, no documented semantics for how or when transaction data is refreshed, and no explanation of caching or refresh triggers for the transactions API — missing for 10: a documented refresh endpoint/mechanism, explicit refresh semantics (latency, staleness window), and confirmation for transactions data (not just balances).

   • [claimed-docs] “The account balances API provides your application with live, real-time account balances.”
   • [claimed-docs] “Guaranteed live account balances. Used for underwriting or ensuring sufficient funds are available before submitting an ACH debit.”
   • [claimed-docs] “To register a new webhook, you need to have a URL in your app that Teller can call. You can configure a new webhook from the Teller Dashboar…”
   • [claimed-docs] “Teller sends webhook events when specific conditions or changes are detected in user enrollments or their financial data.”
   • [claimed-docs] “The transactions API exposes the ledger transactions of a financial account.”

   proof ↗⚑ flag

Webhooks

1. developerData changes arrive as signed webhooks — new transactions, balance updates, connection state changes — so my system stays current without polling

   weight 2 · round to Plaid
   Plaid✓fullclaimed8/10

   Plaid's docs explicitly describe webhooks for transactions, balance, and Item/connection state changes to keep systems updated without polling, and this is a well-documented core mechanism (plaid-docs-4, plaid-docs-8) reinforced by SDK error-handling examples showing transactionsSync usage in conjunction with webhooks (plaid-gh-1). No evidence indicates webhook signing/verification is missing or broken. Missing for 10: explicit mention of webhook signature verification mechanics and independent third-party confirmation of webhook reliability in production.

   • [claimed-docs] “Retrieve up to 24 months of transaction data and stay up-to-date with webhooks”
   • [claimed-docs] “Plaid sends webhooks to programmatically inform you about changes to Plaid Items or the status of asynchronous processes.”
   • [github] “try { await plaidClient.transactionsSync(request); } catch (error) { const err = error.response.data; }”

   proof ↗⚑ flag

   Teller~partialclaimed5/10

   Teller docs confirm webhook events exist for enrollment/data changes (teller-docs-17) and describe how to register a webhook URL (teller-docs-7), covering the general 'push not poll' data-freshness goal. However, the evidence pack contains no mention of webhook payload signing/verification mechanism, nor independent confirmation that webhooks reliably fire for transactions, balances, and connection-state changes as described. Missing for 10: explicit signature/verification scheme for webhooks, documented list of event types (transaction created, balance updated, enrollment disconnected), and third-party/hands-on confirmation of webhook delivery reliability.

   • [claimed-docs] “To register a new webhook, you need to have a URL in your app that Teller can call. You can configure a new webhook from the Teller Dashboar…”
   • [claimed-docs] “Teller sends webhook events when specific conditions or changes are detected in user enrollments or their financial data.”

   proof ↗⚑ flag

Coverage

1. founderThe platform documents how many institutions it reaches and where — published coverage numbers and geographies I can check against where my users actually bank

   weight 3 · round drawn
   Plaid~partialclaimed3/10

   The pack shows only a narrow geography claim (payment-initiation supports '18 European markets') but no overall institution count or country-by-country coverage list that a founder could check against user banks. missing for 10: published total institution count, per-country/region coverage breakdown, and any independent verification of coverage claims.

   • [claimed-docs] “Plaid's European Payments suite enables your users to make real-time payments without manually entering their account details or leaving you…”

   proof ↗⚑ flag

   Teller~partialcommunity3/10

   Teller publishes a single aggregate figure ("more than 7,000 financial institutions") but no breakdown by geography, no searchable list of supported institutions, and no way for a founder to verify coverage against their specific user base. The old community thread references only a handful of UK banks, but this appears to be from an earlier version of the product and is not directly comparable to the current 7,000+ claim. missing for 10: geographic breakdown, institution-name list/coverage tool, independent verification of the 7,000 figure.

   • [claimed-docs] “Connect instantly with more than 7,000 financial institutions and fall back to same-day ACH microdeposit verification for everyone else.”
   • [community] “Teller is available today for Santander UK, Barclays, Natwest, Nationwide, RBS, Isle of Man Bank, and Ulster Bank.”

   proof ↗⚑ flag

Status

1. ops leadPer-institution health is visible — documented institution statuses, outage or degradation signals, and error codes that distinguish a bank problem from my problem

   weight 2 · round to Plaid
   Plaid~partialprobed4/10

   Plaid documents webhooks for Item status changes and SDK-level error handling, and offers a Dashboard MCP server with 'diagnostics tools' for debugging Items, which supports some institution-health visibility. However, there is no evidence of a documented institution-status/error-code taxonomy (e.g., distinguishing bank outages from integration errors) or a public status page for individual institutions. Missing for 10: documented per-institution error code list distinguishing bank vs. client errors, an institution status/outage dashboard or feed, and independent confirmation these diagnostics reliably surface bank-side outages.

   • [claimed-docs] “Plaid sends webhooks to programmatically inform you about changes to Plaid Items or the status of asynchronous processes.”
   • [github] “try { await plaidClient.transactionsSync(request); } catch (error) { const err = error.response.data; }”
   • [github] “All errors can now be caught using try/catch with async/await or through promise chaining.”
   • [claimed-docs] “The Dashboard MCP server is a remote MCP server hosted by Plaid. It provides Production diagnostics and analytics tools, including tools for…”
   • [probe] “official MCP server documented at https://plaid.com/docs/resources/mcp/”

   proof ↗⚑ flag

   Teller—none0/10

   No evidence of a status page, per-institution outage/degradation signals, or documented error codes distinguishing bank-side failures from client-side errors. Webhooks are mentioned for enrollment/data change events, but nothing ties to institution health visibility or error taxonomy.

   ⚑ flag

Multi product

1. developerOne link session can power multiple data products — auth, balances, transactions, identity — without forcing the user through separate connection flows per product

   weight 2 · round to Teller
   Plaid~partialclaimed5/10

   Plaid's sandbox docs explicitly mention creating an Item with 'initial products' (plural) via a single public_token, implying one Link-created Item can be enabled for multiple products (auth, balance, identity, transactions) at once rather than separate connections. However, the evidence pack never explicitly confirms a single Link session UX flow surfacing multiple products to the end user in one consent step. Missing for 10: an explicit doc/example showing a single Link token configured with products=['auth','balances','transactions','identity'] and the resulting single end-user consent flow, plus independent/hands-on confirmation.

   • [claimed-docs] “you can also create Items in Sandbox via the API, using a special Sandbox-only endpoint, /sandbox/public_token/create. This endpoint allows …”
   • [claimed-docs] “Plaid Link is the client-side component that your users will interact with in order to link their accounts to Plaid and allow you to access …”
   • [claimed-docs] “Auth allows you to request a user's checking, savings, or cash management account and routing number, making it easy for you to initiate cre…”
   • [claimed-docs] “Balance is Plaid's product for receiving real-time balance information. This data is commonly used to tell if an account has sufficient fund…”
   • [claimed-docs] “Plaid's Identity product helps you verify users' identities by accessing information on file with their financial institution.”
   • [claimed-docs] “Retrieve up to 24 months of transaction data and stay up-to-date with webhooks”

   proof ↗⚑ flag

   Teller✓fullclaimed7/10

   Teller's architecture centers on a single enrollment/access-token granted via one Connect flow, which then powers balances, transactions, identity, and account-details APIs (teller-docs-1, teller-docs-4/19 note identity covers 'all accounts the end-user granted access authorization', teller-docs-13 defines an enrollment as one bank login with multiple accounts). This implies a single link session unlocks multiple data products without repeated connect flows. missing for 10: an explicit statement confirming no re-authentication is needed per product, and independent/hands-on developer corroboration of this multi-product single-session behavior.

   • [claimed-docs] “Teller lets users connect their accounts in seconds, and you verify account ownership, ACH details, balances, and transactions with ease.”
   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”
   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”
   • [claimed-docs] “**100 enrollment limit** — An enrollment represents one bank login, which may include multiple accounts”
   • [claimed-docs] “The account balances API provides your application with live, real-time account balances.”
   • [claimed-docs] “The transactions API exposes the ledger transactions of a financial account.”

   proof ↗⚑ flag

Quickstart

1. developerGo from signup to my first linked sandbox account fast — self-serve API keys, a runnable quickstart, and client libraries in my language

   weight 2 · round to Plaid
   Plaid~partialprobed7/10

   Docs show self-serve signup via Dashboard for API keys, a runnable Quickstart app, a fully-featured free Sandbox environment supporting all products, and a Node client library with async/await error handling. However, there's no explicit evidence of the breadth of client libraries across multiple languages, no independent hands-on confirmation of quickstart speed/ease, and no OpenAPI spec discoverable via probes. missing for 10: multi-language client library coverage evidence, independent/hands-on time-to-first-linked-account confirmation, public OpenAPI/API reference spec.

   • [claimed-docs] “The Plaid Sandbox is a free and fully-featured environment for application development and testing... you can create an unlimited number of …”
   • [claimed-docs] “Let's test out running Plaid locally by cloning the Quickstart app. You'll need API keys, which you can receive by signing up in the Dashboa…”
   • [claimed-docs] “The Plaid Sandbox is a free and fully-featured environment for application development and testing. All Plaid functionality of both the Plai…”
   • [claimed-docs] “you can also create Items in Sandbox via the API, using a special Sandbox-only endpoint, /sandbox/public_token/create. This endpoint allows …”
   • [github] “try { await plaidClient.transactionsSync(request); } catch (error) { const err = error.response.data; }”
   • [github] “All errors can now be caught using try/catch with async/await or through promise chaining.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://plaid.com/openapi.json, https://plaid.com/swagger.json, https://plaid.com/api/openapi.json, …”

   proof ↗⚑ flag

   Teller~partialclaimed5/10

   Docs confirm a quickstart guide that ends with linking a first sandbox account, a dedicated sandbox environment with simulated data and OTP test flows, and at least one client library (React hook/component) for Teller Connect. However, authentication requires mTLS with client certificates rather than a simple self-serve API key (raising integration friction), and there's no evidence of client libraries beyond React or of a fast self-serve signup process for keys/certs. Missing for 10: explicit self-serve API-key/signup flow, additional-language client libraries (Node/Python/etc.), independent hands-on confirmation of speed from quickstart to first linked sandbox account.

   • [claimed-docs] “finish up by linking your first financial accounts to Teller.”
   • [claimed-docs] “The sandbox environment uses simulated data and never connects to real financial institutions.”
   • [claimed-docs] “`otp` () - Will follow an OTP MFA flow whereby the user will be asked to select a contact to send an OTP code. The correct code is `0000`”
   • [claimed-docs] “The Teller API uses mTLS to authenticate the API caller. Teller issues client certificates that you use to connect to the Teller API.”
   • [github] “React hook and component for integrating with Teller Connect”

   proof ↗⚑ flag

Sandbox

1. developerA sandbox with test institutions and documented test credentials lets me exercise linking, data retrieval, and error states end-to-end before touching a real bank account

   weight 3 · round to Plaid
   Plaid✓fullclaimed9/10

   Plaid's Sandbox docs describe a free, fully-featured test environment supporting all API and Link functionality, unlimited test Items, a special sandbox-only endpoint to create Items with arbitrary institution IDs and test credentials, and SDK error-handling examples for exercising error states end-to-end. This directly matches the story's need to test linking, data retrieval, and error flows before touching real accounts. Missing for 10: independent/hands-on developer corroboration of the sandbox experience beyond first-party docs.

   • [claimed-docs] “The Plaid Sandbox is a free and fully-featured environment for application development and testing... you can create an unlimited number of …”
   • [claimed-docs] “The Plaid Sandbox is a free and fully-featured environment for application development and testing. All Plaid functionality of both the Plai…”
   • [claimed-docs] “you can also create Items in Sandbox via the API, using a special Sandbox-only endpoint, /sandbox/public_token/create. This endpoint allows …”
   • [github] “try { await plaidClient.transactionsSync(request); } catch (error) { const err = error.response.data; }”
   • [github] “All errors can now be caught using try/catch with async/await or through promise chaining.”
   • [claimed-docs] “Plaid Link is the client-side component that your users will interact with in order to link their accounts to Plaid and allow you to access …”

   proof ↗⚑ flag

   Teller✓fullclaimed8/10

   Docs confirm a sandbox environment with simulated data that never touches real institutions, plus documented test credentials/flows (e.g., OTP MFA code '0000'), and full documented APIs for linking, balances, transactions, identity, and payments that can be exercised in sandbox. Missing for 10: independent/hands-on developer accounts specifically validating the sandbox test-credential workflow and documented error-state simulation beyond MFA.

   • [claimed-docs] “The sandbox environment uses simulated data and never connects to real financial institutions.”
   • [claimed-docs] “`otp` () - Will follow an OTP MFA flow whereby the user will be asked to select a contact to send an OTP code. The correct code is `0000`”
   • [claimed-docs] “The account balances API provides your application with live, real-time account balances.”
   • [claimed-docs] “The transactions API exposes the ledger transactions of a financial account.”
   • [claimed-docs] “**100 enrollment limit** — An enrollment represents one bank login, which may include multiple accounts”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Plaid~partialprobed5/10

   Plaid is API-first for core financial data products, and Sandbox Items can be created via API instead of the Dashboard UI (plaid-docs-14), suggesting some UI/API parity. However, the docs explicitly describe Dashboard-only actions like customizing and publishing Link's flow (plaid-docs-11) and signing up for API keys (plaid-docs-10) with no corresponding API endpoint shown, and there's no OpenAPI spec or full endpoint catalog to confirm total parity (plaid-probe-3). Missing for 10: evidence that Dashboard-only settings (Link customization, key management, analytics) have API equivalents, and independent confirmation of full UI/API feature parity.

   • [claimed-docs] “You can customize parts of Link's flow straight from the Dashboard. You can preview your changes in real time and then publish them instantl…”
   • [claimed-docs] “you can also create Items in Sandbox via the API, using a special Sandbox-only endpoint, /sandbox/public_token/create. This endpoint allows …”
   • [claimed-docs] “Let's test out running Plaid locally by cloning the Quickstart app. You'll need API keys, which you can receive by signing up in the Dashboa…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://plaid.com/openapi.json, https://plaid.com/swagger.json, https://plaid.com/api/openapi.json, …”

   proof ↗⚑ flag

   Teller~partialclaimed5/10

   Teller exposes rich API endpoints for balances, transactions, identity, payments, and account details (teller-docs-2,3,4,5,6), suggesting most financial data operations are API-driven, but account linking is done through the Teller Connect UI widget and webhook registration is explicitly described as being configured 'from the Teller Dashboard' rather than via an API endpoint (teller-docs-7), indicating some UI-only actions lack documented API equivalents. Missing for 10: an API endpoint for webhook/enrollment management equivalent to Dashboard actions, explicit documentation confirming full API/UI parity, and independent confirmation of no UI-exclusive features.

   • [claimed-docs] “The account balances API provides your application with live, real-time account balances.”
   • [claimed-docs] “The transactions API exposes the ledger transactions of a financial account.”
   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”
   • [claimed-docs] “The payments resource allows you to send payments to yourself or a 3rd party on behalf of the end-user from their account. Currently the onl…”
   • [claimed-docs] “To access account details from these institutions, you can implement the 'Verify Account Details via Microdeposit' flow.”
   • [claimed-docs] “To register a new webhook, you need to have a URL in your app that Teller can call. You can configure a new webhook from the Teller Dashboar…”
   • [claimed-docs] “Learn about Teller Connect and how to integrate and customize it for you application.”

   proof ↗⚑ flag

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

   weight 3 · round to Teller
   Plaid—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

   Teller~partialcommunity3/10

   Teller exposes account balances/transactions/identity via JSON API (open format), and a community member built a third-party script exporting Teller data to CSV/QIF, showing data can be extracted. However there is no first-party 'export all my data and leave' feature, no bulk data-export or account-deletion tooling, and no documentation of full data portability for end users. Missing for 10: official bulk export/download-all-data feature, documented account closure/data portability process, and independent confirmation beyond one hobbyist script.

   • [community] “I built a little script to export my accounts to CSV/QIF. Super easy to use API! https://github.com/scottrobertson/teller-export”
   • [claimed-docs] “The account balances API provides your application with live, real-time account balances.”
   • [claimed-docs] “The transactions API exposes the ledger transactions of a financial account.”
   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round drawn
   Plaid—none0/10

   Plaid is a closed-source commercial API/SaaS product; its client SDKs (e.g., plaid-node) are open-source wrappers but the core Plaid service/source is not published under an open license, and no evidence shows the product's actual source available for inspection.

   ⚑ flag

   Teller—none0/10

   Teller is a closed, proprietary financial API/service; the only open-source artifact found is a client-side React SDK wrapper (teller-connect-react), not the product's core source. A community comment explicitly wishes Teller were open source, implying it is not, and no license or source-availability claims appear in vendor docs.

   • [github] “React hook and component for integrating with Teller Connect”
   • [community] “I'd much prefer that this were just open source so I don't have to share my bank credentials.”

   proof ↗⚑ flag

Pay by bank

1. developerInitiate a bank payment from a connected account — a documented pay-by-bank or payment-initiation product with its live geographies stated honestly

   weight 2 · round to Plaid
   Plaid~partialclaimed6/10

   Plaid documents a real Payment Initiation product enabling real-time bank payments across 18 named European markets, which is a fairly honest geography disclosure, but Plaid explicitly does not offer this product in the US (US flows rely on Auth+ACH via third-party rails, not Plaid-initiated payment). missing for 10: explicit US/global payment-initiation coverage or a clear statement of unsupported geographies beyond Europe, independent/hands-on confirmation of the payment-initiation flow working as documented, and clarity on settlement/liability model for developers.

   • [claimed-docs] “Plaid's European Payments suite enables your users to make real-time payments without manually entering their account details or leaving you…”
   • [claimed-docs] “Plaid's European Payments suite enables your users to make real-time payments without manually entering their account details or leaving you…”
   • [claimed-docs] “Auth allows you to request a user's checking, savings, or cash management account and routing number, making it easy for you to initiate cre…”

   proof ↗⚑ flag

   Teller~partialclaimed5/10

   Teller docs confirm a payments API that lets a developer send a payment from a connected account to self or a third party, with idempotency support (teller-docs-5, teller-docs-18, teller-docs-20), and separately state broad institution coverage (7,000+ US institutions) for account connectivity (teller-docs-11). However, the payments API explicitly supports only the Zelle scheme currently, not general ACH/bank-transfer payment initiation, and there is no explicit geography statement scoped to the payments product itself (vs. the broader account-linking coverage claim). Missing for 10: multi-rail payment initiation beyond Zelle, an explicit payments-specific geography/eligibility statement, and independent/hands-on confirmation that payment initiation works live in production.

   • [claimed-docs] “The payments resource allows you to send payments to yourself or a 3rd party on behalf of the end-user from their account. Currently the onl…”
   • [claimed-docs] “The payments resource allows you to send payments to yourself or a 3rd party on behalf of the end-user from their account.”
   • [claimed-docs] “This endpoint supports idempotent requests.”
   • [claimed-docs] “Connect instantly with more than 7,000 financial institutions and fall back to same-day ACH microdeposit verification for everyone else.”
   • [claimed-docs] “**100 enrollment limit** — An enrollment represents one bank login, which may include multiple accounts”

   proof ↗⚑ flag

Recurring

1. developerRecurring bank payments are supported — variable recurring payments, standing consents, or documented recurring debit flows built on the connection

   weight 2 · round drawn
   Plaid—none0/10

   Plaid's Payment Initiation docs describe single real-time payments across European markets, with no mention of variable recurring payments, standing orders, or documented recurring debit/consent flows; Auth/ACH docs also only describe initiating one-off credits/debits, not recurring mandates.

   • [claimed-docs] “Plaid's European Payments suite enables your users to make real-time payments without manually entering their account details or leaving you…”
   • [claimed-docs] “Plaid's European Payments suite enables your users to make real-time payments without manually entering their account details or leaving you…”
   • [claimed-docs] “Auth allows you to request a user's checking, savings, or cash management account and routing number, making it easy for you to initiate cre…”

   proof ↗⚑ flag

   Teller—none0/10

   Teller's payments resource only supports Zelle-based payments to self or third parties; there is no mention of variable recurring payments, standing consents, or documented recurring debit flows.

   • [claimed-docs] “The payments resource allows you to send payments to yourself or a 3rd party on behalf of the end-user from their account. Currently the onl…”
   • [claimed-docs] “The payments resource allows you to send payments to yourself or a 3rd party on behalf of the end-user from their account.”
   • [claimed-docs] “This endpoint supports idempotent requests.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Plaid—none0/10

   No evidence of any data residency/region selection controls in Plaid's documentation; the evidence pack covers products, sandbox, MCP server, and payment features but never mentions data storage location choice or regional hosting options.

   ⚑ flag

   Teller—none0/10

   No evidence of any data residency/region selection controls in Teller's docs or community discussion; the pack covers account linking, payments, mTLS auth, and webhooks but nothing about data storage location choice.

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Plaid—none0/10

   No evidence pack item documents any user- or developer-facing mechanism for controlling data retention periods or deleting stored financial data in Plaid; docs cover data collection (Auth, Identity, Transactions, Balance) but not retention/deletion controls. Community commentary even shows a user unsure how to revoke Plaid's access, underscoring the absence of a clear deletion/retention feature.

   • [claimed-docs] “Retrieve up to 24 months of transaction data and stay up-to-date with webhooks”
   • [community] “I gave them access to my bank via coinbase. If I change my bank password would they lose access to my account? If not, what do I need to do …”

   proof ↗⚑ flag

   Teller—none0/10

   No evidence anywhere in the pack addresses data retention policies, deletion controls, or data lifecycle management for end-user financial data; docs cover connectivity, API resources, auth, and webhooks but nothing on retention/deletion controls.

   ⚑ flag

Cashflow

1. finance leadThe platform derives income and cash-flow signals from connected accounts — recurring streams, payroll detection, or documented income verification products built on the same data

   weight 2 · round drawn
   Plaid—none0/10

   The evidence pack covers Auth, Balance, Identity, Transactions, Payment Initiation and Link, but contains no mention of an Income product, payroll detection, or recurring-stream/cash-flow analytics built on transaction data — the specific capability the story asks about is absent from the pack.

   ⚑ flag

   Teller—none0/10

   Teller's docs cover balances, transactions, categorization, and identity, but no evidence describes recurring-stream detection, payroll detection, or an income-verification product built on the transaction data — this is a fair axis for an account-aggregation platform but unaddressed in the evidence pack.

   ⚑ flag

Enrichment

1. developerRaw bank transactions come back enriched — cleaned merchant names, categories, and logos — documented as a capability of the platform, not left as an exercise for me

   weight 2 · round to Teller
   Plaid—none0/10

   While Plaid's Transactions product is documented as returning transaction data, none of the evidence describes enrichment specifics like cleaned merchant names, categories, or logos being a documented feature — only raw transaction retrieval and webhooks are mentioned (plaid-docs-4, plaid-gh-1). Missing for 10: explicit documentation of merchant name cleaning, category taxonomy, and logo/icon fields as part of the Transactions response.

   • [claimed-docs] “Retrieve up to 24 months of transaction data and stay up-to-date with webhooks”
   • [github] “try { await plaidClient.transactionsSync(request); } catch (error) { const err = error.response.data; }”

   proof ↗⚑ flag

   Teller~partialclaimed4/10

   Docs confirm the transactions API includes categorization of transactions (teller-docs-16, teller-docs-3), but there is no documented evidence of merchant name cleaning/normalization or merchant logos as a platform capability. missing for 10: documented merchant-name cleaning, logo enrichment, independent corroboration of enrichment quality.

   • [claimed-docs] “the category that the transaction belongs to. Teller uses the following values for categorization”
   • [claimed-docs] “The transactions API exposes the ledger transactions of a financial account.”

   proof ↗⚑ flag

Transactions

1. developerPull transaction history for a connected account through the API — paginated, with documented history depth and a sync pattern for fetching only what changed

   weight 3 · round to Plaid
   Plaid✓fullclaimed8/10

   Plaid's Transactions docs confirm up to 24 months of history and webhook-based updates, and the plaid-node SDK demonstrates the transactionsSync pattern for fetching only changed data, matching the story's pagination/sync/history-depth requirements. missing for 10: no explicit mention of pagination cursor mechanics or rate limits, and no independent/hands-on corroboration of sync behavior beyond the SDK snippet.

   • [claimed-docs] “Retrieve up to 24 months of transaction data and stay up-to-date with webhooks”
   • [github] “try { await plaidClient.transactionsSync(request); } catch (error) { const err = error.response.data; }”
   • [github] “All errors can now be caught using try/catch with async/await or through promise chaining.”

   proof ↗⚑ flag

   Teller~partialcommunity6/10

   Docs confirm a transactions API with pagination support and category enrichment, plus webhooks that fire on data changes (a plausible 'fetch only what changed' mechanism), and a community report of successfully exporting transaction history via the API. However, there's no documented statement of how far back transaction history extends, and no explicit incremental-sync/cursor endpoint beyond generic webhook notifications. Missing for 10: documented history depth/lookback window, an explicit delta-sync or cursor-based endpoint (not just webhooks) for changed transactions.

   • [claimed-docs] “The transactions API exposes the ledger transactions of a financial account.”
   • [claimed-docs] “the transactions list endpoint supports pagination controls.”
   • [claimed-docs] “the category that the transaction belongs to. Teller uses the following values for categorization”
   • [claimed-docs] “Teller sends webhook events when specific conditions or changes are detected in user enrollments or their financial data.”
   • [claimed-docs] “To register a new webhook, you need to have a URL in your app that Teller can call. You can configure a new webhook from the Teller Dashboar…”
   • [community] “I built a little script to export my accounts to CSV/QIF. Super easy to use API! https://github.com/scottrobertson/teller-export”

   proof ↗⚑ flag