Mastercard Open Finance (Finicity) 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 Teller
   Mastercard Open Finance (Finicity)~partialclaimed3/10

   The evidence only briefly references a 'Connect' mechanism for linking accounts ('link them to at least one account via Connect') but provides no detail on a hosted, drop-in widget, server-side session creation, or token retrieval flow that a developer would use to avoid building institution UI. Missing for 10: documentation of Connect widget UI, session token generation API, and end-to-end token exchange after linking.

   • [claimed-docs] “link them to at least one account via Connect”

   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
   Mastercard Open Finance (Finicity)—none0/10

   The evidence pack covers Connect/account-linking, webhooks, and API products but never mentions OAuth-based bank authentication coverage, connectivity method mix, or a documented plan/status for retiring screen-scraped credential flows. Without explicit documentation of OAuth coverage vs. legacy scraping, this specific developer-facing transparency claim is unevidenced.

   • [claimed-docs] “link them to at least one account via Connect”
   • [claimed-docs] “Webhooks allow you to receive real-time notifications when specific events occur, eliminating the need for constant polling.”

   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 drawn
   Mastercard Open Finance (Finicity)—none0/10

   The evidence pack covers account data products, webhooks, onboarding, and testing personas, but nothing documents connection health statuses (expired/revoked), a re-authentication or 'update mode' flow, or any repair-without-restart mechanism for broken links. Missing for 10: documented connection status states (e.g., expired/revoked/error), an update/re-auth flow API or UI, and any evidence of preserving existing account links during re-auth.

   • [claimed-docs] “Webhooks allow you to receive real-time notifications when specific events occur, eliminating the need for constant polling.”
   • [claimed-docs] “link them to at least one account via Connect”

   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 Mastercard Open Finance (Finicity)
   Mastercard Open Finance (Finicity)✓fullprobed8/10

   A probe confirms llms.txt is live at developer.mastercard.com/llms.txt (HTTP 200), and Mastercard also documents an agent-oriented MCP toolkit with dynamic code generation for agents. Missing for 10: no independent third-party confirmation that agents actually consume this llms.txt effectively, and no explicit doc listing Open Finance-specific sections within it.

   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.mastercard.com/llms.txt # Mastercard Developers Mastercard Developers is a comprehensive API p…”
   • [probe] “official MCP server documented at https://developer.mastercard.com/platform/documentation/agent-toolkit/mcp-overview/”
   • [claimed-docs] “Dynamic Code Generation: Generate accurate, working code examples based on current API specifications”
   • [claimed-docs] “I need to integrate Open Finance to verify account ownership and check balances for my fintech app”

   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 Mastercard Open Finance (Finicity)
   Mastercard Open Finance (Finicity)~partialclaimed6/10

   As a pure REST API platform, Open Finance is inherently headless — it uses PartnerID/secret token auth (docs-10, docs-23), an OpenAPI spec with generated client libraries (mastercard-open-finance-gh-1), and a non-billable 'Test Drive' sandbox with scripted test personas (docs-24, docs-25) suitable for automated/CI testing. Missing for 10: no explicit CI/CD pipeline examples, no documented headless SDK/CLI runner, and no first-party guidance on automating the flow end-to-end in a build pipeline.

   • [claimed-docs] “To create a token, you are required to provide the PartnerID along with the corresponding secret and appKey.”
   • [claimed-docs] “Use your Partner ID and Secret with the following endpoint whenever you need to generate a new access token”
   • [claimed-docs] “Test Drive is a non-billable, unlimited plan that provides access to all Open Finance API endpoints.”
   • [claimed-docs] “we provide you with a set of testing personas. Each persona represents an example of a user who might use your app.”
   • [github] “The test project generates an API client library from the API specification like you would do in a real application”

   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 Mastercard Open Finance (Finicity)
   Mastercard Open Finance (Finicity)✓fullprobed7/10

   Mastercard documents an official Agent Toolkit MCP server (mcp-overview) that includes dynamic code generation and an example use case directly referencing Open Finance verification and balance checks, confirming AI agents can connect via this official MCP server to access Open Finance APIs. Missing for 10: independent/hands-on corroboration of the MCP server working with Open Finance endpoints, and detailed API-to-tool mapping documentation.

   • [claimed-docs] “Dynamic Code Generation: Generate accurate, working code examples based on current API specifications”
   • [claimed-docs] “I need to integrate Open Finance to verify account ownership and check balances for my fintech app”
   • [probe] “official MCP server documented at https://developer.mastercard.com/platform/documentation/agent-toolkit/mcp-overview/”

   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
   Mastercard Open Finance (Finicity)—none0/10

   No evidence of an official CLI tool; evidence covers APIs, webhooks, MCP server, and SDK/test client generation but nothing describing a command-line interface for AI-native workflows. Missing for 10: any mention of an official CLI, its installation, or its use in agentic/AI workflows.

   ⚑ 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 Mastercard Open Finance (Finicity)
   Mastercard Open Finance (Finicity)✓fullprobed8/10

   Mastercard Open Finance exposes a well-documented public REST API (accounts, balances, transactions, ownership verification, webhooks) with OpenAPI spec, token-based auth, sandbox/test-drive access, and even an llms.txt plus official MCP toolkit for agent-driven access. missing for 10: independent third-party developer confirmation of API usability/reliability beyond vendor docs.

   • [claimed-docs] “To create a token, you are required to provide the PartnerID along with the corresponding secret and appKey.”
   • [claimed-docs] “Use your Partner ID and Secret with the following endpoint whenever you need to generate a new access token”
   • [claimed-docs] “Test Drive is a non-billable, unlimited plan that provides access to all Open Finance API endpoints.”
   • [github] “The test project generates an API client library from the API specification like you would do in a real application”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.mastercard.com/llms.txt # Mastercard Developers Mastercard Developers is a comprehensive API p…”
   • [probe] “official MCP server documented at https://developer.mastercard.com/platform/documentation/agent-toolkit/mcp-overview/”
   • [claimed-docs] “Dynamic Code Generation: Generate accurate, working code examples based on current API specifications”

   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
   Mastercard Open Finance (Finicity)—none0/10

   Evidence shows PartnerID/secret/appKey token generation for API access (docs-10, docs-23) but no mention of scoped, least-privilege, or per-agent credential issuance — auth appears to be a single partner-level secret rather than granular scoped tokens for agents. Missing for 10: any documentation of scoped/limited-permission API keys, per-agent credential issuance, or role-based access control for agent use.

   • [claimed-docs] “To create a token, you are required to provide the PartnerID along with the corresponding secret and appKey.”
   • [claimed-docs] “Use your Partner ID and Secret with the following endpoint whenever you need to generate a new access token”

   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 Teller
   Mastercard Open Finance (Finicity)~partialclaimed3/10

   The only relevant evidence is a GitHub repo showing an OpenAPI-generated client library used for testing, not a fully documented, officially published SDK across languages. Missing for 10: dedicated official SDK repositories/packages (e.g., npm, PyPI, Maven), SDK version support docs, and independent developer confirmation of SDK usability.

   • [github] “The test project generates an API client library from the API specification like you would do in a real application”

   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
   Mastercard Open Finance (Finicity)✓fullclaimed7/10

   Docs explicitly describe webhook support for real-time event notifications (avoiding polling) and a subscription-based OBWMS API letting developers subscribe to specific events. Missing for 10: concrete webhook payload/setup examples, independent/hands-on confirmation, and detail on programmatic subscription management via API/SDK.

   • [claimed-docs] “Webhooks allow you to receive real-time notifications when specific events occur, eliminating the need for constant polling.”
   • [claimed-docs] “OBWMS will provide a comprehensive API for managing real-time event notifications, enabling you to subscribe to specific events, ensuring yo…”

   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
   Mastercard Open Finance (Finicity)—none0/10

   The evidence shows Mastercard Open Finance exposes categorized financial data (transaction types, recurring transactions, spending, loan payments) via APIs, and a separate MCP agent toolkit for developers to generate code, but there is no evidence of AI-generated insights or suggestions surfaced to an end-user inside the product itself.

   • [claimed-docs] “Insights into: * [Transaction types] * [Recurring transactions] * [Consumer spending] * [Loan payments]”
   • [claimed-docs] “Dynamic Code Generation: Generate accurate, working code examples based on current API specifications”
   • [claimed-docs] “I need to integrate Open Finance to verify account ownership and check balances for my fintech app”

   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
   Mastercard Open Finance (Finicity)—none0/10

   Evidence shows webhooks for event notifications and an MCP toolkit for code generation, but nothing about scheduling or configuring autonomous background automations/workflows that run without user intervention. Missing for 10: any documentation of scheduled/triggered automation setup, autonomous workflow orchestration, or agentic task execution running independently in the background.

   • [claimed-docs] “Webhooks allow you to receive real-time notifications when specific events occur, eliminating the need for constant polling.”
   • [claimed-docs] “OBWMS will provide a comprehensive API for managing real-time event notifications, enabling you to subscribe to specific events, ensuring yo…”
   • [claimed-docs] “Dynamic Code Generation: Generate accurate, working code examples based on current API specifications”

   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 Mastercard Open Finance (Finicity)
   Mastercard Open Finance (Finicity)~partialprobed5/10

   Mastercard offers an official Agent Toolkit/MCP server with dynamic code generation and natural-language-friendly API access (e.g., 'I need to integrate Open Finance to verify account ownership and check balances'), which supports operating the platform via AI-native/natural-language workflows. However, this is a developer-integration tool rather than end-user natural-language command execution over the product's core financial functions. missing for 10: evidence of an end-user-facing natural-language interface, broader coverage of MCP tool capabilities beyond code generation, and independent/hands-on validation of the MCP server's reliability.

   • [claimed-docs] “Dynamic Code Generation: Generate accurate, working code examples based on current API specifications”
   • [claimed-docs] “I need to integrate Open Finance to verify account ownership and check balances for my fintech app”
   • [probe] “official MCP server documented at https://developer.mastercard.com/platform/documentation/agent-toolkit/mcp-overview/”

   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
   Mastercard Open Finance (Finicity)—none0/10

   The evidence shows extensive product/API documentation, an OpenAPI spec-driven test client, and a 'Test Drive' sandbox plan, but nothing describes an interactive API reference (e.g., Swagger/Postman-style try-it console) with runnable code examples in the docs portal itself.

   • [claimed-docs] “Test Drive is a non-billable, unlimited plan that provides access to all Open Finance API endpoints.”
   • [github] “The test project generates an API client library from the API specification like you would do in a real application”
   • [claimed-docs] “we provide you with a set of testing personas”

   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 to Mastercard Open Finance (Finicity)
   Mastercard Open Finance (Finicity)✓fullprobed8/10

   A GitHub repo (open-banking-us-openapi) explicitly generates an API client library from a published OpenAPI specification, confirming a machine-readable spec is downloadable/usable, and Mastercard also exposes an llms.txt and MCP toolkit for machine-consumable API access. Missing for 10: no direct link/documentation showing a single canonical spec file download page or version history, and no independent third-party confirmation of spec completeness.

   • [github] “The test project generates an API client library from the API specification like you would do in a real application”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.mastercard.com/llms.txt # Mastercard Developers Mastercard Developers is a comprehensive API p…”
   • [probe] “official MCP server documented at https://developer.mastercard.com/platform/documentation/agent-toolkit/mcp-overview/”
   • [claimed-docs] “Dynamic Code Generation: Generate accurate, working code examples based on current API specifications”

   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
   Mastercard Open Finance (Finicity)✓fullclaimed8/10

   Mastercard provides a dedicated non-billable 'Test Drive' plan with unlimited access to all Open Finance API endpoints plus documented testing personas representing example users, explicitly for sandbox-style integration testing without production data, and a GitHub sample project generating a client from the API spec for testing. missing for 10: independent/hands-on confirmation of full production-data isolation and details on sandbox data realism or limitations.

   • [claimed-docs] “Test Drive is a non-billable, unlimited plan that provides access to all Open Finance API endpoints.”
   • [claimed-docs] “we provide you with a set of testing personas”
   • [claimed-docs] “we provide you with a set of testing personas. Each persona represents an example of a user who might use your app.”
   • [github] “The test project generates an API client library from the API specification like you would do in a real application”

   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
   Mastercard Open Finance (Finicity)—none0/10

   No evidence pack items mention API versioning scheme or a documented deprecation policy; docs reference endpoints, onboarding, testing, and webhooks but not version lifecycle management.

   ⚑ 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
   Mastercard Open Finance (Finicity)—none0/10

   No evidence describes batch/bulk endpoints or multi-item operations (e.g., submitting many account IDs or requests in a single call); documented APIs appear per-account/per-transaction oriented, and webhooks only address real-time single-event notifications, not bulk processing.

   ⚑ 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 drawn
   Mastercard Open Finance (Finicity)—none0/10

   Webhooks provide event notifications but there is no evidence of user-definable rules or automated triggered actions based on those events; missing for 10: rule-definition engine, conditional logic, automated action execution tied to events.

   • [claimed-docs] “Webhooks allow you to receive real-time notifications when specific events occur, eliminating the need for constant polling.”
   • [claimed-docs] “OBWMS will provide a comprehensive API for managing real-time event notifications, enabling you to subscribe to specific events, ensuring yo…”

   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
   Mastercard Open Finance (Finicity)—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 Teller
   Mastercard Open Finance (Finicity)~partialclaimed6/10

   Mastercard's docs list dedicated 'Get ACH details' and 'Validate account details' products alongside account-ownership verification and balance checks, which together match the story of retrieving account/routing data and validating funding source without micro-deposits. However, the evidence pack only shows product titles/index links rather than detailed descriptions of the actual data returned (e.g., explicit account/routing number fields, tokenization format, or confirmation that validation replaces micro-deposits). Missing for 10: detailed API schema/response showing routing+account numbers or tokens, explicit statement that validation eliminates micro-deposit verification, and independent developer confirmation of real-world usage.

   • [claimed-docs] “Get ACH details”
   • [claimed-docs] “Get [ACH details]”
   • [claimed-docs] “Validate account details”
   • [claimed-docs] “Validate [account details]”
   • [claimed-docs] “Retrieves account ownership details (name, address, email and phone - where available) from a connected account at a financial institution.”
   • [claimed-docs] “you can send customer data to our match account ownership details endpoint to receive confidence scores comparing the provided data and the …”

   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
   Mastercard Open Finance (Finicity)✓fullclaimed7/10

   Docs explicitly describe an Account Balance service returning real-time or cached balance data from the connected FI, matching the NSF/risk-check use case, and MCP overview references verifying ownership and checking balances as a supported integration flow. Missing for 10: explicit request/response schema examples, independent/hands-on confirmation of real-time latency, and no direct mention of pre-payment NSF workflow tying balance check to payment initiation.

   • [claimed-docs] “The Account Balance service provides real-time or cached bank account balance information from your customer's Financial Institution (FI).”
   • [claimed-docs] “I need to integrate Open Finance to verify account ownership and check balances for my fintech app”

   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
   Mastercard Open Finance (Finicity)✓fullclaimed8/10

   Docs explicitly describe an Account Owner Verification service retrieving name, address, email and phone from the connected FI account, and a match-account-ownership endpoint that compares provided customer data against the bank's on-file details with confidence scores — directly matching the ops matching workflow. Missing for 10: independent/hands-on corroboration beyond vendor docs and more detail on data completeness/edge cases across FIs.

   • [claimed-docs] “Retrieves account ownership details (name, address, email and phone - where available) from a connected account at a financial institution.”
   • [claimed-docs] “you can send customer data to our match account ownership details endpoint to receive confidence scores comparing the provided data and the …”
   • [claimed-docs] “I need to integrate Open Finance to verify account ownership and check balances for my fintech app”

   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 Mastercard Open Finance (Finicity)
   Mastercard Open Finance (Finicity)~partialclaimed5/10

   Mastercard Open Finance provides account ownership verification, balance, ACH details, and account aggregation APIs accessible via token-based auth (PartnerID/secret) that developers can integrate into payment processing flows, and it supports Connect for account linking. However, the evidence does not document specific third-party payment processor/platform integration partnerships or an explicit token-exchange handoff mechanism to hand verified credentials to external processors — the story implies pre-built plug-and-play integrations rather than raw APIs a developer must wire up themselves. missing for 10: named third-party processor/platform integration partners, explicit token-exchange-to-processor handoff documentation, independent confirmation of such integrations working in production.

   • [claimed-docs] “Retrieves account ownership details (name, address, email and phone - where available) from a connected account at a financial institution.”
   • [claimed-docs] “The Account Balance service provides real-time or cached bank account balance information from your customer's Financial Institution (FI).”
   • [claimed-docs] “Get ACH details”
   • [claimed-docs] “To create a token, you are required to provide the PartnerID along with the corresponding secret and appKey.”
   • [claimed-docs] “Use your Partner ID and Secret with the following endpoint whenever you need to generate a new access token”
   • [claimed-docs] “link them to at least one account via Connect”

   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 drawn
   Mastercard Open Finance (Finicity)~partialprobed6/10

   Mastercard Open Finance provides structured JSON APIs with documented schemas for account, transaction, balance, and enrichment data (transaction categorization, recurring transactions, spending insights), an OpenAPI spec with generated client libraries, and even an official MCP/agent-toolkit for AI consumption. However, evidence doesn't show explicit example JSON payloads or schema definitions in the pack, nor confirmation that enrichment fields are agent-optimized (e.g., no heuristic parsing needed) versus requiring developer interpretation. missing for 10: concrete JSON schema examples/response samples, explicit confirmation that enrichment output avoids downstream heuristic parsing, independent developer corroboration of agent-readiness.

   • [claimed-docs] “The Transaction Data Services provide account transaction data.”
   • [claimed-docs] “The account and transaction data elements returned from Account Aggregation and Transaction Data vary depending on the account type.”
   • [claimed-docs] “Insights into: * [Transaction types] * [Recurring transactions] * [Consumer spending] * [Loan payments]”
   • [github] “The test project generates an API client library from the API specification like you would do in a real application”
   • [probe] “official MCP server documented at https://developer.mastercard.com/platform/documentation/agent-toolkit/mcp-overview/”
   • [claimed-docs] “Dynamic Code Generation: Generate accurate, working code examples based on current API specifications”

   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 Mastercard Open Finance (Finicity)
   Mastercard Open Finance (Finicity)~partialprobed6/10

   Mastercard's Open Finance APIs clearly support the core actions an agent would need — creating link sessions via Connect, retrieving balances (Account Balance service), pulling transactions (Transaction Data), and managing connections/webhooks — all gated by PartnerID/secret/appKey OAuth tokens that function as scoped credentials. There is also a documented official MCP surface (agent-toolkit/mcp-overview) explicitly referencing Open Finance use cases like verifying ownership and checking balances, but its documented function is 'dynamic code generation' for developers rather than confirmed direct agentic execution of live account operations. missing for 10: evidence the MCP server itself executes link-session/balance/transaction calls (vs. just generating code samples), and independent/hands-on confirmation of an agent operating end-to-end with scoped MCP credentials.

   • [claimed-docs] “The Account Balance service provides real-time or cached bank account balance information from your customer's Financial Institution (FI).”
   • [claimed-docs] “The Transaction Data Services provide account transaction data.”
   • [claimed-docs] “Webhooks allow you to receive real-time notifications when specific events occur, eliminating the need for constant polling.”
   • [claimed-docs] “To create a token, you are required to provide the PartnerID along with the corresponding secret and appKey.”
   • [claimed-docs] “Use your Partner ID and Secret with the following endpoint whenever you need to generate a new access token”
   • [claimed-docs] “link them to at least one account via Connect”
   • [claimed-docs] “Dynamic Code Generation: Generate accurate, working code examples based on current API specifications”
   • [claimed-docs] “I need to integrate Open Finance to verify account ownership and check balances for my fintech app”
   • [probe] “official MCP server documented at https://developer.mastercard.com/platform/documentation/agent-toolkit/mcp-overview/”

   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
   Mastercard Open Finance (Finicity)—none0/10

   Evidence pack covers data retrieval, verification, transaction data, webhooks, onboarding tokens, and testing personas, but nowhere documents an end-user-facing consent management portal, dashboard, or revocation mechanism for shared bank-data access. No mention of a consent surface for users to view or revoke connected apps' access.

   ⚑ 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
   Mastercard Open Finance (Finicity)—none0/10

   No evidence pack item documents a delete/disconnect endpoint, user data purge process, or data retention/deletion policy for connections or held account data; coverage is limited to data retrieval, verification, and onboarding APIs.

   ⚑ 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 Mastercard Open Finance (Finicity)
   Mastercard Open Finance (Finicity)~partialclaimed4/10

   The docs show a product-based API structure (separate endpoints for account ownership, balance, transactions, ACH, etc.), which implicitly allows requesting only specific data products rather than a single blob, but there is no explicit documentation of scoped consent tokens, granular permission grants, or data-minimization controls presented to developers. missing for 10: explicit consent-scoping API/parameters, documentation of minimal-data-grant mechanisms, evidence of per-scope authorization tokens, and any independent confirmation of data-minimization enforcement.

   • [claimed-docs] “Retrieves account ownership details (name, address, email and phone - where available) from a connected account at a financial institution.”
   • [claimed-docs] “The Account Balance service provides real-time or cached bank account balance information from your customer's Financial Institution (FI).”
   • [claimed-docs] “The Transaction Data Services provide account transaction data.”
   • [claimed-docs] “The account and transaction data elements returned from Account Aggregation and Transaction Data vary depending on the account type.”
   • [claimed-docs] “[Account] and [transaction] details”

   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 to Teller
   Mastercard Open Finance (Finicity)—none0/10

   Evidence shows account balance can be 'real-time or cached' and webhooks provide event notifications, but there is no documented API endpoint or explicit refresh semantics (e.g., a force-refresh trigger, freshness guarantees, or polling-for-refresh-status flow) for triggering an on-demand data refresh. Missing for 10: an explicit refresh/force-update endpoint, documented refresh semantics (sync vs async, staleness thresholds), and any independent confirmation of on-demand refresh behavior.

   • [claimed-docs] “The Account Balance service provides real-time or cached bank account balance information from your customer's Financial Institution (FI).”
   • [claimed-docs] “Webhooks allow you to receive real-time notifications when specific events occur, eliminating the need for constant polling.”
   • [claimed-docs] “The Transaction Data Services provide account transaction data.”

   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 Mastercard Open Finance (Finicity)
   Mastercard Open Finance (Finicity)~partialclaimed6/10

   Docs confirm webhooks exist for real-time event notifications instead of polling, and OBWMS lets you subscribe to specific events; transaction/notification-type docs exist too. However, there's no evidence of webhook payload signing/verification, and no explicit documentation enumerating events like balance updates or connection-state changes with delivery guarantees. Missing for 10: signature verification mechanism, explicit event-type catalog (transactions/balances/connection state), delivery retry/reliability details.

   • [claimed-docs] “Webhooks allow you to receive real-time notifications when specific events occur, eliminating the need for constant polling.”
   • [claimed-docs] “OBWMS will provide a comprehensive API for managing real-time event notifications, enabling you to subscribe to specific events, ensuring yo…”
   • [claimed-docs] “[Transaction notifications]”

   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 to Teller
   Mastercard Open Finance (Finicity)—none0/10

   The evidence pack covers API capabilities (verification, balances, transaction data, webhooks, onboarding) but contains no published institution-coverage numbers, geographic breakdowns, or bank-reach statistics that a founder could check against their users' banks.

   ⚑ 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 drawn
   Mastercard Open Finance (Finicity)—none0/10

   The evidence pack covers API products (balance, ownership, transaction data, webhooks, onboarding) but contains no mention of institution status dashboards, outage/degradation signals, or error codes distinguishing bank-side vs integration-side issues.

   ⚑ 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
   Mastercard Open Finance (Finicity)—none0/10

   The evidence lists multiple separate data products (account ownership, balances, transactions) and mentions a generic 'Connect' linking step, but nothing describes a single link/Connect session simultaneously provisioning auth, balances, transactions, and identity without repeated connection flows per product.

   ⚑ 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 drawn
   Mastercard Open Finance (Finicity)~partialclaimed5/10

   Docs show a self-serve-ish onboarding path (PartnerID/secret/appKey token generation, a non-billable unlimited 'Test Drive' plan, and test personas for sandbox account linking) and a GitHub OpenAPI spec that can generate a client library, but there's no explicit runnable quickstart tutorial or multi-language official client libraries beyond the one generated test project. Missing for 10: an explicit step-by-step quickstart guide, published official SDKs in multiple languages, and clear evidence of instant self-serve API key issuance without a sales/partner approval step.

   • [claimed-docs] “To create a token, you are required to provide the PartnerID along with the corresponding secret and appKey.”
   • [claimed-docs] “Use your Partner ID and Secret with the following endpoint whenever you need to generate a new access token”
   • [claimed-docs] “Test Drive is a non-billable, unlimited plan that provides access to all Open Finance API endpoints.”
   • [claimed-docs] “we provide you with a set of testing personas. Each persona represents an example of a user who might use your app.”
   • [github] “The test project generates an API client library from the API specification like you would do in a real application”

   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 Teller
   Mastercard Open Finance (Finicity)~partialclaimed6/10

   Docs confirm a dedicated Test Drive sandbox with unlimited access to all endpoints, testing personas representing different user scenarios, and a GitHub sample project generating a real API client for end-to-end testing — covering linking, data retrieval, and onboarding tokens. However, there is no explicit documentation of error-state simulation or a catalog of documented test credentials/institutions with specific failure scenarios. Missing for 10: explicit documented test credentials list, coverage of error/failure state simulation, and independent/hands-on confirmation of the sandbox experience.

   • [claimed-docs] “we provide you with a set of testing personas”
   • [claimed-docs] “Test Drive is a non-billable, unlimited plan that provides access to all Open Finance API endpoints.”
   • [claimed-docs] “we provide you with a set of testing personas. Each persona represents an example of a user who might use your app.”
   • [github] “The test project generates an API client library from the API specification like you would do in a real application”
   • [claimed-docs] “link them to at least one account via Connect”

   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 to Mastercard Open Finance (Finicity)
   Mastercard Open Finance (Finicity)~partialclaimed6/10

   As an API-first data platform, virtually all core functions (account verification, balances, transactions, ACH details, webhooks/event management, token generation) are exposed directly via documented REST APIs rather than gated behind a UI, and even administrative functions like webhook subscriptions and token creation are API-driven (docs-9, docs-23, docs-26). However, the 'Connect' account-linking flow is a hosted widget/UI experience (docs-27) whose full API-equivalence isn't evidenced, and there's no explicit confirmation that all developer-portal/dashboard actions (billing, partner management) have API parity. Missing for 10: explicit API equivalents for the Connect linking UI, and confirmation that portal/dashboard admin tasks are fully scriptable.

   • [claimed-docs] “Webhooks allow you to receive real-time notifications when specific events occur, eliminating the need for constant polling.”
   • [claimed-docs] “Use your Partner ID and Secret with the following endpoint whenever you need to generate a new access token”
   • [claimed-docs] “OBWMS will provide a comprehensive API for managing real-time event notifications, enabling you to subscribe to specific events, ensuring yo…”
   • [claimed-docs] “link them to at least one account via Connect”
   • [claimed-docs] “The Transaction Data Services provide account transaction data.”
   • [claimed-docs] “Retrieves account ownership details (name, address, email and phone - where available) from a connected account at a financial institution.”

   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
   Mastercard Open Finance (Finicity)—none0/10

   This is a B2B financial data API platform, not a consumer product with user-owned data to export; the evidence shows no data export/portability feature for end users to take their data out in open formats and leave. No mention of any account/data export or account deletion/portability capability anywhere in the docs.

   ⚑ 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
   Mastercard Open Finance (Finicity)—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

   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 Teller
   Mastercard Open Finance (Finicity)—none0/10

   The evidence pack describes the 'Pay' product family only as verification (account ownership, balance, ACH details, match), fraud/success prediction, and switching services — none of the docs describe an actual payment-initiation endpoint that moves funds from a connected account, nor any stated live geographies for such a capability. Without a documented API to actually initiate a bank payment, this axis is unmet.

   • [claimed-docs] “Retrieves account ownership details (name, address, email and phone - where available) from a connected account at a financial institution.”
   • [claimed-docs] “The Account Balance service provides real-time or cached bank account balance information from your customer's Financial Institution (FI).”
   • [claimed-docs] “you can send customer data to our match account ownership details endpoint to receive confidence scores comparing the provided data and the …”
   • [claimed-docs] “Predict [payment success]”
   • [claimed-docs] “Switch [deposits and bill payments]”
   • [claimed-docs] “Get ACH details”

   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
   Mastercard Open Finance (Finicity)—none0/10

   Evidence covers account data (balances, ownership, transactions), ACH details, and 'switch deposits and bill payments' but nothing documents variable recurring payments, standing consents, or a recurring debit/payment-initiation flow — this product's Pay APIs appear focused on verification (account owner, balance, ACH details) rather than initiating recurring debits.

   ⚑ 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
   Mastercard Open Finance (Finicity)—none0/10

   No evidence anywhere in the pack discusses data residency, regional storage options, or geographic controls for where customer data is stored/processed. This is an applicable axis for a financial data platform handling sensitive PII, but nothing addresses it.

   ⚑ 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
   Mastercard Open Finance (Finicity)—none0/10

   The evidence pack covers API products (account data, verification, transactions, webhooks, onboarding) but contains no mention of data retention policies, deletion controls, or user-facing privacy/data-lifecycle management tools. Missing for 10: any documentation of data retention periods, deletion/erasure APIs, or consumer-facing controls over stored financial data.

   ⚑ 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 to Mastercard Open Finance (Finicity)
   Mastercard Open Finance (Finicity)~partialclaimed6/10

   Docs confirm transaction data services with insights into recurring transactions, transaction types, consumer spending, and loan payments, plus credit-decisioning report APIs — directly supporting cash-flow/recurring-stream signals. However, there's no explicit mention of payroll detection or a dedicated income-verification product built on this data. missing for 10: explicit payroll/income detection feature, named income-verification product, independent validation of accuracy.

   • [claimed-docs] “The Transaction Data Services provide account transaction data.”
   • [claimed-docs] “Insights into: * [Transaction types] * [Recurring transactions] * [Consumer spending] * [Loan payments]”
   • [claimed-docs] “APIs for credit decisioning [reports]”
   • [claimed-docs] “The account and transaction data elements returned from Account Aggregation and Transaction Data vary depending on the account type.”

   proof ↗⚑ 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 drawn
   Mastercard Open Finance (Finicity)~partialclaimed4/10

   Docs confirm Transaction Data Services return categorized insights (transaction types, recurring transactions, consumer spending, loan payments), which implies some enrichment/categorization layer, but nothing explicitly documents merchant-name cleansing or logo attachment as a first-class capability. Missing for 10: explicit documentation of merchant name normalization/cleanup and logo enrichment fields in the transaction schema.

   • [claimed-docs] “The Transaction Data Services provide account transaction data.”
   • [claimed-docs] “The account and transaction data elements returned from Account Aggregation and Transaction Data vary depending on the account type.”
   • [claimed-docs] “Insights into: * [Transaction types] * [Recurring transactions] * [Consumer spending] * [Loan payments]”

   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 Teller
   Mastercard Open Finance (Finicity)~partialclaimed5/10

   Evidence confirms a dedicated Transaction Data Services API that returns account/transaction details and varies by account type, plus a webhook/notification system explicitly framed as eliminating constant polling, which implies a change-based sync pattern. However, no evidence documents pagination mechanics or a specific stated history depth (e.g., days/months of transactions) for the transaction endpoint. missing for 10: explicit pagination documentation, stated transaction history depth/lookback window, explicit delta/cursor sync pattern for transactions specifically (webhooks reference is generic, not transaction-specific).

   • [claimed-docs] “The Transaction Data Services provide account transaction data.”
   • [claimed-docs] “The account and transaction data elements returned from Account Aggregation and Transaction Data vary depending on the account type.”
   • [claimed-docs] “Webhooks allow you to receive real-time notifications when specific events occur, eliminating the need for constant polling.”
   • [claimed-docs] “[Account] and [transaction] details”
   • [claimed-docs] “Insights into: * [Transaction types] * [Recurring transactions] * [Consumer spending] * [Loan payments]”
   • [claimed-docs] “OBWMS will provide a comprehensive API for managing real-time event notifications, enabling you to subscribe to specific events, ensuring yo…”

   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