Mastercard Open Finance (Finicity) vs Yapily

Hosted flows

1. developerLet a user connect their bank with a drop-in hosted flow — create a session server-side, open the widget, and get back a token for the connected account — without building institution UI myself

   weight 3 · round to Yapily
   Mastercard Open Finance (Finicity)~partialclaimed3/10

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

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

   proof ↗⚑ flag

   Yapily✓fullclaimed7/10

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

   proof ↗⚑ flag

Oauth

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

   weight 2 · round to Yapily
   Mastercard Open Finance (Finicity)—none0/10

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

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

   proof ↗⚑ flag

   Yapily~partialclaimed4/10

   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”

   proof ↗⚑ flag

Repair

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

   weight 2 · round drawn
   Mastercard Open Finance (Finicity)—none0/10

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

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

   proof ↗⚑ flag

   Yapily—none0/10

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

   ⚑ flag

Agent access

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

   weight 2 · round to Yapily
   Mastercard Open Finance (Finicity)✓fullprobed8/10

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

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

   proof ↗⚑ flag

   Yapily✓fullprobed9/10

   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”

   proof ↗⚑ flag

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

   weight 2 · round to Mastercard Open Finance (Finicity)
   Mastercard Open Finance (Finicity)~partialclaimed6/10

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

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

   proof ↗⚑ flag

   Yapily~partialclaimed5/10

   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”

   proof ↗⚑ flag

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

   weight 3 · round to Mastercard Open Finance (Finicity)
   Mastercard Open Finance (Finicity)✓fullprobed7/10

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

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

   proof ↗⚑ flag

   Yapily~partialprobed6/10

   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”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Mastercard Open Finance (Finicity)—none0/10

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

   ⚑ flag

   Yapily—none0/10

   Yapily provides SDK/client library generation (yapily-docs-8) and AI-agent connectivity via MCP/llms.txt (yapily-docs-6), but there is no evidence of an official CLI tool for interacting with the Yapily platform or APIs.

   ⚑ flag

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

   weight 3 · round drawn
   Mastercard Open Finance (Finicity)✓fullprobed8/10

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

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

   proof ↗⚑ flag

   Yapily✓fullprobed8/10

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Mastercard Open Finance (Finicity)—none0/10

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

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

   proof ↗⚑ flag

   Yapily—none0/10

   No evidence in the pack describes issuing scoped or least-privilege API credentials/keys for agent use; documentation covers payments, data access, consent flows, and AI-agent documentation connectivity (MCP/llms.txt) but not credential scoping mechanisms.

   ⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Yapily
   Mastercard Open Finance (Finicity)~partialclaimed3/10

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

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

   proof ↗⚑ flag

   Yapily~partialprobed5/10

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

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Yapily
   Mastercard Open Finance (Finicity)✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   Yapily✓fullclaimed8/10

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

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round drawn
   Mastercard Open Finance (Finicity)—none0/10

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

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

   proof ↗⚑ flag

   Yapily—none0/10

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

   proof ↗⚑ flag

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

   weight 2 · round to Yapily
   Mastercard Open Finance (Finicity)—none0/10

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

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

   proof ↗⚑ flag

   Yapily~partialclaimed4/10

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

   proof ↗⚑ flag

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

   weight 2 · round to Mastercard Open Finance (Finicity)
   Mastercard Open Finance (Finicity)~partialprobed5/10

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

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

   proof ↗⚑ flag

   Yapily—none0/10

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

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   Mastercard Open Finance (Finicity)—none0/10

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

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

   proof ↗⚑ flag

   Yapily—none0/10

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

   proof ↗⚑ flag

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

   weight 2 · round to Mastercard Open Finance (Finicity)
   Mastercard Open Finance (Finicity)✓fullprobed8/10

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

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

   proof ↗⚑ flag

   Yapily!disputedcontradicted4/10

   Docs 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/…”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   Mastercard Open Finance (Finicity)✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   Yapily✓fullclaimed8/10

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Mastercard Open Finance (Finicity)—none0/10

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

   ⚑ flag

   Yapily—none0/10

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

   ⚑ flag

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

   weight 2 · round to Yapily
   Mastercard Open Finance (Finicity)—none0/10

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

   ⚑ flag

   Yapily~partialclaimed4/10

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

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Mastercard Open Finance (Finicity)—none0/10

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

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

   proof ↗⚑ flag

   Yapily—none0/10

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

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Yapily
   Mastercard Open Finance (Finicity)—none0/10

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

   ⚑ flag

   Yapily~partialclaimed5/10

   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”

   proof ↗⚑ flag

