Plaid vs MX

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 drawn
   Plaid✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   MX✓fullclaimed8/10

   MX 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.”

   proof ↗⚑ flag

Oauth

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

   weight 2 · round drawn
   Plaid—none0/10

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

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

   proof ↗⚑ flag

   MX—none0/10

   Evidence 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 …”

   proof ↗⚑ flag

Repair

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

   weight 2 · round to Plaid
   Plaid~partialclaimed3/10

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

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

   proof ↗⚑ flag

   MX—none0/10

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

   ⚑ flag

Agent access

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

   weight 2 · round to MX
   Plaid~partialprobed6/10

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

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

   proof ↗⚑ flag

   MX✓fullprobed9/10

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

   • [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”

   proof ↗⚑ flag

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

   weight 2 · round to Plaid
   Plaid~partialclaimed6/10

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

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

   proof ↗⚑ flag

   MX~partialclaimed5/10

   MX 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.”

   proof ↗⚑ flag

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

   weight 3 · round to MX
   Plaid~partialprobed7/10

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

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

   proof ↗⚑ flag

   MX✓fullprobed7/10

   MX 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”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Plaid—none0/10

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

   ⚑ flag

   MX—none0/10

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

   ⚑ flag

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

   weight 3 · round to MX
   Plaid~partialprobed7/10

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

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

   proof ↗⚑ flag

   MX✓fullprobed8/10

   MX 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”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Plaid—none0/10

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

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

   proof ↗⚑ flag

   MX—none0/10

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

   ⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Plaid
   Plaid~partialclaimed6/10

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

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

   proof ↗⚑ flag

   MX~partialclaimed4/10

   MX 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.”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to MX
   Plaid✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   MX✓fullclaimed8/10

   MX 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.”

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round to MX
   Plaid—none0/10

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

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

   proof ↗⚑ flag

   MX~partialclaimed5/10

   MX'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.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Plaid~partialclaimed3/10

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

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

   proof ↗⚑ flag

   MX~partialprobed3/10

   MX 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”

   proof ↗⚑ flag

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

   weight 2 · round to MX
   Plaid~partialprobed4/10

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

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

   proof ↗⚑ flag

   MX~partialprobed6/10

   MX 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 …”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round to MX
   Plaid—none0/10

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

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

   proof ↗⚑ flag

   MX~partialprobed5/10

   MX 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.…”

   proof ↗⚑ flag

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

   weight 2 · round to MX
   Plaid—none0/10

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

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

   proof ↗⚑ flag

   MX✓fullprobed9/10

   MX 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.…”

   proof ↗⚑ flag

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

   weight 1 · round to Plaid
   Plaid✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   MX✓fullclaimed7/10

   MX 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.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Plaid—none0/10

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

   ⚑ flag

   MX—none0/10

   Evidence 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.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Plaid—none0/10

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

   ⚑ flag

   MX—none0/10

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

   ⚑ flag

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

   weight 3 · round drawn
   Plaid~partialclaimed4/10

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

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

   proof ↗⚑ flag

   MX~partialclaimed4/10

   MX 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.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   Plaid—none0/10

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

   ⚑ flag

   MX—none0/10

   MX'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”

   proof ↗⚑ 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 MX
   Plaid✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   MX✓fullclaimed9/10

   MX'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.”

   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 Plaid
   Plaid✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   MX~partialclaimed6/10

   MX 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”

   proof ↗⚑ flag

Ownership

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

   weight 2 · round drawn
   Plaid✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   MX✓fullclaimed8/10

   MX'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…”

   proof ↗⚑ flag

Processor tokens

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

   weight 2 · round to Plaid
   Plaid✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   MX~partialclaimed6/10

   MX 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”

   proof ↗⚑ flag

Agent data

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

   weight 2 · round to MX
   Plaid~partialprobed5/10

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

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

   proof ↗⚑ flag

   MX✓fullprobed8/10

   MX 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…”

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

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

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

   proof ↗⚑ flag

   MX~partialprobed6/10

   MX 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.”

   proof ↗⚑ flag

Consent

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

   weight 2 · round drawn
   Plaid—none0/10

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

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

   proof ↗⚑ flag

   MX—none0/10

   The 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”

   proof ↗⚑ flag

Deletion

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

   weight 2 · round drawn
   Plaid—none0/10

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

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

   proof ↗⚑ flag

   MX—none0/10

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

   ⚑ 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 MX
   Plaid!disputedcontradicted4/10

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

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

   proof ↗⚑ flag

   MX~partialclaimed4/10

   MX 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.”

   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 Plaid
   Plaid~partialclaimed4/10

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

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

   proof ↗⚑ flag

   MX—none0/10

   The 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”

   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 drawn
   Plaid✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   MX✓fullclaimed8/10

   MX 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.”

   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 Plaid
   Plaid~partialclaimed3/10

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

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

   proof ↗⚑ flag

   MX—none0/10

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

   ⚑ flag

Status

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

   weight 2 · round to Plaid
   Plaid~partialprobed4/10

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

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

   proof ↗⚑ flag

   MX—none0/10

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

   ⚑ 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 MX
   Plaid~partialclaimed5/10

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

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

   proof ↗⚑ flag

   MX✓fullclaimed7/10

   MX'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”

   proof ↗⚑ flag

Quickstart

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

   weight 2 · round to Plaid
   Plaid~partialprobed7/10

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

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

   proof ↗⚑ flag

   MX~partialprobed4/10

   MX 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.…”

   proof ↗⚑ flag

Sandbox

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

   weight 3 · round to Plaid
   Plaid✓fullclaimed9/10

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

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

   proof ↗⚑ flag

   MX~partialclaimed7/10

   MX 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 …”

   proof ↗⚑ flag

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

   weight 2 · round to MX
   Plaid~partialprobed5/10

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

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

   proof ↗⚑ flag

   MX~partialprobed6/10

   MX 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.”

   proof ↗⚑ flag

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

   weight 3 · round to MX
   Plaid—none0/10

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

   ⚑ flag

   MX~partialclaimed3/10

   MX 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.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Plaid—none0/10

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

   ⚑ flag

   MX—none0/10

   MX 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”

   proof ↗⚑ flag

Pay by bank

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

   weight 2 · round to Plaid
   Plaid~partialclaimed6/10

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

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

   proof ↗⚑ flag

   MX—none0/10

   MX'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.”

   proof ↗⚑ flag

Recurring

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

   weight 2 · round drawn
   Plaid—none0/10

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

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

   proof ↗⚑ flag

   MX—none0/10

   MX'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.

   ⚑ flag

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

   weight 2 · round drawn
   Plaid—none0/10

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

   ⚑ flag

   MX—none0/10

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

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Plaid—none0/10

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

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

   proof ↗⚑ flag

   MX—none0/10

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

   ⚑ flag

3. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Plaid—none0/10

   No evidence in the pack addresses telemetry or usage-tracking opt-out for Plaid's SDKs, Link, or APIs; the docs and community items focus on financial data access and privacy concerns about data collection scope, not an opt-out mechanism for usage analytics.

   ⚑ flag

   MX—none0/10

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

   ⚑ flag

Cashflow

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

   weight 2 · round drawn
   Plaid—none0/10

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

   ⚑ flag

   MX—none0/10

   MX'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.

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

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

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

   proof ↗⚑ flag

   MX—none0/10

   The 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.”

   proof ↗⚑ flag

Transactions

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

   weight 3 · round to Plaid
   Plaid✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   MX~partialclaimed7/10

   MX 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”

   proof ↗⚑ flag