Stripe Financial Connections vs TrueLayer

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 Stripe Financial Connections
   Stripe Financial Connections✓fullcommunity8/10

   Docs describe a server-side session (client_secret) that launches a hosted collectFinancialConnectionsAccounts widget with built-in institution selection across 12,000+ banks, returning connected account data and firing webhooks on link — exactly the drop-in flow described, and community reports confirm real-world adoption for ACH/fraud use cases (docs-6, docs-7, docs-12, comm-6). missing for 10: no explicit doc snippet naming a returned 'token' object schema, and no independent hands-on write-up specifically validating the create-session-then-widget code path (only high-level docs and general community sentiment).

   • [claimed-docs] “Use collectFinancialConnectionsAccounts to launch the authentication flow from your client using the client_secret returned by your server”
   • [claimed-docs] “Users select their bank from frequently chosen institutions or by searching more than 12,000 supported banks.”
   • [claimed-docs] “Sent when a customer links a new account. If they link multiple accounts, it emits multiple events (one per account).”
   • [claimed-docs] “the authentication flow exclusively shows a selection of test institutions managed by Stripe. The client can link accounts from any of these…”
   • [community] “I work at one of the companies that integrated Financial Connections during its beta, moving from Plaid Auth. We use the link to bank accoun…”

   proof ↗⚑ flag

   TrueLayer—none0/10

   The evidence pack describes TrueLayer's Data API for reading account/identity/transaction info and lists supported providers, but nowhere documents a drop-in hosted widget with a server-side session creation and token retrieval flow for account-linking (the closest analog, 'payment links', applies only to payments, not data/account linking). Missing for 10: hosted account-linking widget SDK/UI docs, session-creation endpoint for linking, and evidence of a returned account-link token from a widget flow.

   • [claimed-docs] “Access identity, accounts, transactions and balance data for all integrated banks with a single interface.”
   • [claimed-docs] “Read account information, balances and transaction history from a user's bank.”
   • [claimed-docs] “Query the providers endpoint to see which banks are supported in each European country and segment.”

   proof ↗⚑ flag

Oauth

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

   weight 2 · round drawn
   Stripe Financial Connections—none0/10

   None of the docs mention OAuth explicitly, document which institutions use bank-hosted OAuth versus other methods, or describe retirement of legacy credential-based flows. In fact, community commentary indicates Stripe proxies to Plaid-like providers (i.e., non-OAuth/screen-scraping) for institutions lacking OAuth support, undermining the premise that connections are exclusively OAuth-based.

   • [community] “If Stripe can leverage their banking relationships to leapfrog Plaid by integrating directly with bank's APIs instead of screen scraping, th…”
   • [claimed-docs] “Users select their bank from frequently chosen institutions or by searching more than 12,000 supported banks.”
   • [claimed-docs] “You can use one integration to instantly verify bank accounts for ACH payments, reduce underwriting risk with balances data, mitigate fraud …”

   proof ↗⚑ flag

   TrueLayer—none0/10

   The evidence pack covers TrueLayer's Payments, Data, and Verification APIs, SDKs, and a providers endpoint listing supported banks per country, but nothing explicitly documents that connections use bank-hosted OAuth versus screen-scraping, nor any statement about retiring legacy credential-based flows. Without that specific documentation, this axis is unsupported.

   • [claimed-docs] “Query the providers endpoint to see which banks are supported in each European country and segment.”
   • [claimed-docs] “Access identity, accounts, transactions and balance data for all integrated banks with a single interface.”

   proof ↗⚑ flag

Repair

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

   weight 2 · round to Stripe Financial Connections
   Stripe Financial Connections~partialclaimed6/10

   Stripe documents a dedicated relink API to help reconnect an inactive/broken account, plus webhooks marking refresh completions (balance, ownership, transaction), implying some status tracking for account health. However, the pack lacks explicit documentation of distinct 'expired' vs 'revoked' status codes or a walkthrough showing the re-auth update flow preserving prior account context so users don't start over. missing for 10: explicit status enumeration for expired/revoked links, end-to-end UX documentation of the re-auth flow without data loss, and independent confirmation the relink flow works as described.

   • [claimed-docs] “Use the relink API to help your user reconnect their inactive account.”
   • [claimed-docs] “Sent when a customer links a new account. If they link multiple accounts, it emits multiple events (one per account).”
   • [claimed-docs] “Sent after a balance refresh is complete.”
   • [claimed-docs] “Sent after an ownership refresh is complete.”
   • [claimed-docs] “Sent after a transaction refresh is complete.”

   proof ↗⚑ flag

   TrueLayer—none0/10

   TrueLayer's docs cover consent, mandates, and webhooks for payment status but nowhere document how expired/revoked account-links surface as distinct statuses or how a user re-authenticates via an update flow without restarting; the evidence pack has no reference to reconnection/re-auth UX for broken links.

   ⚑ flag