Ach details

1. developerObtain verified account and routing numbers (or tokenized equivalents) from a linked account to fund ACH or bank-debit payments without micro-deposits

   weight 3 · round to Mastercard Open Finance (Finicity)
   Mastercard Open Finance (Finicity)~partialclaimed6/10

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

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

   proof ↗⚑ flag

   Yapily—none0/10

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

   ⚑ flag

Balances

1. developerFetch a real-time balance for a connected account before initiating a payment — a documented balance endpoint intended for NSF and risk checks

   weight 3 · round drawn
   Mastercard Open Finance (Finicity)✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   Yapily✓fullclaimed7/10

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

   proof ↗⚑ flag

Ownership

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

   weight 2 · round to Mastercard Open Finance (Finicity)
   Mastercard Open Finance (Finicity)✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   Yapily✓fullclaimed7/10

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

   proof ↗⚑ flag

Processor tokens

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

   weight 2 · round to Mastercard Open Finance (Finicity)
   Mastercard Open Finance (Finicity)~partialclaimed5/10

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

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

   proof ↗⚑ flag

   Yapily—none0/10

   Yapily's docs describe account verification and payment initiation via its own Payments/Data APIs, but there is no evidence of documented integrations or token-exchange mechanisms that hand verified account credentials to third-party payment processors or platforms.

   ⚑ flag

Agent data

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

   weight 2 · round to Mastercard Open Finance (Finicity)
   Mastercard Open Finance (Finicity)~partialprobed6/10

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

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

   proof ↗⚑ flag

   Yapily~partialprobed5/10

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

   proof ↗⚑ flag

Agent operations

1. ai-native userAn agent can operate the platform — create link sessions, retrieve balances and transactions, and manage connections through the API or an MCP surface with scoped credentials

   weight 3 · round to Mastercard Open Finance (Finicity)
   Mastercard Open Finance (Finicity)~partialprobed6/10

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

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

   proof ↗⚑ flag

   Yapily~partialprobed4/10

   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”

   proof ↗⚑ flag

Consent

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

   weight 2 · round drawn
   Mastercard Open Finance (Finicity)—none0/10

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

   ⚑ flag

   Yapily—none0/10

   Evidence shows Yapily Connect provides consent screens for initiating AIS/PIS authorization (docs-7, docs-20) but nothing about a portal or surface where end users can view all apps/connections and actively revoke previously granted consent to their bank data.

   ⚑ flag

Deletion

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

   weight 2 · round drawn
   Mastercard Open Finance (Finicity)—none0/10

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

   ⚑ flag

   Yapily—none0/10

   No evidence describes a documented deletion/revocation flow for connections or users, nor confirmation that data collection stops and held data is purged; docs only mention consent collection, sandbox, webhooks, and data retrieval, not consent revocation or data deletion/purge.

   ⚑ flag

Scopes

1. developerI request only the data scopes I need — product-scoped consents and documented data-minimization controls, not an all-or-nothing grant

   weight 2 · round to Yapily
   Mastercard Open Finance (Finicity)~partialclaimed4/10

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

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

   proof ↗⚑ flag

   Yapily~partialclaimed5/10

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

   proof ↗⚑ flag

Refresh

1. developerTrigger an on-demand refresh of a connected account's data through the API when my use case needs now-fresh data, with the refresh semantics documented

   weight 2 · round drawn
   Mastercard Open Finance (Finicity)—none0/10

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

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

   proof ↗⚑ flag

   Yapily—none0/10

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

   proof ↗⚑ flag

Webhooks

1. developerData changes arrive as signed webhooks — new transactions, balance updates, connection state changes — so my system stays current without polling

   weight 2 · round drawn
   Mastercard Open Finance (Finicity)~partialclaimed6/10

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

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

   proof ↗⚑ flag

   Yapily~partialclaimed6/10

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

   proof ↗⚑ flag

Coverage

1. founderThe platform documents how many institutions it reaches and where — published coverage numbers and geographies I can check against where my users actually bank

   weight 3 · round drawn
   Mastercard Open Finance (Finicity)—none0/10

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

   ⚑ flag

   Yapily—none0/10

   The evidence pack contains no published institution counts, geographic coverage lists, or bank-name directories that a founder could check against their users' banks—only product/API feature descriptions.

   ⚑ flag

