MX vs Teller
enterprise-custom
·free-tier · usage-based
MX wins · 18–10 (19 drawn)
Account linking — stories about account linking in this arenaAccount linking
Stories about account linking in this arena
Hosted flows
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 MXMX docs describe the Connect Widget as a ready-made, embeddable UI that prompts end users to authenticate with their institution credentials, paired with the Platform API for server-side session/member creation, matching the drop-in hosted flow with no custom institution UI needed. Webhooks and member/account tokens (e.g., guid-based member connections) round out the server-to-client flow. missing for 10: explicit mention of a 'connect token' generation endpoint and independent/third-party confirmation of the end-to-end session-create-then-widget-open flow.
- [claimed-docs] “MX's ready-made UI that can be embedded in your application to aggregate users' account data by prompting end users to connect to their fina…”
- [claimed-docs] “Use the Connect Widget and Platform API to let end users connect to their accounts.”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice.”
- [claimed-docs] “To test OAuth in the Connect Widget when it's embedded in a WebView, you must load the financial institution's OAuth window in the device's …”
- [claimed-docs] “MX automatically aggregates each `member` approximately every 24 hours.”
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.”
Oauth
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 drawnMXnone0/10Evidence shows MX supports OAuth in its Connect Widget (mx-docs-23) but there is no documentation of overall OAuth coverage across institutions or any stated plan for retiring legacy credential-based (screen-scraped) connections, which is the core of this story.
- [claimed-docs] “To test OAuth in the Connect Widget when it's embedded in a WebView, you must load the financial institution's OAuth window in the device's …”
Tellernone0/10Teller'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.”
Repair
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 drawnMXnone0/10The evidence pack covers MX's connectivity products (aggregation, IAV, AOI, microdeposits, webhooks) but never documents connection/member status codes (e.g., expired, revoked, challenged) or a dedicated re-authentication/update flow that lets users fix a broken link without re-onboarding. This is a plausible and expected capability for an account-aggregation platform, but nothing in the pack substantiates it.
Tellernone0/10The 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`”
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
Agent access
ai-native userPoint an agent at llms.txt or agent-oriented docs
weight 2 · round to MXMX hosts a working llms.txt at docs.mx.com/llms.txt (confirmed HTTP 200 with structured doc links) and also documents an official MCP server, both explicitly agent-oriented entry points into their docs. Missing for 10: independent third-party confirmation of an AI agent successfully consuming these resources end-to-end.
Tellernone0/10Probes 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.
ai-native userRun the product headlessly / in CI for automation
weight 2 · round drawnMX is an API-first platform with a documented REST/OpenAPI spec (mx-gh-1, mx-docs-12/26) and webhooks (mx-docs-7/22) that could be driven headlessly from CI, but there is no explicit evidence of a CLI, headless SDK mode, or documented CI/automation workflow — the Connect Widget appears UI-embedded (mx-docs-9, mx-docs-21) which cuts against pure headless use. missing for 10: explicit CI/headless usage docs, a CLI or automation-focused SDK, confirmation that Connect flows can run without embedded UI.
- [github] “This repository contains the OpenAPI specification for the MX Platform API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API and its request and response payloads.”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice. This enables you to subscribe to certain events”
- [claimed-docs] “MX's ready-made UI that can be embedded in your application to aggregate users' account data by prompting end users to connect to their fina…”
- [claimed-docs] “Use the Connect Widget and Platform API to let end users connect to their accounts.”
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”
ai-native userConnect an agent via an official MCP server
weight 3 · round to MXMX documents an official MCP server at docs.mx.com/mcp, confirmed via probe, indicating a first-party MCP integration point. Missing for 10: detailed setup/config docs excerpt, independent/hands-on confirmation of the MCP server working, and specifics on tool coverage exposed via MCP.
- [probe] “official MCP server documented at https://docs.mx.com/mcp”
ai-native userUse an official CLI
weight 2 · round drawnMXnone0/10MX is a financial data API/SDK platform; no evidence of an official CLI tool for developers or AI-native workflows appears in the evidence pack — only API specs, webhooks, and a widget/UI. Evidence exists of an MCP server and OpenAPI spec, but no CLI is documented.
Tellernone0/10No 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”
ai-native userDrive the product through a documented public API
weight 3 · round to MXMX exposes a documented Platform API with OpenAPI spec (available via GitHub and Postman import), REST endpoints across account verification, aggregation, statements, and webhooks, plus llms.txt and an MCP endpoint enabling AI-native access. Missing for 10: the official openapi.json isn't directly hosted at expected docs.mx.com paths (probe 404s), and there's no independent third-party corroboration of API robustness beyond MX's own docs.
- [github] “This repository contains the OpenAPI specification for the MX Platform API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API and its request and response payloads.”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.mx.com/llms.txt # MX Documentation - [Welcome to the MX Documentation](https://docs.mx.com/index.m…”
- [probe] “official MCP server documented at https://docs.mx.com/mcp”
- [claimed-docs] “Use the Connect Widget and Platform API to let end users connect to their accounts.”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice. This enables you to subscribe to certain events”
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”
ai-native userIssue scoped/least-privilege API credentials for an agent
weight 2 · round drawnMXnone0/10No evidence of scoped/least-privilege API credential issuance for agents—docs cover data connectivity, webhooks, OpenAPI spec, and even an MCP server reference, but nothing about issuing restricted-scope API keys/tokens for AI agent use.
Tellernone0/10Teller'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”
ai-native userBuild against official SDKs
weight 2 · round to TellerMX publishes an official OpenAPI specification (mx-gh-1) and supports importing it into Postman for API exploration (mx-docs-12/26), which enables building typed/generated clients, but there is no evidence of dedicated first-party SDK libraries (e.g., Python, JS, Java) or SDK-specific documentation/examples. missing for 10: named official SDK packages/libraries, language-specific SDK docs, and independent confirmation of SDK usage.
- [github] “This repository contains the OpenAPI specification for the MX Platform API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API and its request and response payloads.”
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, …”
ai-native userSubscribe to events via webhooks
weight 2 · round to MXMX documents a webhooks system that sends HTTPS POST callbacks so developers can subscribe to specific events, clearly supporting webhook-based event subscription. Missing for 10: an exhaustive list of supported event types and independent/hands-on confirmation beyond first-party docs.
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice. This enables you to subscribe to certain events”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice.”
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.”
Agentic features
ai-native userGet AI-generated insights and suggestions from my data inside the product
weight 2 · round to MXMX's marketing pages describe personalized financial guidance and a conversational 'ask about your money' experience generated from each consumer's data (mx-docs-14, mx-docs-27), which matches the AI-insights story, and mx-docs-13 references 'data-driven intelligence.' However, these are thin, high-level marketing snippets rather than detailed product docs, and there is no independent/hands-on corroboration or technical documentation of the underlying AI model or insight-generation pipeline. Missing for 10: dedicated technical documentation of the AI/insights feature, concrete examples of generated insights, and independent verification of the claim.
- [claimed-docs] “Use data-driven intelligence about your customers”
- [claimed-docs] “Personalized financial guidance generated from each consumer's financial data, surfaced in a relevant and timely experience”
- [claimed-docs] “Provide an experience where consumers can ask about their money in plain language and act on the answer, with every figure pulled from real …”
- [claimed-docs] “Access account and transaction history all in one view. Use the data to increase multi-product adoption, and build trust.”
ai-native userSet up automations that run autonomously in the background
weight 2 · round to TellerMX documents autonomous background behavior — automatic re-aggregation of accounts roughly every 24 hours and webhook callbacks for events — which could underpin background automations, and an MCP endpoint is referenced. However there's no evidence of a user-facing automation/workflow builder or agent-orchestration framework for setting up custom autonomous tasks. Missing for 10: explicit automation/workflow configuration tooling, evidence of AI-agent-driven autonomous task execution beyond scheduled sync, and independent confirmation of the MCP server's automation capabilities.
- [claimed-docs] “MX automatically aggregates each `member` approximately every 24 hours.”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice. This enables you to subscribe to certain events”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice.”
- [probe] “official MCP server documented at https://docs.mx.com/mcp”
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.”
ai-native userOperate the product with natural-language commands
weight 2 · round to MXMX documents an official MCP server (mx-probe-3) that would let AI agents issue natural-language commands against the platform, and marketing copy (mx-docs-27) describes enabling plain-language financial queries. However, there is no detailed documentation of the NL command set, limits, or hands-on confirmation of how well it works. Missing for 10: detailed MCP tool/command documentation, independent verification of NL command execution, and coverage of edge cases/limitations.
- [probe] “official MCP server documented at https://docs.mx.com/mcp”
- [claimed-docs] “Provide an experience where consumers can ask about their money in plain language and act on the answer, with every figure pulled from real …”
Tellernone0/10Teller 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.
Api quality
ai-native userExplore an interactive API reference with runnable examples
weight 2 · round to MXMX publishes an OpenAPI spec (mx-gh-1) that users can import into Postman to explore requests/responses (mx-docs-12, mx-docs-26), and provides a sandbox test-platform with test institutions (mx-docs-8). However, there is no evidence of an embedded, in-docs interactive API reference with directly runnable examples (e.g., a Swagger/Redoc-style try-it-now console) — probes for a hosted openapi.json on the docs site 404 (mx-probe-2), meaning users must leave the docs and use an external tool like Postman to run calls. Missing for 10: an in-browser interactive explorer with click-to-run examples, and confirmation the OpenAPI spec is directly hosted/interactive on docs.mx.com rather than requiring external import.
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API and its request and response payloads.”
- [github] “This repository contains the OpenAPI specification for the MX Platform API”
- [claimed-docs] “We offer four test institutions that you can use”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.mx.com/openapi.json, https://docs.mx.com/swagger.json, https://docs.mx.com/api/openapi.…”
Tellernone0/10Teller 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.”
ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)
weight 2 · round to MXMX explicitly documents downloading its OpenAPI Specification for import into Postman, and a dedicated GitHub repo (mxenabled/openapi) hosts the machine-readable spec. Missing for 10: no evidence of a standard hosted openapi.json endpoint (probe found 404s at common paths), so discovery relies on docs/GitHub rather than a canonical URL.
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API and its request and response payloads.”
- [github] “This repository contains the OpenAPI specification for the MX Platform API”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.mx.com/openapi.json, https://docs.mx.com/swagger.json, https://docs.mx.com/api/openapi.…”
Tellernone0/10Probes 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.
ai-native userTest against a sandbox environment without touching production data
weight 1 · round to TellerMX explicitly documents a test platform with four test institutions and OpenAPI spec/Postman import for exercising the API without touching real production financial data, plus dedicated guidance for testing the Connect Widget/OAuth flows. missing for 10: no explicit statement distinguishing a separate 'sandbox' credential set or environment isolation guarantee, and no independent/hands-on confirmation that test data never touches production systems.
- [claimed-docs] “We offer four test institutions that you can use”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API”
- [claimed-docs] “To test OAuth in the Connect Widget when it's embedded in a WebView, you must load the financial institution's OAuth window in the device's …”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API and its request and response payloads.”
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”
ai-native userRely on versioned APIs with a documented deprecation policy
weight 2 · round drawnMXnone0/10Evidence confirms MX publishes an OpenAPI spec (mx-gh-1, mx-docs-12/26) but nowhere documents API versioning conventions or a formal deprecation policy for breaking changes. Missing for 10: documented version numbering scheme, deprecation timeline/notice policy, changelog of breaking changes.
- [github] “This repository contains the OpenAPI specification for the MX Platform API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API and its request and response payloads.”
Tellernone0/10No 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.
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
ai-native userPerform bulk operations across many items at once
weight 2 · round drawnMXnone0/10The evidence describes per-user/per-account connectivity, aggregation, and identity verification features, but nothing documents bulk or batch operations across many items/accounts/users at once. Missing for 10: any batch API endpoints, bulk data export/import operations, or documentation of multi-item processing at scale.
Tellernone0/10Teller'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.”
ai-native userDefine rules that trigger actions automatically on events
weight 3 · round to MXMX provides webhooks that let subscribers receive event notifications (e.g., aggregation completion) which developers can use to trigger their own downstream actions, but there is no evidence of a native rules/automation engine where users define conditional trigger-action logic within MX itself. missing for 10: a documented rules/automation builder or conditional trigger-action configuration UI, evidence of built-in actions (not just external webhook consumption).
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice. This enables you to subscribe to certain events”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice.”
- [claimed-docs] “MX automatically aggregates each `member` approximately every 24 hours.”
Tellernone0/10Teller 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.”
ai-native userSchedule recurring jobs or workflows
weight 2 · round drawnMXnone0/10MX's aggregation happens automatically on a fixed ~24-hour cycle (mx-docs-25) and webhooks push events, but there is no evidence of user-defined recurring job/workflow scheduling, cron-like configuration, or workflow orchestration for AI-native users. missing for 10: user-configurable schedule/frequency controls, workflow/orchestration engine, any AI-native automation scheduling feature.
- [claimed-docs] “MX automatically aggregates each `member` approximately every 24 hours.”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice. This enables you to subscribe to certain events”
Balance ownership — stories about balance ownership in this arenaBalance ownership
Stories about balance ownership in this arena
Ach details
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 MXMX's Instant Account Verification explicitly retrieves account and routing numbers for demand deposit accounts without micro-deposits, and Tokenized Account Numbers (TANs) provide a secure tokenized alternative for ACH money movement, both documented as distinct from the separate microdeposits verification method. missing for 10: independent/hands-on corroboration beyond first-party docs.
- [claimed-docs] “you can connect to an end user's financial institution and retrieve account and routing numbers for their demand deposit accounts”
- [claimed-docs] “With Instant Account Verification, you can connect to an end user's financial institution and retrieve account and routing numbers for their…”
- [claimed-docs] “Tokenized Account Numbers (TANs) are substitute account numbers used for secure ACH money movement.”
- [claimed-docs] “Microdeposits is different—it provides an alternate method for verifying account ownership by making small test deposits to an account.”
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…”
Balances
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 TellerMX documents a balance product ('Get the available balance for an end user's financial accounts') confirming real-time balance retrieval for connected accounts, which aligns with the story's core ask. However, there is no explicit mention of NSF/risk-check use case, no documented latency/real-time SLA, and no dedicated endpoint spec or code sample shown in evidence. missing for 10: explicit NSF/risk-check framing, real-time performance guarantees, concrete endpoint/request-response example.
- [claimed-docs] “Get the available balance for an end user’s financial accounts”
- [claimed-docs] “Get the available balance for an end user's financial accounts”
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.”
Ownership
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 drawnMX's Account Owner Identification product explicitly retrieves name and address data tied to a financial account, directly enabling ops to match account holder identity against a customer record; this is well documented with first-party docs. Missing for 10: independent/hands-on corroboration beyond MX's own docs, and no explicit mention of retrieving full contact data (phone/email) alongside name/address.
- [claimed-docs] “you can connect to an end user's financial account to retrieve information such as their name and address”
- [claimed-docs] “With Account Owner Identification, you can connect to an end user's financial account to retrieve information such as their name and address…”
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.”
Processor tokens
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 MXMX provides Instant Account Verification (account/routing numbers) and Tokenized Account Numbers (TANs) explicitly described as 'substitute account numbers used for secure ACH money movement,' which supports handing verified account credentials to processors for payment initiation, plus a Connect Widget/Platform API for linking accounts. However, evidence does not show explicit named integrations or token-exchange flows with specific third-party payment processors (e.g., Stripe, Plaid-style processor partnerships) beyond MX's own ACH/TAN mechanism. missing for 10: documented named processor/platform integrations or partner list, explicit token-exchange API examples handing credentials to a specific external processor, independent confirmation of processor handoff working in production.
- [claimed-docs] “you can connect to an end user's financial institution and retrieve account and routing numbers for their demand deposit accounts”
- [claimed-docs] “With Instant Account Verification, you can connect to an end user's financial institution and retrieve account and routing numbers for their…”
- [claimed-docs] “Tokenized Account Numbers (TANs) are substitute account numbers used for secure ACH money movement.”
- [claimed-docs] “Use the Connect Widget and Platform API to let end users connect to their accounts.”
- [github] “This repository contains the OpenAPI specification for the MX Platform API”
Tellernone0/10Teller'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…”
Banking agent access — stories about banking agent access in this arenaBanking agent access
Stories about banking agent access in this arena
Agent data
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 MXMX publishes a full OpenAPI specification (mx-gh-1, mx-docs-12/26) covering structured request/response payloads across accounts, transactions, balances, identity, and verification endpoints, plus webhooks for event-driven consumption (mx-docs-7/22) and even an official MCP server for agent access (mx-probe-3), directly supporting machine-consumable, schema-documented data for automated workflows. Missing for 10: concrete sample JSON response bodies in the evidence pack and independent third-party corroboration that the schemas are agent-friendly without extra parsing.
- [github] “This repository contains the OpenAPI specification for the MX Platform API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API and its request and response payloads.”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice. This enables you to subscribe to certain events”
- [probe] “official MCP server documented at https://docs.mx.com/mcp”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.mx.com/llms.txt # MX Documentation - [Welcome to the MX Documentation](https://docs.mx.com/index.m…”
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, …”
Agent operations
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 MXMX exposes a full Platform API (with OpenAPI spec) covering balances, transactions, account aggregation, connect sessions/members, and webhooks, and there is a documented MCP surface at docs.mx.com/mcp confirming an MCP entry point exists. However, the evidence pack lacks detail on MCP tool scoping, credential/permission scoping for agent use, or hands-on confirmation of agent-driven session creation and connection management via MCP. missing for 10: documented MCP tool list/schema, evidence of scoped credentials for agent access, independent/hands-on validation of the MCP surface in agentic workflows.
- [probe] “official MCP server documented at https://docs.mx.com/mcp”
- [github] “This repository contains the OpenAPI specification for the MX Platform API”
- [claimed-docs] “Get the available balance for an end user’s financial accounts”
- [claimed-docs] “connect to end users' financial institutions and retrieve 90 days of data for their accounts and transactions”
- [claimed-docs] “Use the Connect Widget and Platform API to let end users connect to their accounts.”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice.”
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, …”
Consent security — stories about consent security in this arenaConsent security
Stories about consent security in this arena
Consent
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 drawnMXnone0/10The evidence pack covers MX's data connectivity products (account verification, aggregation, transaction history) and webhooks, but contains no mention of any end-user-facing consent dashboard, permissions center, or revocation portal where users can view/manage which apps hold access to their bank data. missing for 10: documented consent/permissions portal, revocation flow, any UI or API for end users to view/manage connected app access.
- [claimed-docs] “MX's ready-made UI that can be embedded in your application to aggregate users' account data by prompting end users to connect to their fina…”
- [claimed-docs] “Use the Connect Widget and Platform API to let end users connect to their accounts.”
- [claimed-docs] “Share your held data with an FDX open finance platform”
Tellernone0/10No 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.”
Deletion
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 drawnMXnone0/10The evidence pack covers connectivity, aggregation, webhooks, and API testing but contains no documentation of a delete/disconnect flow for members or users, nor any statement about MX stopping data collection or purging held data upon request. This is a fair question for a financial data aggregator handling sensitive consumer data, but no supporting evidence exists.
Tellernone0/10No 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.
Scopes
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 MXMX splits data access into distinct products (Instant Account Verification, Account Owner Identification, Account Aggregation, Extended Transaction History, Balance), which implies a developer could integrate only the specific product/data type needed rather than one monolithic grant. However, there is no explicit documentation of a consent-scoping mechanism, a permission UI showing only requested scopes to end users, or stated data-minimization principles/controls. Missing for 10: explicit consent/scope management docs, evidence of end-user-facing scope selection in Connect Widget, and any stated data-minimization policy.
- [claimed-docs] “you can connect to an end user's financial institution and retrieve account and routing numbers for their demand deposit accounts”
- [claimed-docs] “you can connect to an end user's financial account to retrieve information such as their name and address”
- [claimed-docs] “connect to end users' financial institutions and retrieve 90 days of data for their accounts and transactions”
- [claimed-docs] “you can connect to an end user's financial institution and retrieve up to 24 months of data for their accounts and transactions”
- [claimed-docs] “Get the available balance for an end user’s financial accounts”
- [claimed-docs] “Use the Connect Widget and Platform API to let end users connect to their accounts.”
Tellernone0/10The 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.”
Data freshness — stories about data freshness in this arenaData freshness
Stories about data freshness in this arena
Refresh
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 TellerMXnone0/10The evidence only shows MX automatically aggregates accounts on a ~24-hour cycle (mx-docs-25) and describes webhooks for event notifications, but there is no documented API endpoint or semantics for a developer-triggered on-demand refresh of a connected account's data.
- [claimed-docs] “MX automatically aggregates each `member` approximately every 24 hours.”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice. This enables you to subscribe to certain events”
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.”
Webhooks
developerData changes arrive as signed webhooks — new transactions, balance updates, connection state changes — so my system stays current without polling
weight 2 · round to MXMX docs confirm webhooks with HTTPS POST callbacks for subscribing to events like transaction/balance/connection changes, and note that account aggregation runs automatically (~every 24h) with webhook notification rather than requiring polling. Missing for 10: explicit documentation of webhook payload signing/verification mechanism and a full enumerated list of event types, plus independent/hands-on corroboration beyond first-party docs.
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice. This enables you to subscribe to certain events”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice.”
- [claimed-docs] “MX automatically aggregates each `member` approximately every 24 hours.”
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.”
Institution coverage — stories about institution coverage in this arenaInstitution coverage
Stories about institution coverage in this arena
Coverage
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 TellerMXnone0/10The evidence pack covers MX's connectivity products, APIs, and webhooks but contains no published figures on number of institutions reached, geographic coverage, or any coverage map/list a founder could check against their users' banks.
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.”
Status
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 drawnMXnone0/10Evidence covers connectivity, aggregation, webhooks, and test institutions, but there is no documented institution status dashboard, outage/degradation signal, or error-code taxonomy distinguishing bank-side failures from client-side issues. Missing for 10: institution health/status page, outage or degradation indicators, and documented error codes for bank vs integration failure.
Tellernone0/10No 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.
Integration dx — sandboxes, test modes, webhooks, and how fast a developer gets to a working integrationIntegration dx
Sandboxes, test modes, webhooks, and how fast a developer gets to a working integration
Multi product
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 drawnMX's Connect Widget/Platform API model uses a single connection (member) per institution that then exposes multiple products—verification, identity, balances, aggregation, extended history—via the same member without re-prompting the user (mx-docs-21, mx-docs-9, mx-docs-15/16/18/19/20). Webhooks and the 24-hour auto-aggregation cycle (mx-docs-25, mx-docs-7) further support a single persistent connection powering ongoing multi-product data access. missing for 10: no explicit documentation or hands-on confirmation that a single Connect session activates all products simultaneously without separate per-product entitlement/config steps, and no independent developer account of this exact flow.
- [claimed-docs] “Use the Connect Widget and Platform API to let end users connect to their accounts.”
- [claimed-docs] “MX's ready-made UI that can be embedded in your application to aggregate users' account data by prompting end users to connect to their fina…”
- [claimed-docs] “With Instant Account Verification, you can connect to an end user's financial institution and retrieve account and routing numbers for their…”
- [claimed-docs] “With Account Owner Identification, you can connect to an end user's financial account to retrieve information such as their name and address…”
- [claimed-docs] “Get the available balance for an end user's financial accounts”
- [claimed-docs] “With Account Aggregation, connect to end users' financial institutions and retrieve 90 days of data for their accounts and transactions.”
- [claimed-docs] “With Extended Transaction History, you can connect to an end user's financial institution and retrieve up to 24 months of data for their acc…”
- [claimed-docs] “MX automatically aggregates each `member` approximately every 24 hours.”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice. This enables you to subscribe to certain events”
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.”
Quickstart
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 TellerMX provides developer-facing artifacts like a downloadable OpenAPI spec (importable into Postman), a public GitHub OpenAPI repo, and a test platform with sandbox test institutions, which support quick experimentation. However there's no evidence of a self-serve API key signup flow, a step-by-step quickstart guide, or officially maintained client libraries/SDKs in specific languages. missing for 10: self-serve API key/account signup flow, official quickstart tutorial, language-specific client libraries/SDKs.
- [claimed-docs] “We offer four test institutions that you can use”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API and its request and response payloads.”
- [github] “This repository contains the OpenAPI specification for the MX Platform API”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.mx.com/openapi.json, https://docs.mx.com/swagger.json, https://docs.mx.com/api/openapi.…”
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”
Sandbox
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 TellerMX documents a dedicated test platform with four test institutions and an OpenAPI spec importable into Postman, plus guidance on testing the Connect Widget's OAuth flow end-to-end — directly supporting sandbox-based linking/testing before production use. However, the evidence does not show explicit documented test credentials for each test institution or guidance on simulating specific error states. Missing for 10: documented test credentials per institution, explicit error-state/failure simulation guidance.
- [claimed-docs] “We offer four test institutions that you can use”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API and its request and response payloads.”
- [claimed-docs] “To test OAuth in the Connect Widget when it's embedded in a WebView, you must load the financial institution's OAuth window in the device's …”
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”
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
ai-native userDo everything through the API that I can do in the UI
weight 2 · round to MXMX exposes a full Platform API (with public OpenAPI spec and even an MCP server) covering the same core capabilities as its Connect Widget UI—account verification, aggregation, balances, transaction history, webhooks—so most end-user and data flows are API-accessible. However, there is no explicit documentation confirming full parity between the API and MX's dashboard/admin UI (e.g., configuration, analytics, or account-management screens), so some UI-only functions may not be exposed. Missing for 10: explicit parity statement, evidence covering dashboard/admin functions via API, independent confirmation of no UI-only features.
- [claimed-docs] “Use the Connect Widget and Platform API to let end users connect to their accounts.”
- [github] “This repository contains the OpenAPI specification for the MX Platform API”
- [probe] “official MCP server documented at https://docs.mx.com/mcp”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API and its request and response payloads.”
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.”
ai-native userExport all of my data in open formats and leave
weight 3 · round drawnMX supports sharing held data with an FDX open finance platform and exposes an OpenAPI spec, suggesting some open-format data portability for the businesses that integrate with it, but there is no evidence of an end-user-facing 'export all my data and leave' feature or documented full data export/deletion workflow. missing for 10: end-user self-service export tool, documentation of full data export scope/format, evidence of account closure/data portability workflow, independent confirmation of FDX export usage.
- [claimed-docs] “Share your held data with an FDX open finance platform”
- [github] “This repository contains the OpenAPI specification for the MX Platform API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API and its request and response payloads.”
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…”
ai-native userRead the product's source under an open license
weight 2 · round drawnMXnone0/10MX is a closed commercial fintech API/SaaS product; the only public GitHub repo (mx-gh-1) contains an OpenAPI specification for documentation/integration purposes, not the actual application source code, and no license grants access to MX's implementation source.
- [github] “This repository contains the OpenAPI specification for the MX Platform API”
Tellernone0/10Teller 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.”
Payment initiation — stories about payment initiation in this arenaPayment initiation
Stories about payment initiation in this arena
Pay by bank
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 TellerMXnone0/10MX's evidence covers account verification, aggregation, balance, transaction history, and identity data, plus 'Tokenized Account Numbers... for secure ACH money movement' (mx-docs-24), but there is no documented payment-initiation API/product, no description of initiating a bank payment/transfer, and no stated live geographies for such a capability.
- [claimed-docs] “Tokenized Account Numbers (TANs) are substitute account numbers used for secure ACH money movement.”
- [claimed-docs] “With Instant Account Verification, you can connect to an end user's financial institution and retrieve account and routing numbers for their…”
- [claimed-docs] “With Account Aggregation, connect to end users' financial institutions and retrieve 90 days of data for their accounts and transactions.”
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”
Recurring
developerRecurring bank payments are supported — variable recurring payments, standing consents, or documented recurring debit flows built on the connection
weight 2 · round drawnMXnone0/10MX's evidence covers account aggregation, identity/verification, balances, transaction history and ACH microdeposit verification, plus tokenized account numbers for ACH money movement — but there is no mention of variable recurring payments, standing consents, or any recurring/scheduled debit payment-initiation flow.
Tellernone0/10Teller'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.”
Privacy posture — data-handling and privacy storiesPrivacy posture
Data-handling and privacy stories
ai-native userChoose where my data is stored (region/residency)
weight 2 · round drawnMXnone0/10No evidence in the pack addresses data residency, region selection, or storage location controls for MX's data; all citations concern connectivity, aggregation, and API/testing features. missing for 10: any mention of data residency/region options, compliance certifications tied to geographic storage, or configuration for where data is stored.
ai-native userControl data retention and deletion
weight 2 · round drawnMXnone0/10The evidence pack contains no mention of data retention periods, deletion policies, or user/data-controller controls over stored financial data; all citations relate to connectivity, aggregation, and API features rather than privacy/data lifecycle controls.
Transactions enrichment — stories about transactions enrichment in this arenaTransactions enrichment
Stories about transactions enrichment in this arena
Cashflow
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 drawnMXnone0/10MX's evidence covers account aggregation, balances, identity/ownership verification, and general 'data intelligence' or 'personalized guidance' claims, but nothing documents a specific income/cash-flow signal product — no mention of recurring-income detection, payroll detection, or a named income verification offering built on transaction data.
Tellernone0/10Teller'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.
Enrichment
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 TellerMXnone0/10The evidence pack covers connectivity, verification, aggregation, webhooks, and testing tools, but never documents transaction enrichment specifics like cleaned merchant names, categorization, or logos — only vague references to 'data-driven intelligence' and 'account and transaction history in one view.' Since enrichment is a fair and expected capability for a financial-data-aggregation platform, but no concrete documentation of merchant cleansing/categories/logos appears, this is 'none' rather than 'na'.
- [claimed-docs] “Use data-driven intelligence about your customers”
- [claimed-docs] “Access account and transaction history all in one view. Use the data to increase multi-product adoption, and build trust.”
- [claimed-docs] “connect to end users' financial institutions and retrieve 90 days of data for their accounts and transactions”
- [claimed-docs] “With Account Aggregation, connect to end users' financial institutions and retrieve 90 days of data for their accounts and transactions.”
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.”
Transactions
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 MXMX clearly documents transaction history depth (90 days standard via Account Aggregation, up to 24 months via Extended Transaction History) and provides a sync mechanism via webhooks plus automatic ~24hr re-aggregation of connected accounts, backed by a public OpenAPI spec for the Platform API. However, the evidence never explicitly documents pagination parameters/behavior for the transactions endpoint itself, and the webhook-based sync isn't described as an incremental 'only what changed' diff pattern (e.g., no mention of delta/cursor tokens). Missing for 10: explicit pagination documentation for transaction list endpoints, explicit incremental/delta sync mechanism beyond generic webhooks/24h refresh.
- [claimed-docs] “connect to end users' financial institutions and retrieve 90 days of data for their accounts and transactions”
- [claimed-docs] “you can connect to an end user's financial institution and retrieve up to 24 months of data for their accounts and transactions”
- [claimed-docs] “With Account Aggregation, connect to end users' financial institutions and retrieve 90 days of data for their accounts and transactions.”
- [claimed-docs] “With Extended Transaction History, you can connect to an end user's financial institution and retrieve up to 24 months of data for their acc…”
- [claimed-docs] “MX automatically aggregates each `member` approximately every 24 hours.”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice. This enables you to subscribe to certain events”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice.”
- [github] “This repository contains the OpenAPI specification for the MX Platform API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API”
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”
Not comparable on these axes
ai-native userPlug MCP servers into this product so it can use their tools
weight 3 · not comparableMXnone0/10Evidence shows MX publishes its own MCP server (docs.mx.com/mcp) so external agents can call MX's tools, but this is the opposite role from the story, which asks whether MX itself can consume/plug in external MCP servers and use their tools. There is no documentation of MX acting as an MCP client or any mechanism for feeding third-party MCP tool servers into MX's own workflows or its conversational AI feature.
- [probe] “official MCP server documented at https://docs.mx.com/mcp”
- [claimed-docs] “Provide an experience where consumers can ask about their money in plain language and act on the answer, with every figure pulled from real …”
ai-native userDelegate tasks to a built-in AI assistant inside the product
weight 3 · not comparableMXnone0/10The evidence shows MX enabling data connectivity and hints at conversational/personalized finance experiences (mx-docs-27, mx-docs-13/14) that MX's customers could build for their end-users, but there is no evidence of a built-in AI assistant inside the MX product itself that an AI-native user could delegate tasks to.
ai-native userVersion, review, and roll back my automations
weight 1 · not comparableMXn/aMX is a financial data connectivity/aggregation API platform, not an automation-builder tool; there is no concept of 'automations' with version/review/rollback in its product surface, so this axis is a category error rather than an unmet capability.
ai-native userSelf-host the core product
weight 3 · not comparableMXn/aMX is a cloud-hosted financial data connectivity API/SaaS platform with no evidence of any self-hostable core product; self-hosting is a category error for this kind of managed financial-data service.
ai-native userPrevent my data from being used to train AI models
weight 3 · not comparableMXnone0/10No evidence in the pack addresses AI training data usage, opt-out controls, or any privacy policy statement about model training; the pack is entirely about financial data connectivity, aggregation, and webhooks.
Tellern/aTeller is a financial account aggregation/banking API product, not an AI model or AI-native content/data platform; the story about preventing data from being used to train AI models is an axis that applies to AI tools/assistants, not to a fintech data API. No evidence suggests Teller trains AI models on user data or offers AI opt-out controls, so this axis is a category mismatch.
ai-native userOpt out of telemetry and usage tracking
weight 2 · not comparableMXnone0/10No evidence pack item addresses telemetry, usage tracking, analytics opt-out, or data collection controls for AI-native usage; the docs focus entirely on financial data connectivity and APIs. Missing for 10: any mention of telemetry collection, an opt-out mechanism, or privacy settings related to usage tracking.