MX vs Yapily
enterprise-custom
·enterprise-custom
MX wins · 17–11 (20 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.”
Yapily Connect is explicitly documented as a ready-built, white-label hosted UI for AIS/PIS flows with pre-built institution selection and consent screens, no frontend engineering required, automatic SCA/redirect handling, and customizable branding — matching the drop-in widget story closely. Missing for 10: explicit documentation of the server-side 'create session' API call and the exact token/consent-object returned to the backend after widget completion, plus independent/hands-on corroboration beyond vendor docs.
- [claimed-docs] “Yapily Connect provides a ready-built, white-label open banking UI for AIS and PIS flows. Reduce development effort with pre-built instituti…”
- [claimed-docs] “No frontend engineering required for consent and authorisation flows”
- [claimed-docs] “Handles Strong Customer Authentication (SCA) and bank redirects automatically”
- [claimed-docs] “Customisable branding (logo and colours)”
- [claimed-docs] “UX design guidelines for Yapily Connect AIS flows. Best practices for institution selection, consent screens, and account selection for data…”
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 to YapilyMXnone0/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 …”
Yapily's docs describe bank redirect and SCA-based consent flows (docs-9, docs-10) which imply OAuth-style bank-hosted authentication rather than screen-scraping, but no evidence explicitly uses the term 'OAuth,' documents OAuth coverage across institutions, or discusses retirement of legacy credential-scraping flows. Missing for 10: explicit OAuth terminology/documentation, institution-by-institution OAuth coverage stats, and any statement about phasing out screen-scraped credential flows.
- [claimed-docs] “No frontend engineering required for consent and authorisation flows”
- [claimed-docs] “Handles Strong Customer Authentication (SCA) and bank redirects automatically”
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.
Yapilynone0/10The evidence pack covers payments, data retrieval, webhooks, and Yapily Connect UI, but nothing documents how expired/revoked consent links surface as statuses or how users re-authenticate via an update flow without restarting the linking process — missing for 10: documented consent-expiry/revocation status codes, and an explicit re-auth/update flow that preserves prior linkage.
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 drawnMX 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.
Yapily explicitly documents an llms.txt file (confirmed live via probe returning HTTP 200) and dedicated agent-oriented docs describing how to connect Claude, Cursor, or other AI agents via MCP, llms.txt, or Agent Skills, directly matching the story. Missing for 10: independent third-party confirmation of an agent successfully consuming the docs end-to-end.
- [claimed-docs] “Connect Claude, Cursor, or another AI coding agent directly to these docs via MCP, llms.txt, or Agent Skills.”
- [claimed-docs] “Yapily Connect provides a ready-built, white-label open banking UI for AIS and PIS flows. Reduce development effort with pre-built instituti…”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.yapily.com/llms.txt # Yapily API Documentation - [Welcome to Yapily Docs](https://docs.yapily.com/…”
- [probe] “official MCP server documented at https://docs.yapily.com/resources/ai-agents”
ai-native userRun the product headlessly / in CI for automation
weight 2 · round drawnMX is an API-first platform with a documented REST/OpenAPI spec (mx-gh-1, mx-docs-12/26) and webhooks (mx-docs-7/22) that could be driven headlessly from CI, but there is no explicit evidence of a CLI, headless SDK mode, or documented CI/automation workflow — the Connect Widget appears UI-embedded (mx-docs-9, mx-docs-21) which cuts against pure headless use. missing for 10: explicit CI/headless usage docs, a CLI or automation-focused SDK, confirmation that Connect flows can run without embedded UI.
- [github] “This repository contains the OpenAPI specification for the MX Platform API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API and its request and response payloads.”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice. This enables you to subscribe to certain events”
- [claimed-docs] “MX's ready-made UI that can be embedded in your application to aggregate users' account data by prompting end users to connect to their fina…”
- [claimed-docs] “Use the Connect Widget and Platform API to let end users connect to their accounts.”
Yapily is a REST/API-first platform (payments, data, webhooks) with a sandbox for testing and generated client libraries, implying it can be scripted/automated without a UI, but there is no explicit documentation of running it headlessly in a CI pipeline, no CLI tool, and no automation/testing-pipeline example. missing for 10: explicit CI/CD or headless automation documentation, a CLI or scriptable test harness, evidence of pipeline integration examples.
- [claimed-docs] “A sandbox is a test environment that allows you to connect your application to a bank and access test accounts to simulate the real Open Ban…”
- [claimed-docs] “Generate API client libraries for Yapily in your preferred language using the OpenAPI specification. Supports code generation for Java, Pyth…”
- [claimed-docs] “Webhooks allows you to receive real-time HTTP notifications of changes happening in the Yapily Platform.”
- [claimed-docs] “No frontend engineering required for consent and authorisation flows”
ai-native userConnect an agent via an official MCP server
weight 3 · round to MXMX documents an official MCP server at docs.mx.com/mcp, confirmed via probe, indicating a first-party MCP integration point. Missing for 10: detailed setup/config docs excerpt, independent/hands-on confirmation of the MCP server working, and specifics on tool coverage exposed via MCP.
- [probe] “official MCP server documented at https://docs.mx.com/mcp”
Yapily documents an official MCP server for connecting AI agents (Claude, Cursor) to its docs, confirmed by both docs and a probe verifying the ai-agents.md resource, so the axis clearly applies and is addressed. However, the evidence only shows MCP access to documentation/context, not to Yapily's actual banking APIs (payments, data, AIS/PIS) as agent-callable tools, and there's no independent or hands-on confirmation of the MCP server's tool set in action. Missing for 10: evidence that the MCP server exposes real API operations (payments, account data) as agent tools, tool/resource list details, and independent corroboration beyond first-party docs.
- [claimed-docs] “Connect Claude, Cursor, or another AI coding agent directly to these docs via MCP, llms.txt, or Agent Skills.”
- [probe] “official MCP server documented at https://docs.yapily.com/resources/ai-agents”
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.
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”
Yapily is API-first: docs describe endpoints for payments, data, webhooks, and confirm OpenAPI-based client library generation, plus explicit AI-agent access via MCP/llms.txt (confirmed live by probe-1 and probe-3), directly matching the 'documented public API for AI-native use' story. Missing for 10: a verifiable OpenAPI spec file (probe-2 found all standard OpenAPI/swagger paths 404) and independent third-party confirmation of API completeness beyond first-party docs.
- [claimed-docs] “Generate API client libraries for Yapily in your preferred language using the OpenAPI specification. Supports code generation for Java, Pyth…”
- [claimed-docs] “Connect Claude, Cursor, or another AI coding agent directly to these docs via MCP, llms.txt, or Agent Skills.”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.yapily.com/llms.txt # Yapily API Documentation - [Welcome to Yapily Docs](https://docs.yapily.com/…”
- [probe] “official MCP server documented at https://docs.yapily.com/resources/ai-agents”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.yapily.com/openapi.json, https://docs.yapily.com/swagger.json, https://docs.yapily.com/…”
- [claimed-docs] “You can initiate single, scheduled and periodic payments using Yapily's Payments API.”
- [claimed-docs] “Using Yapily's Data API you can access your customers' financial data including account balances, transaction history and account details to…”
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.
ai-native userBuild against official SDKs
weight 2 · round to YapilyMX 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.”
Yapily documents generating client libraries from an OpenAPI spec for Java, Python, Node.js, etc., which supports the 'official SDK' story, but this is code generation rather than a maintained, first-party SDK repository, and the probe found no accessible OpenAPI spec file, undermining confidence in this claim. missing for 10: evidence of actual published/maintained SDK repos (GitHub links, versioning, install instructions), independent corroboration, and working OpenAPI spec access.
- [claimed-docs] “Generate API client libraries for Yapily in your preferred language using the OpenAPI specification. Supports code generation for Java, Pyth…”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.yapily.com/openapi.json, https://docs.yapily.com/swagger.json, https://docs.yapily.com/…”
ai-native userSubscribe to events via webhooks
weight 2 · round drawnMX 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.”
Yapily documents a dedicated webhooks system delivering real-time HTTP notifications of platform events (e.g., payment status changes), directly matching the story. Missing for 10: independent/hands-on corroboration of webhook reliability and no detail on subscription filtering/event types.
- [claimed-docs] “Webhooks allows you to receive real-time HTTP notifications of changes happening in the Yapily Platform.”
- [claimed-docs] “You can track the status of each payment via [Webhooks](/tools-and-services/webhooks/get-started) from the Yapily API for visibility of the …”
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.”
Yapilynone0/10Yapily's data API supports transaction categorisation and spending insights (yapily-docs-3), but this is not documented as AI-generated insights or suggestions surfaced within a Yapily product interface; the only AI-related evidence concerns connecting coding agents to its docs via MCP, not AI-driven analysis of user data.
- [claimed-docs] “Categorise and analyse transaction data with merchant detection and spending insights.”
- [claimed-docs] “Connect Claude, Cursor, or another AI coding agent directly to these docs via MCP, llms.txt, or Agent Skills.”
ai-native userSet up automations that run autonomously in the background
weight 2 · round to YapilyMX 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”
Yapily's Payments API supports scheduled and recurring/variable-recurring payments that execute autonomously without re-authorisation, and webhooks provide background event notifications — both are forms of autonomous background automation. However, there's no evidence of an AI-agent-specific automation-setup flow (e.g., an agent configuring or monitoring these jobs), just generic API-level scheduling. Missing for 10: explicit AI-agent-driven automation setup, agent monitoring/adjusting of scheduled tasks, and independent confirmation of reliability of unattended runs.
- [claimed-docs] “Initiate bank-to-bank payments directly from your customer's account. Single, scheduled, or recurring.”
- [claimed-docs] “Collect variable recurring payments without re-authorisation each time.”
- [claimed-docs] “You can initiate single, scheduled and periodic payments using Yapily's Payments API.”
- [claimed-docs] “Webhooks allows you to receive real-time HTTP notifications of changes happening in the Yapily Platform.”
- [claimed-docs] “You can track the status of each payment via [Webhooks](/tools-and-services/webhooks/get-started) from the Yapily API for visibility of the …”
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 …”
Yapilynone0/10Yapily's evidence covers a developer API/SDKs and an MCP-served documentation assistant for coding agents (yapily-docs-6, yapily-probe-3), but there is no evidence that end users can issue natural-language commands to actually operate Yapily's core functions (payments, account data retrieval, etc.). The MCP/llms.txt integration is for helping coding agents navigate docs, not a natural-language control interface for the product's operations.
- [claimed-docs] “Connect Claude, Cursor, or another AI coding agent directly to these docs via MCP, llms.txt, or Agent Skills.”
- [probe] “official MCP server documented at https://docs.yapily.com/resources/ai-agents”
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.…”
Yapilynone0/10No evidence of an interactive API reference or runnable code examples; the OpenAPI spec probe returned 404s and docs only mention static content, code-gen libraries, and AI-agent integration (MCP/llms.txt), not an interactive playground with runnable examples.
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.yapily.com/openapi.json, https://docs.yapily.com/swagger.json, https://docs.yapily.com/…”
- [claimed-docs] “Generate API client libraries for Yapily in your preferred language using the OpenAPI specification. Supports code generation for Java, Pyth…”
- [claimed-docs] “Connect Claude, Cursor, or another AI coding agent directly to these docs via MCP, llms.txt, or Agent Skills.”
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.…”
Yapilydisputedcontradicted4/10Docs reference an OpenAPI specification used to generate client libraries (yapily-docs-8), implying a machine-readable spec exists, but a direct probe for standard OpenAPI/Swagger file locations returned 404 everywhere (yapily-probe-2), meaning no publicly downloadable spec could be located. missing for 10: a working public URL/download link for the OpenAPI/Swagger file, confirmation of its format and completeness, and independent corroboration that it can actually be fetched.
- [claimed-docs] “Generate API client libraries for Yapily in your preferred language using the OpenAPI specification. Supports code generation for Java, Pyth…”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.yapily.com/openapi.json, https://docs.yapily.com/swagger.json, https://docs.yapily.com/…”
ai-native userTest against a sandbox environment without touching production data
weight 1 · round to YapilyMX 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.”
Yapily explicitly documents a sandbox environment that simulates real Open Banking flows with test accounts/banks so developers can test without touching production data (yapily-docs-12), supported by webhook and API docs for testing flows. Missing for 10: independent/hands-on confirmation of sandbox behavior and explicit detail on data isolation guarantees beyond the doc description.
- [claimed-docs] “A sandbox is a test environment that allows you to connect your application to a bank and access test accounts to simulate the real Open Ban…”
- [claimed-docs] “Webhooks allows you to receive real-time HTTP notifications of changes happening in the Yapily Platform.”
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.”
Yapilynone0/10No evidence pack items mention API versioning scheme or a documented deprecation policy; docs reference API capabilities, sandbox, webhooks, and client library generation but nothing about version lifecycle or deprecation commitments. missing for 10: versioning scheme documentation, deprecation policy/notice process, changelog or migration guides.
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 to YapilyMXnone0/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.
Yapily's docs mention 'bulk' as a supported payment type alongside scheduled/periodic/international payments, indicating some batch-processing capability, but there is no detailed documentation of bulk API semantics (batch size limits, bulk data retrieval, bulk consent management, etc.) beyond this one-line reference. missing for 10: dedicated bulk API endpoint documentation, batch limits/pagination for data retrieval, examples of bulk operations in practice.
- [claimed-docs] “Choose this when you need payment types Hosted does not yet support (bulk, scheduled, periodic, international)”
- [claimed-docs] “You can initiate single, scheduled and periodic payments using Yapily's Payments API.”
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.”
Yapilynone0/10Yapily documents webhooks for real-time event notifications, but there is no evidence of a rules engine or mechanism letting users define conditional triggers that automatically execute actions based on events — webhooks only notify, they don't let a user configure 'if X then do Y' automation.
- [claimed-docs] “Webhooks allows you to receive real-time HTTP notifications of changes happening in the Yapily Platform.”
- [claimed-docs] “You can track the status of each payment via [Webhooks](/tools-and-services/webhooks/get-started) from the Yapily API for visibility of the …”
ai-native userSchedule recurring jobs or workflows
weight 2 · round to YapilyMXnone0/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”
Yapily's Payments API explicitly supports scheduled and recurring (periodic/variable recurring) payment initiation, which is a concrete recurring-job capability exposed via API and webhooks for status tracking. However, this is domain-specific (payments only) rather than a general-purpose job/workflow scheduler or automation engine that an AI agent could use to orchestrate arbitrary recurring tasks. Missing for 10: evidence of a generic scheduling/orchestration API or cron-like trigger system beyond payment initiation, and no independent corroboration of this working end-to-end.
- [claimed-docs] “Initiate bank-to-bank payments directly from your customer's account. Single, scheduled, or recurring.”
- [claimed-docs] “Collect variable recurring payments without re-authorisation each time.”
- [claimed-docs] “You can initiate single, scheduled and periodic payments using Yapily's Payments API.”
- [claimed-docs] “Choose this when you need payment types Hosted does not yet support (bulk, scheduled, periodic, international)”
- [claimed-docs] “You can track the status of each payment via [Webhooks](/tools-and-services/webhooks/get-started) from the Yapily API for visibility of the …”
- [claimed-docs] “Payments are made via local payment rails including Faster Payments in the UK and SEPA in Europe for fast settlement”
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.”
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 YapilyMX 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”
Yapily's Data API explicitly documents retrieving account balances (via AIS/Open Banking) alongside accounts and transactions, which is the core capability needed for pre-payment balance checks. Missing for 10: explicit 'real-time' latency guarantees and explicit framing of the endpoint for NSF/risk-check use cases.
- [claimed-docs] “Retrieve accounts, balances, and transactions with user consent.”
- [claimed-docs] “Using Yapily's Data API you can access your customers' financial data including account balances, transaction history and account details to…”
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 to MXMX'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…”
Yapily explicitly documents confirming account ownership and retrieving customer details, plus broader Data API access to account details/balances for identity matching purposes. Missing for 10: no explicit breakdown of which fields (name, address, contact) are returned, and no independent/hands-on corroboration beyond first-party docs.
- [claimed-docs] “Confirm account ownership and customer details instantly.”
- [claimed-docs] “Using Yapily's Data API you can access your customers' financial data including account balances, transaction history and account details to…”
- [claimed-docs] “Retrieve accounts, balances, and transactions with user consent.”
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”
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…”
Docs show enrichment (merchant detection, spending insights) and a Data API returning structured account/transaction/balance data, plus OpenAPI-based client generation implying documented schemas (yapily-docs-3, yapily-docs-2, yapily-docs-8, yapily-docs-15). However, a probe found the openapi.json/swagger.json spec not resolvable at standard paths, casting doubt on how discoverable the machine-readable schema actually is, and no evidence pack item shows an actual JSON response sample or schema definition. Missing for 10: concrete JSON response examples/schema snippets, confirmation of a publicly resolvable OpenAPI spec, and explicit statement that enrichment fields are machine-parseable without heuristics.
- [claimed-docs] “Retrieve accounts, balances, and transactions with user consent.”
- [claimed-docs] “Categorise and analyse transaction data with merchant detection and spending insights.”
- [claimed-docs] “Generate API client libraries for Yapily in your preferred language using the OpenAPI specification. Supports code generation for Java, Pyth…”
- [claimed-docs] “Using Yapily's Data API you can access your customers' financial data including account balances, transaction history and account details to…”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.yapily.com/openapi.json, https://docs.yapily.com/swagger.json, https://docs.yapily.com/…”
Agent operations
ai-native userAn agent can operate the platform — create link sessions, retrieve balances and transactions, and manage connections through the API or an MCP surface with scoped credentials
weight 3 · round to MXMX exposes a full Platform API (with OpenAPI spec) covering balances, transactions, account aggregation, connect sessions/members, and webhooks, and there is a documented MCP surface at docs.mx.com/mcp confirming an MCP entry point exists. However, the evidence pack lacks detail on MCP tool scoping, credential/permission scoping for agent use, or hands-on confirmation of agent-driven session creation and connection management via MCP. missing for 10: documented MCP tool list/schema, evidence of scoped credentials for agent access, independent/hands-on validation of the MCP surface in agentic workflows.
- [probe] “official MCP server documented at https://docs.mx.com/mcp”
- [github] “This repository contains the OpenAPI specification for the MX Platform API”
- [claimed-docs] “Get the available balance for an end user’s financial accounts”
- [claimed-docs] “connect to end users' financial institutions and retrieve 90 days of data for their accounts and transactions”
- [claimed-docs] “Use the Connect Widget and Platform API to let end users connect to their accounts.”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice.”
Yapily's API clearly supports creating consent/link sessions, retrieving balances/transactions, and managing connections (yapily-docs-2, -7, -9, -15), and there is an MCP surface (yapily-docs-6, yapily-probe-3) — but that MCP is documented as connecting coding agents (Claude/Cursor) to the documentation, not as an operational interface for agents to actually invoke banking actions with scoped credentials. Missing for 10: evidence of an MCP tool surface that performs live API calls (link sessions, balance/transaction retrieval) rather than just docs access, and explicit scoped-credential/agent-auth model for such calls.
- [claimed-docs] “Retrieve accounts, balances, and transactions with user consent.”
- [claimed-docs] “Yapily Connect provides a ready-built, white-label open banking UI for AIS and PIS flows. Reduce development effort with pre-built instituti…”
- [claimed-docs] “No frontend engineering required for consent and authorisation flows”
- [claimed-docs] “Using Yapily's Data API you can access your customers' financial data including account balances, transaction history and account details to…”
- [claimed-docs] “Connect Claude, Cursor, or another AI coding agent directly to these docs via MCP, llms.txt, or Agent Skills.”
- [probe] “official MCP server documented at https://docs.yapily.com/resources/ai-agents”
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”
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 to YapilyMX 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.”
Yapily separates its offerings into distinct products (Data API for AIS, Payments API for PIS, account confirmation, VRP) each with its own consent screen, implying developers only request the product-specific consent they need rather than a single blanket grant (yapily-docs-2, -15, -16, -20). However, there is no explicit documentation of fine-grained data-minimization controls within a product (e.g., requesting balances only vs. full transaction history) or scope parameters in the API reference. missing for 10: granular in-product scope/field-level consent documentation, explicit data-minimization API parameters, independent confirmation of scope enforcement.
- [claimed-docs] “Retrieve accounts, balances, and transactions with user consent.”
- [claimed-docs] “Using Yapily's Data API you can access your customers' financial data including account balances, transaction history and account details to…”
- [claimed-docs] “You can initiate single, scheduled and periodic payments using Yapily's Payments API.”
- [claimed-docs] “UX design guidelines for Yapily Connect AIS flows. Best practices for institution selection, consent screens, and account selection for data…”
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”
Yapilynone0/10Evidence covers account data retrieval, webhooks for real-time notifications, and payments, but nothing describes an on-demand refresh endpoint/parameter or documents refresh semantics (e.g., how often data updates or how to force a refresh). Missing for 10: any mention of a refresh API/endpoint, refresh frequency/rate limits, or documented semantics for on-demand data freshness.
- [claimed-docs] “Retrieve accounts, balances, and transactions with user consent.”
- [claimed-docs] “Webhooks allows you to receive real-time HTTP notifications of changes happening in the Yapily Platform.”
- [claimed-docs] “Using Yapily's Data API you can access your customers' financial data including account balances, transaction history and account details to…”
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.”
Yapily documents webhooks for real-time HTTP notifications of platform changes, explicitly used for payment status tracking, supporting event-driven updates instead of polling. However, the evidence never confirms webhook payloads are cryptographically signed, nor details specific coverage for new transactions/balance updates/connection state changes as separate event types. Missing for 10: signature/verification mechanism documentation, explicit event types for transactions/balances/connection state, and independent confirmation of reliability.
- [claimed-docs] “Webhooks allows you to receive real-time HTTP notifications of changes happening in the Yapily Platform.”
- [claimed-docs] “You can track the status of each payment via [Webhooks](/tools-and-services/webhooks/get-started) from the Yapily API for visibility of the …”
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.
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.
Yapilynone0/10No evidence of a documented institution status page, outage/degradation signals, or error-code taxonomy distinguishing bank-side failures from client-side issues; only generic webhook and payment-status mentions are present. Missing for 10: institution status/availability page, degradation/outage signals, and documented bank-vs-integration error code distinctions.
- [claimed-docs] “You can track the status of each payment via [Webhooks](/tools-and-services/webhooks/get-started) from the Yapily API for visibility of the …”
- [claimed-docs] “Webhooks allows you to receive real-time HTTP notifications of changes happening in the Yapily Platform.”
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”
Yapily's Data API and consent flow (via Yapily Connect) grant access to accounts, balances, transactions, and identity data under a single AIS consent/session (yapily-docs-2, yapily-docs-4, yapily-docs-15, yapily-docs-20), and Yapily Connect explicitly reduces repeated consent screens across flows (yapily-docs-7, yapily-docs-9). However, payments (PIS) are documented as a separate initiation flow/API from data access (AIS), and no evidence explicitly confirms a single link/consent session spans both AIS and PIS products without re-authentication. missing for 10: explicit confirmation that one consent/session token covers both payments and data products together, and independent/hands-on evidence of a true single multi-product session rather than per-product consent screens.
- [claimed-docs] “Retrieve accounts, balances, and transactions with user consent.”
- [claimed-docs] “Confirm account ownership and customer details instantly.”
- [claimed-docs] “Yapily Connect provides a ready-built, white-label open banking UI for AIS and PIS flows. Reduce development effort with pre-built instituti…”
- [claimed-docs] “No frontend engineering required for consent and authorisation flows”
- [claimed-docs] “Using Yapily's Data API you can access your customers' financial data including account balances, transaction history and account details to…”
- [claimed-docs] “UX design guidelines for Yapily Connect AIS flows. Best practices for institution selection, consent screens, and account selection for data…”
- [claimed-docs] “You can initiate single, scheduled and periodic payments using Yapily's Payments API.”
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 drawnMX 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.…”
Evidence confirms a sandbox test environment (yapily-docs-12) and client library generation via OpenAPI spec for Java, Python, Node.js, etc. (yapily-docs-8), but there is no evidence of a self-serve signup flow, API key issuance process, or a runnable quickstart guide. The openapi.json probe returned 404s across all candidate paths, casting doubt on how straightforward the client-library generation actually is in practice. missing for 10: self-serve signup/API-key evidence, an explicit quickstart walkthrough, working OpenAPI spec endpoint, independent corroboration of time-to-first-sandbox-account.
- [claimed-docs] “A sandbox is a test environment that allows you to connect your application to a bank and access test accounts to simulate the real Open Ban…”
- [claimed-docs] “Generate API client libraries for Yapily in your preferred language using the OpenAPI specification. Supports code generation for Java, Pyth…”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.yapily.com/openapi.json, https://docs.yapily.com/swagger.json, https://docs.yapily.com/…”
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 sandbox exists to connect to test banks and simulate the Open Banking experience, but the evidence pack doesn't detail documented test credentials, specific error-state simulation, or step-by-step end-to-end linking/retrieval walkthroughs. missing for 10: explicit test credentials list, error/edge-case simulation documentation, independent/hands-on confirmation of the sandbox experience.
- [claimed-docs] “A sandbox is a test environment that allows you to connect your application to a bank and access test accounts to simulate the real Open Ban…”
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.”
Yapily's UI (Yapily Connect) is explicitly described as a pre-built white-label layer for AIS/PIS flows that sits on top of the same Data and Payments APIs (docs-7, docs-9, docs-15, docs-16), implying most UI functionality is API-backed rather than API-exclusive. However, there is no explicit documentation stating full UI/API parity, and a probe found no discoverable OpenAPI spec at expected locations, raising doubt about complete self-service API coverage. Missing for 10: explicit parity statement enumerating any UI-only conveniences (e.g., branding, consent screen customization) and their API equivalents, and a working public OpenAPI spec confirming full endpoint coverage.
- [claimed-docs] “Yapily Connect provides a ready-built, white-label open banking UI for AIS and PIS flows. Reduce development effort with pre-built instituti…”
- [claimed-docs] “No frontend engineering required for consent and authorisation flows”
- [claimed-docs] “Using Yapily's Data API you can access your customers' financial data including account balances, transaction history and account details to…”
- [claimed-docs] “You can initiate single, scheduled and periodic payments using Yapily's Payments API.”
- [claimed-docs] “Generate API client libraries for Yapily in your preferred language using the OpenAPI specification. Supports code generation for Java, Pyth…”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.yapily.com/openapi.json, https://docs.yapily.com/swagger.json, https://docs.yapily.com/…”
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.”
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 to YapilyMXnone0/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.”
Yapily's docs clearly describe payment initiation (single, scheduled, periodic, recurring/VRP) via its Payments API using local rails like UK Faster Payments and European SEPA, giving some geographic grounding, but there is no comprehensive, explicit list of supported countries/markets or independent confirmation of live coverage claims. missing for 10: full country/geography list, independent verification of live markets, and any hands-on confirmation of payment success rates.
- [claimed-docs] “Initiate bank-to-bank payments directly from your customer's account. Single, scheduled, or recurring.”
- [claimed-docs] “You can initiate single, scheduled and periodic payments using Yapily's Payments API.”
- [claimed-docs] “Choose this when you need payment types Hosted does not yet support (bulk, scheduled, periodic, international)”
- [claimed-docs] “Payments are made via local payment rails including Faster Payments in the UK and SEPA in Europe for fast settlement”
- [claimed-docs] “You can track the status of each payment via [Webhooks](/tools-and-services/webhooks/get-started) from the Yapily API for visibility of the …”
Recurring
developerRecurring bank payments are supported — variable recurring payments, standing consents, or documented recurring debit flows built on the connection
weight 2 · round to YapilyMXnone0/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.
Docs explicitly cover recurring/scheduled/periodic payments (yapily-docs-1, -16, -17) and dedicated variable recurring payment support without re-authorisation (yapily-docs-5), plus webhook-based status tracking and local rail settlement for recurring debits (yapily-docs-18, -21). Missing for 10: independent/hands-on confirmation of VRP flows in production and more detail on standing consent lifecycle management beyond docs claims.
- [claimed-docs] “Initiate bank-to-bank payments directly from your customer's account. Single, scheduled, or recurring.”
- [claimed-docs] “Collect variable recurring payments without re-authorisation each time.”
- [claimed-docs] “You can initiate single, scheduled and periodic payments using Yapily's Payments API.”
- [claimed-docs] “Choose this when you need payment types Hosted does not yet support (bulk, scheduled, periodic, international)”
- [claimed-docs] “You can track the status of each payment via [Webhooks](/tools-and-services/webhooks/get-started) from the Yapily API for visibility of the …”
- [claimed-docs] “Payments are made via local payment rails including Faster Payments in the UK and SEPA in Europe for fast settlement”
Privacy posture — data-handling and privacy storiesPrivacy posture
Data-handling and privacy stories
ai-native userChoose where my data is stored (region/residency)
weight 2 · round drawnMXnone0/10No evidence in the pack addresses data residency, region selection, or storage location controls for MX's data; all citations concern connectivity, aggregation, and API/testing features. missing for 10: any mention of data residency/region options, compliance certifications tied to geographic storage, or configuration for where data is stored.
ai-native userControl data retention and deletion
weight 2 · round drawnMXnone0/10The evidence pack contains no mention of data retention periods, deletion policies, or user/data-controller controls over stored financial data; all citations relate to connectivity, aggregation, and API features rather than privacy/data lifecycle controls.
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 drawnMXnone0/10MX's evidence covers account aggregation, balances, identity/ownership verification, and general 'data intelligence' or 'personalized guidance' claims, but nothing documents a specific income/cash-flow signal product — no mention of recurring-income detection, payroll detection, or a named income verification offering built on transaction data.
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 YapilyMXnone0/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 explicitly claim categorisation, merchant detection, and spending insights on transaction data (yapily-docs-3, yapily-docs-15), directly supporting enrichment as a documented platform capability rather than a DIY task. However, no evidence specifically documents merchant logo enrichment or detailed 'cleaned name' normalization, and there's no independent/hands-on confirmation of enrichment quality. Missing for 10: explicit logo enrichment documentation, detail on merchant name cleaning methodology, third-party/hands-on validation of enrichment accuracy.
- [claimed-docs] “Categorise and analyse transaction data with merchant detection and spending insights.”
- [claimed-docs] “Using Yapily's Data API you can access your customers' financial data including account balances, transaction history and account details to…”
Transactions
developerPull transaction history for a connected account through the API — paginated, with documented history depth and a sync pattern for fetching only what changed
weight 3 · round to MXMX clearly documents transaction history depth (90 days standard via Account Aggregation, up to 24 months via Extended Transaction History) and provides a sync mechanism via webhooks plus automatic ~24hr re-aggregation of connected accounts, backed by a public OpenAPI spec for the Platform API. However, the evidence never explicitly documents pagination parameters/behavior for the transactions endpoint itself, and the webhook-based sync isn't described as an incremental 'only what changed' diff pattern (e.g., no mention of delta/cursor tokens). Missing for 10: explicit pagination documentation for transaction list endpoints, explicit incremental/delta sync mechanism beyond generic webhooks/24h refresh.
- [claimed-docs] “connect to end users' financial institutions and retrieve 90 days of data for their accounts and transactions”
- [claimed-docs] “you can connect to an end user's financial institution and retrieve up to 24 months of data for their accounts and transactions”
- [claimed-docs] “With Account Aggregation, connect to end users' financial institutions and retrieve 90 days of data for their accounts and transactions.”
- [claimed-docs] “With Extended Transaction History, you can connect to an end user's financial institution and retrieve up to 24 months of data for their acc…”
- [claimed-docs] “MX automatically aggregates each `member` approximately every 24 hours.”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice. This enables you to subscribe to certain events”
- [claimed-docs] “MX provides webhooks that send HTTPS POST callback requests to the URL of your choice.”
- [github] “This repository contains the OpenAPI specification for the MX Platform API”
- [claimed-docs] “You can download our OpenAPI Specification and import it into Postman to learn more about our API”
Docs confirm transaction/account/balance retrieval via the Data API with consent (yapily-docs-2, yapily-docs-15) and webhooks for real-time change notifications (yapily-docs-13), which could support a sync pattern, but there is no documented pagination mechanism, no stated history depth/lookback window, and no explicit delta/incremental-fetch API for transactions. missing for 10: pagination details, documented transaction history depth, explicit changed-only/delta sync endpoint or pattern beyond generic webhooks.
- [claimed-docs] “Retrieve accounts, balances, and transactions with user consent.”
- [claimed-docs] “Using Yapily's Data API you can access your customers' financial data including account balances, transaction history and account details to…”
- [claimed-docs] “Webhooks allows you to receive real-time HTTP notifications of changes happening in the Yapily Platform.”
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 …”
Yapilyn/aYapily is an open-banking API/platform, not an agentic runtime that consumes external tools; the evidence only shows Yapily exposing an MCP server so AI coding agents can query its docs, not Yapily itself acting as an MCP client that plugs in and uses other servers' tools. This client-side 'use MCP tools' axis is a category mismatch for a banking API product.
- [claimed-docs] “Connect Claude, Cursor, or another AI coding agent directly to these docs via MCP, llms.txt, or Agent Skills.”
- [probe] “official MCP server documented at https://docs.yapily.com/resources/ai-agents”
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.
Yapilyn/aYapily is an open banking API/infrastructure platform, not an AI assistant product; the evidence shows it supports AI agents connecting to its docs (MCP/llms.txt) as an API consumer, but it does not embed a built-in AI assistant for users to delegate tasks to within the product itself.
ai-native userVersion, review, and roll back my automations
weight 1 · not comparableMXn/aMX is a financial data connectivity/aggregation API platform, not an automation-builder tool; there is no concept of 'automations' with version/review/rollback in its product surface, so this axis is a category error rather than an unmet capability.
ai-native userSelf-host the core product
weight 3 · not comparableMXn/aMX is a cloud-hosted financial data connectivity API/SaaS platform with no evidence of any self-hostable core product; self-hosting is a category error for this kind of managed financial-data service.
ai-native userPrevent my data from being used to train AI models
weight 3 · not comparableMXnone0/10No evidence in the pack addresses AI training data usage, opt-out controls, or any privacy policy statement about model training; the pack is entirely about financial data connectivity, aggregation, and webhooks.