MX vs Mastercard Open Finance (Finicity)
enterprise-custom
·enterprise-custom
MX wins · 18–6 (25 drawn)
Account linking — stories about account linking in this arenaAccount linking
Stories about account linking in this arena
Hosted flows
developerLet a user connect their bank with a drop-in hosted flow — create a session server-side, open the widget, and get back a token for the connected account — without building institution UI myself
weight 3 · round to MXMX docs describe the Connect Widget as a ready-made, embeddable UI that prompts end users to authenticate with their institution credentials, paired with the Platform API for server-side session/member creation, matching the drop-in hosted flow with no custom institution UI needed. Webhooks and member/account tokens (e.g., guid-based member connections) round out the server-to-client flow. missing for 10: explicit mention of a 'connect token' generation endpoint and independent/third-party confirmation of the end-to-end session-create-then-widget-open flow.
- [claimed-docs] “MX's ready-made UI that can be embedded in your application to aggregate users' account data by prompting end users to connect to their fina…”
- [claimed-docs] “Use the Connect Widget and Platform API to let end users connect to their accounts.”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice.”
- [claimed-docs] “To test OAuth in the Connect Widget when it's embedded in a WebView, you must load the financial institution's OAuth window in the device's …”
- [claimed-docs] “MX automatically aggregates each `member` approximately every 24 hours.”
The evidence only briefly references a 'Connect' mechanism for linking accounts ('link them to at least one account via Connect') but provides no detail on a hosted, drop-in widget, server-side session creation, or token retrieval flow that a developer would use to avoid building institution UI. Missing for 10: documentation of Connect widget UI, session token generation API, and end-to-end token exchange after linking.
- [claimed-docs] “link them to at least one account via Connect”
Oauth
developerConnections to major institutions use bank-hosted OAuth rather than screen-scraped credentials — the platform documents its OAuth coverage and how legacy credential flows are being retired
weight 2 · round drawnMXnone0/10Evidence shows MX supports OAuth in its Connect Widget (mx-docs-23) but there is no documentation of overall OAuth coverage across institutions or any stated plan for retiring legacy credential-based (screen-scraped) connections, which is the core of this story.
- [claimed-docs] “To test OAuth in the Connect Widget when it's embedded in a WebView, you must load the financial institution's OAuth window in the device's …”
Mastercard Open Finance (Finicity)none0/10The evidence pack covers Connect/account-linking, webhooks, and API products but never mentions OAuth-based bank authentication coverage, connectivity method mix, or a documented plan/status for retiring screen-scraped credential flows. Without explicit documentation of OAuth coverage vs. legacy scraping, this specific developer-facing transparency claim is unevidenced.
- [claimed-docs] “link them to at least one account via Connect”
- [claimed-docs] “Webhooks allow you to receive real-time notifications when specific events occur, eliminating the need for constant polling.”
Repair
ops leadBroken connections are repairable — expired or revoked links surface as documented statuses, and users can re-authenticate in an update flow without starting over
weight 2 · round drawnMXnone0/10The evidence pack covers MX's connectivity products (aggregation, IAV, AOI, microdeposits, webhooks) but never documents connection/member status codes (e.g., expired, revoked, challenged) or a dedicated re-authentication/update flow that lets users fix a broken link without re-onboarding. This is a plausible and expected capability for an account-aggregation platform, but nothing in the pack substantiates it.
Mastercard Open Finance (Finicity)none0/10The evidence pack covers account data products, webhooks, onboarding, and testing personas, but nothing documents connection health statuses (expired/revoked), a re-authentication or 'update mode' flow, or any repair-without-restart mechanism for broken links. Missing for 10: documented connection status states (e.g., expired/revoked/error), an update/re-auth flow API or UI, and any evidence of preserving existing account links during re-auth.
- [claimed-docs] “Webhooks allow you to receive real-time notifications when specific events occur, eliminating the need for constant polling.”
- [claimed-docs] “link them to at least one account via Connect”
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
Agent access
ai-native userPoint an agent at llms.txt or agent-oriented docs
weight 2 · round to MXMX hosts a working llms.txt at docs.mx.com/llms.txt (confirmed HTTP 200 with structured doc links) and also documents an official MCP server, both explicitly agent-oriented entry points into their docs. Missing for 10: independent third-party confirmation of an AI agent successfully consuming these resources end-to-end.
A probe confirms llms.txt is live at developer.mastercard.com/llms.txt (HTTP 200), and Mastercard also documents an agent-oriented MCP toolkit with dynamic code generation for agents. Missing for 10: no independent third-party confirmation that agents actually consume this llms.txt effectively, and no explicit doc listing Open Finance-specific sections within it.
- [probe] “PROBE llms.txt: HTTP 200 at https://developer.mastercard.com/llms.txt # Mastercard Developers Mastercard Developers is a comprehensive API p…”
- [probe] “official MCP server documented at https://developer.mastercard.com/platform/documentation/agent-toolkit/mcp-overview/”
- [claimed-docs] “Dynamic Code Generation: Generate accurate, working code examples based on current API specifications”
- [claimed-docs] “I need to integrate Open Finance to verify account ownership and check balances for my fintech app”
ai-native userRun the product headlessly / in CI for automation
weight 2 · round to Mastercard Open Finance (Finicity)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.”
As a pure REST API platform, Open Finance is inherently headless — it uses PartnerID/secret token auth (docs-10, docs-23), an OpenAPI spec with generated client libraries (mastercard-open-finance-gh-1), and a non-billable 'Test Drive' sandbox with scripted test personas (docs-24, docs-25) suitable for automated/CI testing. Missing for 10: no explicit CI/CD pipeline examples, no documented headless SDK/CLI runner, and no first-party guidance on automating the flow end-to-end in a build pipeline.
- [claimed-docs] “To create a token, you are required to provide the PartnerID along with the corresponding secret and appKey.”
- [claimed-docs] “Use your Partner ID and Secret with the following endpoint whenever you need to generate a new access token”
- [claimed-docs] “Test Drive is a non-billable, unlimited plan that provides access to all Open Finance API endpoints.”
- [claimed-docs] “we provide you with a set of testing personas. Each persona represents an example of a user who might use your app.”
- [github] “The test project generates an API client library from the API specification like you would do in a real application”
ai-native userConnect an agent via an official MCP server
weight 3 · round drawnMX 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”
Mastercard documents an official Agent Toolkit MCP server (mcp-overview) that includes dynamic code generation and an example use case directly referencing Open Finance verification and balance checks, confirming AI agents can connect via this official MCP server to access Open Finance APIs. Missing for 10: independent/hands-on corroboration of the MCP server working with Open Finance endpoints, and detailed API-to-tool mapping documentation.
- [claimed-docs] “Dynamic Code Generation: Generate accurate, working code examples based on current API specifications”
- [claimed-docs] “I need to integrate Open Finance to verify account ownership and check balances for my fintech app”
- [probe] “official MCP server documented at https://developer.mastercard.com/platform/documentation/agent-toolkit/mcp-overview/”
ai-native userUse an official CLI
weight 2 · round drawnMXnone0/10MX is a financial data API/SDK platform; no evidence of an official CLI tool for developers or AI-native workflows appears in the evidence pack — only API specs, webhooks, and a widget/UI. Evidence exists of an MCP server and OpenAPI spec, but no CLI is documented.
Mastercard Open Finance (Finicity)none0/10No evidence of an official CLI tool; evidence covers APIs, webhooks, MCP server, and SDK/test client generation but nothing describing a command-line interface for AI-native workflows. Missing for 10: any mention of an official CLI, its installation, or its use in agentic/AI workflows.
ai-native userDrive the product through a documented public API
weight 3 · round drawnMX 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”
Mastercard Open Finance exposes a well-documented public REST API (accounts, balances, transactions, ownership verification, webhooks) with OpenAPI spec, token-based auth, sandbox/test-drive access, and even an llms.txt plus official MCP toolkit for agent-driven access. missing for 10: independent third-party developer confirmation of API usability/reliability beyond vendor docs.
- [claimed-docs] “To create a token, you are required to provide the PartnerID along with the corresponding secret and appKey.”
- [claimed-docs] “Use your Partner ID and Secret with the following endpoint whenever you need to generate a new access token”
- [claimed-docs] “Test Drive is a non-billable, unlimited plan that provides access to all Open Finance API endpoints.”
- [github] “The test project generates an API client library from the API specification like you would do in a real application”
- [probe] “PROBE llms.txt: HTTP 200 at https://developer.mastercard.com/llms.txt # Mastercard Developers Mastercard Developers is a comprehensive API p…”
- [probe] “official MCP server documented at https://developer.mastercard.com/platform/documentation/agent-toolkit/mcp-overview/”
- [claimed-docs] “Dynamic Code Generation: Generate accurate, working code examples based on current API specifications”
ai-native userIssue scoped/least-privilege API credentials for an agent
weight 2 · round drawnMXnone0/10No evidence of scoped/least-privilege API credential issuance for agents—docs cover data connectivity, webhooks, OpenAPI spec, and even an MCP server reference, but nothing about issuing restricted-scope API keys/tokens for AI agent use.
Mastercard Open Finance (Finicity)none0/10Evidence shows PartnerID/secret/appKey token generation for API access (docs-10, docs-23) but no mention of scoped, least-privilege, or per-agent credential issuance — auth appears to be a single partner-level secret rather than granular scoped tokens for agents. Missing for 10: any documentation of scoped/limited-permission API keys, per-agent credential issuance, or role-based access control for agent use.
- [claimed-docs] “To create a token, you are required to provide the PartnerID along with the corresponding secret and appKey.”
- [claimed-docs] “Use your Partner ID and Secret with the following endpoint whenever you need to generate a new access token”
ai-native userBuild against official SDKs
weight 2 · round to MXMX 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.”
The only relevant evidence is a GitHub repo showing an OpenAPI-generated client library used for testing, not a fully documented, officially published SDK across languages. Missing for 10: dedicated official SDK repositories/packages (e.g., npm, PyPI, Maven), SDK version support docs, and independent developer confirmation of SDK usability.
- [github] “The test project generates an API client library from the API specification like you would do in a real application”
ai-native userSubscribe to events via webhooks
weight 2 · round to MXMX documents a webhooks system that sends HTTPS POST callbacks so developers can subscribe to specific events, clearly supporting webhook-based event subscription. Missing for 10: an exhaustive list of supported event types and independent/hands-on confirmation beyond first-party docs.
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice. This enables you to subscribe to certain events”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice.”
Docs explicitly describe webhook support for real-time event notifications (avoiding polling) and a subscription-based OBWMS API letting developers subscribe to specific events. Missing for 10: concrete webhook payload/setup examples, independent/hands-on confirmation, and detail on programmatic subscription management via API/SDK.
- [claimed-docs] “Webhooks allow you to receive real-time notifications when specific events occur, eliminating the need for constant polling.”
- [claimed-docs] “OBWMS will provide a comprehensive API for managing real-time event notifications, enabling you to subscribe to specific events, ensuring yo…”
Agentic features
ai-native userGet AI-generated insights and suggestions from my data inside the product
weight 2 · round to MXMX's marketing pages describe personalized financial guidance and a conversational 'ask about your money' experience generated from each consumer's data (mx-docs-14, mx-docs-27), which matches the AI-insights story, and mx-docs-13 references 'data-driven intelligence.' However, these are thin, high-level marketing snippets rather than detailed product docs, and there is no independent/hands-on corroboration or technical documentation of the underlying AI model or insight-generation pipeline. Missing for 10: dedicated technical documentation of the AI/insights feature, concrete examples of generated insights, and independent verification of the claim.
- [claimed-docs] “Use data-driven intelligence about your customers”
- [claimed-docs] “Personalized financial guidance generated from each consumer's financial data, surfaced in a relevant and timely experience”
- [claimed-docs] “Provide an experience where consumers can ask about their money in plain language and act on the answer, with every figure pulled from real …”
- [claimed-docs] “Access account and transaction history all in one view. Use the data to increase multi-product adoption, and build trust.”
Mastercard Open Finance (Finicity)none0/10The evidence shows Mastercard Open Finance exposes categorized financial data (transaction types, recurring transactions, spending, loan payments) via APIs, and a separate MCP agent toolkit for developers to generate code, but there is no evidence of AI-generated insights or suggestions surfaced to an end-user inside the product itself.
- [claimed-docs] “Insights into: * [Transaction types] * [Recurring transactions] * [Consumer spending] * [Loan payments]”
- [claimed-docs] “Dynamic Code Generation: Generate accurate, working code examples based on current API specifications”
- [claimed-docs] “I need to integrate Open Finance to verify account ownership and check balances for my fintech app”
ai-native userSet up automations that run autonomously in the background
weight 2 · round to MXMX 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”
Mastercard Open Finance (Finicity)none0/10Evidence shows webhooks for event notifications and an MCP toolkit for code generation, but nothing about scheduling or configuring autonomous background automations/workflows that run without user intervention. Missing for 10: any documentation of scheduled/triggered automation setup, autonomous workflow orchestration, or agentic task execution running independently in the background.
- [claimed-docs] “Webhooks allow you to receive real-time notifications when specific events occur, eliminating the need for constant polling.”
- [claimed-docs] “OBWMS will provide a comprehensive API for managing real-time event notifications, enabling you to subscribe to specific events, ensuring yo…”
- [claimed-docs] “Dynamic Code Generation: Generate accurate, working code examples based on current API specifications”
ai-native userOperate the product with natural-language commands
weight 2 · round to MXMX documents an official MCP server (mx-probe-3) that would let AI agents issue natural-language commands against the platform, and marketing copy (mx-docs-27) describes enabling plain-language financial queries. However, there is no detailed documentation of the NL command set, limits, or hands-on confirmation of how well it works. Missing for 10: detailed MCP tool/command documentation, independent verification of NL command execution, and coverage of edge cases/limitations.
- [probe] “official MCP server documented at https://docs.mx.com/mcp”
- [claimed-docs] “Provide an experience where consumers can ask about their money in plain language and act on the answer, with every figure pulled from real …”
Mastercard offers an official Agent Toolkit/MCP server with dynamic code generation and natural-language-friendly API access (e.g., 'I need to integrate Open Finance to verify account ownership and check balances'), which supports operating the platform via AI-native/natural-language workflows. However, this is a developer-integration tool rather than end-user natural-language command execution over the product's core financial functions. missing for 10: evidence of an end-user-facing natural-language interface, broader coverage of MCP tool capabilities beyond code generation, and independent/hands-on validation of the MCP server's reliability.
- [claimed-docs] “Dynamic Code Generation: Generate accurate, working code examples based on current API specifications”
- [claimed-docs] “I need to integrate Open Finance to verify account ownership and check balances for my fintech app”
- [probe] “official MCP server documented at https://developer.mastercard.com/platform/documentation/agent-toolkit/mcp-overview/”
Api quality
ai-native userExplore an interactive API reference with runnable examples
weight 2 · round to MXMX publishes an OpenAPI spec (mx-gh-1) that users can import into Postman to explore requests/responses (mx-docs-12, mx-docs-26), and provides a sandbox test-platform with test institutions (mx-docs-8). However, there is no evidence of an embedded, in-docs interactive API reference with directly runnable examples (e.g., a Swagger/Redoc-style try-it-now console) — probes for a hosted openapi.json on the docs site 404 (mx-probe-2), meaning users must leave the docs and use an external tool like Postman to run calls. Missing for 10: an in-browser interactive explorer with click-to-run examples, and confirmation the OpenAPI spec is directly hosted/interactive on docs.mx.com rather than requiring external import.
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API and its request and response payloads.”
- [github] “This repository contains the OpenAPI specification for the MX Platform API”
- [claimed-docs] “We offer four test institutions that you can use”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.mx.com/openapi.json, https://docs.mx.com/swagger.json, https://docs.mx.com/api/openapi.…”
Mastercard Open Finance (Finicity)none0/10The evidence shows extensive product/API documentation, an OpenAPI spec-driven test client, and a 'Test Drive' sandbox plan, but nothing describes an interactive API reference (e.g., Swagger/Postman-style try-it console) with runnable code examples in the docs portal itself.
- [claimed-docs] “Test Drive is a non-billable, unlimited plan that provides access to all Open Finance API endpoints.”
- [github] “The test project generates an API client library from the API specification like you would do in a real application”
- [claimed-docs] “we provide you with a set of testing personas”
ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)
weight 2 · round to MXMX explicitly documents downloading its OpenAPI Specification for import into Postman, and a dedicated GitHub repo (mxenabled/openapi) hosts the machine-readable spec. Missing for 10: no evidence of a standard hosted openapi.json endpoint (probe found 404s at common paths), so discovery relies on docs/GitHub rather than a canonical URL.
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API and its request and response payloads.”
- [github] “This repository contains the OpenAPI specification for the MX Platform API”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.mx.com/openapi.json, https://docs.mx.com/swagger.json, https://docs.mx.com/api/openapi.…”
A GitHub repo (open-banking-us-openapi) explicitly generates an API client library from a published OpenAPI specification, confirming a machine-readable spec is downloadable/usable, and Mastercard also exposes an llms.txt and MCP toolkit for machine-consumable API access. Missing for 10: no direct link/documentation showing a single canonical spec file download page or version history, and no independent third-party confirmation of spec completeness.
- [github] “The test project generates an API client library from the API specification like you would do in a real application”
- [probe] “PROBE llms.txt: HTTP 200 at https://developer.mastercard.com/llms.txt # Mastercard Developers Mastercard Developers is a comprehensive API p…”
- [probe] “official MCP server documented at https://developer.mastercard.com/platform/documentation/agent-toolkit/mcp-overview/”
- [claimed-docs] “Dynamic Code Generation: Generate accurate, working code examples based on current API specifications”
ai-native userTest against a sandbox environment without touching production data
weight 1 · round to Mastercard Open Finance (Finicity)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.”
Mastercard provides a dedicated non-billable 'Test Drive' plan with unlimited access to all Open Finance API endpoints plus documented testing personas representing example users, explicitly for sandbox-style integration testing without production data, and a GitHub sample project generating a client from the API spec for testing. missing for 10: independent/hands-on confirmation of full production-data isolation and details on sandbox data realism or limitations.
- [claimed-docs] “Test Drive is a non-billable, unlimited plan that provides access to all Open Finance API endpoints.”
- [claimed-docs] “we provide you with a set of testing personas”
- [claimed-docs] “we provide you with a set of testing personas. Each persona represents an example of a user who might use your app.”
- [github] “The test project generates an API client library from the API specification like you would do in a real application”
ai-native userRely on versioned APIs with a documented deprecation policy
weight 2 · round drawnMXnone0/10Evidence confirms MX publishes an OpenAPI spec (mx-gh-1, mx-docs-12/26) but nowhere documents API versioning conventions or a formal deprecation policy for breaking changes. Missing for 10: documented version numbering scheme, deprecation timeline/notice policy, changelog of breaking changes.
- [github] “This repository contains the OpenAPI specification for the MX Platform API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API and its request and response payloads.”
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
ai-native userPerform bulk operations across many items at once
weight 2 · round drawnMXnone0/10The evidence describes per-user/per-account connectivity, aggregation, and identity verification features, but nothing documents bulk or batch operations across many items/accounts/users at once. Missing for 10: any batch API endpoints, bulk data export/import operations, or documentation of multi-item processing at scale.
Mastercard Open Finance (Finicity)none0/10No evidence describes batch/bulk endpoints or multi-item operations (e.g., submitting many account IDs or requests in a single call); documented APIs appear per-account/per-transaction oriented, and webhooks only address real-time single-event notifications, not bulk processing.
ai-native userDefine rules that trigger actions automatically on events
weight 3 · round to MXMX provides webhooks that let subscribers receive event notifications (e.g., aggregation completion) which developers can use to trigger their own downstream actions, but there is no evidence of a native rules/automation engine where users define conditional trigger-action logic within MX itself. missing for 10: a documented rules/automation builder or conditional trigger-action configuration UI, evidence of built-in actions (not just external webhook consumption).
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice. This enables you to subscribe to certain events”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice.”
- [claimed-docs] “MX automatically aggregates each `member` approximately every 24 hours.”
Mastercard Open Finance (Finicity)none0/10Webhooks provide event notifications but there is no evidence of user-definable rules or automated triggered actions based on those events; missing for 10: rule-definition engine, conditional logic, automated action execution tied to events.
- [claimed-docs] “Webhooks allow you to receive real-time notifications when specific events occur, eliminating the need for constant polling.”
- [claimed-docs] “OBWMS will provide a comprehensive API for managing real-time event notifications, enabling you to subscribe to specific events, ensuring yo…”
ai-native userSchedule recurring jobs or workflows
weight 2 · round drawnMXnone0/10MX's aggregation happens automatically on a fixed ~24-hour cycle (mx-docs-25) and webhooks push events, but there is no evidence of user-defined recurring job/workflow scheduling, cron-like configuration, or workflow orchestration for AI-native users. missing for 10: user-configurable schedule/frequency controls, workflow/orchestration engine, any AI-native automation scheduling feature.
- [claimed-docs] “MX automatically aggregates each `member` approximately every 24 hours.”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice. This enables you to subscribe to certain events”
Balance ownership — stories about balance ownership in this arenaBalance ownership
Stories about balance ownership in this arena
Ach details
developerObtain verified account and routing numbers (or tokenized equivalents) from a linked account to fund ACH or bank-debit payments without micro-deposits
weight 3 · round to MXMX's Instant Account Verification explicitly retrieves account and routing numbers for demand deposit accounts without micro-deposits, and Tokenized Account Numbers (TANs) provide a secure tokenized alternative for ACH money movement, both documented as distinct from the separate microdeposits verification method. missing for 10: independent/hands-on corroboration beyond first-party docs.
- [claimed-docs] “you can connect to an end user's financial institution and retrieve account and routing numbers for their demand deposit accounts”
- [claimed-docs] “With Instant Account Verification, you can connect to an end user's financial institution and retrieve account and routing numbers for their…”
- [claimed-docs] “Tokenized Account Numbers (TANs) are substitute account numbers used for secure ACH money movement.”
- [claimed-docs] “Microdeposits is different—it provides an alternate method for verifying account ownership by making small test deposits to an account.”
Mastercard's docs list dedicated 'Get ACH details' and 'Validate account details' products alongside account-ownership verification and balance checks, which together match the story of retrieving account/routing data and validating funding source without micro-deposits. However, the evidence pack only shows product titles/index links rather than detailed descriptions of the actual data returned (e.g., explicit account/routing number fields, tokenization format, or confirmation that validation replaces micro-deposits). Missing for 10: detailed API schema/response showing routing+account numbers or tokens, explicit statement that validation eliminates micro-deposit verification, and independent developer confirmation of real-world usage.
- [claimed-docs] “Get ACH details”
- [claimed-docs] “Get [ACH details]”
- [claimed-docs] “Validate account details”
- [claimed-docs] “Validate [account details]”
- [claimed-docs] “Retrieves account ownership details (name, address, email and phone - where available) from a connected account at a financial institution.”
- [claimed-docs] “you can send customer data to our match account ownership details endpoint to receive confidence scores comparing the provided data and the …”
Balances
developerFetch a real-time balance for a connected account before initiating a payment — a documented balance endpoint intended for NSF and risk checks
weight 3 · round to Mastercard Open Finance (Finicity)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”
Docs explicitly describe an Account Balance service returning real-time or cached balance data from the connected FI, matching the NSF/risk-check use case, and MCP overview references verifying ownership and checking balances as a supported integration flow. Missing for 10: explicit request/response schema examples, independent/hands-on confirmation of real-time latency, and no direct mention of pre-payment NSF workflow tying balance check to payment initiation.
- [claimed-docs] “The Account Balance service provides real-time or cached bank account balance information from your customer's Financial Institution (FI).”
- [claimed-docs] “I need to integrate Open Finance to verify account ownership and check balances for my fintech app”
Ownership
ops leadRetrieve account-holder details — names, addresses, contact data on file at the bank — to match the account owner against my customer
weight 2 · round drawnMX's Account Owner Identification product explicitly retrieves name and address data tied to a financial account, directly enabling ops to match account holder identity against a customer record; this is well documented with first-party docs. Missing for 10: independent/hands-on corroboration beyond MX's own docs, and no explicit mention of retrieving full contact data (phone/email) alongside name/address.
- [claimed-docs] “you can connect to an end user's financial account to retrieve information such as their name and address”
- [claimed-docs] “With Account Owner Identification, you can connect to an end user's financial account to retrieve information such as their name and address…”
Docs explicitly describe an Account Owner Verification service retrieving name, address, email and phone from the connected FI account, and a match-account-ownership endpoint that compares provided customer data against the bank's on-file details with confidence scores — directly matching the ops matching workflow. Missing for 10: independent/hands-on corroboration beyond vendor docs and more detail on data completeness/edge cases across FIs.
- [claimed-docs] “Retrieves account ownership details (name, address, email and phone - where available) from a connected account at a financial institution.”
- [claimed-docs] “you can send customer data to our match account ownership details endpoint to receive confidence scores comparing the provided data and the …”
- [claimed-docs] “I need to integrate Open Finance to verify account ownership and check balances for my fintech app”
Processor tokens
developerLinked accounts plug into my payment processor — documented integrations or token exchange that hand verified account credentials to third-party processors and platforms
weight 2 · round to MXMX provides Instant Account Verification (account/routing numbers) and Tokenized Account Numbers (TANs) explicitly described as 'substitute account numbers used for secure ACH money movement,' which supports handing verified account credentials to processors for payment initiation, plus a Connect Widget/Platform API for linking accounts. However, evidence does not show explicit named integrations or token-exchange flows with specific third-party payment processors (e.g., Stripe, Plaid-style processor partnerships) beyond MX's own ACH/TAN mechanism. missing for 10: documented named processor/platform integrations or partner list, explicit token-exchange API examples handing credentials to a specific external processor, independent confirmation of processor handoff working in production.
- [claimed-docs] “you can connect to an end user's financial institution and retrieve account and routing numbers for their demand deposit accounts”
- [claimed-docs] “With Instant Account Verification, you can connect to an end user's financial institution and retrieve account and routing numbers for their…”
- [claimed-docs] “Tokenized Account Numbers (TANs) are substitute account numbers used for secure ACH money movement.”
- [claimed-docs] “Use the Connect Widget and Platform API to let end users connect to their accounts.”
- [github] “This repository contains the OpenAPI specification for the MX Platform API”
Mastercard Open Finance provides account ownership verification, balance, ACH details, and account aggregation APIs accessible via token-based auth (PartnerID/secret) that developers can integrate into payment processing flows, and it supports Connect for account linking. However, the evidence does not document specific third-party payment processor/platform integration partnerships or an explicit token-exchange handoff mechanism to hand verified credentials to external processors — the story implies pre-built plug-and-play integrations rather than raw APIs a developer must wire up themselves. missing for 10: named third-party processor/platform integration partners, explicit token-exchange-to-processor handoff documentation, independent confirmation of such integrations working in production.
- [claimed-docs] “Retrieves account ownership details (name, address, email and phone - where available) from a connected account at a financial institution.”
- [claimed-docs] “The Account Balance service provides real-time or cached bank account balance information from your customer's Financial Institution (FI).”
- [claimed-docs] “Get ACH details”
- [claimed-docs] “To create a token, you are required to provide the PartnerID along with the corresponding secret and appKey.”
- [claimed-docs] “Use your Partner ID and Secret with the following endpoint whenever you need to generate a new access token”
- [claimed-docs] “link them to at least one account via Connect”
Banking agent access — stories about banking agent access in this arenaBanking agent access
Stories about banking agent access in this arena
Agent data
ai-native userThe data comes back agent-consumable — clean structured JSON, documented schemas, and enrichment an automated financial workflow can reason over without heuristic parsing
weight 2 · round to MXMX publishes a full OpenAPI specification (mx-gh-1, mx-docs-12/26) covering structured request/response payloads across accounts, transactions, balances, identity, and verification endpoints, plus webhooks for event-driven consumption (mx-docs-7/22) and even an official MCP server for agent access (mx-probe-3), directly supporting machine-consumable, schema-documented data for automated workflows. Missing for 10: concrete sample JSON response bodies in the evidence pack and independent third-party corroboration that the schemas are agent-friendly without extra parsing.
- [github] “This repository contains the OpenAPI specification for the MX Platform API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API and its request and response payloads.”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice. This enables you to subscribe to certain events”
- [probe] “official MCP server documented at https://docs.mx.com/mcp”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.mx.com/llms.txt # MX Documentation - [Welcome to the MX Documentation](https://docs.mx.com/index.m…”
Mastercard Open Finance provides structured JSON APIs with documented schemas for account, transaction, balance, and enrichment data (transaction categorization, recurring transactions, spending insights), an OpenAPI spec with generated client libraries, and even an official MCP/agent-toolkit for AI consumption. However, evidence doesn't show explicit example JSON payloads or schema definitions in the pack, nor confirmation that enrichment fields are agent-optimized (e.g., no heuristic parsing needed) versus requiring developer interpretation. missing for 10: concrete JSON schema examples/response samples, explicit confirmation that enrichment output avoids downstream heuristic parsing, independent developer corroboration of agent-readiness.
- [claimed-docs] “The Transaction Data Services provide account transaction data.”
- [claimed-docs] “The account and transaction data elements returned from Account Aggregation and Transaction Data vary depending on the account type.”
- [claimed-docs] “Insights into: * [Transaction types] * [Recurring transactions] * [Consumer spending] * [Loan payments]”
- [github] “The test project generates an API client library from the API specification like you would do in a real application”
- [probe] “official MCP server documented at https://developer.mastercard.com/platform/documentation/agent-toolkit/mcp-overview/”
- [claimed-docs] “Dynamic Code Generation: Generate accurate, working code examples based on current API specifications”
Agent operations
ai-native userAn agent can operate the platform — create link sessions, retrieve balances and transactions, and manage connections through the API or an MCP surface with scoped credentials
weight 3 · round drawnMX 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.”
Mastercard's Open Finance APIs clearly support the core actions an agent would need — creating link sessions via Connect, retrieving balances (Account Balance service), pulling transactions (Transaction Data), and managing connections/webhooks — all gated by PartnerID/secret/appKey OAuth tokens that function as scoped credentials. There is also a documented official MCP surface (agent-toolkit/mcp-overview) explicitly referencing Open Finance use cases like verifying ownership and checking balances, but its documented function is 'dynamic code generation' for developers rather than confirmed direct agentic execution of live account operations. missing for 10: evidence the MCP server itself executes link-session/balance/transaction calls (vs. just generating code samples), and independent/hands-on confirmation of an agent operating end-to-end with scoped MCP credentials.
- [claimed-docs] “The Account Balance service provides real-time or cached bank account balance information from your customer's Financial Institution (FI).”
- [claimed-docs] “The Transaction Data Services provide account transaction data.”
- [claimed-docs] “Webhooks allow you to receive real-time notifications when specific events occur, eliminating the need for constant polling.”
- [claimed-docs] “To create a token, you are required to provide the PartnerID along with the corresponding secret and appKey.”
- [claimed-docs] “Use your Partner ID and Secret with the following endpoint whenever you need to generate a new access token”
- [claimed-docs] “link them to at least one account via Connect”
- [claimed-docs] “Dynamic Code Generation: Generate accurate, working code examples based on current API specifications”
- [claimed-docs] “I need to integrate Open Finance to verify account ownership and check balances for my fintech app”
- [probe] “official MCP server documented at https://developer.mastercard.com/platform/documentation/agent-toolkit/mcp-overview/”
Consent security — stories about consent security in this arenaConsent security
Stories about consent security in this arena
Consent
ops leadEnd users can see and revoke what they've shared — a documented consent surface or portal where a user manages which apps hold access to their bank data
weight 2 · round drawnMXnone0/10The evidence pack covers MX's data connectivity products (account verification, aggregation, transaction history) and webhooks, but contains no mention of any end-user-facing consent dashboard, permissions center, or revocation portal where users can view/manage which apps hold access to their bank data. missing for 10: documented consent/permissions portal, revocation flow, any UI or API for end users to view/manage connected app access.
- [claimed-docs] “MX's ready-made UI that can be embedded in your application to aggregate users' account data by prompting end users to connect to their fina…”
- [claimed-docs] “Use the Connect Widget and Platform API to let end users connect to their accounts.”
- [claimed-docs] “Share your held data with an FDX open finance platform”
Mastercard Open Finance (Finicity)none0/10Evidence pack covers data retrieval, verification, transaction data, webhooks, onboarding tokens, and testing personas, but nowhere documents an end-user-facing consent management portal, dashboard, or revocation mechanism for shared bank-data access. No mention of a consent surface for users to view or revoke connected apps' access.
Deletion
ops leadSever and clean up — a documented way to delete a connection or user and have the platform stop collecting and purge held data
weight 2 · round drawnMXnone0/10The evidence pack covers connectivity, aggregation, webhooks, and API testing but contains no documentation of a delete/disconnect flow for members or users, nor any statement about MX stopping data collection or purging held data upon request. This is a fair question for a financial data aggregator handling sensitive consumer data, but no supporting evidence exists.
Scopes
developerI request only the data scopes I need — product-scoped consents and documented data-minimization controls, not an all-or-nothing grant
weight 2 · round drawnMX 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.”
The docs show a product-based API structure (separate endpoints for account ownership, balance, transactions, ACH, etc.), which implicitly allows requesting only specific data products rather than a single blob, but there is no explicit documentation of scoped consent tokens, granular permission grants, or data-minimization controls presented to developers. missing for 10: explicit consent-scoping API/parameters, documentation of minimal-data-grant mechanisms, evidence of per-scope authorization tokens, and any independent confirmation of data-minimization enforcement.
- [claimed-docs] “Retrieves account ownership details (name, address, email and phone - where available) from a connected account at a financial institution.”
- [claimed-docs] “The Account Balance service provides real-time or cached bank account balance information from your customer's Financial Institution (FI).”
- [claimed-docs] “The Transaction Data Services provide account transaction data.”
- [claimed-docs] “The account and transaction data elements returned from Account Aggregation and Transaction Data vary depending on the account type.”
- [claimed-docs] “[Account] and [transaction] details”
Data freshness — stories about data freshness in this arenaData freshness
Stories about data freshness in this arena
Refresh
developerTrigger an on-demand refresh of a connected account's data through the API when my use case needs now-fresh data, with the refresh semantics documented
weight 2 · round drawnMXnone0/10The evidence only shows MX automatically aggregates accounts on a ~24-hour cycle (mx-docs-25) and describes webhooks for event notifications, but there is no documented API endpoint or semantics for a developer-triggered on-demand refresh of a connected account's data.
- [claimed-docs] “MX automatically aggregates each `member` approximately every 24 hours.”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice. This enables you to subscribe to certain events”
Mastercard Open Finance (Finicity)none0/10Evidence shows account balance can be 'real-time or cached' and webhooks provide event notifications, but there is no documented API endpoint or explicit refresh semantics (e.g., a force-refresh trigger, freshness guarantees, or polling-for-refresh-status flow) for triggering an on-demand data refresh. Missing for 10: an explicit refresh/force-update endpoint, documented refresh semantics (sync vs async, staleness thresholds), and any independent confirmation of on-demand refresh behavior.
- [claimed-docs] “The Account Balance service provides real-time or cached bank account balance information from your customer's Financial Institution (FI).”
- [claimed-docs] “Webhooks allow you to receive real-time notifications when specific events occur, eliminating the need for constant polling.”
- [claimed-docs] “The Transaction Data Services provide account transaction data.”
Webhooks
developerData changes arrive as signed webhooks — new transactions, balance updates, connection state changes — so my system stays current without polling
weight 2 · round to MXMX docs confirm webhooks with HTTPS POST callbacks for subscribing to events like transaction/balance/connection changes, and note that account aggregation runs automatically (~every 24h) with webhook notification rather than requiring polling. Missing for 10: explicit documentation of webhook payload signing/verification mechanism and a full enumerated list of event types, plus independent/hands-on corroboration beyond first-party docs.
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice. This enables you to subscribe to certain events”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice.”
- [claimed-docs] “MX automatically aggregates each `member` approximately every 24 hours.”
Docs confirm webhooks exist for real-time event notifications instead of polling, and OBWMS lets you subscribe to specific events; transaction/notification-type docs exist too. However, there's no evidence of webhook payload signing/verification, and no explicit documentation enumerating events like balance updates or connection-state changes with delivery guarantees. Missing for 10: signature verification mechanism, explicit event-type catalog (transactions/balances/connection state), delivery retry/reliability details.
- [claimed-docs] “Webhooks allow you to receive real-time notifications when specific events occur, eliminating the need for constant polling.”
- [claimed-docs] “OBWMS will provide a comprehensive API for managing real-time event notifications, enabling you to subscribe to specific events, ensuring yo…”
- [claimed-docs] “[Transaction notifications]”
Institution coverage — stories about institution coverage in this arenaInstitution coverage
Stories about institution coverage in this arena
Coverage
founderThe platform documents how many institutions it reaches and where — published coverage numbers and geographies I can check against where my users actually bank
weight 3 · round drawnMXnone0/10The evidence pack covers MX's connectivity products, APIs, and webhooks but contains no published figures on number of institutions reached, geographic coverage, or any coverage map/list a founder could check against their users' banks.
Mastercard Open Finance (Finicity)none0/10The evidence pack covers API capabilities (verification, balances, transaction data, webhooks, onboarding) but contains no published institution-coverage numbers, geographic breakdowns, or bank-reach statistics that a founder could check against their users' banks.
Status
ops leadPer-institution health is visible — documented institution statuses, outage or degradation signals, and error codes that distinguish a bank problem from my problem
weight 2 · round drawnMXnone0/10Evidence covers connectivity, aggregation, webhooks, and test institutions, but there is no documented institution status dashboard, outage/degradation signal, or error-code taxonomy distinguishing bank-side failures from client-side issues. Missing for 10: institution health/status page, outage or degradation indicators, and documented error codes for bank vs integration failure.
Mastercard Open Finance (Finicity)none0/10The evidence pack covers API products (balance, ownership, transaction data, webhooks, onboarding) but contains no mention of institution status dashboards, outage/degradation signals, or error codes distinguishing bank-side vs integration-side issues.
Integration dx — sandboxes, test modes, webhooks, and how fast a developer gets to a working integrationIntegration dx
Sandboxes, test modes, webhooks, and how fast a developer gets to a working integration
Multi product
developerOne link session can power multiple data products — auth, balances, transactions, identity — without forcing the user through separate connection flows per product
weight 2 · round to MXMX'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”
Mastercard Open Finance (Finicity)none0/10The evidence lists multiple separate data products (account ownership, balances, transactions) and mentions a generic 'Connect' linking step, but nothing describes a single link/Connect session simultaneously provisioning auth, balances, transactions, and identity without repeated connection flows per product.
Quickstart
developerGo from signup to my first linked sandbox account fast — self-serve API keys, a runnable quickstart, and client libraries in my language
weight 2 · round to Mastercard Open Finance (Finicity)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.…”
Docs show a self-serve-ish onboarding path (PartnerID/secret/appKey token generation, a non-billable unlimited 'Test Drive' plan, and test personas for sandbox account linking) and a GitHub OpenAPI spec that can generate a client library, but there's no explicit runnable quickstart tutorial or multi-language official client libraries beyond the one generated test project. Missing for 10: an explicit step-by-step quickstart guide, published official SDKs in multiple languages, and clear evidence of instant self-serve API key issuance without a sales/partner approval step.
- [claimed-docs] “To create a token, you are required to provide the PartnerID along with the corresponding secret and appKey.”
- [claimed-docs] “Use your Partner ID and Secret with the following endpoint whenever you need to generate a new access token”
- [claimed-docs] “Test Drive is a non-billable, unlimited plan that provides access to all Open Finance API endpoints.”
- [claimed-docs] “we provide you with a set of testing personas. Each persona represents an example of a user who might use your app.”
- [github] “The test project generates an API client library from the API specification like you would do in a real application”
Sandbox
developerA sandbox with test institutions and documented test credentials lets me exercise linking, data retrieval, and error states end-to-end before touching a real bank account
weight 3 · round to MXMX documents a dedicated test platform with four test institutions and an OpenAPI spec importable into Postman, plus guidance on testing the Connect Widget's OAuth flow end-to-end — directly supporting sandbox-based linking/testing before production use. However, the evidence does not show explicit documented test credentials for each test institution or guidance on simulating specific error states. Missing for 10: documented test credentials per institution, explicit error-state/failure simulation guidance.
- [claimed-docs] “We offer four test institutions that you can use”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API and its request and response payloads.”
- [claimed-docs] “To test OAuth in the Connect Widget when it's embedded in a WebView, you must load the financial institution's OAuth window in the device's …”
Docs confirm a dedicated Test Drive sandbox with unlimited access to all endpoints, testing personas representing different user scenarios, and a GitHub sample project generating a real API client for end-to-end testing — covering linking, data retrieval, and onboarding tokens. However, there is no explicit documentation of error-state simulation or a catalog of documented test credentials/institutions with specific failure scenarios. Missing for 10: explicit documented test credentials list, coverage of error/failure state simulation, and independent/hands-on confirmation of the sandbox experience.
- [claimed-docs] “we provide you with a set of testing personas”
- [claimed-docs] “Test Drive is a non-billable, unlimited plan that provides access to all Open Finance API endpoints.”
- [claimed-docs] “we provide you with a set of testing personas. Each persona represents an example of a user who might use your app.”
- [github] “The test project generates an API client library from the API specification like you would do in a real application”
- [claimed-docs] “link them to at least one account via Connect”
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
ai-native userDo everything through the API that I can do in the UI
weight 2 · round drawnMX 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.”
As an API-first data platform, virtually all core functions (account verification, balances, transactions, ACH details, webhooks/event management, token generation) are exposed directly via documented REST APIs rather than gated behind a UI, and even administrative functions like webhook subscriptions and token creation are API-driven (docs-9, docs-23, docs-26). However, the 'Connect' account-linking flow is a hosted widget/UI experience (docs-27) whose full API-equivalence isn't evidenced, and there's no explicit confirmation that all developer-portal/dashboard actions (billing, partner management) have API parity. Missing for 10: explicit API equivalents for the Connect linking UI, and confirmation that portal/dashboard admin tasks are fully scriptable.
- [claimed-docs] “Webhooks allow you to receive real-time notifications when specific events occur, eliminating the need for constant polling.”
- [claimed-docs] “Use your Partner ID and Secret with the following endpoint whenever you need to generate a new access token”
- [claimed-docs] “OBWMS will provide a comprehensive API for managing real-time event notifications, enabling you to subscribe to specific events, ensuring yo…”
- [claimed-docs] “link them to at least one account via Connect”
- [claimed-docs] “The Transaction Data Services provide account transaction data.”
- [claimed-docs] “Retrieves account ownership details (name, address, email and phone - where available) from a connected account at a financial institution.”
ai-native userExport all of my data in open formats and leave
weight 3 · round to MXMX 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.”
Mastercard Open Finance (Finicity)none0/10This is a B2B financial data API platform, not a consumer product with user-owned data to export; the evidence shows no data export/portability feature for end users to take their data out in open formats and leave. No mention of any account/data export or account deletion/portability capability anywhere in the docs.
ai-native userRead the product's source under an open license
weight 2 · round drawnMXnone0/10MX is a closed commercial fintech API/SaaS product; the only public GitHub repo (mx-gh-1) contains an OpenAPI specification for documentation/integration purposes, not the actual application source code, and no license grants access to MX's implementation source.
- [github] “This repository contains the OpenAPI specification for the MX Platform API”
Payment initiation — stories about payment initiation in this arenaPayment initiation
Stories about payment initiation in this arena
Pay by bank
developerInitiate a bank payment from a connected account — a documented pay-by-bank or payment-initiation product with its live geographies stated honestly
weight 2 · round drawnMXnone0/10MX's evidence covers account verification, aggregation, balance, transaction history, and identity data, plus 'Tokenized Account Numbers... for secure ACH money movement' (mx-docs-24), but there is no documented payment-initiation API/product, no description of initiating a bank payment/transfer, and no stated live geographies for such a capability.
- [claimed-docs] “Tokenized Account Numbers (TANs) are substitute account numbers used for secure ACH money movement.”
- [claimed-docs] “With Instant Account Verification, you can connect to an end user's financial institution and retrieve account and routing numbers for their…”
- [claimed-docs] “With Account Aggregation, connect to end users' financial institutions and retrieve 90 days of data for their accounts and transactions.”
Mastercard Open Finance (Finicity)none0/10The evidence pack describes the 'Pay' product family only as verification (account ownership, balance, ACH details, match), fraud/success prediction, and switching services — none of the docs describe an actual payment-initiation endpoint that moves funds from a connected account, nor any stated live geographies for such a capability. Without a documented API to actually initiate a bank payment, this axis is unmet.
- [claimed-docs] “Retrieves account ownership details (name, address, email and phone - where available) from a connected account at a financial institution.”
- [claimed-docs] “The Account Balance service provides real-time or cached bank account balance information from your customer's Financial Institution (FI).”
- [claimed-docs] “you can send customer data to our match account ownership details endpoint to receive confidence scores comparing the provided data and the …”
- [claimed-docs] “Predict [payment success]”
- [claimed-docs] “Switch [deposits and bill payments]”
- [claimed-docs] “Get ACH details”
Recurring
developerRecurring bank payments are supported — variable recurring payments, standing consents, or documented recurring debit flows built on the connection
weight 2 · round drawnMXnone0/10MX's evidence covers account aggregation, identity/verification, balances, transaction history and ACH microdeposit verification, plus tokenized account numbers for ACH money movement — but there is no mention of variable recurring payments, standing consents, or any recurring/scheduled debit payment-initiation flow.
Mastercard Open Finance (Finicity)none0/10Evidence covers account data (balances, ownership, transactions), ACH details, and 'switch deposits and bill payments' but nothing documents variable recurring payments, standing consents, or a recurring debit/payment-initiation flow — this product's Pay APIs appear focused on verification (account owner, balance, ACH details) rather than initiating recurring debits.
Privacy posture — data-handling and privacy storiesPrivacy posture
Data-handling and privacy stories
ai-native userChoose where my data is stored (region/residency)
weight 2 · round drawnMXnone0/10No evidence in the pack addresses data residency, region selection, or storage location controls for MX's data; all citations concern connectivity, aggregation, and API/testing features. missing for 10: any mention of data residency/region options, compliance certifications tied to geographic storage, or configuration for where data is stored.
Mastercard Open Finance (Finicity)none0/10No evidence anywhere in the pack discusses data residency, regional storage options, or geographic controls for where customer data is stored/processed. This is an applicable axis for a financial data platform handling sensitive PII, but nothing addresses it.
ai-native userPrevent my data from being used to train AI models
weight 3 · round drawnMXnone0/10No evidence in the pack addresses AI training data usage, opt-out controls, or any privacy policy statement about model training; the pack is entirely about financial data connectivity, aggregation, and webhooks.
ai-native userControl data retention and deletion
weight 2 · round drawnMXnone0/10The evidence pack contains no mention of data retention periods, deletion policies, or user/data-controller controls over stored financial data; all citations relate to connectivity, aggregation, and API features rather than privacy/data lifecycle controls.
Mastercard Open Finance (Finicity)none0/10The evidence pack covers API products (account data, verification, transactions, webhooks, onboarding) but contains no mention of data retention policies, deletion controls, or user-facing privacy/data-lifecycle management tools. Missing for 10: any documentation of data retention periods, deletion/erasure APIs, or consumer-facing controls over stored financial data.
ai-native userOpt out of telemetry and usage tracking
weight 2 · round drawnMXnone0/10No evidence pack item addresses telemetry, usage tracking, analytics opt-out, or data collection controls for AI-native usage; the docs focus entirely on financial data connectivity and APIs. Missing for 10: any mention of telemetry collection, an opt-out mechanism, or privacy settings related to usage tracking.
Transactions enrichment — stories about transactions enrichment in this arenaTransactions enrichment
Stories about transactions enrichment in this arena
Cashflow
finance leadThe platform derives income and cash-flow signals from connected accounts — recurring streams, payroll detection, or documented income verification products built on the same data
weight 2 · round to Mastercard Open Finance (Finicity)MXnone0/10MX's evidence covers account aggregation, balances, identity/ownership verification, and general 'data intelligence' or 'personalized guidance' claims, but nothing documents a specific income/cash-flow signal product — no mention of recurring-income detection, payroll detection, or a named income verification offering built on transaction data.
Docs confirm transaction data services with insights into recurring transactions, transaction types, consumer spending, and loan payments, plus credit-decisioning report APIs — directly supporting cash-flow/recurring-stream signals. However, there's no explicit mention of payroll detection or a dedicated income-verification product built on this data. missing for 10: explicit payroll/income detection feature, named income-verification product, independent validation of accuracy.
- [claimed-docs] “The Transaction Data Services provide account transaction data.”
- [claimed-docs] “Insights into: * [Transaction types] * [Recurring transactions] * [Consumer spending] * [Loan payments]”
- [claimed-docs] “APIs for credit decisioning [reports]”
- [claimed-docs] “The account and transaction data elements returned from Account Aggregation and Transaction Data vary depending on the account type.”
Enrichment
developerRaw bank transactions come back enriched — cleaned merchant names, categories, and logos — documented as a capability of the platform, not left as an exercise for me
weight 2 · round to Mastercard Open Finance (Finicity)MXnone0/10The evidence pack covers connectivity, verification, aggregation, webhooks, and testing tools, but never documents transaction enrichment specifics like cleaned merchant names, categorization, or logos — only vague references to 'data-driven intelligence' and 'account and transaction history in one view.' Since enrichment is a fair and expected capability for a financial-data-aggregation platform, but no concrete documentation of merchant cleansing/categories/logos appears, this is 'none' rather than 'na'.
- [claimed-docs] “Use data-driven intelligence about your customers”
- [claimed-docs] “Access account and transaction history all in one view. Use the data to increase multi-product adoption, and build trust.”
- [claimed-docs] “connect to end users' financial institutions and retrieve 90 days of data for their accounts and transactions”
- [claimed-docs] “With Account Aggregation, connect to end users' financial institutions and retrieve 90 days of data for their accounts and transactions.”
Docs confirm Transaction Data Services return categorized insights (transaction types, recurring transactions, consumer spending, loan payments), which implies some enrichment/categorization layer, but nothing explicitly documents merchant-name cleansing or logo attachment as a first-class capability. Missing for 10: explicit documentation of merchant name normalization/cleanup and logo enrichment fields in the transaction schema.
- [claimed-docs] “The Transaction Data Services provide account transaction data.”
- [claimed-docs] “The account and transaction data elements returned from Account Aggregation and Transaction Data vary depending on the account type.”
- [claimed-docs] “Insights into: * [Transaction types] * [Recurring transactions] * [Consumer spending] * [Loan payments]”
Transactions
developerPull transaction history for a connected account through the API — paginated, with documented history depth and a sync pattern for fetching only what changed
weight 3 · round to MXMX clearly documents transaction history depth (90 days standard via Account Aggregation, up to 24 months via Extended Transaction History) and provides a sync mechanism via webhooks plus automatic ~24hr re-aggregation of connected accounts, backed by a public OpenAPI spec for the Platform API. However, the evidence never explicitly documents pagination parameters/behavior for the transactions endpoint itself, and the webhook-based sync isn't described as an incremental 'only what changed' diff pattern (e.g., no mention of delta/cursor tokens). Missing for 10: explicit pagination documentation for transaction list endpoints, explicit incremental/delta sync mechanism beyond generic webhooks/24h refresh.
- [claimed-docs] “connect to end users' financial institutions and retrieve 90 days of data for their accounts and transactions”
- [claimed-docs] “you can connect to an end user's financial institution and retrieve up to 24 months of data for their accounts and transactions”
- [claimed-docs] “With Account Aggregation, connect to end users' financial institutions and retrieve 90 days of data for their accounts and transactions.”
- [claimed-docs] “With Extended Transaction History, you can connect to an end user's financial institution and retrieve up to 24 months of data for their acc…”
- [claimed-docs] “MX automatically aggregates each `member` approximately every 24 hours.”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice. This enables you to subscribe to certain events”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice.”
- [github] “This repository contains the OpenAPI specification for the MX Platform API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API”
Evidence confirms a dedicated Transaction Data Services API that returns account/transaction details and varies by account type, plus a webhook/notification system explicitly framed as eliminating constant polling, which implies a change-based sync pattern. However, no evidence documents pagination mechanics or a specific stated history depth (e.g., days/months of transactions) for the transaction endpoint. missing for 10: explicit pagination documentation, stated transaction history depth/lookback window, explicit delta/cursor sync pattern for transactions specifically (webhooks reference is generic, not transaction-specific).
- [claimed-docs] “The Transaction Data Services provide account transaction data.”
- [claimed-docs] “The account and transaction data elements returned from Account Aggregation and Transaction Data vary depending on the account type.”
- [claimed-docs] “Webhooks allow you to receive real-time notifications when specific events occur, eliminating the need for constant polling.”
- [claimed-docs] “[Account] and [transaction] details”
- [claimed-docs] “Insights into: * [Transaction types] * [Recurring transactions] * [Consumer spending] * [Loan payments]”
- [claimed-docs] “OBWMS will provide a comprehensive API for managing real-time event notifications, enabling you to subscribe to specific events, ensuring yo…”
Not comparable on these axes
ai-native userPlug MCP servers into this product so it can use their tools
weight 3 · not comparableMXnone0/10Evidence shows MX publishes its own MCP server (docs.mx.com/mcp) so external agents can call MX's tools, but this is the opposite role from the story, which asks whether MX itself can consume/plug in external MCP servers and use their tools. There is no documentation of MX acting as an MCP client or any mechanism for feeding third-party MCP tool servers into MX's own workflows or its conversational AI feature.
- [probe] “official MCP server documented at https://docs.mx.com/mcp”
- [claimed-docs] “Provide an experience where consumers can ask about their money in plain language and act on the answer, with every figure pulled from real …”
Mastercard Open Finance (Finicity)n/aMastercard Open Finance is a financial data/API platform, not an agent or assistant host that could itself consume external MCP servers as tools; the evidence only shows Mastercard publishing its own MCP server (agent-toolkit) for others to call into Open Finance APIs, which is the opposite role from 'plugging MCP servers into this product'.
- [probe] “official MCP server documented at https://developer.mastercard.com/platform/documentation/agent-toolkit/mcp-overview/”
- [claimed-docs] “Dynamic Code Generation: Generate accurate, working code examples based on current API specifications”
ai-native userDelegate tasks to a built-in AI assistant inside the product
weight 3 · not comparableMXnone0/10The evidence shows MX enabling data connectivity and hints at conversational/personalized finance experiences (mx-docs-27, mx-docs-13/14) that MX's customers could build for their end-users, but there is no evidence of a built-in AI assistant inside the MX product itself that an AI-native user could delegate tasks to.
Mastercard Open Finance (Finicity)n/aMastercard Open Finance is a developer API platform for financial data/verification, not a consumer or workflow product with a built-in AI assistant persona to delegate tasks to; the MCP toolkit evidence is about exposing APIs to external agents/tools, not a native in-product assistant.
ai-native userVersion, review, and roll back my automations
weight 1 · not comparableMXn/aMX is a financial data connectivity/aggregation API platform, not an automation-builder tool; there is no concept of 'automations' with version/review/rollback in its product surface, so this axis is a category error rather than an unmet capability.
ai-native userSelf-host the core product
weight 3 · not comparableMXn/aMX is a cloud-hosted financial data connectivity API/SaaS platform with no evidence of any self-hostable core product; self-hosting is a category error for this kind of managed financial-data service.