BVNK vs MoonPay

Agent access

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

   weight 2 · round to MoonPay
   BVNK✓fullprobed8/10

   BVNK hosts a live llms.txt file at docs.bvnk.com/llms.txt confirmed via HTTP 200 probe, containing structured summaries of its API documentation, and individual doc pages are also machine-readable markdown (.md) endpoints. Missing for 10: no independent third-party confirmation of agent usage/adoption of this llms.txt beyond the probe check.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.bvnk.com/llms.txt # BVNK API Documentation > Complete API documentation for BVNK payment infrastru…”
   • [claimed-docs] “BVNK uses **Hawk authentication** for secure API access.”
   • [claimed-docs] “As a partner, you can add a markup fee to your customers' transactions, enabling you to collect additional revenue from your customers.”

   proof ↗⚑ flag

   MoonPay✓fullprobed9/10

   MoonPay has a confirmed llms.txt (probe returned HTTP 200 with descriptive content) and dedicated docs on using AI agents, including an official MCP server for searching/retrieving docs. missing for 10: independent third-party confirmation of agent usage beyond MoonPay's own docs/probes.

   • [probe] “PROBE llms.txt: HTTP 200 at https://dev.moonpay.com/llms.txt # MoonPay Developer Docs > Integrate MoonPay's on-ramp, off-ramp, and swap pro…”
   • [claimed-docs] “Let new customers buy crypto with Apple Pay or Google Pay without a MoonPay account.”
   • [claimed-docs] “The documentation includes a Model Context Protocol (MCP) server that gives AI agents direct access to search and retrieve content.”
   • [probe] “official MCP server documented at https://dev.moonpay.com/platform/overview/using-agents”

   proof ↗⚑ flag

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

   weight 2 · round to BVNK
   BVNK~partialprobed6/10

   BVNK exposes a full REST API with Hawk authentication, webhooks for automated notifications, and a sandbox environment for simulating pay-ins/payouts—all of which support headless, non-interactive automation. There's also a mentioned agent-wallet-cli tool suggesting scriptable/CLI usage. However, there's no explicit documentation of CI pipeline integration, headless auth flows for automated agents, or CI-specific guidance. Missing for 10: explicit CI/automation guide, confirmation the CLI supports non-interactive auth/config for pipelines, and independent evidence of real-world CI usage.

   • [claimed-docs] “BVNK uses **Hawk authentication** for secure API access.”
   • [claimed-docs] “Webhooks provide real-time, automated notifications for changes in your BVNK account.”
   • [claimed-docs] “The sandbox environment provides a consistent simulation experience for pay-ins and payouts across all customer accounts.”
   • [probe] “official CLI documented at https://github.com/bvnk/agent-wallet-cli”

   proof ↗⚑ flag

   MoonPay~partialclaimed4/10

   MoonPay offers headless APIs/SDKs (build-your-own on-ramp, quote and session endpoints) and a dedicated test mode with testnets/simulated payments that could be scripted in a CI pipeline, but there is no evidence of a CLI, automation-first tooling, or documentation describing running MoonPay flows unattended in CI. Missing for 10: explicit CI/automation guidance, evidence of non-interactive KYC/payment flows, and independent confirmation of headless test-mode usage in pipelines.

   • [claimed-docs] “Build your own on-ramp and off-ramp on MoonPay's APIs and SDKs. Your UI, your flow, our rails.”
   • [claimed-docs] “MoonPay provides a test mode for integration development and testing. Test mode uses testnet blockchains and simulated payments. No real ass…”
   • [claimed-docs] “Builds a quote for a fiat-to-crypto buy. Returns locked rate, fees, and signature for payment execution.”
   • [claimed-docs] “Create a session token to initialize a connection”

   proof ↗⚑ flag

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

   weight 3 · round to MoonPay
   BVNK—none0/10

   BVNK is a payments infrastructure product, and while an MCP server is a plausible axis for such an API platform, no evidence shows an official MCP server; only Hawk auth, webhooks, and REST APIs are documented, plus an unrelated CLI mention.

   • [claimed-docs] “BVNK uses **Hawk authentication** for secure API access.”
   • [claimed-docs] “Webhooks provide real-time, automated notifications for changes in your BVNK account.”
   • [probe] “official CLI documented at https://github.com/bvnk/agent-wallet-cli”

   proof ↗⚑ flag

   MoonPay✓fullprobed7/10

   MoonPay documents an official MCP server for its developer docs that gives AI agents direct access to search and retrieve content, corroborated by a probe confirming the page exists. Missing for 10: independent hands-on verification of the MCP server actually working with an agent, and details on scope/capabilities beyond docs search/retrieval.

   • [claimed-docs] “The documentation includes a Model Context Protocol (MCP) server that gives AI agents direct access to search and retrieve content.”
   • [probe] “official MCP server documented at https://dev.moonpay.com/platform/overview/using-agents”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to BVNK
   BVNK~partialprobed3/10

   A single probe result points to an 'agent-wallet-cli' GitHub repo described as an official CLI, but there is no documentation content, usage examples, or independent corroboration of its functionality. missing for 10: detailed CLI docs, command reference, install/usage examples, independent confirmation of adoption.

   • [probe] “official CLI documented at https://github.com/bvnk/agent-wallet-cli”

   proof ↗⚑ flag

   MoonPay—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

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

   weight 3 · round to BVNK
   BVNK✓fullprobed8/10

   BVNK publishes a documented public API (Hawk auth, webhooks, wallets, transfers, payment rules) with a dedicated docs site and llms.txt endpoint confirming API-driven access, plus a sandbox for testing. missing for 10: independent third-party corroboration of API robustness/versioning and explicit rate-limit/SLA documentation.

   • [claimed-docs] “BVNK uses **Hawk authentication** for secure API access.”
   • [claimed-docs] “On BVNK, you can create and manage both crypto and fiat wallets through the Portal or API.”
   • [claimed-docs] “To create a rule that links a fiat virtual account to a crypto blockchain address, send the `POST /payment/v1/rules` request”
   • [claimed-docs] “The Transfers v.3 API replaces the legacy Quote API for wallet-to-wallet currency conversion.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.bvnk.com/llms.txt # BVNK API Documentation > Complete API documentation for BVNK payment infrastru…”

   proof ↗⚑ flag

   MoonPay~partialprobed7/10

   MoonPay publishes detailed API reference docs (quotes, sessions, webhooks, test mode) letting developers programmatically drive on/off-ramp flows, and even documents an MCP server for AI agents to browse docs. However, a probe for standard machine-readable API specs (OpenAPI/Swagger) returned 404s across all candidate paths, suggesting no formal machine-consumable spec exists, which limits fully autonomous/agentic API discovery. missing for 10: a discoverable OpenAPI/Swagger spec, independent/hands-on confirmation that an AI agent can successfully call the API end-to-end.

   • [claimed-docs] “Builds a quote for a fiat-to-crypto buy. Returns locked rate, fees, and signature for payment execution.”
   • [claimed-docs] “Create a session token to initialize a connection”
   • [claimed-docs] “MoonPay can send webhook events that notify your application whenever an activity occurs on your account.”
   • [claimed-docs] “MoonPay provides a test mode for integration development and testing. Test mode uses testnet blockchains and simulated payments. No real ass…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://dev.moonpay.com/openapi.json, https://dev.moonpay.com/swagger.json, https://dev.moonpay.com/…”
   • [probe] “official MCP server documented at https://dev.moonpay.com/platform/overview/using-agents”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   BVNK—none0/10

   BVNK's docs only mention Hawk-based API authentication (bvnk-docs-1) and webhooks, with no mention of scoped, least-privilege, or role-restricted API credentials or agent-specific key issuance. No evidence describes creating limited-permission API keys or tokens for AI agents.

   • [claimed-docs] “BVNK uses **Hawk authentication** for secure API access.”

   proof ↗⚑ flag

   MoonPay—none0/10

   Evidence shows API keys and session tokens for general integration (moonpay-docs-15) and a documentation MCP server for search/retrieval (moonpay-docs-6), but nothing about issuing scoped or least-privilege credentials specifically for AI agents acting on a user's behalf. No permissions model, credential scoping, or agent-specific access controls are documented.

   • [claimed-docs] “Create a session token to initialize a connection”
   • [claimed-docs] “The documentation includes a Model Context Protocol (MCP) server that gives AI agents direct access to search and retrieve content.”
   • [probe] “official MCP server documented at https://dev.moonpay.com/platform/overview/using-agents”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to MoonPay
   BVNK—none0/10

   Evidence shows extensive REST API documentation (auth, webhooks, sandbox, wallets, etc.) and one official CLI tool (agent-wallet-cli), but no evidence of official client SDKs (e.g., Python, JS, Java libraries) that developers could build against. The axis is fair for an API-driven fintech platform, but no SDK evidence is present, so this is 'none' rather than 'na'.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.bvnk.com/llms.txt # BVNK API Documentation > Complete API documentation for BVNK payment infrastru…”
   • [probe] “official CLI documented at https://github.com/bvnk/agent-wallet-cli”
   • [claimed-docs] “BVNK uses **Hawk authentication** for secure API access.”

   proof ↗⚑ flag

   MoonPay~partialprobed5/10

   MoonPay's docs explicitly mention building on 'APIs and SDKs' (moonpay-docs-3) and provide a demo integrations repo (moonpay-docs-7) and API reference endpoints (moonpay-docs-14, moonpay-docs-15), indicating some SDK/dev-tooling support. However, there's no direct evidence of language-specific SDK packages, an OpenAPI spec (probe shows 404s for standard OpenAPI paths, moonpay-probe-2), or independent developer corroboration of SDK quality/coverage. Missing for 10: concrete SDK package listings (npm, PyPI, etc.), OpenAPI/spec-driven tooling, and independent hands-on confirmation of SDK usability.

   • [claimed-docs] “Build your own on-ramp and off-ramp on MoonPay's APIs and SDKs. Your UI, your flow, our rails.”
   • [claimed-docs] “The MoonPay Demo Integrations GitHub repository has working, clone-able example integrations ready to use - just add your API keys.”
   • [claimed-docs] “Builds a quote for a fiat-to-crypto buy. Returns locked rate, fees, and signature for payment execution.”
   • [claimed-docs] “Create a session token to initialize a connection”
   • [probe] “PROBE openapi: all candidate paths 404 (https://dev.moonpay.com/openapi.json, https://dev.moonpay.com/swagger.json, https://dev.moonpay.com/…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   BVNK✓fullclaimed7/10

   BVNK documents webhook subscriptions for real-time account event notifications, with a dedicated setup guide for creating a webhook listener. Missing for 10: no details on event type filtering/selection, payload signing/verification specifics, or independent hands-on corroboration of webhook reliability.

   • [claimed-docs] “Webhooks provide real-time, automated notifications for changes in your BVNK account.”

   proof ↗⚑ flag

   MoonPay✓fullclaimed7/10

   MoonPay documents webhook events that notify applications of account activity, with specific examples like sell_transaction_requote_required, giving developers a concrete subscription mechanism for events. This directly satisfies the story's core need for event-driven notifications. Missing for 10: a full list/catalog of all webhook event types, subscription management API/UI documentation, and independent third-party confirmation of webhook reliability.

   • [claimed-docs] “MoonPay can send webhook events that notify your application whenever an activity occurs on your account.”
   • [claimed-docs] “Handle the sell_transaction_requote_required webhook to surface in-app requote notifications when a sell price changes.”

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round to BVNK
   BVNK~partialclaimed6/10

   BVNK exposes a rules-based automation API (e.g., POST /payment/v1/rules to auto-link fiat virtual accounts to crypto addresses) and webhooks for real-time automated notifications, plus automatic on-ramp/settlement flows, which together enable background, event-driven automations without manual triggering. However this is payment-domain automation (rules, webhooks) rather than a general agentic/background-task framework, and there's no documentation of scheduling, monitoring dashboards, or broader autonomous workflow orchestration beyond these payment rules. missing for 10: general-purpose scheduling/orchestration beyond payment rules, evidence of monitoring/alerting for autonomous runs, and independent confirmation of reliability of these automations running unattended.

   • [claimed-docs] “Webhooks provide real-time, automated notifications for changes in your BVNK account.”
   • [claimed-docs] “To create a rule that links a fiat virtual account to a crypto blockchain address, send the `POST /payment/v1/rules` request”
   • [claimed-docs] “Automatically on-ramp to crypto and send to blockchain addresses.”

   proof ↗⚑ flag

   MoonPay—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

2. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round drawn
   BVNK—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

   MoonPay—none0/10

   MoonPay's evidence only describes an MCP server that lets external AI agents search/retrieve documentation content (moonpay-docs-6, moonpay-probe-3) — this is a developer-docs tool, not a built-in AI assistant inside the product that end-users can delegate purchase/sell/swap tasks to. No evidence of any in-product assistant, chat interface, or agentic task delegation for users.

   • [claimed-docs] “The documentation includes a Model Context Protocol (MCP) server that gives AI agents direct access to search and retrieve content.”
   • [probe] “official MCP server documented at https://dev.moonpay.com/platform/overview/using-agents”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   BVNK—none0/10

   No evidence BVNK offers a natural-language command interface; its API/CLI (bvnk-probe-2) and docs describe structured REST endpoints and a traditional CLI, not NL-driven interaction. Missing for 10: any chat/NL command interface, agent SDK, or documented natural-language operation mode.

   • [probe] “official CLI documented at https://github.com/bvnk/agent-wallet-cli”
   • [claimed-docs] “BVNK uses **Hawk authentication** for secure API access.”

   proof ↗⚑ flag

   MoonPay—none0/10

   MoonPay's evidence only shows an MCP server for searching/retrieving documentation content, not for operating the actual on-ramp/off-ramp transactions via natural language; there is no evidence of a chat/agent interface that lets a user issue commands like 'buy $50 of ETH' through natural language.

   • [claimed-docs] “The documentation includes a Model Context Protocol (MCP) server that gives AI agents direct access to search and retrieve content.”
   • [probe] “official MCP server documented at https://dev.moonpay.com/platform/overview/using-agents”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round to MoonPay
   BVNK—none0/10

   BVNK's docs describe endpoints and a sandbox simulation environment, but there is no evidence of an interactive API reference (e.g., a Swagger/OpenAPI explorer or 'try it' console) with runnable code examples embedded in the docs.

   • [claimed-docs] “The sandbox environment provides a consistent simulation experience for pay-ins and payouts across all customer accounts.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.bvnk.com/llms.txt # BVNK API Documentation > Complete API documentation for BVNK payment infrastru…”

   proof ↗⚑ flag

   MoonPay~partialprobed4/10

   MoonPay's dev docs include structured API reference pages (e.g., quotes/get, sessions/create) and a separate GitHub repo of clone-able demo integrations, but there's no evidence of an interactive, in-browser 'try it now' console — a probe for standard OpenAPI/swagger endpoints returned 404s, suggesting no exposed spec powering live runnable examples. Missing for 10: in-docs interactive request builder/console, publicly exposed OpenAPI spec, and confirmation that example code snippets are directly executable from the reference pages.

   • [claimed-docs] “Builds a quote for a fiat-to-crypto buy. Returns locked rate, fees, and signature for payment execution.”
   • [claimed-docs] “Create a session token to initialize a connection”
   • [claimed-docs] “The MoonPay Demo Integrations GitHub repository has working, clone-able example integrations ready to use - just add your API keys.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://dev.moonpay.com/openapi.json, https://dev.moonpay.com/swagger.json, https://dev.moonpay.com/…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   BVNK—none0/10

   The evidence pack shows extensive API documentation (docs.bvnk.com, llms.txt) and endpoint references, but nowhere is an OpenAPI/Swagger spec or other machine-readable spec file mentioned or linked for download. missing for 10: explicit OpenAPI/Swagger JSON or YAML file, a documented spec download link, any mention of spec format.

   ⚑ flag

   MoonPay—none0/10

   No evidence of a downloadable OpenAPI/Swagger spec; a direct probe of common OpenAPI paths (openapi.json, swagger.json, etc.) returned 404 across the board, and docs only mention API reference pages and an MCP server for agent content retrieval, not a machine-readable spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://dev.moonpay.com/openapi.json, https://dev.moonpay.com/swagger.json, https://dev.moonpay.com/…”
   • [claimed-docs] “Builds a quote for a fiat-to-crypto buy. Returns locked rate, fees, and signature for payment execution.”
   • [claimed-docs] “Create a session token to initialize a connection”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   BVNK✓fullclaimed7/10

   BVNK explicitly documents a sandbox environment that simulates pay-ins and payouts consistently across accounts, letting developers test without touching production data. Missing for 10: no explicit statement of how sandbox data/credentials are isolated from production, no independent/hands-on confirmation, and no detail on how to switch environments via API.

   • [claimed-docs] “The sandbox environment provides a consistent simulation experience for pay-ins and payouts across all customer accounts.”

   proof ↗⚑ flag

   MoonPay✓fullclaimed7/10

   MoonPay explicitly documents a test mode using testnet blockchains and simulated payments so no real assets are transferred, directly matching the sandbox story, and this is reinforced by clone-able demo integrations for testing before production use. Missing for 10: independent/hands-on confirmation that the sandbox fully mirrors production behavior and more detail on how test-mode credentials/environments are provisioned.

   • [claimed-docs] “MoonPay provides a test mode for integration development and testing. Test mode uses testnet blockchains and simulated payments. No real ass…”
   • [claimed-docs] “The MoonPay Demo Integrations GitHub repository has working, clone-able example integrations ready to use - just add your API keys.”
   • [claimed-docs] “Create a session token to initialize a connection”

   proof ↗⚑ flag

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

   weight 2 · round to BVNK
   BVNK~partialclaimed3/10

   There is evidence of API versioning practice (Transfers v.3 replacing the legacy Quote API), showing BVNK does version and migrate APIs, but no documented deprecation policy, sunset timeline, or versioning scheme is provided. missing for 10: explicit deprecation policy documentation, versioning scheme details, sunset/EOL timelines, migration guarantees beyond one example.

   • [claimed-docs] “The Transfers v.3 API replaces the legacy Quote API for wallet-to-wallet currency conversion.”

   proof ↗⚑ flag

   MoonPay—none0/10

   No evidence of API versioning scheme or a documented deprecation policy anywhere in the docs; openapi spec probe 404s, and no changelog/versioning page is cited. missing for 10: versioning scheme documentation, deprecation policy/timeline, changelog or migration guides.

   • [probe] “PROBE openapi: all candidate paths 404 (https://dev.moonpay.com/openapi.json, https://dev.moonpay.com/swagger.json, https://dev.moonpay.com/…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   BVNK—none0/10

   No evidence of bulk/batch endpoints (e.g., batch payouts, bulk wallet creation, or bulk transfer APIs); documentation covers single-item operations (single wallet, single rule, single transfer) with no mention of batch processing or multi-item requests. missing for 10: bulk/batch API endpoints, batch job status tracking, documentation of multi-item request payloads.

   • [claimed-docs] “To create a rule that links a fiat virtual account to a crypto blockchain address, send the `POST /payment/v1/rules` request”
   • [claimed-docs] “The Transfers v.3 API replaces the legacy Quote API for wallet-to-wallet currency conversion.”
   • [claimed-docs] “Create virtual accounts in USD, EUR, GBP for your business or customers.”
   • [claimed-docs] “Send stablecoins or cryptocurrencies from your BVNK account.”

   proof ↗⚑ flag

   MoonPay—none0/10

   No evidence of bulk/batch operations across many items (e.g., batch quotes, bulk transaction processing) in MoonPay's API or docs; endpoints shown are single-item (single quote, single session).

   ⚑ flag

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

   weight 3 · round to BVNK
   BVNK~partialclaimed6/10

   BVNK exposes a documented Rules API (POST /payment/v1/rules) that automatically links a fiat virtual account to a crypto address, and webhooks provide real-time event notifications that could trigger downstream automation. This shows genuine rule/event-driven automation, but only for a narrow, specific use case rather than a general-purpose rules engine covering arbitrary triggers/actions. Missing for 10: evidence of broader rule types (e.g., conditional logic across multiple event types), a general rules/automation dashboard, and third-party corroboration of rule reliability at scale.

   • [claimed-docs] “To create a rule that links a fiat virtual account to a crypto blockchain address, send the `POST /payment/v1/rules` request”
   • [claimed-docs] “Webhooks provide real-time, automated notifications for changes in your BVNK account.”

   proof ↗⚑ flag

   MoonPay~partialclaimed4/10

   MoonPay exposes webhook events (e.g., transaction status, requote-required) that notify an application when activity occurs, which developers can use to build their own automated actions, but there is no evidence of a built-in rules/automation engine where users define conditional triggers within MoonPay itself. missing for 10: a native rule-builder or automation configuration UI/API, evidence of conditional logic or multi-step workflows tied to events, independent confirmation of automation use in production.

   • [claimed-docs] “MoonPay can send webhook events that notify your application whenever an activity occurs on your account.”
   • [claimed-docs] “Handle the sell_transaction_requote_required webhook to surface in-app requote notifications when a sell price changes.”

   proof ↗⚑ flag

Kyc

1. ops leadCustomer and recipient onboarding is programmatic — documented KYC/KYB endpoints or flows that clear a counterparty for sending and receiving before money moves

   weight 2 · round to MoonPay
   BVNK—none0/10

   Evidence pack covers wallets, payments, webhooks, embedded wallets, and API auth, but no documented KYC/KYB endpoints or onboarding/counterparty-clearance flows are mentioned anywhere in the docs list.

   ⚑ flag

   MoonPay~partialprobed5/10

   MoonPay's docs describe KYC as a built-in, hosted part of its on-/off-ramp widget and API flow (session creation, quotes, webhooks) and note that returning users can skip re-onboarding, but there is no documented standalone KYC/KYB endpoint or explicit 'counterparty cleared' status API that an ops team could call programmatically before initiating a transfer — KYC is embedded in the transaction flow rather than exposed as an independent compliance-check service. missing for 10: explicit KYC/KYB API/endpoint documentation, a way to query verification/clearance status independent of a transaction, and any B2B/KYB (business) onboarding flow.

   • [claimed-docs] “MoonPay lets you add fiat-to-crypto to your product without rebuilding payments, KYC, and compliance.”
   • [claimed-docs] “A hosted on-ramp and off-ramp you embed in your app. MoonPay runs the KYC, payments, and UI.”
   • [claimed-docs] “Connect existing MoonPay usersSkip re-onboarding. Plug into the existing MoonPay account base.”
   • [claimed-docs] “Create a session token to initialize a connection”
   • [claimed-docs] “Millions of users have previously purchased cryptocurrencies using MoonPay, having stored their payment and KYC details, leading to maximize…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://dev.moonpay.com/openapi.json, https://dev.moonpay.com/swagger.json, https://dev.moonpay.com/…”

   proof ↗⚑ flag

Licensing

1. founderSee who I'm actually contracting with — the licensed or registered entities behind the product and the jurisdictions they cover, published rather than buried

   weight 2 · round drawn
   BVNK—none0/10

   The evidence pack contains only API/product documentation (webhooks, wallets, transfers, sandbox) and no published disclosure of the specific licensed or registered legal entities behind BVNK or the jurisdictions each covers. No regulatory/licensing page, entity list, or legal disclosures are cited anywhere in the evidence.

   ⚑ flag

   MoonPay—none0/10

   No evidence pack item names MoonPay's licensed/registered legal entities, regulatory licenses, or jurisdictional coverage; documentation is entirely product/API focused, and community items concern fee transparency and an unrelated scam-fund allegation, not entity/licensing disclosure.

   ⚑ flag

Screening

1. ops leadThe platform documents its sanctions screening, wallet risk checks, and travel-rule handling — compliance machinery named specifically, not waved at

   weight 2 · round drawn
   BVNK—none0/10

   None of the evidence names sanctions screening, wallet risk scoring/checks, or travel-rule handling—docs cover authentication, wallets, webhooks, transfers, and embedded partner features only. Absence of any specific compliance-machinery documentation means this axis is unmet.

   ⚑ flag

   MoonPay—none0/10

   MoonPay's docs mention generic 'KYC and compliance' and 'payments' but never name specific machinery like sanctions screening, wallet risk scoring, or travel-rule data sharing — the exact named-not-waved-at requirement of this story. Missing for 10: any documentation naming sanctions/OFAC screening process, wallet address risk-scoring methodology, or travel-rule protocol implementation (e.g., Notabene/Sygna/TRISA integration).

   • [claimed-docs] “MoonPay lets you add fiat-to-crypto to your product without rebuilding payments, KYC, and compliance.”
   • [claimed-docs] “A hosted on-ramp and off-ramp you embed in your app. MoonPay runs the KYC, payments, and UI.”
   • [claimed-docs] “Millions of users have previously purchased cryptocurrencies using MoonPay, having stored their payment and KYC details, leading to maximize…”

   proof ↗⚑ flag

Abstraction

1. developerI never operate blockchain infrastructure — the platform abstracts nodes, gas, and chain mechanics behind a conventional REST API with client libraries in my language

   weight 3 · round to MoonPay
   BVNK~partialprobed5/10

   Docs show BVNK exposes a REST API for wallets, transfers, channels and payouts that hides on-chain mechanics (e.g., wallet, rule, and transfer endpoints), so nodes/gas are clearly abstracted. However, evidence only shows a Hawk-authenticated REST API and one CLI repo, not official client libraries/SDKs in multiple languages as the story specifies. Missing for 10: documented multi-language SDKs/client libraries, explicit statement that developers never touch node/gas mechanics.

   • [claimed-docs] “On BVNK, you can create and manage both crypto and fiat wallets through the Portal or API.”
   • [claimed-docs] “To create a rule that links a fiat virtual account to a crypto blockchain address, send the `POST /payment/v1/rules` request”
   • [claimed-docs] “The Transfers v.3 API replaces the legacy Quote API for wallet-to-wallet currency conversion.”
   • [claimed-docs] “A channel is a unique, repeated-use blockchain address that can receive crypto or stablecoins at any time. The address never changes.”
   • [claimed-docs] “BVNK uses **Hawk authentication** for secure API access.”
   • [probe] “official CLI documented at https://github.com/bvnk/agent-wallet-cli”

   proof ↗⚑ flag

   MoonPay~partialprobed6/10

   MoonPay's docs show a conventional REST API (quotes, sessions, webhooks) and widgets/SDKs that abstract on-chain mechanics like fees and rate-locking, letting developers build fiat-to-crypto flows without running nodes (moonpay-docs-3, moonpay-docs-14, moonpay-docs-15, moonpay-docs-11). However, there's no evidence of concrete multi-language client libraries or a public OpenAPI spec (probe found 404s at all candidate spec URLs), so the 'client libraries in my language' part of the story is unsupported. Missing for 10: enumerated SDK languages/repos, published OpenAPI/swagger spec, independent confirmation of ease-of-use across languages.

   • [claimed-docs] “Build your own on-ramp and off-ramp on MoonPay's APIs and SDKs. Your UI, your flow, our rails.”
   • [claimed-docs] “Builds a quote for a fiat-to-crypto buy. Returns locked rate, fees, and signature for payment execution.”
   • [claimed-docs] “Create a session token to initialize a connection”
   • [claimed-docs] “MoonPay can send webhook events that notify your application whenever an activity occurs on your account.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://dev.moonpay.com/openapi.json, https://dev.moonpay.com/swagger.json, https://dev.moonpay.com/…”

   proof ↗⚑ flag

Sandbox

1. developerRehearse everything without real funds — a documented sandbox or testnet mode covering payments, payouts, and conversions with test values that behave deterministically

   weight 3 · round to MoonPay
   BVNK~partialclaimed5/10

   BVNK documents a dedicated sandbox ('payment-sim') that simulates pay-ins and payouts consistently across accounts, which covers part of the story, but there is no explicit documentation of sandbox coverage for currency conversions (Transfers v3) or of deterministic test values/testnet behavior for those flows. missing for 10: sandbox coverage for conversions/Transfers API, explicit deterministic test-value behavior, and independent developer confirmation of sandbox fidelity.

   • [claimed-docs] “The sandbox environment provides a consistent simulation experience for pay-ins and payouts across all customer accounts.”
   • [claimed-docs] “The Transfers v.3 API replaces the legacy Quote API for wallet-to-wallet currency conversion.”

   proof ↗⚑ flag

   MoonPay✓fullclaimed7/10

   MoonPay documents a dedicated test mode using testnet blockchains and simulated payments where no real assets are transferred, directly matching the sandbox/testnet rehearsal story for buy/sell/conversion flows. Missing for 10: explicit documentation of deterministic test values (e.g., specific test card numbers or fixed exchange rates) and independent/hands-on confirmation that payouts and conversions behave predictably in test mode.

   • [claimed-docs] “MoonPay provides a test mode for integration development and testing. Test mode uses testnet blockchains and simulated payments. No real ass…”
   • [claimed-docs] “Builds a quote for a fiat-to-crypto buy. Returns locked rate, fees, and signature for payment execution.”
   • [claimed-docs] “Create a session token to initialize a connection”

   proof ↗⚑ flag

Webhooks

1. developerMoney movement emits signed webhooks — payment confirmed, payout settled, conversion executed — so my system tracks state without polling chains or dashboards

   weight 2 · round drawn
   BVNK~partialclaimed5/10

   Docs confirm BVNK webhooks deliver real-time, automated notifications for account changes (bvnk-docs-2), which supports event-driven state tracking without polling. However, the evidence never confirms webhook payloads are cryptographically signed/verifiable, nor does it enumerate specific event types like payment confirmed, payout settled, or conversion executed. Missing for 10: explicit signature/verification mechanism for webhooks, documented list of event types matching the story (payment/payout/conversion events), and any independent confirmation of reliability.

   • [claimed-docs] “Webhooks provide real-time, automated notifications for changes in your BVNK account.”
   • [claimed-docs] “BVNK uses **Hawk authentication** for secure API access.”

   proof ↗⚑ flag

   MoonPay~partialclaimed5/10

   MoonPay docs confirm a webhook system that notifies apps of account activity and give an example event (sell_transaction_requote_required), supporting event-driven state tracking. However, there is no evidence of cryptographic signing/verification of webhooks, nor documentation of specific 'payment confirmed', 'payout settled', or 'conversion executed' event types the story describes. missing for 10: signature verification details, full enumerated list of transaction lifecycle events (buy/sell/swap completion, payout settlement), independent confirmation of webhook reliability.

   • [claimed-docs] “MoonPay can send webhook events that notify your application whenever an activity occurs on your account.”
   • [claimed-docs] “Handle the sell_transaction_requote_required webhook to surface in-app requote notifications when a sell price changes.”

   proof ↗⚑ flag

Conversion

1. developerConversion is a first-class API — quotes and executed conversions between fiat and stablecoins (and between stablecoins) with documented rates, fees, and settlement times

   weight 2 · round to MoonPay
   BVNK~partialclaimed5/10

   BVNK exposes a dedicated Transfers v3 API for wallet-to-wallet currency conversion (replacing a legacy Quote API), plus fiat/stablecoin flows (fund in stablecoin, pay out in fiat) and partner markup-fee controls, indicating conversion is an API-first primitive. However, the pack lacks concrete documentation of quote request/response fields showing rates, fee breakdowns, or settlement-time SLAs for these conversions. missing for 10: explicit quote endpoint schema with rate/fee/settlement fields, independent confirmation of conversion accuracy or timing.

   • [claimed-docs] “The Transfers v.3 API replaces the legacy Quote API for wallet-to-wallet currency conversion.”
   • [claimed-docs] “Use your fiat balance to send stablecoins, or fund in stablecoins and pay out in fiat.”
   • [claimed-docs] “Automatically on-ramp to crypto and send to blockchain addresses.”
   • [claimed-docs] “As a partner, you can add a markup fee to your customers' transactions, enabling you to collect additional revenue from your customers.”
   • [claimed-docs] “Crypto converted and received in fiat: Accept stablecoin payments from customers and receive fiat currency in your account”

   proof ↗⚑ flag

   MoonPay~partialclaimed6/10

   MoonPay documents a Quotes endpoint returning locked rate, fees, and a signature for fiat-to-crypto buys, plus off-ramp requote webhooks for sell price changes, giving developers programmatic access to rates/fees for fiat↔stablecoin conversion. However, stablecoin-to-stablecoin 'swap' conversion is only mentioned as a marketing feature (docs-18) without a documented quotes/fees API for that path, and no settlement-time documentation appears anywhere in the pack. missing for 10: documented quote/fee API for stablecoin-to-stablecoin swaps, explicit settlement-time guarantees, independent confirmation of rate accuracy.

   • [claimed-docs] “Builds a quote for a fiat-to-crypto buy. Returns locked rate, fees, and signature for payment execution.”
   • [claimed-docs] “Handle the sell_transaction_requote_required webhook to surface in-app requote notifications when a sell price changes.”
   • [claimed-docs] “Trade between tokens, even if they're on different chains (we make bridging seamless too).”
   • [claimed-docs] “MoonPay can send webhook events that notify your application whenever an activity occurs on your account.”

   proof ↗⚑ flag

Onramp

1. developerEmbed a fiat-to-stablecoin onramp — a documented widget or API where end users buy stablecoins with cards or bank transfers inside my product

   weight 2 · round to MoonPay
   BVNK~partialclaimed5/10

   BVNK documents API-driven fiat-to-crypto conversion (linking fiat virtual accounts to blockchain addresses, automated on-ramp to crypto) and embedded wallets/virtual accounts that a developer could use to build an onramp flow, but there is no documented pre-built onramp widget, and no explicit mention of end users paying via card to buy stablecoins — the flow described is bank/virtual-account based automation rather than a card-based consumer buy widget. Missing for 10: a documented embeddable UI/widget component, explicit card-payment support for the onramp, and end-user-facing checkout flow evidence.

   • [claimed-docs] “To create a rule that links a fiat virtual account to a crypto blockchain address, send the `POST /payment/v1/rules` request”
   • [claimed-docs] “Crypto converted and received in fiat: Accept stablecoin payments from customers and receive fiat currency in your account”
   • [claimed-docs] “Automatically on-ramp to crypto and send to blockchain addresses.”
   • [claimed-docs] “Embedded Wallets provide partners with seamless payment and fund management capabilities directly within their platform while maintaining th…”
   • [claimed-docs] “Create virtual accounts in USD, EUR, GBP for your business or customers.”

   proof ↗⚑ flag

   MoonPay✓fullclaimed8/10

   MoonPay documents a widget and API/SDK approach for embedding fiat-to-stablecoin (and crypto) onramp flows, supporting card, Apple Pay, Google Pay and bank transfers, with customization, prefill, webhooks, quotes and session tokens, plus test mode for development. missing for 10: no independent/hands-on developer corroboration of the integration experience, and no explicit confirmation of stablecoin-specific (vs generic crypto) purchase support in the widget docs.

   • [claimed-docs] “A hosted on-ramp and off-ramp you embed in your app. MoonPay runs the KYC, payments, and UI.”
   • [claimed-docs] “Build your own on-ramp and off-ramp on MoonPay's APIs and SDKs. Your UI, your flow, our rails.”
   • [claimed-docs] “You can customize the widget to feel like a native part of your site or application by adjusting button and background colors. You can also …”
   • [claimed-docs] “Improve your customers' experience and speed up the buying process by pre-filling information such as their wallet address, email, selected …”
   • [claimed-docs] “MoonPay can send webhook events that notify your application whenever an activity occurs on your account.”
   • [claimed-docs] “MoonPay provides a test mode for integration development and testing. Test mode uses testnet blockchains and simulated payments. No real ass…”
   • [claimed-docs] “Builds a quote for a fiat-to-crypto buy. Returns locked rate, fees, and signature for payment execution.”
   • [claimed-docs] “Create a session token to initialize a connection”
   • [claimed-docs] “Use a card, Apple Pay or Google Pay to buy crypto fast. We also accept bank transfers and wires.”

   proof ↗⚑ flag

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

   weight 2 · round to BVNK
   BVNK~partialprobed7/10

   BVNK's docs show broad API coverage across core UI functions—wallet creation (fiat/crypto), transfers, payouts, rules, embedded wallets, webhooks—and explicitly note wallets can be managed 'through the Portal or API' (bvnk-docs-4), suggesting strong UI/API parity. However there is no explicit statement or independent audit confirming every UI feature (e.g., rewards, virtual cards, markup fee configuration) has a full API equivalent. Missing for 10: explicit parity documentation stating all UI actions are API-accessible, and independent/hands-on verification that no UI-only features exist.

   • [claimed-docs] “On BVNK, you can create and manage both crypto and fiat wallets through the Portal or API.”
   • [claimed-docs] “To create a rule that links a fiat virtual account to a crypto blockchain address, send the `POST /payment/v1/rules` request”
   • [claimed-docs] “The Transfers v.3 API replaces the legacy Quote API for wallet-to-wallet currency conversion.”
   • [claimed-docs] “Embedded Wallets provide partners with seamless payment and fund management capabilities directly within their platform while maintaining th…”
   • [claimed-docs] “This process allows for the ability for the `CUSTOMER ENABLED` wallet to complete payouts to other bank accounts using their virtual account…”
   • [claimed-docs] “Create virtual accounts in USD, EUR, GBP for your business or customers.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.bvnk.com/llms.txt # BVNK API Documentation > Complete API documentation for BVNK payment infrastru…”

   proof ↗⚑ flag

   MoonPay~partialprobed6/10

   MoonPay documents a full build-your-own API/SDK path (quotes, sessions, webhooks, prefill, wallet creation, requote handling) that mirrors much of what the hosted widget UI offers, suggesting broad but not explicitly total parity. However, no OpenAPI/swagger spec was found (404s on all probed paths), and there's no explicit documentation stating 100% feature parity between API and UI, with a community question even asking if the API/webhook list is public at all. Missing for 10: explicit statement of full UI/API parity, a published OpenAPI spec, and independent developer confirmation that all UI features are API-accessible.

   • [claimed-docs] “Build your own on-ramp and off-ramp on MoonPay's APIs and SDKs. Your UI, your flow, our rails.”
   • [claimed-docs] “Builds a quote for a fiat-to-crypto buy. Returns locked rate, fees, and signature for payment execution.”
   • [claimed-docs] “Create a session token to initialize a connection”
   • [claimed-docs] “MoonPay can send webhook events that notify your application whenever an activity occurs on your account.”
   • [claimed-docs] “Improve your customers' experience and speed up the buying process by pre-filling information such as their wallet address, email, selected …”
   • [claimed-docs] “Users don't have a digital wallet? We can create one for them using just their email address as they go through the purchase flow.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://dev.moonpay.com/openapi.json, https://dev.moonpay.com/swagger.json, https://dev.moonpay.com/…”
   • [community] “Wow, Congrats to MoonPay! I was curious about their fee structure, and after digging was able to find the following chart... Is the API publ…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   BVNK—none0/10

   No evidence of a bulk data export feature or open-format data portability; documentation covers payments, wallets, and APIs but nothing about exporting account/transaction data for migration or leaving the platform.

   ⚑ flag

   MoonPay—none0/10

   MoonPay stores user KYC and transaction data (moonpay-docs-20) but the evidence pack contains no mention of any data export feature, open-format download, or account portability/deletion tooling for end users.

   ⚑ flag

Batch

1. ops leadRun mass disbursements — batch or bulk payout APIs that push many stablecoin or fiat payouts in one documented operation with per-item status

   weight 2 · round drawn
   BVNK—none0/10

   Evidence shows individual payout, wallet, and transfer APIs (e.g., bvnk-docs-11, bvnk-docs-13, bvnk-docs-6) but nothing documenting a batch/bulk payout endpoint, mass-disbursement operation, or per-item status reporting for multiple payouts in one call. This is a fair axis for a payments platform, so absence of evidence means 'none' rather than 'na'.

   ⚑ flag

   MoonPay—none0/10

   MoonPay's docs describe single-transaction on-ramp/off-ramp flows (quotes, sessions, webhooks) for individual end-user purchases/sells, but there is no evidence of a batch/bulk payout API, mass disbursement endpoint, or per-item status reporting for many payouts in one operation.

   • [claimed-docs] “Builds a quote for a fiat-to-crypto buy. Returns locked rate, fees, and signature for payment execution.”
   • [claimed-docs] “Create a session token to initialize a connection”
   • [claimed-docs] “Turn your crypto into cash. In a flash. Get paid straight to your bank account or Visa card.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://dev.moonpay.com/openapi.json, https://dev.moonpay.com/swagger.json, https://dev.moonpay.com/…”

   proof ↗⚑ flag

Offramp

1. ops leadRecipients can land in local fiat — documented off-ramp rails that convert stablecoins into bank transfers across a published set of currencies and countries

   weight 2 · round to BVNK
   BVNK~partialclaimed6/10

   BVNK docs describe fiat payout rails (payout-overview, virtual accounts in USD/EUR/GBP, stablecoin-to-fiat settlement flows) confirming that off-ramp to local bank accounts is supported, but there is no single published table enumerating all supported countries or the full currency corridor list beyond USD/EUR/GBP mentions. missing for 10: a published country/currency coverage matrix, confirmation of local payout rails outside USD/EUR/GBP, and independent verification of settlement speed/coverage claims.

   • [claimed-docs] “This process allows for the ability for the `CUSTOMER ENABLED` wallet to complete payouts to other bank accounts using their virtual account…”
   • [claimed-docs] “Create virtual accounts in USD, EUR, GBP for your business or customers.”
   • [claimed-docs] “Crypto converted and received in fiat: Accept stablecoin payments from customers and receive fiat currency in your account”
   • [claimed-docs] “Use your fiat balance to send stablecoins, or fund in stablecoins and pay out in fiat.”
   • [claimed-docs] “Accept payments globally in stablecoins. Settle in fiat.”

   proof ↗⚑ flag

   MoonPay~partialclaimed5/10

   MoonPay documents off-ramp (sell) rails paying out to bank account or card, with build-your-own or hosted options and sell-specific webhooks (requote), showing the payout mechanism exists and is documented for developers. However, there is no evidence of a published, itemized list of supported fiat currencies or countries for the off-ramp, which the story specifically requires. Missing for 10: published currency/country coverage table for off-ramp, independent confirmation of payout rails working across those markets.

   • [claimed-docs] “Build your own on-ramp and off-ramp on MoonPay's APIs and SDKs. Your UI, your flow, our rails.”
   • [claimed-docs] “Turn your crypto into cash. In a flash. Get paid straight to your bank account or Visa card.”
   • [claimed-docs] “Handle the sell_transaction_requote_required webhook to surface in-app requote notifications when a sell price changes.”
   • [claimed-docs] “MoonPay can send webhook events that notify your application whenever an activity occurs on your account.”

   proof ↗⚑ flag

Payouts

1. developerSend stablecoin payouts programmatically — pay a wallet address or stored recipient through the API with documented status tracking to final settlement

   weight 3 · round to BVNK
   BVNK~partialclaimed6/10

   BVNK's docs confirm programmatic stablecoin sending via API (bvnk-docs-13, bvnk-docs-14, bvnk-docs-18), wallet creation/management via API (bvnk-docs-4), and webhook-based notifications for account changes (bvnk-docs-2), plus a sandbox simulation for payouts (bvnk-docs-3). However, there is no explicit documentation of a 'stored recipient' object, dedicated payout endpoint with status-lifecycle documentation (e.g., pending→settled states), or confirmation that webhooks specifically track payout-to-settlement status. missing for 10: dedicated payout API/status-tracking docs, stored-recipient object documentation, explicit settlement-state webhook events.

   • [claimed-docs] “Send stablecoins or cryptocurrencies from your BVNK account.”
   • [claimed-docs] “Automatically on-ramp to crypto and send to blockchain addresses.”
   • [claimed-docs] “Use your fiat balance to send stablecoins, or fund in stablecoins and pay out in fiat.”
   • [claimed-docs] “On BVNK, you can create and manage both crypto and fiat wallets through the Portal or API.”
   • [claimed-docs] “Webhooks provide real-time, automated notifications for changes in your BVNK account.”
   • [claimed-docs] “The sandbox environment provides a consistent simulation experience for pay-ins and payouts across all customer accounts.”

   proof ↗⚑ flag

   MoonPay—none0/10

   MoonPay's docs describe on-ramp/off-ramp widgets and APIs for individual users buying/selling crypto (quotes, sessions, webhooks for sell/requote), but there is no evidence of a payouts API that lets a developer programmatically disburse stablecoins to a wallet address or stored recipient list with settlement status tracking — that is a distinct payouts/disbursement capability not shown in the pack.

   • [claimed-docs] “A hosted on-ramp and off-ramp you embed in your app. MoonPay runs the KYC, payments, and UI.”
   • [claimed-docs] “Builds a quote for a fiat-to-crypto buy. Returns locked rate, fees, and signature for payment execution.”
   • [claimed-docs] “Create a session token to initialize a connection”
   • [claimed-docs] “MoonPay can send webhook events that notify your application whenever an activity occurs on your account.”
   • [claimed-docs] “Turn your crypto into cash. In a flash. Get paid straight to your bank account or Visa card.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   BVNK—none0/10

   No evidence describes data residency/region selection controls in BVNK's docs or product pages; the evidence pack covers payments, wallets, and API features only. This axis applies to a payments/fintech platform handling customer data, so absence of evidence yields none.

   ⚑ flag

   MoonPay—none0/10

   No evidence in the pack addresses data residency, regional data storage options, or user/developer control over where data is stored; MoonPay's docs cover payment/KYC integration but never mention data locality choices.

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   BVNK—none0/10

   BVNK's evidence pack covers payments, wallets, webhooks, and API auth, but contains no mention of data retention policies, deletion controls, or privacy/data lifecycle management features for AI-native users. This is a fintech payments platform where such controls could plausibly exist (e.g., in compliance/data policies), but no documentation surfaces them.

   ⚑ flag

   MoonPay—none0/10

   No evidence pack content addresses data retention policies, user data deletion requests, or privacy controls for AI-native users; docs focus on payments, KYC integration, and widget customization. Missing for 10: any documentation of data retention policy, user-initiated deletion/erasure mechanism, or privacy control API/settings.

   ⚑ flag

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

   weight 2 · round drawn
   BVNK—none0/10

   No evidence in the pack addresses telemetry, usage tracking, or opt-out controls; BVNK's documentation focuses entirely on payment/wallet/API functionality. This is a fair privacy-posture question for any product handling user data via API/portal, so absence of evidence yields 'none' rather than 'na'. missing for 10: any mention of telemetry collection, opt-out settings, or privacy controls.

   ⚑ flag

   MoonPay—none0/10

   No evidence of any telemetry/usage-tracking opt-out mechanism or privacy controls for AI-native users; documentation covers payments, KYC, and integration features only.

   ⚑ flag

Settlement

1. finance leadSettlement is legible — documented timing from payment to available balance, published fees per rail, and statements or reports my accounting can consume

   weight 2 · round drawn
   BVNK—none0/10

   No evidence pack items document settlement timing SLAs (payment to available balance), a published fee schedule per rail, or exportable statements/reports for accounting reconciliation; evidence only covers API mechanics like wallets, webhooks, transfers, and embedded partner features.

   ⚑ flag

   MoonPay—none0/10

   The evidence pack shows webhooks, quotes with locked rates/fees, and test mode, but nothing documents settlement timing (payment to available balance), a published fee schedule per rail, or accounting-consumable statements/reports. A community comment even asks whether MoonPay's fee structure/API is publicly available, suggesting no clear published fee documentation exists. Missing for 10: settlement timing documentation, per-rail fee schedules, downloadable statements/reports for accounting.

   • [claimed-docs] “Builds a quote for a fiat-to-crypto buy. Returns locked rate, fees, and signature for payment execution.”
   • [claimed-docs] “MoonPay can send webhook events that notify your application whenever an activity occurs on your account.”
   • [community] “Wow, Congrats to MoonPay! I was curious about their fee structure, and after digging was able to find the following chart... Is the API publ…”

   proof ↗⚑ flag

Treasury

1. finance leadMove value between fiat and stablecoin balances on the platform — internal transfers and rebalancing through the API or dashboard, documented end to end

   weight 2 · round to BVNK
   BVNK✓fullclaimed8/10

   BVNK documents crypto/fiat wallet creation, the Transfers v3 API for wallet-to-wallet currency conversion, fiat-to-crypto automation rules, on/off-ramp flows, and messaging like 'use your fiat balance to send stablecoins, or fund in stablecoins and pay out in fiat' — covering both API and dashboard rebalancing between fiat and stablecoin balances end to end. Missing for 10: an explicit worked example/tutorial showing a full internal transfer+rebalance flow with request/response payloads, and independent (non-vendor) confirmation of dashboard UX.

   • [claimed-docs] “On BVNK, you can create and manage both crypto and fiat wallets through the Portal or API.”
   • [claimed-docs] “To create a rule that links a fiat virtual account to a crypto blockchain address, send the `POST /payment/v1/rules` request”
   • [claimed-docs] “The Transfers v.3 API replaces the legacy Quote API for wallet-to-wallet currency conversion.”
   • [claimed-docs] “Crypto converted and received in fiat: Accept stablecoin payments from customers and receive fiat currency in your account”
   • [claimed-docs] “Create virtual accounts in USD, EUR, GBP for your business or customers.”
   • [claimed-docs] “Send stablecoins or cryptocurrencies from your BVNK account.”
   • [claimed-docs] “Automatically on-ramp to crypto and send to blockchain addresses.”
   • [claimed-docs] “Use your fiat balance to send stablecoins, or fund in stablecoins and pay out in fiat.”
   • [claimed-docs] “Accept payments globally in stablecoins. Settle in fiat.”

   proof ↗⚑ flag

   MoonPay—none0/10

   MoonPay's documented capabilities are consumer-facing on-ramp/off-ramp/swap widgets and APIs (buy, sell, quote, webhooks) for end users converting fiat to crypto and back — there is no evidence of an internal treasury/balance system, account-to-account transfers, or rebalancing API/dashboard aimed at a finance lead managing platform-held fiat and stablecoin balances. Missing for 10: any documentation of internal ledger/balance accounts, transfer-between-balances API, or treasury dashboard for rebalancing fiat vs stablecoin holdings.

   • [claimed-docs] “Builds a quote for a fiat-to-crypto buy. Returns locked rate, fees, and signature for payment execution.”
   • [claimed-docs] “Use a card, Apple Pay or Google Pay to buy crypto fast. We also accept bank transfers and wires.”
   • [claimed-docs] “Turn your crypto into cash. In a flash. Get paid straight to your bank account or Visa card.”
   • [claimed-docs] “MoonPay can send webhook events that notify your application whenever an activity occurs on your account.”

   proof ↗⚑ flag

Acceptance

1. developerAccept a stablecoin payment from a customer through a documented checkout or payment API — create the payment, present the address or flow, and confirm settlement programmatically

   weight 3 · round to BVNK
   BVNK✓fullclaimed8/10

   BVNK's docs describe creating payment channels (unique repeated-use blockchain addresses) to accept stablecoin payments, converting to fiat, plus webhook notifications for settlement confirmation and a sandbox for testing pay-ins programmatically. This covers create → present address → confirm settlement end-to-end via documented API, though evidence is docs-only without independent hands-on confirmation. Missing for 10: independent/hands-on verification of the checkout flow working in practice, and more detail on the specific 'create payment' endpoint/response schema.

   • [claimed-docs] “Crypto converted and received in fiat: Accept stablecoin payments from customers and receive fiat currency in your account”
   • [claimed-docs] “A channel is a unique, repeated-use blockchain address that can receive crypto or stablecoins at any time. The address never changes.”
   • [claimed-docs] “Webhooks provide real-time, automated notifications for changes in your BVNK account.”
   • [claimed-docs] “The sandbox environment provides a consistent simulation experience for pay-ins and payouts across all customer accounts.”
   • [claimed-docs] “BVNK uses **Hawk authentication** for secure API access.”

   proof ↗⚑ flag

   MoonPay—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

Chains

1. developerThe platform documents which stablecoins and chains it supports — USDC, USDT and peers across multiple named networks — so I can match what my customers actually hold

   weight 2 · round drawn
   BVNK—none0/10

   The evidence pack shows BVNK supports generic 'stablecoins' and 'crypto' wallets, but nowhere does it name specific stablecoins (USDC, USDT, etc.) or specific blockchain networks/chains supported. missing for 10: named stablecoin list (USDC, USDT, etc.), named supported chains/networks, any coin-to-chain compatibility matrix.

   • [claimed-docs] “Crypto converted and received in fiat: Accept stablecoin payments from customers and receive fiat currency in your account”
   • [claimed-docs] “A channel is a unique, repeated-use blockchain address that can receive crypto or stablecoins at any time. The address never changes.”
   • [claimed-docs] “Send stablecoins or cryptocurrencies from your BVNK account.”
   • [claimed-docs] “Use your fiat balance to send stablecoins, or fund in stablecoins and pay out in fiat.”
   • [claimed-docs] “Accept payments globally in stablecoins. Settle in fiat.”

   proof ↗⚑ flag

   MoonPay—none0/10

   The evidence pack shows general on-ramp/off-ramp and cross-chain swap capabilities but contains no documentation listing specific supported stablecoins (USDC, USDT, etc.) or named blockchain networks. Missing for 10: an explicit supported-assets/networks list, stablecoin-specific documentation, and named chain coverage.

   ⚑ flag

Fiat settlement

1. finance leadTake crypto payments but settle in fiat — a documented option to auto-convert stablecoin receipts into a fiat balance or bank payout so my books never hold crypto

   weight 3 · round to BVNK
   BVNK✓fullclaimed9/10

   BVNK explicitly documents accepting stablecoin payments and receiving fiat currency in the account (bvnk-docs-9), with marketing and docs confirming 'Accept payments globally in stablecoins. Settle in fiat' and 'fund in stablecoins and pay out in fiat' (bvnk-docs-18, bvnk-docs-19), plus payout mechanisms to bank accounts (bvnk-docs-11) and fiat virtual accounts in major currencies (bvnk-docs-12). missing for 10: independent/hands-on confirmation of the auto-conversion accounting flow beyond vendor docs.

   • [claimed-docs] “Crypto converted and received in fiat: Accept stablecoin payments from customers and receive fiat currency in your account”
   • [claimed-docs] “Use your fiat balance to send stablecoins, or fund in stablecoins and pay out in fiat.”
   • [claimed-docs] “Accept payments globally in stablecoins. Settle in fiat.”
   • [claimed-docs] “This process allows for the ability for the `CUSTOMER ENABLED` wallet to complete payouts to other bank accounts using their virtual account…”
   • [claimed-docs] “Create virtual accounts in USD, EUR, GBP for your business or customers.”

   proof ↗⚑ flag

   MoonPay~partialclaimed4/10

   MoonPay's off-ramp product (docs-17, docs-3) lets crypto be converted to cash paid to a bank account or card, and this can be built into a business's own flow via APIs/webhooks (docs-11, docs-14). However, this is framed as a consumer/end-user cash-out feature, not a documented merchant treasury/settlement product for automatically converting incoming stablecoin payments into a fiat balance so a business's books never hold crypto. Missing for 10: explicit merchant/business settlement documentation, stablecoin-specific auto-conversion mechanics, fiat balance/ledger concept, and accounting-oriented guarantees that crypto is never held.

   • [claimed-docs] “Turn your crypto into cash. In a flash. Get paid straight to your bank account or Visa card.”
   • [claimed-docs] “Build your own on-ramp and off-ramp on MoonPay's APIs and SDKs. Your UI, your flow, our rails.”
   • [claimed-docs] “MoonPay can send webhook events that notify your application whenever an activity occurs on your account.”
   • [claimed-docs] “Builds a quote for a fiat-to-crypto buy. Returns locked rate, fees, and signature for payment execution.”

   proof ↗⚑ flag

Agent payments

1. ai-native userAn agent can move stablecoins under scoped authority — documented agent payment flows where an agent initiates a payment or payout with spend controls a human configured

   weight 3 · round drawn
   BVNK—none0/10

   Evidence shows general wallet/payment/API capabilities (wallets, rules automation, transfers) but nothing describing an 'agent' actor, scoped spend authority, or human-configured spend limits governing agent-initiated payments. The lone 'agent-wallet-cli' repo mention has no accompanying documentation of spend controls or agent payment flows, so this doesn't establish the capability.

   • [probe] “official CLI documented at https://github.com/bvnk/agent-wallet-cli”
   • [claimed-docs] “To create a rule that links a fiat virtual account to a crypto blockchain address, send the `POST /payment/v1/rules` request”
   • [claimed-docs] “Send stablecoins or cryptocurrencies from your BVNK account.”

   proof ↗⚑ flag

   MoonPay—none0/10

   MoonPay's MCP server (moonpay-docs-6, moonpay-probe-3) only gives agents access to search/retrieve documentation content, not to initiate payments. There is no evidence of an agent payment flow with human-configured spend controls, scoped authority, or delegated transaction limits — the API docs describe quotes/sessions for human-driven checkout flows, not autonomous agent-initiated payouts.

   • [claimed-docs] “The documentation includes a Model Context Protocol (MCP) server that gives AI agents direct access to search and retrieve content.”
   • [probe] “official MCP server documented at https://dev.moonpay.com/platform/overview/using-agents”
   • [claimed-docs] “Builds a quote for a fiat-to-crypto buy. Returns locked rate, fees, and signature for payment execution.”
   • [claimed-docs] “Create a session token to initialize a connection”

   proof ↗⚑ flag

Agent wallets

1. ai-native userAgents can hold and use wallets safely — programmatic wallet issuance for agents with scoped keys, policy controls, and documented limits on what an agent can move

   weight 2 · round to BVNK
   BVNK~partialprobed3/10

   BVNK documents general programmatic wallet creation (crypto/fiat) via API/Portal and Hawk-based API authentication, and a probe references an 'agent-wallet-cli' repo, suggesting some agent-oriented wallet tooling exists. However there is no documentation of scoped API keys per agent, policy/permission controls, or explicit spending/movement limits tailored to autonomous agents. Missing for 10: scoped-key issuance mechanics, policy engine/spend-limit configuration, and agent-specific governance documentation.

   • [claimed-docs] “On BVNK, you can create and manage both crypto and fiat wallets through the Portal or API.”
   • [claimed-docs] “BVNK uses **Hawk authentication** for secure API access.”
   • [probe] “official CLI documented at https://github.com/bvnk/agent-wallet-cli”

   proof ↗⚑ flag

   MoonPay—none0/10

   Evidence covers MoonPay's on/off-ramp widget, API, and MCP docs-server for content retrieval, but there is no mention of programmatic wallet issuance for AI agents, scoped API keys, policy controls, or documented spend limits governing what an agent can move. The comm-1 item is off-topic (fraud allegation, not agent wallet controls) and ignored.

   ⚑ flag

Protocols

1. ai-native userThe platform speaks the machine-payment protocols by name — x402, ACP, MPP, or AP2 support documented with endpoints or SDKs, not just a blog aspiration

   weight 2 · round drawn
   BVNK—none0/10

   No evidence of x402, ACP, MPP, or AP2 protocol support anywhere in the docs pack; BVNK documents Hawk auth, webhooks, wallets, and fiat/crypto conversion APIs but never mentions these machine-payment protocols by name or provides endpoints/SDKs for them.

   • [claimed-docs] “BVNK uses **Hawk authentication** for secure API access.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.bvnk.com/llms.txt # BVNK API Documentation > Complete API documentation for BVNK payment infrastru…”

   proof ↗⚑ flag

   MoonPay—none0/10

   Evidence shows MoonPay has an MCP server for docs search and standard fiat on/off-ramp APIs, but no mention of named machine-payment protocols like x402, ACP, MPP, or AP2 anywhere in the docs, endpoints, or SDKs.

   ⚑ flag

Issuance

1. founderIssue a branded stablecoin on the platform's infrastructure — a documented issuance product covering minting, redemption, and reserve management, with its gating quoted honestly

   weight 2 · round drawn
   BVNK—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

   MoonPay—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

Yield

1. finance leadThe economics of held stablecoins are documented — reserve composition, attestations, and any yield or rewards program with its eligibility and regulatory caveats stated plainly

   weight 2 · round to BVNK
   BVNK~partialclaimed2/10

   Marketing copy mentions a rewards program ('Put idle balances to work with built-in rewards') implying some yield mechanism, but there is no documentation of reserve composition, attestation reports, eligibility criteria, or regulatory caveats for held stablecoins. Missing for 10: reserve composition disclosure, third-party attestation reports, yield program eligibility rules, regulatory/risk caveats for the rewards program.

   • [claimed-docs] “Put idle balances to work with built-in rewards.”

   proof ↗⚑ flag

   MoonPay—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. finance leadMy business can hold a stablecoin balance on the platform — documented custodial accounts with stated availability, geographies, and any gating quoted honestly

   weight 3 · round to BVNK
   BVNK~partialclaimed5/10

   BVNK docs and marketing confirm you can create and hold crypto/stablecoin wallets/balances (bvnk-docs-4, bvnk-docs-15, bvnk-docs-13, bvnk-docs-17, bvnk-docs-19), but there is no documentation on custodial account structure, licensing, geographic availability, or any gating/eligibility disclosures for holding stablecoin balances. missing for 10: explicit custodial/regulatory documentation, stated geographic availability, and honest disclosure of any gating or KYC/jurisdiction restrictions for balance holding.

   • [claimed-docs] “On BVNK, you can create and manage both crypto and fiat wallets through the Portal or API.”
   • [claimed-docs] “Send stablecoins or cryptocurrencies from your BVNK account.”
   • [claimed-docs] “Spin up stablecoin and fiat wallets for your customers.”
   • [claimed-docs] “Put idle balances to work with built-in rewards.”
   • [claimed-docs] “Accept payments globally in stablecoins. Settle in fiat.”

   proof ↗⚑ flag

   MoonPay—none0/10

   Evidence describes MoonPay purely as an on-ramp/off-ramp/swap payment rail (buy/sell/bridge crypto, webhooks, quotes, session tokens) with no documented custodial account product for holding a business stablecoin balance, nor any stated availability, geography, or gating for such a balance. This is a plausible axis for a crypto payments platform to address, but no supporting evidence exists.

   • [claimed-docs] “MoonPay lets you add fiat-to-crypto to your product without rebuilding payments, KYC, and compliance.”
   • [claimed-docs] “Use a card, Apple Pay or Google Pay to buy crypto fast. We also accept bank transfers and wires.”
   • [claimed-docs] “Turn your crypto into cash. In a flash. Get paid straight to your bank account or Visa card.”
   • [claimed-docs] “Trade between tokens, even if they're on different chains (we make bridging seamless too).”

   proof ↗⚑ flag

Virtual accounts

1. developerIncoming funds are attributable — named virtual accounts or dedicated deposit addresses per customer so reconciliation knows who paid without manual matching

   weight 2 · round to BVNK
   BVNK✓fullclaimed7/10

   BVNK docs show both named virtual accounts (USD/EUR/GBP) for businesses/customers and 'channels' — unique, repeated-use blockchain deposit addresses that never change per customer — plus webhooks for real-time notification of incoming funds, directly enabling attribution without manual matching. missing for 10: explicit documentation tying a specific virtual account/address to a customer ID in transaction payloads, and independent/hands-on confirmation of reconciliation workflow.

   • [claimed-docs] “A channel is a unique, repeated-use blockchain address that can receive crypto or stablecoins at any time. The address never changes.”
   • [claimed-docs] “Create virtual accounts in USD, EUR, GBP for your business or customers.”
   • [claimed-docs] “Webhooks provide real-time, automated notifications for changes in your BVNK account.”
   • [claimed-docs] “This process allows for the ability for the `CUSTOMER ENABLED` wallet to complete payouts to other bank accounts using their virtual account…”

   proof ↗⚑ flag

   MoonPay—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

Wallets

1. developerCreate wallets programmatically — per-customer or per-purpose wallets and deposit addresses provisioned through the API with documented key custody semantics

   weight 2 · round to BVNK
   BVNK~partialclaimed6/10

   Docs confirm crypto/fiat wallet and virtual-account creation via API or Portal (bvnk-docs-4, bvnk-docs-12), per-customer wallet provisioning (bvnk-docs-15), and reusable deposit addresses/'channels' for receiving crypto (bvnk-docs-10), which together demonstrate programmatic wallet/address provisioning. However there is no documentation of key custody semantics (custodial model, key management, signing responsibility) anywhere in the pack. Missing for 10: explicit key custody/ownership documentation, independent confirmation of API wallet creation workflow beyond docs snippets.

   • [claimed-docs] “On BVNK, you can create and manage both crypto and fiat wallets through the Portal or API.”
   • [claimed-docs] “A channel is a unique, repeated-use blockchain address that can receive crypto or stablecoins at any time. The address never changes.”
   • [claimed-docs] “Create virtual accounts in USD, EUR, GBP for your business or customers.”
   • [claimed-docs] “Spin up stablecoin and fiat wallets for your customers.”

   proof ↗⚑ flag

   MoonPay—none0/10

   MoonPay's docs mention it can auto-create a wallet for users via email during the on-ramp purchase flow, but this is a widget-embedded convenience feature, not a documented developer API for programmatically provisioning per-customer/purpose wallets or deposit addresses, and there is no documentation of key custody semantics.

   • [claimed-docs] “Users don't have a digital wallet? We can create one for them using just their email address as they go through the purchase flow.”

   proof ↗⚑ flag