Agent access

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

   weight 2 · round to TrueLayer
   Stripe Financial Connections✓fullprobed8/10

   Stripe hosts a live llms.txt (HTTP 200) and markdown-formatted docs (financial-connections.md) confirmed by direct probes, and there's also agent-oriented documentation like use-cases.md with an explicit 'Financial insights for agents' section referencing agent-powered analysis tools. Missing for 10: independent/community confirmation that agents actually consume these docs successfully, and no dedicated llms.txt content specific to Financial Connections (it's the site-wide docs.stripe.com/llms.txt).

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stripe.com/llms.txt # Stripe Documentation When installing Stripe packages, always check the npm r…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/financial-connections.md # Stripe Financial Connections Access permissioned data from yo…”
   • [claimed-docs] “Financial insights for agents | - Agent-powered spending analysis - Balance and transaction monitoring | Link CLI”

   proof ↗⚑ flag

   TrueLayer✓fullprobed9/10

   TrueLayer hosts a verified llms.txt at docs.truelayer.com/llms.txt (probe confirms HTTP 200) with a documented convention that any docs page can be appended with .md for markdown, directly enabling agent-oriented consumption; docs also explicitly cover an MCP integration for AI assistants, reinforcing agent-native design. Missing for 10: no independent third-party confirmation that agents reliably use this in practice beyond TrueLayer's own docs.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.truelayer.com/llms.txt # TrueLayer Documentation > TrueLayer Documentation Append .md to any docu…”
   • [claimed-docs] “Monitor payments and generate reports in Console.”
   • [claimed-docs] “By integrating the TrueLayer MCP server with this AI assistant, you'd empower Claude AI to perform a range of banking and payment operations…”
   • [probe] “official MCP server documented at https://docs.truelayer.com/docs/truelayer-mcp-integration-for-claude-ai”

   proof ↗⚑ flag

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

   weight 2 · round to TrueLayer
   Stripe Financial Connections~partialprobed4/10

   Financial Connections exposes server-side webhooks and a documented testing mode where test institutions can be linked without credentials, which supports some automated/CI testing (docs-15, docs-26, docs-12/13/24/25), and Stripe's broader platform offers a CLI and MCP server for agent-driven automation (probe-4, probe-5, docs-18). However, the core account-linking flow requires a client-side authentication step (collectFinancialConnectionsAccounts) that is inherently interactive, not headless, for real accounts. Missing for 10: explicit documentation of a fully headless/server-only flow for production account linking, and independent confirmation that CI-only automation works end-to-end without any UI step.

   • [claimed-docs] “the authentication flow exclusively shows a selection of test institutions managed by Stripe. The client can link accounts from any of these…”
   • [claimed-docs] “The client can link accounts from any of these institutions without providing credentials.”
   • [claimed-docs] “Sent when a customer links a new account. If they link multiple accounts, it emits multiple events (one per account).”
   • [claimed-docs] “Sent after a balance refresh is complete.”
   • [claimed-docs] “Sent after an ownership refresh is complete.”
   • [claimed-docs] “Sent after a transaction refresh is complete.”
   • [claimed-docs] “Use collectFinancialConnectionsAccounts to launch the authentication flow from your client using the client_secret returned by your server”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”

   proof ↗⚑ flag

   TrueLayer~partialclaimed5/10

   TrueLayer is API-first with SDKs (Node.js, Python, Java, .NET) and signing libraries, which are inherently usable in headless/automated/CI contexts since there is no GUI dependency for core payment/data operations. However, there is no explicit documentation about CI/CD integration, automated testing pipelines, or headless deployment guidance. Missing for 10: explicit CI/automation documentation, example CI pipeline configs, headless testing guidance, non-interactive auth flow docs for automated environments.

   • [claimed-docs] “SDKs for Node.js, Python, Java and .NET.”
   • [claimed-docs] “They simplify API calls with easy-to-use interfaces, type-hinted methods and abstractions. They also automate request signing for all Paymen…”
   • [github] “Convenient libraries to produce TrueLayer API requests signatures.”
   • [claimed-docs] “The Payments API v3 allows you to make and accept payments and payouts in the UK and EU.”

   proof ↗⚑ flag

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

   weight 3 · round to Stripe Financial Connections
   Stripe Financial Connections✓fullprobed8/10

   Stripe documents an official MCP server that lets AI agents interact with the Stripe API and knowledge base, and Financial Connections docs explicitly call out an agent use case ('Financial insights for agents' with agent-powered spending analysis and balance/transaction monitoring), confirmed by a live docs probe at docs.stripe.com/mcp. Missing for 10: independent/hands-on confirmation that Financial Connections-specific tools (balances, transactions, ownership) are exposed via the MCP server, and no community reports of using it.

   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
   • [claimed-docs] “Financial insights for agents | - Agent-powered spending analysis - Balance and transaction monitoring | Link CLI”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   proof ↗⚑ flag

   TrueLayer✓fullprobed7/10

   TrueLayer documents an official MCP server integration for Claude AI, exposing at least one concrete tool (create-truelayer-payment-link) that lets an agent perform banking/payment operations, and a probe confirms the doc page exists. Missing for 10: broader tool catalog beyond payment-link creation, independent/hands-on verification of the MCP server working, and details on setup/auth for non-Claude MCP clients.

   • [claimed-docs] “By integrating the TrueLayer MCP server with this AI assistant, you'd empower Claude AI to perform a range of banking and payment operations…”
   • [claimed-docs] “create-truelayer-payment-link` - Generate a new payment link for initiating a payment from a bank account to the TrueLayer merchant account”
   • [probe] “official MCP server documented at https://docs.truelayer.com/docs/truelayer-mcp-integration-for-claude-ai”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Stripe Financial Connections
   Stripe Financial Connections✓fullprobed7/10

   Stripe provides an official Stripe CLI documented at docs.stripe.com/stripe-cli, which applies across Stripe products including Financial Connections, and this is a first-party, well-documented tool rather than just a wrapper. missing for 10: Financial Connections-specific CLI usage examples/workflows and independent hands-on corroboration of CLI use for this product's API.

   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”

   proof ↗⚑ flag

   TrueLayer—none0/10

   TrueLayer is a payments/banking API platform with SDKs, an MCP server for Claude, and signing libraries, but no evidence anywhere in the pack of an official CLI tool for developers or AI-native workflows.

   ⚑ flag

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

   weight 3 · round to TrueLayer
   Stripe Financial Connections~partialprobed6/10

   Stripe Financial Connections is documented via Stripe's broader public REST API and webhooks (account linking, balance/ownership/transaction refresh events, relink API), and Stripe provides an official MCP server for AI agents to interact with the Stripe API plus a documented CLI, which together support agent-driven use. However, evidence doesn't show Financial Connections-specific MCP tools or agent-native documentation beyond a generic 'Financial insights for agents' use-case mention, and no independent corroboration of agents successfully driving this specific product exists. Missing for 10: dedicated Financial Connections MCP tool documentation, hands-on/independent verification of agentic API usage for this product specifically, and full OpenAPI spec discoverability (404s found).

   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
   • [claimed-docs] “Financial insights for agents | - Agent-powered spending analysis - Balance and transaction monitoring | Link CLI”
   • [claimed-docs] “Use collectFinancialConnectionsAccounts to launch the authentication flow from your client using the client_secret returned by your server”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”
   • [claimed-docs] “Use the relink API to help your user reconnect their inactive account.”

   proof ↗⚑ flag

   TrueLayer✓fullprobed8/10

   TrueLayer publishes extensive public API documentation covering Payments API v3, Data API, Verification API, webhooks, signing, and SDKs for Node.js/Python/Java/.NET, with a quickstart for making a test payment — clear evidence of a documented, programmatically drivable API for an AI-native or any developer user. Missing for 10: a discoverable machine-readable OpenAPI/Swagger spec (probe found only 404s), so full API surface must be inferred from prose docs rather than a formal schema.

   • [claimed-docs] “The Payments API v3 allows you to make and accept payments and payouts in the UK and EU.”
   • [claimed-docs] “Read account information, balances and transaction history from a user's bank.”
   • [claimed-docs] “SDKs for Node.js, Python, Java and .NET.”
   • [claimed-docs] “The Payments API v3 uses a pair of ECDSA keys in addition to a bearer token.”
   • [claimed-docs] “They simplify API calls with easy-to-use interfaces, type-hinted methods and abstractions. They also automate request signing for all Paymen…”
   • [claimed-docs] “you'll create a free UK merchant account and complete your first test payment with the Payments API v3”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.truelayer.com/llms.txt # TrueLayer Documentation > TrueLayer Documentation Append .md to any docu…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.truelayer.com/openapi.json, https://docs.truelayer.com/swagger.json, https://docs.truel…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Stripe Financial Connections—none0/10

   The evidence pack covers Financial Connections' bank-linking, data-access, and webhook features, plus a generic Stripe MCP server for agent API access, but nothing about issuing scoped or least-privilege API credentials/keys specifically for agents. No mention of restricted API keys, credential scoping, or permission granularity for agentic use is present.

   ⚑ flag

   TrueLayer—none0/10

   TrueLayer's docs describe standard API client credentials, OAuth-style bearer tokens plus ECDSA signing, and an MCP integration for Claude, but nothing describes issuing scoped or least-privilege credentials specifically for an AI agent (e.g., agent-specific API keys, granular permission tiers, or restricted scopes for automated/agentic use). Missing for 10: any mention of agent-specific credential scoping, permission tiers, or least-privilege key issuance beyond generic client_id/secret and bearer tokens.

   • [claimed-docs] “Invite users so they can retrieve your integration's client credentials, access the payments view, or issue refunds.”
   • [claimed-docs] “The Payments API v3 uses a pair of ECDSA keys in addition to a bearer token.”
   • [claimed-docs] “By integrating the TrueLayer MCP server with this AI assistant, you'd empower Claude AI to perform a range of banking and payment operations…”
   • [claimed-docs] “create-truelayer-payment-link` - Generate a new payment link for initiating a payment from a bank account to the TrueLayer merchant account”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round drawn
   Stripe Financial Connections✓fullprobed7/10

   Stripe provides official SDKs and client integration methods (e.g., collectFinancialConnectionsAccounts) for Financial Connections, plus a documented official CLI and an official MCP server enabling AI agents to interact with Stripe APIs including this product, and docs explicitly mention 'Financial insights for agents' use cases. missing for 10: independent hands-on developer confirmation of building an AI-native agent integration specifically with Financial Connections via SDK/MCP, and no explicit SDK code samples in multiple languages shown in evidence.

   • [claimed-docs] “Use collectFinancialConnectionsAccounts to launch the authentication flow from your client using the client_secret returned by your server”
   • [claimed-docs] “Financial insights for agents | - Agent-powered spending analysis - Balance and transaction monitoring | Link CLI”
   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”

   proof ↗⚑ flag

   TrueLayer✓fullclaimed7/10

   TrueLayer explicitly documents official SDKs for Node.js, Python, Java and .NET (truelayer-docs-11) that simplify API calls with typed interfaces and automate request signing (truelayer-docs-24), backed by a public GitHub signing library (truelayer-gh-1). Missing for 10: broader language coverage evidence, independent developer adoption signals (stars, community usage), and versioned changelog/release cadence proof.

   • [claimed-docs] “SDKs for Node.js, Python, Java and .NET.”
   • [claimed-docs] “They simplify API calls with easy-to-use interfaces, type-hinted methods and abstractions. They also automate request signing for all Paymen…”
   • [claimed-docs] “We offer signing libraries in these languages”
   • [github] “Convenient libraries to produce TrueLayer API requests signatures.”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to TrueLayer
   Stripe Financial Connections✓fullclaimed7/10

   Stripe Financial Connections documents specific webhook events (account linked, balance/ownership/transaction refresh completed) that any integrator, including AI-native agent backends, can subscribe to for event-driven workflows. This is standard first-party webhook documentation but lacks AI-specific framing or independent corroboration of agentic webhook consumption. Missing for 10: independent/hands-on confirmation of AI agents consuming these webhooks, and explicit agent-oriented event subscription guidance.

   • [claimed-docs] “Sent when a customer links a new account. If they link multiple accounts, it emits multiple events (one per account).”
   • [claimed-docs] “Sent after a balance refresh is complete.”
   • [claimed-docs] “Use the relink API to help your user reconnect their inactive account.”
   • [claimed-docs] “Sent after an ownership refresh is complete.”
   • [claimed-docs] “Sent after a transaction refresh is complete.”

   proof ↗⚑ flag

   TrueLayer✓fullclaimed8/10

   TrueLayer documents webhooks as JSON notifications for Payments API v3 events (e.g. payment status changes), configurable per-app via a webhook URI in Console, with signature verification (Tl-Signature) recommended via signing libraries. This gives a clear, documented subscribe-to-events-via-webhook mechanism usable programmatically by an AI-native integration. Missing for 10: no independent/hands-on corroboration of webhook reliability, and no evidence of webhook management via API (vs Console-only configuration) or filtering/subscription granularity.

   • [claimed-docs] “Webhooks are JSON-format notifications you receive when any event occurs within the Payments API v3.”
   • [claimed-docs] “webhooks inform you about: when a payment changes to a new status in the authorisation process”
   • [claimed-docs] “You must validate all incoming webhook requests through the `Tl-Signature` that accompanies the webhook.”
   • [claimed-docs] “Each of your apps in Console can have a single webhook URI, which the Payments API sends webhooks to.”
   • [claimed-docs] “We strongly recommend you use our signing libraries to verify the `Tl-Signature` of any webhooks you receive.”

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round to Stripe Financial Connections
   Stripe Financial Connections~partialprobed3/10

   Docs list 'Financial insights for agents' with 'Agent-powered spending analysis' and 'Balance and transaction monitoring' as a named use case, and Stripe's MCP server lets AI agents query account data — but these are thin, high-level mentions rather than a documented native AI-insights feature inside the Financial Connections product itself; the core product is described as raw data access (balances, transactions, ownership) for developers to build on, not an insight-generation UI. Missing for 10: concrete documentation of an actual AI-generated insights/suggestions feature, UI screenshots or workflow showing insights surfaced to end users, and independent/hands-on confirmation that agent-powered analysis works as described.

   • [claimed-docs] “Financial insights for agents | - Agent-powered spending analysis - Balance and transaction monitoring | Link CLI”
   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”
   • [claimed-docs] “Access an account’s current and available balances.”
   • [claimed-docs] “Access an account’s transaction history.”

   proof ↗⚑ flag

   TrueLayer—none0/10

   TrueLayer's evidence covers Data/Payments APIs and an MCP integration letting Claude perform banking actions on a user's behalf, but nothing shows TrueLayer itself generating AI insights or suggestions from account/transaction data inside its Console or product surface.

   ⚑ flag

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

   weight 2 · round drawn
   Stripe Financial Connections~partialclaimed5/10

   Financial Connections supports webhook events (account linked, balance/ownership/transaction refresh completed) and a relink API, which let developers build background automations that react to account/data changes without manual polling, and docs even reference an 'agent-powered spending analysis' use case. However, there's no evidence of built-in scheduling, orchestration, or agent-specific automation tooling beyond webhooks — it's infrastructure a developer must wire up themselves. Missing for 10: native scheduling/orchestration primitives, explicit AI-agent automation framework, and hands-on evidence of autonomous background agents running on this data.

   • [claimed-docs] “Sent when a customer links a new account. If they link multiple accounts, it emits multiple events (one per account).”
   • [claimed-docs] “Sent after a balance refresh is complete.”
   • [claimed-docs] “Use the relink API to help your user reconnect their inactive account.”
   • [claimed-docs] “Sent after an ownership refresh is complete.”
   • [claimed-docs] “Sent after a transaction refresh is complete.”
   • [claimed-docs] “Financial insights for agents | - Agent-powered spending analysis - Balance and transaction monitoring | Link CLI”

   proof ↗⚑ flag

   TrueLayer~partialprobed5/10

   TrueLayer supports payment mandates (VRPs/Direct Debits) that, once authorised, execute automatically in the background without further user authorisation, and webhooks provide event-driven automation; the MCP server integration also lets an AI agent (Claude) trigger banking/payment operations. However, there is no dedicated AI-native automation/scheduling framework—just mandate-based recurring payments plus generic webhooks and a single third-party MCP integration. Missing for 10: a first-party AI-agent automation/orchestration feature, evidence of persistent autonomous background agents beyond mandate execution, and broader multi-step automation tooling.

   • [claimed-docs] “Use the following steps to learn how to create a new payment mandate for your user. You'll need this mandate to set up recurring payments.”
   • [claimed-docs] “Once you create a payment on an authorised mandate, it executes immediately without requiring further user authorisation.”
   • [claimed-docs] “Payment mandates belong to one of three types: Sweeping VRPs... Wave 1 VRPs... Direct Debits”
   • [claimed-docs] “After you create a payment mandate and your user has authorised it, you can create a payment on the mandate... it executes immediately.”
   • [claimed-docs] “webhooks inform you about: when a payment changes to a new status in the authorisation process”
   • [claimed-docs] “By integrating the TrueLayer MCP server with this AI assistant, you'd empower Claude AI to perform a range of banking and payment operations…”
   • [claimed-docs] “create-truelayer-payment-link` - Generate a new payment link for initiating a payment from a bank account to the TrueLayer merchant account”
   • [probe] “official MCP server documented at https://docs.truelayer.com/docs/truelayer-mcp-integration-for-claude-ai”

   proof ↗⚑ flag

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

   weight 2 · round to TrueLayer
   Stripe Financial Connections~partialprobed4/10

   Stripe's docs mention an 'agent-powered spending analysis' use case for Financial Connections and Stripe's general MCP server lets AI agents call the Stripe API, implying some natural-language operability, but there's no detailed documentation of specific natural-language commands or agent workflows scoped to Financial Connections itself. Missing for 10: concrete examples of NL commands/agent interactions specific to Financial Connections, independent/hands-on validation that agents can operate this product conversationally, and clarity on how much of the flow (bank auth, consent) can be agent-driven vs. requiring a human UI step.

   • [claimed-docs] “Financial insights for agents | - Agent-powered spending analysis - Balance and transaction monitoring | Link CLI”
   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   proof ↗⚑ flag

   TrueLayer~partialprobed6/10

   TrueLayer documents an official MCP server integration with Claude AI that lets users invoke banking/payment operations (e.g., 'create-truelayer-payment-link') via natural language, directly enabling AI-native NL command usage. However, evidence only shows one example tool and a single AI assistant integration rather than a broad natural-language command surface across the full API. Missing for 10: evidence of broader NL command coverage across accounts/verification/mandates, independent hands-on confirmation of the MCP server's reliability, and support beyond Claude AI.

   • [claimed-docs] “By integrating the TrueLayer MCP server with this AI assistant, you'd empower Claude AI to perform a range of banking and payment operations…”
   • [claimed-docs] “create-truelayer-payment-link` - Generate a new payment link for initiating a payment from a bank account to the TrueLayer merchant account”
   • [probe] “official MCP server documented at https://docs.truelayer.com/docs/truelayer-mcp-integration-for-claude-ai”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   Stripe Financial Connections—none0/10

   The evidence pack shows only text-based documentation pages (feature descriptions, webhooks list, testing docs) and confirms no OpenAPI spec was found at any candidate path (probe-3: all 404). There is no mention of an interactive API reference, live code runner, or runnable examples for Financial Connections specifically.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”
   • [claimed-docs] “Access an account’s current and available balances.”

   proof ↗⚑ flag

   TrueLayer—none0/10

   The evidence pack contains only static documentation descriptions (guides, webhook references, SDK mentions) with no mention of an interactive API reference or runnable code examples/try-it-out console. A direct probe for OpenAPI/Swagger specs at standard paths returned 404 across all candidates, indicating no discoverable interactive API explorer.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.truelayer.com/openapi.json, https://docs.truelayer.com/swagger.json, https://docs.truel…”
   • [claimed-docs] “SDKs for Node.js, Python, Java and .NET.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.truelayer.com/llms.txt # TrueLayer Documentation > TrueLayer Documentation Append .md to any docu…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Stripe Financial Connections—none0/10

   A direct probe for OpenAPI/swagger specs at expected doc paths returned 404 for all candidates, and no other evidence in the pack shows a downloadable machine-readable API spec for Financial Connections; only markdown docs (.md) and llms.txt are available, which are not an OpenAPI-equivalent spec.

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

   proof ↗⚑ flag

   TrueLayer—none0/10

   A direct probe for OpenAPI/Swagger spec files at common paths (openapi.json, swagger.json, etc.) returned 404 across the board, and no documentation item references a downloadable machine-readable API spec despite extensive API docs.

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

   proof ↗⚑ flag

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

   weight 1 · round to Stripe Financial Connections
   Stripe Financial Connections✓fullclaimed7/10

   Stripe documents a dedicated testing mode where the authentication flow shows only Stripe-managed test institutions and accounts can be linked without real credentials, explicitly separating sandbox testing from production data access. Missing for 10: no explicit mention of a fully isolated test API key/environment guarantee for financial data, no independent hands-on confirmation of sandbox fidelity, and no detail on how test data maps to production behavior.

   • [claimed-docs] “the authentication flow exclusively shows a selection of test institutions managed by Stripe. The client can link accounts from any of these…”
   • [claimed-docs] “The client can link accounts from any of these institutions without providing credentials.”

   proof ↗⚑ flag

   TrueLayer~partialprobed5/10

   TrueLayer provides a free test/sandbox merchant account for making test payments (truelayer-docs-32, quickstart-make-a-test-payment), which lets a developer or AI agent exercise the Payments API without touching production data. However, there is no explicit documentation of a dedicated sandbox environment concept (separate sandbox base URLs, sandbox-specific credentials, or sandbox banks/test providers) distinct from a 'free account' used for a first test payment, and no confirmation the MCP integration itself can be pointed at a sandbox. Missing for 10: explicit sandbox environment documentation (test-mode endpoints, mock bank providers), confirmation that the MCP server/agent tooling can target sandbox vs production, and independent/hands-on verification of sandbox isolation.

   • [claimed-docs] “you'll create a free UK merchant account and complete your first test payment with the Payments API v3”
   • [claimed-docs] “By integrating the TrueLayer MCP server with this AI assistant, you'd empower Claude AI to perform a range of banking and payment operations…”
   • [probe] “official MCP server documented at https://docs.truelayer.com/docs/truelayer-mcp-integration-for-claude-ai”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Stripe Financial Connections—none0/10

   No evidence pack items reference API versioning, version headers, or a documented deprecation policy for Stripe Financial Connections; only feature descriptions, webhooks, and community sentiment are present.

   ⚑ flag

   TrueLayer—none0/10

   Evidence confirms TrueLayer exposes a versioned API (Payments API v3) but nowhere documents a deprecation policy, versioning changelog, or sunset schedule for older API versions. Missing for 10: any versioning/deprecation policy page, changelog, migration guide, or sunset timeline evidence.

   • [claimed-docs] “The Payments API v3 allows you to make and accept payments and payouts in the UK and EU.”
   • [claimed-docs] “The Payments API v3 uses a pair of ECDSA keys in addition to a bearer token.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.truelayer.com/openapi.json, https://docs.truelayer.com/swagger.json, https://docs.truel…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Stripe Financial Connections—none0/10

   No evidence of bulk/batch operations (e.g., batch account linking, bulk transaction pulls, multi-item API calls) for AI-native automation; the closest evidence is a webhook that emits one event per linked account, which is not a bulk-operation capability.

   • [claimed-docs] “Sent when a customer links a new account. If they link multiple accounts, it emits multiple events (one per account).”

   proof ↗⚑ flag

   TrueLayer—none0/10

   The evidence pack covers single-payment, single-payout, and single-mandate creation flows, webhooks, and MCP tool for one-off payment links, but no documentation of any batch/bulk endpoint for processing many payments, payouts, or accounts in one call. Missing for 10: batch payment/payout creation endpoints, bulk data export or bulk verification APIs, any documented rate/volume-oriented bulk operation.

   • [claimed-docs] “The Payments API v3 allows you to make and accept payments and payouts in the UK and EU.”
   • [claimed-docs] “Send payments to bank accounts. Covers the API, beneficiary management and reconciliation.”
   • [claimed-docs] “Send payouts to bank accounts that have been verified against a user's identity.”
   • [claimed-docs] “Use the following steps to learn how to create a new payment mandate for your user. You'll need this mandate to set up recurring payments.”
   • [claimed-docs] “create-truelayer-payment-link` - Generate a new payment link for initiating a payment from a bank account to the TrueLayer merchant account”

   proof ↗⚑ flag

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

   weight 3 · round to TrueLayer
   Stripe Financial Connections—none0/10

   Financial Connections offers webhooks for events (account linked, balance refresh, etc.) but there is no evidence of a rules engine or automation layer where users can define conditional rules that trigger actions on those events—developers would need to build that logic themselves outside the product. missing for 10: rule-definition interface, conditional trigger-action mapping, any built-in automation/workflow engine.

   • [claimed-docs] “Sent when a customer links a new account. If they link multiple accounts, it emits multiple events (one per account).”
   • [claimed-docs] “Sent after a balance refresh is complete.”
   • [claimed-docs] “Sent after an ownership refresh is complete.”
   • [claimed-docs] “Sent after a transaction refresh is complete.”

   proof ↗⚑ flag

   TrueLayer~partialclaimed4/10

   TrueLayer provides webhooks that notify external systems on payment status events, and payment mandates that execute automatically once authorised (e.g. VRPs, Direct Debits), giving building blocks for event-driven automation. However, there is no evidence of a native rules-engine or condition/action configuration UI where a user defines arbitrary 'if event X then do Y' automations within TrueLayer itself — the actual rule logic must be built by the developer's own system consuming the webhook. Missing for 10: a documented rules/automation engine, in-product trigger-action configuration, and any first-party or independent example of user-defined automation rules beyond webhooks and fixed mandate execution.

   • [claimed-docs] “Webhooks are JSON-format notifications you receive when any event occurs within the Payments API v3.”
   • [claimed-docs] “webhooks inform you about: when a payment changes to a new status in the authorisation process”
   • [claimed-docs] “Use the following steps to learn how to create a new payment mandate for your user. You'll need this mandate to set up recurring payments.”
   • [claimed-docs] “Once you create a payment on an authorised mandate, it executes immediately without requiring further user authorisation.”
   • [claimed-docs] “Payment mandates belong to one of three types: Sweeping VRPs... Wave 1 VRPs... Direct Debits”
   • [claimed-docs] “Each of your apps in Console can have a single webhook URI, which the Payments API sends webhooks to.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to TrueLayer
   Stripe Financial Connections—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

   TrueLayer~partialclaimed5/10

   TrueLayer supports payment mandates (VRPs) that, once authorised, let a payment execute automatically and repeatedly without further user authorisation — a domain-specific form of recurring workflow (docs-15, docs-16, docs-30, docs-31). However there is no evidence of a general-purpose scheduler, cron-like triggers, or workflow orchestration beyond recurring payments themselves. missing for 10: general job/workflow scheduling primitives, evidence of scheduling cadence configuration (daily/weekly/custom), and any non-payment automation use case.

   • [claimed-docs] “Use the following steps to learn how to create a new payment mandate for your user. You'll need this mandate to set up recurring payments.”
   • [claimed-docs] “Once you create a payment on an authorised mandate, it executes immediately without requiring further user authorisation.”
   • [claimed-docs] “Payment mandates belong to one of three types: Sweeping VRPs... Wave 1 VRPs... Direct Debits”
   • [claimed-docs] “After you create a payment mandate and your user has authorised it, you can create a payment on the mandate... it executes immediately.”

   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 Stripe Financial Connections
   Stripe Financial Connections✓fullcommunity8/10

   Docs explicitly describe an 'instant' verification flow with 'no manual entry and microdeposit fallback' for ACH Direct Debit, collecting bank account + ownership/balance data in one integration, eliminating the need for users to locate account/routing numbers, and a real-world adopter (comm-6) confirms using it for instant account verification and ACH fraud signaling in production, replacing Plaid Auth. Missing for 10: explicit technical detail on the exact token/PaymentMethod format returned to the server and any independent benchmarking of ACH failure-rate reduction beyond Stripe's own claims.

   • [claimed-docs] “instant | Financial Connections only, with no manual entry and microdeposit fallback”
   • [claimed-docs] “Reduce your payment failure rate from closed or inactive accounts - Improve payments conversion by keeping users on session, instead of forc…”
   • [claimed-docs] “Collect a bank account for ACH Direct Debit payments while using account data, including balances.”
   • [claimed-docs] “Save development time by eliminating the need to create a custom bank account collection form”
   • [community] “I work at one of the companies that integrated Financial Connections during its beta, moving from Plaid Auth. We use the link to bank accoun…”

   proof ↗⚑ flag

   TrueLayer—none0/10

   TrueLayer's documented Payments/Verification/Data APIs operate on UK/EU account identifiers (sort code/account number, IBAN, Direct Debit, Faster Payments, VRPs) and provide identity/name verification, not US-style ACH funding via account/routing numbers or tokenized ACH equivalents. No evidence pack item references ACH, routing numbers, or micro-deposit-free bank-debit tokenization.

   • [claimed-docs] “Verify that a bank account belongs to a given user.”
   • [claimed-docs] “Send payouts to bank accounts that have been verified against a user's identity.”
   • [claimed-docs] “We compare the identity data to the account holder's name for all the connected account(s) the user has given consent for.”
   • [claimed-docs] “Payment mandates belong to one of three types: Sweeping VRPs... Wave 1 VRPs... Direct Debits”
   • [claimed-docs] “Store bank account details for future payment initiation. Covers setup, consent and reuse.”

   proof ↗⚑ flag

Balances

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

   weight 3 · round to Stripe Financial Connections
   Stripe Financial Connections✓fullcommunity7/10

   Docs explicitly state Financial Connections lets you 'Access an account's current and available balances' and 'reduce underwriting risk with balances data', with a dedicated balance-refresh webhook event, and community evidence confirms real customers use the linked-account data as a fraud/risk signal before ACH debits. This matches the NSF/risk-check use case described in the story. missing for 10: explicit API reference/endpoint schema for the balance object, and confirmation of real-time (vs refresh-triggered) latency guarantees.

   • [claimed-docs] “Access an account’s current and available balances.”
   • [claimed-docs] “Collect a bank account for ACH Direct Debit payments while using account data, including balances.”
   • [claimed-docs] “Sent after a balance refresh is complete.”
   • [claimed-docs] “reduce underwriting risk with balances data”
   • [community] “I work at one of the companies that integrated Financial Connections during its beta, moving from Plaid Auth. We use the link to bank accoun…”

   proof ↗⚑ flag

   TrueLayer~partialclaimed5/10

   TrueLayer's Data API documents reading account balances (truelayer-docs-5, truelayer-docs-28), which could be used before initiating a payment, but there is no documented endpoint or guidance explicitly framed as a pre-payment real-time balance/NSF or risk check tied to the Payments API flow. missing for 10: explicit documentation of a balance-check step integrated into the payment initiation flow, real-time/NSF-specific balance endpoint framing, and independent confirmation of this workflow.

   • [claimed-docs] “Read account information, balances and transaction history from a user's bank.”
   • [claimed-docs] “Access identity, accounts, transactions and balance data for all integrated banks with a single interface.”
   • [claimed-docs] “The Payments API v3 allows you to make and accept payments and payouts in the UK and EU.”

   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 Stripe Financial Connections
   Stripe Financial Connections✓fullcommunity8/10

   Docs explicitly state you can 'Access account owners' names and mailing addresses' and 'mitigate fraud by verifying account ownership details,' plus an ownership-refresh webhook event confirms this data can be kept current for ownership matching. Community evidence corroborates real-world use as a fraud/ownership signal for ACH payments. Missing for 10: explicit documentation of contact/phone/email fields beyond name+address, and independent hands-on verification of the exact data schema returned.

   • [claimed-docs] “Access account owners’ names and mailing addresses.”
   • [claimed-docs] “mitigate fraud by verifying account ownership details”
   • [claimed-docs] “Sent after an ownership refresh is complete.”
   • [community] “I work at one of the companies that integrated Financial Connections during its beta, moving from Plaid Auth. We use the link to bank accoun…”

   proof ↗⚑ flag

   TrueLayer~partialclaimed5/10

   TrueLayer's Data API exposes 'identity' data alongside accounts/transactions/balances, and its Verification API explicitly compares identity data (name) against connected account holders — supporting name-based ownership matching. However, the evidence never confirms retrieval of addresses or contact details on file at the bank, only name matching. Missing for 10: explicit documentation of address/contact fields returned by the identity endpoint, and any hands-on confirmation of full account-holder profile retrieval.

   • [claimed-docs] “Access identity, accounts, transactions and balance data for all integrated banks with a single interface.”
   • [claimed-docs] “We compare the identity data to the account holder's name for all the connected account(s) the user has given consent for.”

   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 Stripe Financial Connections
   Stripe Financial Connections✓fullcommunity8/10

   Stripe's docs describe explicit, well-documented integrations where Financial Connections hands verified bank-account data (balances, ownership, transactions) to other Stripe payment products—ACH Direct Debit collection, Connect payouts, and underwriting/fraud tooling—via a documented client_secret/token exchange flow and webhooks, and a Hacker News commenter confirms real-world production use for ACH verification and fraud signals alongside other Stripe products. missing for 10: evidence of handoff to non-Stripe third-party processors/platforms specifically, and independent security review of the credential-exchange mechanism.

   • [claimed-docs] “Use collectFinancialConnectionsAccounts to launch the authentication flow from your client using the client_secret returned by your server”
   • [claimed-docs] “Collect a bank account for ACH Direct Debit payments while using account data, including balances.”
   • [claimed-docs] “Collect a bank account to use for Connect payouts, and use account data, such as ownership details, with your integration.”
   • [claimed-docs] “instant | Financial Connections only, with no manual entry and microdeposit fallback”
   • [claimed-docs] “Sent when a customer links a new account. If they link multiple accounts, it emits multiple events (one per account).”
   • [community] “I work at one of the companies that integrated Financial Connections during its beta, moving from Plaid Auth. We use the link to bank accoun…”

   proof ↗⚑ flag

   TrueLayer~partialclaimed6/10

   TrueLayer documents Data API/Verification API flows that verify account ownership and identity, plus Payments API mechanisms (mandates, webhooks, signed requests) that let merchants/platforms initiate verified payments to bank accounts — this covers the core 'linked accounts feed a payment processor' story. However, evidence is entirely first-party docs describing TrueLayer's own APIs as the processor, not clear documentation of handing verified credentials to a distinct third-party processor/platform via token exchange. missing for 10: independent/hands-on confirmation, explicit third-party processor handoff or OAuth token exchange spec, and real-world integration case studies beyond marketing snippets.

   • [claimed-docs] “Verify that a bank account belongs to a given user.”
   • [claimed-docs] “Read account information, balances and transaction history from a user's bank.”
   • [claimed-docs] “Store bank account details for future payment initiation. Covers setup, consent and reuse.”
   • [claimed-docs] “Send payouts to bank accounts that have been verified against a user's identity.”
   • [claimed-docs] “Access identity, accounts, transactions and balance data for all integrated banks with a single interface.”
   • [claimed-docs] “We compare the identity data to the account holder's name for all the connected account(s) the user has given consent for.”
   • [claimed-docs] “Use the following steps to learn how to create a new payment mandate for your user. You'll need this mandate to set up recurring payments.”
   • [claimed-docs] “After you create a payment mandate and your user has authorised it, you can create a payment on the mandate... it executes immediately.”
   • [claimed-docs] “Use TrueLayer for payments in your webshop with our plugins for WooCommerce, Shopify and Magento.”

   proof ↗⚑ flag

Agent data

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

   weight 2 · round to TrueLayer
   Stripe Financial Connections~partialprobed6/10

   Stripe's docs show structured API objects for balances, ownership, and transactions plus typed webhook events (docs-2,3,4,12-14,24,25), and even a dedicated 'Financial insights for agents' use-case section citing agent-powered spending analysis and balance/transaction monitoring (docs-11), supporting agent-consumable data. However, no OpenAPI/schema file could be found (probe-3 shows all openapi.json paths 404), and there's no independent/hands-on evidence confirming an agent can parse this data without additional tooling. Missing for 10: published OpenAPI/JSON schema docs, and independent corroboration of agent-consumability beyond Stripe's own docs.

   • [claimed-docs] “Access an account’s current and available balances.”
   • [claimed-docs] “Access account owners’ names and mailing addresses.”
   • [claimed-docs] “Access an account’s transaction history.”
   • [claimed-docs] “Financial insights for agents | - Agent-powered spending analysis - Balance and transaction monitoring | Link CLI”
   • [claimed-docs] “Sent when a customer links a new account. If they link multiple accounts, it emits multiple events (one per account).”
   • [claimed-docs] “Sent after a balance refresh is complete.”
   • [claimed-docs] “Sent after an ownership refresh is complete.”
   • [claimed-docs] “Sent after a transaction refresh is complete.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”

   proof ↗⚑ flag

   TrueLayer~partialprobed7/10

   TrueLayer's Data API returns structured JSON (identity, accounts, transactions, balances) with a dedicated MCP server letting an AI assistant like Claude perform banking operations directly, and typed SDKs abstract the raw API surface — all strong signals of agent-consumable design. However, a probe found no discoverable OpenAPI/JSON schema (all candidate schema paths 404'd), and no evidence describes transaction enrichment (categorization, merchant normalization) that would let an agent reason without heuristic parsing. Missing for 10: published machine-readable schema/OpenAPI spec, documented data enrichment/categorization features, independent corroboration of agent consumption in practice.

   • [claimed-docs] “Access identity, accounts, transactions and balance data for all integrated banks with a single interface.”
   • [claimed-docs] “Webhooks are JSON-format notifications you receive when any event occurs within the Payments API v3.”
   • [claimed-docs] “SDKs for Node.js, Python, Java and .NET.”
   • [claimed-docs] “They simplify API calls with easy-to-use interfaces, type-hinted methods and abstractions. They also automate request signing for all Paymen…”
   • [claimed-docs] “By integrating the TrueLayer MCP server with this AI assistant, you'd empower Claude AI to perform a range of banking and payment operations…”
   • [claimed-docs] “create-truelayer-payment-link` - Generate a new payment link for initiating a payment from a bank account to the TrueLayer merchant account”
   • [probe] “official MCP server documented at https://docs.truelayer.com/docs/truelayer-mcp-integration-for-claude-ai”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.truelayer.com/openapi.json, https://docs.truelayer.com/swagger.json, https://docs.truel…”

   proof ↗⚑ flag