Status

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

   weight 2 · round drawn
   Mastercard Open Finance (Finicity)—none0/10

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

   ⚑ flag

   Yapily—none0/10

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

   proof ↗⚑ flag

Multi product

1. developerOne link session can power multiple data products — auth, balances, transactions, identity — without forcing the user through separate connection flows per product

   weight 2 · round to Yapily
   Mastercard Open Finance (Finicity)—none0/10

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

   ⚑ flag

   Yapily~partialclaimed6/10

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

   proof ↗⚑ flag

Quickstart

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

   weight 2 · round to Mastercard Open Finance (Finicity)
   Mastercard Open Finance (Finicity)~partialclaimed5/10

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

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

   proof ↗⚑ flag

   Yapily~partialprobed4/10

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

   proof ↗⚑ flag

Sandbox

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

   weight 3 · round drawn
   Mastercard Open Finance (Finicity)~partialclaimed6/10

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

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

   proof ↗⚑ flag

   Yapily~partialclaimed6/10

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Mastercard Open Finance (Finicity)~partialclaimed6/10

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

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

   proof ↗⚑ flag

   Yapily~partialprobed6/10

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

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Mastercard Open Finance (Finicity)—none0/10

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

   ⚑ flag

   Yapily—none0/10

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

   ⚑ flag

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

   weight 2 · round drawn
   Mastercard Open Finance (Finicity)—none0/10

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

   ⚑ flag

   Yapily—none0/10

   Yapily is a closed commercial open banking API/SaaS platform; there is no evidence of any open-source license or public source repository for its core product. Documentation and OpenAPI probes exist but source code openness is not evidenced anywhere in the pack.

   ⚑ flag

Pay by bank

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

   weight 2 · round to Yapily
   Mastercard Open Finance (Finicity)—none0/10

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

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

   proof ↗⚑ flag

   Yapily~partialclaimed6/10

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

   proof ↗⚑ flag

Recurring

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

   weight 2 · round to Yapily
   Mastercard Open Finance (Finicity)—none0/10

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

   ⚑ flag

   Yapily✓fullclaimed8/10

   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”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Mastercard Open Finance (Finicity)—none0/10

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

   ⚑ flag

   Yapily—none0/10

   No evidence in the pack addresses data residency, regional storage choice, or hosting location options for customer data; all docs focus on payments, data access APIs, and AI-agent connectivity.

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Mastercard Open Finance (Finicity)—none0/10

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

   ⚑ flag

   Yapily—none0/10

   No evidence in the pack addresses data retention policies, deletion controls, or user-initiated data removal options for Yapily; the documentation covers data access, payments, and AI-agent integration but nothing about retention/deletion controls.

   ⚑ flag

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

   weight 2 · round drawn
   Mastercard Open Finance (Finicity)—none0/10

   No evidence pack items mention telemetry, usage tracking, analytics collection, or any opt-out mechanism for AI-native or any users; this is an applicable axis for a developer platform but simply unevidenced.

   ⚑ flag

   Yapily—none0/10

   No evidence in the pack addresses telemetry opt-out or usage tracking controls for Yapily's products or docs; this is a fair question for an API/SaaS platform but is unaddressed.

   ⚑ flag

Cashflow

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

   weight 2 · round to Mastercard Open Finance (Finicity)
   Mastercard Open Finance (Finicity)~partialclaimed6/10

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

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

   proof ↗⚑ flag

   Yapily—none0/10

   Yapily's docs show transaction categorisation, merchant detection, and spending insights (yapily-docs-3), but there is no evidence of recurring income/payroll detection, cash-flow signal derivation, or income verification products built on the data.

   ⚑ flag

Enrichment

1. developerRaw bank transactions come back enriched — cleaned merchant names, categories, and logos — documented as a capability of the platform, not left as an exercise for me

   weight 2 · round to Yapily
   Mastercard Open Finance (Finicity)~partialclaimed4/10

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

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

   proof ↗⚑ flag

   Yapily~partialclaimed6/10

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

   proof ↗⚑ flag

Transactions

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

   weight 3 · round to Mastercard Open Finance (Finicity)
   Mastercard Open Finance (Finicity)~partialclaimed5/10

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

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

   proof ↗⚑ flag

   Yapily~partialclaimed4/10

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

   proof ↗⚑ flag