Agent operations

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

   weight 3 · round drawn
   Stripe Financial Connections~partialprobed6/10

   Financial Connections' API clearly supports creating link sessions, retrieving balances/transactions, and managing connections (docs-2,3,4,5,6,14), and Stripe publishes both a generic MCP server for AI agents to interact with the Stripe API (docs-18, probe-4) and an explicit 'Financial insights for agents' use case mentioning agent-powered spending analysis and balance/transaction monitoring (docs-11). However, no evidence specifies that the MCP surface exposes Financial-Connections-specific tools (e.g., create_link_session, get_balances) or how scoped/restricted credentials are issued for agent use. missing for 10: explicit MCP tool list for Financial Connections actions, documentation of scoped-credential/permission model for agent access, independent confirmation of agent operation end-to-end.

   • [claimed-docs] “Access an account’s current and available balances.”
   • [claimed-docs] “Access an account’s transaction history.”
   • [claimed-docs] “Use collectFinancialConnectionsAccounts to launch the authentication flow from your client using the client_secret returned by your server”
   • [claimed-docs] “Financial insights for agents | - Agent-powered spending analysis - Balance and transaction monitoring | Link CLI”
   • [claimed-docs] “Use the relink API to help your user reconnect their inactive account.”
   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   proof ↗⚑ flag

   TrueLayer~partialprobed6/10

   TrueLayer ships an official MCP server for Claude AI (truelayer-docs-17, probe-3) with at least a documented `create-truelayer-payment-link` tool (truelayer-docs-27), and its APIs separately support account/balance/transaction retrieval (truelayer-docs-5, truelayer-docs-28) and connection management with scoped client credentials and ECDSA-signed requests (truelayer-docs-12, truelayer-docs-21). However, the MCP surface itself is only shown to expose link-session creation, not balance/transaction retrieval or connection management as MCP tools. Missing for 10: explicit MCP tools/endpoints for balance/transaction retrieval and connection management, and documentation of MCP-specific scoped credentials rather than general API auth.

   • [claimed-docs] “By integrating the TrueLayer MCP server with this AI assistant, you'd empower Claude AI to perform a range of banking and payment operations…”
   • [claimed-docs] “create-truelayer-payment-link` - Generate a new payment link for initiating a payment from a bank account to the TrueLayer merchant account”
   • [claimed-docs] “Read account information, balances and transaction history from a user's bank.”
   • [claimed-docs] “Access identity, accounts, transactions and balance data for all integrated banks with a single interface.”
   • [claimed-docs] “The Payments API v3 uses a pair of ECDSA keys in addition to a bearer token.”
   • [claimed-docs] “Invite users so they can retrieve your integration's client credentials, access the payments view, or issue refunds.”
   • [probe] “official MCP server documented at https://docs.truelayer.com/docs/truelayer-mcp-integration-for-claude-ai”

   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
   Stripe Financial Connections—none0/10

   No evidence describes an end-user-facing consent dashboard or portal where users can view/revoke which apps hold access to their linked bank data; documentation only covers merchant-side integration flows (linking, webhooks, relink API) and business-side account/balance/transaction access controls. This is a fair axis for a financial data aggregation product (competitors offer such portals), but Stripe's evidence pack contains no mention of a user-facing consent management surface.

   • [claimed-docs] “Use collectFinancialConnectionsAccounts to launch the authentication flow from your client using the client_secret returned by your server”
   • [claimed-docs] “Sent when a customer links a new account. If they link multiple accounts, it emits multiple events (one per account).”
   • [claimed-docs] “Use the relink API to help your user reconnect their inactive account.”
   • [claimed-docs] “allowing them to save and reuse their bank account details across Stripe businesses”

   proof ↗⚑ flag

   TrueLayer—none0/10

   No evidence of an end-user-facing consent dashboard or portal for viewing/revoking bank data access; documentation only covers developer-side consent creation (mandates, verification consent) and admin Console user management, not an end-user self-service revocation surface.

   ⚑ 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
   Stripe Financial Connections—none0/10

   No evidence pack item documents a disconnect/delete-account API, data deletion/purge process, or account termination workflow for Financial Connections; the docs focus on connecting, collecting, and refreshing account data, not severing/purging it. Missing for 10: documented disconnect/delete API or account endpoint, data retention/purge policy, and any confirmation that collection stops and data is deleted upon disconnection.

   • [claimed-docs] “Sent when a customer links a new account. If they link multiple accounts, it emits multiple events (one per account).”
   • [claimed-docs] “Use the relink API to help your user reconnect their inactive account.”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/financial-connections.md # Stripe Financial Connections Access permissioned data from yo…”

   proof ↗⚑ flag

   TrueLayer—none0/10

   No evidence pack item documents a way to delete a connection/user, revoke consent, stop data collection, or purge held data; documentation covers payments, mandates, webhooks, and MCP integration but nothing about consent revocation or data deletion/erasure workflows.

   ⚑ 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 Stripe Financial Connections
   Stripe Financial Connections~partialclaimed6/10

   Docs show Financial Connections lets you request specific data types (balances, ownership, transactions) rather than a single blanket account link, and different use-case flows (ACH, Connect payouts, personal finance apps) pull only the subset of data relevant to that use case, implying product-scoped consent. However, there's no explicit documentation of a formal 'permissions' parameter/API, no description of the actual consent screen showing scoped checkboxes, and no independent/community evidence confirming data-minimization behavior in practice. Missing for 10: explicit permissions/scopes API reference, documented consent UI mechanics, and independent verification that only requested scopes are granted.

   • [claimed-docs] “Access an account’s current and available balances.”
   • [claimed-docs] “Access account owners’ names and mailing addresses.”
   • [claimed-docs] “Access an account’s transaction history.”
   • [claimed-docs] “Collect a bank account for ACH Direct Debit payments while using account data, including balances.”
   • [claimed-docs] “Collect a bank account to use for Connect payouts, and use account data, such as ownership details, with your integration.”
   • [claimed-docs] “Collect user accounts and gain access to account data to build more complex integrations, such as personal finance apps.”

   proof ↗⚑ flag

   TrueLayer~partialclaimed5/10

   TrueLayer offers distinct product APIs (Payments, Data/Account Info, Verification, Payouts) that developers can integrate separately, implying some scoping by product, and Data API notes consent is tied to specific connected accounts a user has approved. However there is no explicit documentation of granular, developer-selectable OAuth scopes or a consent screen showing minimized data requests per call. missing for 10: explicit scope/permission parameters documented in API reference, evidence of a consent UI showing selectable data categories, and independent confirmation that unused scopes aren't granted by default.

   • [claimed-docs] “Access identity, accounts, transactions and balance data for all integrated banks with a single interface.”
   • [claimed-docs] “We compare the identity data to the account holder's name for all the connected account(s) the user has given consent for.”
   • [claimed-docs] “Read account information, balances and transaction history from a user's bank.”
   • [claimed-docs] “The Payments API v3 allows you to make and accept payments and payouts in the UK and EU.”
   • [claimed-docs] “Send payouts to bank accounts that have been verified against a user's identity.”

   proof ↗⚑ flag

Refresh

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

   weight 2 · round to Stripe Financial Connections
   Stripe Financial Connections~partialcommunity5/10

   Docs mention webhook events fired after a balance, ownership, and transaction 'refresh' is complete (docs-13, docs-24, docs-25), implying an underlying refresh mechanism exists, but the evidence pack never documents the actual API call/endpoint to trigger an on-demand refresh or its semantics (rate limits, latency, cost). A community report even suggests refresh is limited to daily pulls rather than freely on-demand, indicating real constraints on freshness. Missing for 10: explicit API reference for a refresh endpoint, documented refresh-trigger semantics (frequency limits, sync latency), and confirmation this applies across balance/ownership/transaction data uniformly.

   • [claimed-docs] “Sent after a balance refresh is complete.”
   • [claimed-docs] “Sent after an ownership refresh is complete.”
   • [claimed-docs] “Sent after a transaction refresh is complete.”
   • [community] “The limit to only daily pulls and up to 180 days of historical data is pretty disappointing. Would expect Stripe to push the envelope here..…”

   proof ↗⚑ flag

   TrueLayer—none0/10

   The evidence pack documents TrueLayer's Data API for reading account info, balances, and transactions, but contains no mention of an explicit on-demand refresh endpoint or documented refresh semantics (e.g., cache TTLs, force-refresh parameters, or freshness guarantees). This is a fair axis for an open banking data API, but no supporting evidence exists.

   • [claimed-docs] “Read account information, balances and transaction history from a user's bank.”
   • [claimed-docs] “Access identity, accounts, transactions and balance data for all integrated banks with a single interface.”

   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 to Stripe Financial Connections
   Stripe Financial Connections~partialclaimed6/10

   Docs confirm signed webhook events for account linking, balance refresh, ownership refresh, and transaction refresh, directly enabling event-driven freshness instead of polling. However, evidence lacks detail on signature verification specifics, latency/timeliness guarantees, connection state-change events beyond relink, and independent/hands-on confirmation of webhook reliability. missing for 10: signature verification documentation detail, guaranteed latency/freshness SLAs, broader connection-state-change event coverage, independent developer corroboration of webhook reliability.

   • [claimed-docs] “Sent when a customer links a new account. If they link multiple accounts, it emits multiple events (one per account).”
   • [claimed-docs] “Sent after a balance refresh is complete.”
   • [claimed-docs] “Sent after an ownership refresh is complete.”
   • [claimed-docs] “Sent after a transaction refresh is complete.”
   • [claimed-docs] “Use the relink API to help your user reconnect their inactive account.”

   proof ↗⚑ flag

   TrueLayer~partialclaimed5/10

   TrueLayer documents signed webhooks (Tl-Signature validation) for the Payments API, notifying about payment status changes during authorisation — this covers signed delivery and payment state changes, but the evidence never shows webhooks for the Data API events explicitly named in the story (new transactions, balance updates, connection/consent state changes). Missing for 10: documented webhook events for transaction/balance/connection state changes on the Data/Accounts side, and any confirmation these are pushed rather than requiring polling of the Data API.

   • [claimed-docs] “We strongly recommend you use our signing libraries to verify the `Tl-Signature` of any webhooks you receive.”
   • [claimed-docs] “Webhooks are JSON-format notifications you receive when any event occurs within the Payments API v3.”
   • [claimed-docs] “webhooks inform you about: when a payment changes to a new status in the authorisation process”
   • [claimed-docs] “You must validate all incoming webhook requests through the `Tl-Signature` that accompanies the webhook.”
   • [claimed-docs] “Each of your apps in Console can have a single webhook URI, which the Payments API sends webhooks to.”
   • [claimed-docs] “Access identity, accounts, transactions and balance data for all integrated banks with a single interface.”

   proof ↗⚑ flag

Coverage

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

   weight 3 · round to TrueLayer
   Stripe Financial Connections~partialcommunity4/10

   Stripe's docs publish a single coverage figure ("more than 12,000 supported banks") but no official breakdown of geographies or country-level coverage; the only geography signal comes from community reports that the product is US-only (and doesn't work for Canada or other countries), which isn't corroborated by first-party documentation. Missing for 10: official geographic coverage documentation, per-country institution counts, and any first-party statement matching the community's US-only observation.

   • [claimed-docs] “Users select their bank from frequently chosen institutions or by searching more than 12,000 supported banks.”
   • [community] “Curious that they translated it to German based on my phone settings for a product that only supports US banks? (I don't mind that it is US …”
   • [community] “Only available in the US.”
   • [community] “guessing this doesn't work with Canada”

   proof ↗⚑ flag

   TrueLayer~partialclaimed5/10

   Docs state payments coverage spans UK and EU and provide a providers endpoint to query which banks are supported per country/segment, giving founders a way to check coverage against their user base. However, there's no published aggregate coverage numbers (e.g., total institutions reached) or a static geography breakdown document — only an API-based lookup. Missing for 10: published institution-count statistics, a documented list/table of supported countries and bank counts, and independent verification of coverage claims.

   • [claimed-docs] “The Payments API v3 allows you to make and accept payments and payouts in the UK and EU.”
   • [claimed-docs] “Query the providers endpoint to see which banks are supported in each European country and segment.”

   proof ↗⚑ flag

Status

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

   weight 2 · round to Stripe Financial Connections
   Stripe Financial Connections~partialclaimed3/10

   Docs show webhook events for refresh completions (balance, ownership, transaction) and a relink API for inactive accounts, which provide some signal that an account/connection has degraded, but there is no documented institution status page, no outage/degradation signal feed, and no error-code taxonomy that distinguishes a bank-side problem from an integration-side problem. Missing for 10: institution health/status dashboard, explicit outage signals, and documented error codes separating bank vs. merchant-side failures.

   • [claimed-docs] “Sent after a balance refresh is complete.”
   • [claimed-docs] “Use the relink API to help your user reconnect their inactive account.”
   • [claimed-docs] “Sent after an ownership refresh is complete.”
   • [claimed-docs] “Sent after a transaction refresh is complete.”

   proof ↗⚑ flag

   TrueLayer—none0/10

   Evidence shows a providers endpoint for bank coverage/support by country (truelayer-docs-10) and generic webhook status events (truelayer-docs-33), but nothing documents per-institution health status, outage/degradation signals, or error codes that distinguish a bank-side failure from an integration-side one — missing for 10: institution status page/API, outage/degradation indicators, and error taxonomy separating bank vs merchant faults.

   • [claimed-docs] “Query the providers endpoint to see which banks are supported in each European country and segment.”
   • [claimed-docs] “webhooks inform you about: when a payment changes to a new status in the authorisation process”

   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 Stripe Financial Connections
   Stripe Financial Connections✓fullcommunity8/10

   Docs confirm one Financial Connections session/client_secret lets a user link an account and expose auth, balances, ownership/identity, and transactions data together (docs-1, docs-8/9/10, docs-2/3/4), and a community integrator confirms using the same link for verification, ACH fraud signal, and adjacent Stripe products (comm-6). missing for 10: no explicit first-party statement that all four data products are requested/returned in a single session without re-prompting the user, and one community report notes transactions/other data products were 'coming soon' at beta (comm-8), leaving some ambiguity about full simultaneous availability.

   • [claimed-docs] “You can use one integration to instantly verify bank accounts for ACH payments, reduce underwriting risk with balances data, mitigate fraud …”
   • [claimed-docs] “Access an account’s current and available balances.”
   • [claimed-docs] “Access account owners’ names and mailing addresses.”
   • [claimed-docs] “Access an account’s transaction history.”
   • [claimed-docs] “Collect a bank account for ACH Direct Debit payments while using account data, including balances.”
   • [claimed-docs] “Collect a bank account to use for Connect payouts, and use account data, such as ownership details, with your integration.”
   • [claimed-docs] “Collect user accounts and gain access to account data to build more complex integrations, such as personal finance apps.”
   • [community] “I work at one of the companies that integrated Financial Connections during its beta, moving from Plaid Auth. We use the link to bank accoun…”
   • [community] “By clicking 'Start Now', I try to visit dashboard.stripe.com/financial-connections/application and it redirects to the test dashboard. A lot…”

   proof ↗⚑ flag

   TrueLayer✓fullclaimed7/10

   TrueLayer's Data API docs describe a single interface that covers identity, accounts, transactions and balance data across all integrated banks, implying one connection can serve multiple data products rather than separate flows per product ([truelayer-docs-28], [truelayer-docs-5]). Missing for 10: explicit description of the underlying consent/session mechanics (e.g., how one auth link's token scopes map to multiple product calls without re-prompting the user) and independent/hands-on confirmation that no re-authentication is required per product.

   • [claimed-docs] “Access identity, accounts, transactions and balance data for all integrated banks with a single interface.”
   • [claimed-docs] “Read account information, balances and transaction history from a user's bank.”
   • [claimed-docs] “Verify that a bank account belongs to a given user.”
   • [claimed-docs] “We compare the identity data to the account holder's name for all the connected account(s) the user has given consent for.”

   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 TrueLayer
   Stripe Financial Connections~partialprobed6/10

   Docs show a testable sandbox flow (test institutions requiring no real credentials, client_secret-based auth via collectFinancialConnectionsAccounts) and an official CLI, indicating a runnable quickstart path to a first linked sandbox account. However, the pack lacks explicit evidence of self-serve API key issuance or language-specific client library listings for Financial Connections. missing for 10: explicit self-serve API key/dashboard signup evidence, explicit client library/SDK language coverage, and independent hands-on confirmation of quickstart speed.

   • [claimed-docs] “the authentication flow exclusively shows a selection of test institutions managed by Stripe. The client can link accounts from any of these…”
   • [claimed-docs] “Use collectFinancialConnectionsAccounts to launch the authentication flow from your client using the client_secret returned by your server”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”
   • [community] “By clicking 'Start Now', I try to visit dashboard.stripe.com/financial-connections/application and it redirects to the test dashboard. A lot…”

   proof ↗⚑ flag

   TrueLayer✓fullclaimed7/10

   TrueLayer docs describe a self-serve quickstart that creates a free UK merchant account and completes a first test payment, plus SDKs for Node.js, Python, Java and .NET and dedicated signing libraries to speed integration. This directly matches the signup-to-first-linked-sandbox-account story, though all evidence is first-party docs with no independent/hands-on corroboration of actual time-to-first-success. Missing for 10: independent developer reports confirming ease/speed of the flow, explicit sandbox-environment terminology (vs 'test payment'), and confirmation that API key generation itself is fully self-serve without sales contact.

   • [claimed-docs] “you'll create a free UK merchant account and complete your first test payment with the Payments API v3”
   • [claimed-docs] “SDKs for Node.js, Python, Java and .NET.”
   • [claimed-docs] “They simplify API calls with easy-to-use interfaces, type-hinted methods and abstractions. They also automate request signing for all Paymen…”
   • [claimed-docs] “We offer signing libraries in these languages”
   • [github] “Convenient libraries to produce TrueLayer API requests signatures.”

   proof ↗⚑ flag

Sandbox

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

   weight 3 · round to Stripe Financial Connections
   Stripe Financial Connections✓fullclaimed7/10

   Docs explicitly describe a dedicated testing mode where the authentication flow shows only Stripe-managed test institutions that can be linked without credentials, enabling end-to-end exercise of the linking flow before touching real banks. However, evidence doesn't detail documented test credentials for specific error-state scenarios (e.g., forced failures, specific test account numbers for different data states) or confirm sandbox coverage of balances/transactions/ownership retrieval scenarios. Missing for 10: documented specific test credentials/account numbers for triggering distinct error states, and explicit confirmation that data retrieval (balances/transactions) can be exercised in test mode with corroborating independent developer accounts.

   • [claimed-docs] “the authentication flow exclusively shows a selection of test institutions managed by Stripe. The client can link accounts from any of these…”
   • [claimed-docs] “The client can link accounts from any of these institutions without providing credentials.”

   proof ↗⚑ flag

   TrueLayer~partialclaimed3/10

   Docs reference a quickstart that walks through creating a free account and completing a 'test payment' and a providers endpoint to see supported banks, implying some testing path exists, but there is no explicit mention of a sandbox environment, documented test institutions, or test credentials for exercising the Data API (linking/account retrieval) or specific error-state scenarios end-to-end. Missing for 10: explicit sandbox/test-bank credentials documentation, coverage of Data API linking and retrieval testing, and documented error-state simulation.

   • [claimed-docs] “you'll create a free UK merchant account and complete your first test payment with the Payments API v3”
   • [claimed-docs] “Query the providers endpoint to see which banks are supported in each European country and segment.”
   • [claimed-docs] “Read account information, balances and transaction history from a user's bank.”

   proof ↗⚑ flag

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

   weight 2 · round to TrueLayer
   Stripe Financial Connections~partialprobed5/10

   Most Financial Connections operations (creating sessions, retrieving balances/ownership/transactions, webhooks, relink) are documented as pure server-side API calls, and Stripe also exposes an MCP server and CLI for agent-driven interaction with the API (docs-11, docs-18, probe-4, probe-5). However, the actual account-linking/authentication step inherently requires the client-side `collectFinancialConnectionsAccounts` hosted flow (docs-6, docs-7) — a consumer-facing UI that cannot be bypassed via pure API calls, so an AI-native user cannot complete the core linking action through API alone. Missing for 10: evidence of a pure-API path to complete bank authentication/consent without the client SDK, and confirmation that all Dashboard-configurable settings are also API-exposed.

   • [claimed-docs] “Use collectFinancialConnectionsAccounts to launch the authentication flow from your client using the client_secret returned by your server”
   • [claimed-docs] “Users select their bank from frequently chosen institutions or by searching more than 12,000 supported banks.”
   • [claimed-docs] “Financial insights for agents | - Agent-powered spending analysis - Balance and transaction monitoring | Link CLI”
   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”
   • [claimed-docs] “Sent when a customer links a new account. If they link multiple accounts, it emits multiple events (one per account).”
   • [claimed-docs] “Use the relink API to help your user reconnect their inactive account.”

   proof ↗⚑ flag

   TrueLayer~partialprobed6/10

   TrueLayer is API-first: payments, payouts, mandates, data/account access, verification, webhooks and signing are all exposed as core API operations with SDKs, and Console (the UI) appears to largely mirror these merchant operations. However, some Console-only functions (inviting team users, MFA setup, account management, monitoring/reporting dashboards) are described as UI actions with no evidence of an equivalent API/endpoint, and no OpenAPI spec is discoverable (probe 404s), making full programmatic parity unverifiable. missing for 10: API-equivalents for Console user/team management and MFA setup, a public OpenAPI/schema confirming full endpoint parity, and independent confirmation that all UI actions have API counterparts.

   • [claimed-docs] “The Payments API v3 allows you to make and accept payments and payouts in the UK and EU.”
   • [claimed-docs] “Monitor payments and generate reports in Console.”
   • [claimed-docs] “Quickly see your merchant account balances, access balance reports, and configure sweeping.”
   • [claimed-docs] “Invite users so they can retrieve your integration's client credentials, access the payments view, or issue refunds.”
   • [claimed-docs] “After you create an account, add another layer of security with multi-factor authentication (MFA).”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.truelayer.com/openapi.json, https://docs.truelayer.com/swagger.json, https://docs.truel…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Stripe Financial Connections—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

   TrueLayer—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 to TrueLayer
   Stripe Financial Connections—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

   TrueLayer~partialclaimed2/10

   TrueLayer's core payments/banking product is a closed proprietary SaaS API with no evidence of full source availability, but one auxiliary component—the request-signing library—is published as open source on GitHub. missing for 10: no open license for the actual product/platform source, only a small signing helper library is open.

   • [github] “Convenient libraries to produce TrueLayer API requests signatures.”

   proof ↗⚑ flag

Pay by bank

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

   weight 2 · round to TrueLayer
   Stripe Financial Connections~partialcommunity4/10

   Financial Connections lets a linked bank account be used to collect ACH Direct Debit payments (docs-8, docs-16, docs-17, docs-27-29), which is a debit-based bank payment initiation flow, but this is not a full 'pay-by-bank' push-payment product, and there is no documented statement of live geographies — the only geography signal comes from community reports that it is US-only (comm-9, comm-11, comm-12), not honest first-party docs. Missing for 10: explicit documented geography/coverage list, and evidence of true push-payment (real-time transfer) initiation rather than just ACH debit collection.

   • [claimed-docs] “Collect a bank account for ACH Direct Debit payments while using account data, including balances.”
   • [claimed-docs] “instant | Financial Connections only, with no manual entry and microdeposit fallback”
   • [claimed-docs] “Reduce your payment failure rate from closed or inactive accounts - Improve payments conversion by keeping users on session, instead of forc…”
   • [claimed-docs] “Reduce your payment failure rate from closed or inactive accounts”
   • [claimed-docs] “Improve payments conversion by keeping users on session, instead of forcing them to leave your payments flow to locate their accounts and ro…”
   • [claimed-docs] “Save development time by eliminating the need to create a custom bank account collection form”
   • [community] “Curious that they translated it to German based on my phone settings for a product that only supports US banks? (I don't mind that it is US …”
   • [community] “Only available in the US.”
   • [community] “guessing this doesn't work with Canada”

   proof ↗⚑ flag

   TrueLayer✓fullclaimed8/10

   TrueLayer's Payments API v3 is well documented for initiating pay-by-bank payments from a connected account, with a quickstart to create a test payment, payment links, mandates for recurring payments, and webhooks — and it explicitly states its live geographies as UK and EU (truelayer-docs-1, truelayer-docs-23, truelayer-docs-32, truelayer-docs-10). Missing for 10: independent/hands-on developer confirmation of the payment flow working end-to-end and a fully granular, country-by-country live-market breakdown beyond the UK/EU summary.

   • [claimed-docs] “The Payments API v3 allows you to make and accept payments and payouts in the UK and EU.”
   • [claimed-docs] “Accept Pay by Bank payments. Covers the API, authentication, webhooks and testing.”
   • [claimed-docs] “Generate payment links without a custom integration.”
   • [claimed-docs] “Use the following steps to learn how to create a new payment mandate for your user. You'll need this mandate to set up recurring payments.”
   • [claimed-docs] “you'll create a free UK merchant account and complete your first test payment with the Payments API v3”
   • [claimed-docs] “Query the providers endpoint to see which banks are supported in each European country and segment.”
   • [claimed-docs] “webhooks inform you about: when a payment changes to a new status in the authorisation process”

   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 TrueLayer
   Stripe Financial Connections~partialcommunity4/10

   Financial Connections explicitly supports collecting a bank account for ACH Direct Debit payments (docs-8, docs-16, docs-17), and ACH Direct Debit mandates are inherently reusable for repeat debits, but the evidence never documents a specific recurring/subscription debit flow, standing consent, or variable recurring payment (VRP) mechanism built on top of the connection. Missing for 10: explicit documentation of mandate reuse for recurring charges, standing consent/authorization language, and any VRP-style flow or recurring-debit API guidance.

   • [claimed-docs] “Collect a bank account for ACH Direct Debit payments while using account data, including balances.”
   • [claimed-docs] “instant | Financial Connections only, with no manual entry and microdeposit fallback”
   • [claimed-docs] “Reduce your payment failure rate from closed or inactive accounts - Improve payments conversion by keeping users on session, instead of forc…”
   • [community] “I work at one of the companies that integrated Financial Connections during its beta, moving from Plaid Auth. We use the link to bank accoun…”

   proof ↗⚑ flag

   TrueLayer✓fullclaimed8/10

   TrueLayer documents payment mandates explicitly covering Sweeping VRPs, Wave 1 VRPs, and Direct Debits, with dedicated docs on creating a mandate and executing recurring payments on an authorised mandate without further user auth. This directly matches variable recurring payments, standing consents, and recurring debit flows built on the Payments API. Missing for 10: independent/hands-on corroboration beyond first-party docs, and more detail on standing consent lifecycle management (renewal/revocation).

   • [claimed-docs] “Use the following steps to learn how to create a new payment mandate for your user. You'll need this mandate to set up recurring payments.”
   • [claimed-docs] “Once you create a payment on an authorised mandate, it executes immediately without requiring further user authorisation.”
   • [claimed-docs] “Payment mandates belong to one of three types: Sweeping VRPs... Wave 1 VRPs... Direct Debits”
   • [claimed-docs] “After you create a payment mandate and your user has authorised it, you can create a payment on the mandate... it executes immediately.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Stripe Financial Connections—none0/10

   No evidence in the pack mentions data residency, regional storage options, or user/customer choice of data location for Financial Connections; comments even note it's US-only, which suggests no regional selection capability. Missing for 10: any documentation of region/residency configuration, data localization options, or EU/other data center choices.

   • [community] “Only available in the US.”
   • [community] “guessing this doesn't work with Canada”

   proof ↗⚑ flag

   TrueLayer—none0/10

   TrueLayer's evidence covers UK/EU payments and data APIs but nowhere mentions user-selectable data residency or region storage controls; the mention of UK/EU scope reflects operational coverage, not a configurable data-residency choice. Missing for 10: any documentation of data residency options, region selection controls, or storage location configurability.

   • [claimed-docs] “The Payments API v3 allows you to make and accept payments and payouts in the UK and EU.”
   • [claimed-docs] “Access identity, accounts, transactions and balance data for all integrated banks with a single interface.”

   proof ↗⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Stripe Financial Connections—none0/10

   No evidence in the pack addresses data retention controls, deletion APIs/mechanisms, or configurable data lifecycle policies for Financial Connections data; docs describe data access (balances, transactions, ownership) and webhooks but not retention/deletion controls for AI-native users. Missing for 10: any documentation of data retention settings, account/data deletion endpoints, or user-controlled data lifecycle management.

   ⚑ flag

   TrueLayer—none0/10

   No evidence of any data retention or deletion controls (e.g., data export, deletion API, retention policy settings) for AI-native users; evidence pack covers payments, data access APIs, webhooks, and MCP integration but nothing about controlling or deleting stored data.

   ⚑ flag

Cashflow

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

   weight 2 · round drawn
   Stripe Financial Connections—none0/10

   Financial Connections documents raw data access (balances, transactions, ownership) and encourages building 'fintech products with transactions data' or 'personal finance apps,' but there is no evidence of Stripe itself deriving income/cash-flow signals — no recurring-stream detection, payroll identification, or documented income-verification product built on this data. Community discussion also focuses on account linking reliability and pricing, not income analytics.

   • [claimed-docs] “Access an account’s transaction history.”
   • [claimed-docs] “Collect user accounts and gain access to account data to build more complex integrations, such as personal finance apps.”
   • [claimed-docs] “build new fintech products with transactions data”

   proof ↗⚑ flag

   TrueLayer—none0/10

   TrueLayer's Data API covers identity, accounts, balances and raw transaction history, but no evidence describes derived income/cash-flow signals such as recurring stream detection, payroll detection, or a dedicated income verification product built on the data.

   • [claimed-docs] “Read account information, balances and transaction history from a user's bank.”
   • [claimed-docs] “Access identity, accounts, transactions and balance data for all integrated banks with a single interface.”
   • [claimed-docs] “We compare the identity data to the account holder's name for all the connected account(s) the user has given consent for.”

   proof ↗⚑ flag

Enrichment

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

   weight 2 · round drawn
   Stripe Financial Connections—none0/10

   The docs describe raw transaction history access (docs-4) but never mention any enrichment layer — no cleaned/normalized merchant names, spending categories, or merchant logos are documented anywhere in the evidence pack. Community threads even note the transactions product was still 'Coming Soon' at one point, with no follow-up confirming enrichment features shipped.

   • [claimed-docs] “Access an account’s transaction history.”
   • [claimed-docs] “Collect user accounts and gain access to account data to build more complex integrations, such as personal finance apps.”
   • [community] “By clicking 'Start Now', I try to visit dashboard.stripe.com/financial-connections/application and it redirects to the test dashboard. A lot…”

   proof ↗⚑ flag

   TrueLayer—none0/10

   The Data API is documented as returning identity, accounts, transactions and balance data (truelayer-docs-28), but no evidence describes merchant name cleaning, categorization, or logo enrichment as a documented capability. Missing for 10: any mention of transaction enrichment, merchant name normalization, category tagging, or logo/icon data in the docs.

   • [claimed-docs] “Access identity, accounts, transactions and balance data for all integrated banks with a single interface.”

   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 Stripe Financial Connections
   Stripe Financial Connections~partialcommunity5/10

   Docs confirm access to an account's transaction history (docs-4) and a webhook-driven refresh model (transaction refresh completed events, docs-25) that lets a client know when to pull new data, and community evidence confirms documented depth/cadence limits (180 days history, daily pulls) as a real sync pattern. However, there is no explicit documentation in the pack of the transactions list endpoint's pagination parameters (cursor/starting_after) or a formal delta/sync-token mechanism for fetching only changed transactions. Missing for 10: explicit API pagination documentation for the transactions list endpoint, and a documented incremental-sync/cursor mechanism beyond the refresh webhook.

   • [claimed-docs] “Access an account’s transaction history.”
   • [claimed-docs] “Sent after a transaction refresh is complete.”
   • [claimed-docs] “Sent after a balance refresh is complete.”
   • [community] “The limit to only daily pulls and up to 180 days of historical data is pretty disappointing. Would expect Stripe to push the envelope here..…”

   proof ↗⚑ flag

   TrueLayer~partialclaimed3/10

   Docs confirm a Data API that reads account, balance and transaction history via a single interface (truelayer-docs-5, truelayer-docs-28), but there is no evidence of pagination mechanics, documented history depth/lookback window, or an incremental sync pattern (e.g., delta/cursor endpoints) for fetching only changed transactions. missing for 10: pagination details, documented transaction history depth/limits, incremental/delta sync mechanism.

   • [claimed-docs] “Read account information, balances and transaction history from a user's bank.”
   • [claimed-docs] “Access identity, accounts, transactions and balance data for all integrated banks with a single interface.”

   proof ↗⚑ flag