Teller 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 Teller
   Teller~partialclaimed6/10

   Teller has a documented Connect widget (React SDK, teller-connect-react) and quickstart flow that lets users link accounts, plus a sandbox environment for testing enrollments and OTP flows, matching the drop-in hosted-flow story. However, evidence lacks explicit detail on server-side session creation and the exact token exchange flow, and no independent hands-on account of the widget UX beyond first-party docs. missing for 10: explicit session-creation API docs, independent/hands-on verification of the widget flow, and detail on token retrieval mechanics.

   • [claimed-docs] “Learn about Teller Connect and how to integrate and customize it for you application.”
   • [claimed-docs] “finish up by linking your first financial accounts to Teller.”
   • [github] “React hook and component for integrating with Teller Connect”
   • [claimed-docs] “`otp` () - Will follow an OTP MFA flow whereby the user will be asked to select a contact to send an OTP code. The correct code is `0000`”
   • [claimed-docs] “The sandbox environment uses simulated data and never connects to real financial institutions.”
   • [claimed-docs] “Connect instantly with more than 7,000 financial institutions and fall back to same-day ACH microdeposit verification for everyone else.”

   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
   Teller—none0/10

   Teller's docs describe connecting via 'Verify Account Details via Microdeposit' and general account-linking language, but nowhere document OAuth coverage of major institutions or a retirement plan for legacy credential-based flows. Community evidence actually points the other way — the founder compares Teller's terms to 'incumbent screen-scrapers in the market, e.g. Yodlee and Plaid,' and users note banks disclaim liability 'if you give your online banking credentials to a third party,' indicating credential-based (not bank-hosted OAuth) connections were in use historically.

   • [community] “Founder response: 'FWIW it is not currently possible for users to move money with Teller... Our terms are comparable to the incumbent screen…”
   • [community] “UK banks don't accept any liability if you give your online banking credentials to a third party. If some fraud was to come about as a resul…”
   • [claimed-docs] “To access account details from these institutions, you can implement the 'Verify Account Details via Microdeposit' flow.”
   • [claimed-docs] “Connect instantly with more than 7,000 financial institutions and fall back to same-day ACH microdeposit verification for everyone else.”

   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 drawn
   Teller—none0/10

   The evidence covers enrollment webhooks, MFA/OTP sandbox flows, and microdeposit verification, but nowhere documents a specific 'broken connection' status taxonomy or a re-authentication/update flow for expired or revoked links. Webhook docs mention 'changes in user enrollments' generically but don't detail reconnect/repair UX.

   • [claimed-docs] “To register a new webhook, you need to have a URL in your app that Teller can call. You can configure a new webhook from the Teller Dashboar…”
   • [claimed-docs] “Teller sends webhook events when specific conditions or changes are detected in user enrollments or their financial data.”
   • [claimed-docs] “`otp` () - Will follow an OTP MFA flow whereby the user will be asked to select a contact to send an OTP code. The correct code is `0000`”

   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
   Teller—none0/10

   Probes directly show no llms.txt, no docs.md, and no OpenAPI file at expected locations (all 404), and no evidence of any agent-oriented documentation format elsewhere in the pack.

   • [probe] “PROBE llms.txt: HTTP 404 at https://teller.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://teller.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://teller.io/openapi.json, https://teller.io/swagger.json, https://teller.io/api/openapi.json, …”

   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 drawn
   Teller~partialcommunity5/10

   Teller is an API-first product (mTLS-authenticated REST API with a sandbox environment) that is inherently callable headlessly from scripts, and a community example shows a script consuming the API to export data. However there is no explicit documentation of CI integration, a CLI, or automation-specific guidance/examples for headless pipelines. Missing for 10: explicit CI/CD documentation, CLI or SDK examples for automated pipelines, and any first-party guidance on non-interactive/headless usage patterns.

   • [claimed-docs] “The Teller API uses mTLS to authenticate the API caller. Teller issues client certificates that you use to connect to the Teller API.”
   • [claimed-docs] “The sandbox environment uses simulated data and never connects to real financial institutions.”
   • [claimed-docs] “`otp` () - Will follow an OTP MFA flow whereby the user will be asked to select a contact to send an OTP code. The correct code is `0000`”
   • [community] “I built a little script to export my accounts to CSV/QIF. Super easy to use API! https://github.com/scottrobertson/teller-export”

   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 TrueLayer
   Teller—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✓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 drawn
   Teller—none0/10

   No evidence of an official CLI for Teller; only a REST API, SDKs, and a React connect component are documented, and probes for llms.txt/openapi/docs.md all 404. Missing for 10: any mention of a CLI tool, package, or command-line workflow for AI-native/agentic use.

   • [probe] “PROBE llms.txt: HTTP 404 at https://teller.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://teller.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://teller.io/openapi.json, https://teller.io/swagger.json, https://teller.io/api/openapi.json, …”
   • [github] “React hook and component for integrating with Teller Connect”

   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
   Teller~partialprobed6/10

   Teller documents a full REST API (accounts, balances, transactions, identity, payments, webhooks, mTLS auth, pagination, idempotency) that a developer or agent can drive programmatically, and a community member confirms it as an 'easy to use API' for scripting exports. However, probes show no OpenAPI/Swagger spec or llms.txt/docs.md machine-readable format, which limits easy AI-native discovery/automation of the API surface. missing for 10: OpenAPI/Swagger spec, llms.txt or docs.md for agent-friendly discovery, broader independent evidence of agentic/automated API usage beyond one CSV-export script.

   • [claimed-docs] “The account balances API provides your application with live, real-time account balances.”
   • [claimed-docs] “The transactions API exposes the ledger transactions of a financial account.”
   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”
   • [claimed-docs] “The payments resource allows you to send payments to yourself or a 3rd party on behalf of the end-user from their account. Currently the onl…”
   • [claimed-docs] “The Teller API uses mTLS to authenticate the API caller. Teller issues client certificates that you use to connect to the Teller API.”
   • [claimed-docs] “This endpoint supports idempotent requests.”
   • [claimed-docs] “the transactions list endpoint supports pagination controls.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://teller.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://teller.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://teller.io/openapi.json, https://teller.io/swagger.json, https://teller.io/api/openapi.json, …”
   • [community] “I built a little script to export my accounts to CSV/QIF. Super easy to use API! https://github.com/scottrobertson/teller-export”

   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
   Teller—none0/10

   Teller's docs describe mTLS client-certificate authentication and per-enrollment user consent, but there is no evidence of any mechanism to mint scoped, least-privilege API credentials specifically for delegating access to an AI agent (e.g., granular permission scopes, agent-specific keys, or revocable sub-credentials). Missing for 10: any documentation of scoped/limited-permission credential issuance, agent-specific key management, or fine-grained access control beyond whole-enrollment consent.

   • [claimed-docs] “The Teller API uses mTLS to authenticate the API caller. Teller issues client certificates that you use to connect to the Teller API.”
   • [claimed-docs] “The Teller API uses mTLS to authenticate the API caller”
   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”
   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”
   • [claimed-docs] “**100 enrollment limit** — An enrollment represents one bank login, which may include multiple accounts”

   proof ↗⚑ 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 to TrueLayer
   Teller~partialprobed5/10

   Teller provides an official REST API with documented endpoints and a first-party React SDK (teller-connect-react) for integrating Teller Connect, giving developers something concrete to build against. However, probes show no OpenAPI/swagger spec or llms.txt for machine-readable discovery, and there's no evidence of official SDKs beyond the single React component (e.g., no Python/Node/mobile SDKs), limiting AI-native tooling support. Missing for 10: multi-language official SDKs, machine-readable OpenAPI spec, llms.txt or other AI-agent-friendly documentation.

   • [github] “React hook and component for integrating with Teller Connect”
   • [claimed-docs] “Learn about Teller Connect and how to integrate and customize it for you application.”
   • [claimed-docs] “The Teller API uses mTLS to authenticate the API caller. Teller issues client certificates that you use to connect to the Teller API.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://teller.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://teller.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://teller.io/openapi.json, https://teller.io/swagger.json, https://teller.io/api/openapi.json, …”

   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
   Teller✓fullclaimed7/10

   Teller documents a webhooks API where users register a URL to receive events for enrollment/data changes, configurable via the Dashboard, covering the core subscribe-to-events capability. missing for 10: no documented event type catalog/payload schema, no independent/hands-on confirmation of webhook reliability, and no AI-agent-specific integration pattern beyond generic docs.

   • [claimed-docs] “To register a new webhook, you need to have a URL in your app that Teller can call. You can configure a new webhook from the Teller Dashboar…”
   • [claimed-docs] “Teller sends webhook events when specific conditions or changes are detected in user enrollments or their financial data.”

   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 drawn
   Teller—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

   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 to TrueLayer
   Teller~partialclaimed4/10

   Teller offers webhooks that fire on enrollment/data changes, enabling event-driven background processing without polling, which is the closest analog to autonomous automation for this financial-data API. However there's no evidence of an AI-agent framework, scheduling/orchestration engine, or any AI-native automation tooling — webhooks are a generic API feature, not an agentic automation capability. Missing for 10: AI agent orchestration support, scheduled/recurring automation tooling, explicit AI-native automation framework or examples.

   • [claimed-docs] “To register a new webhook, you need to have a URL in your app that Teller can call. You can configure a new webhook from the Teller Dashboar…”
   • [claimed-docs] “Teller sends webhook events when specific conditions or changes are detected in user enrollments or their financial data.”

   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
   Teller—none0/10

   Teller is a banking-data API/SDK product with no evidence of a natural-language command interface, chatbot, or AI-native interaction layer; probes for llms.txt/docs.md/openapi also failed, and no docs mention NL commands or agent interfaces.

   • [probe] “PROBE llms.txt: HTTP 404 at https://teller.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://teller.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://teller.io/openapi.json, https://teller.io/swagger.json, https://teller.io/api/openapi.json, …”

   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
   Teller—none0/10

   Teller has extensive markdown-based API documentation but no evidence of an interactive reference with runnable examples (e.g., Swagger/OpenAPI explorer). Probes for openapi.json/swagger.json all returned 404, and no docs mention a try-it-now console or code sandbox.

   • [probe] “PROBE openapi: all candidate paths 404 (https://teller.io/openapi.json, https://teller.io/swagger.json, https://teller.io/api/openapi.json, …”
   • [claimed-docs] “Learn about Teller Connect and how to integrate and customize it for you application.”

   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
   Teller—none0/10

   Probes for llms.txt, docs.md, and common OpenAPI/swagger paths all return 404, and no evidence pack item references a downloadable machine-readable spec; documentation is only in prose/markdown form.

   • [probe] “PROBE llms.txt: HTTP 404 at https://teller.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://teller.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://teller.io/openapi.json, https://teller.io/swagger.json, https://teller.io/api/openapi.json, …”

   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 Teller
   Teller✓fullclaimed8/10

   Teller documents a dedicated sandbox environment using simulated data that never connects to real financial institutions, with defined test flows (e.g., OTP MFA with code 0000), letting developers test integrations without touching production data or real accounts. Missing for 10: independent/hands-on developer confirmation of sandbox fidelity and no mention of sandbox-specific rate limits or data reset options.

   • [claimed-docs] “The sandbox environment uses simulated data and never connects to real financial institutions.”
   • [claimed-docs] “`otp` () - Will follow an OTP MFA flow whereby the user will be asked to select a contact to send an OTP code. The correct code is `0000`”
   • [claimed-docs] “**100 enrollment limit** — An enrollment represents one bank login, which may include multiple accounts”

   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
   Teller—none0/10

   No evidence of API versioning scheme or a documented deprecation policy anywhere in the docs pack; probes for llms.txt/openapi spec also failed, suggesting no machine-readable API contract either.

   • [probe] “PROBE llms.txt: HTTP 404 at https://teller.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://teller.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://teller.io/openapi.json, https://teller.io/swagger.json, https://teller.io/api/openapi.json, …”

   proof ↗⚑ 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
   Teller—none0/10

   Teller's docs describe per-item endpoints (single account balances, single transaction list with pagination, single payment with idempotency) but there is no evidence of any batch/bulk endpoint for operating across many accounts, transactions, or payments at once. Pagination controls exist for reading a transaction list, but that is not a bulk operation on multiple items simultaneously.

   • [claimed-docs] “the transactions list endpoint supports pagination controls.”
   • [claimed-docs] “This endpoint supports idempotent requests.”
   • [claimed-docs] “The payments resource allows you to send payments to yourself or a 3rd party on behalf of the end-user from their account. Currently the onl…”
   • [claimed-docs] “The transactions API exposes the ledger transactions of a financial 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
   Teller—none0/10

   Teller offers webhooks for event notifications (teller-docs-7, teller-docs-17), but there is no evidence of a rules engine or automation-configuration capability where users can define conditional actions triggered by events — webhook delivery only notifies an external app, it doesn't let a user define trigger-action rules within Teller itself. missing for 10: any rule/condition builder, action templates, or automation configuration UI/API beyond raw webhook event delivery.

   • [claimed-docs] “To register a new webhook, you need to have a URL in your app that Teller can call. You can configure a new webhook from the Teller Dashboar…”
   • [claimed-docs] “Teller sends webhook events when specific conditions or changes are detected in user enrollments or their financial data.”

   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
   Teller—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 Teller
   Teller~partialclaimed7/10

   Teller's docs describe an account-details endpoint providing verified account/routing numbers with instant verification for 7,000+ institutions, explicitly positioned to avoid microdeposits, with balances API used to confirm funds before ACH debit. However the same docs show a same-day microdeposit fallback is still required for institutions outside instant coverage, and there is no independent/hands-on confirmation of the instant-verification success rate or that routing numbers are tokenized rather than plaintext. missing for 10: independent corroboration of instant verification working in practice, clarity on tokenization vs raw account/routing number exposure, and confirmation that non-covered institutions aren't a common real-world limitation.

   • [claimed-docs] “To access account details from these institutions, you can implement the 'Verify Account Details via Microdeposit' flow.”
   • [claimed-docs] “Connect instantly with more than 7,000 financial institutions and fall back to same-day ACH microdeposit verification for everyone else.”
   • [claimed-docs] “Guaranteed live account balances. Used for underwriting or ensuring sufficient funds are available before submitting an ACH debit.”
   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”

   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 Teller
   Teller✓fullclaimed9/10

   Teller's docs explicitly provide a dedicated real-time balances API endpoint, and marketing/docs copy directly frames it for underwriting/NSF risk checks before submitting an ACH debit, matching the story precisely. Missing for 10: no independent/hands-on developer confirmation of the balance endpoint's real-time accuracy or latency in production.

   • [claimed-docs] “The account balances API provides your application with live, real-time account balances.”
   • [claimed-docs] “Guaranteed live account balances. Used for underwriting or ensuring sufficient funds are available before submitting an ACH debit.”
   • [claimed-docs] “Teller lets users connect their accounts in seconds, and you verify account ownership, ACH details, balances, and transactions with ease.”

   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 Teller
   Teller✓fullclaimed8/10

   Teller's Identity API explicitly returns beneficial owner identity information for each authorized account, directly matching the story's need to retrieve account-holder names/identity data for owner matching (teller-docs-4, teller-docs-19), and the docs message frames account ownership verification as a core use case (teller-docs-1). Missing for 10: explicit confirmation that address/contact fields (not just legal name) are included in the Identity payload, and independent/hands-on corroboration beyond vendor docs.

   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”
   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”
   • [claimed-docs] “Teller lets users connect their accounts in seconds, and you verify account ownership, ACH details, balances, and transactions with ease.”

   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 TrueLayer
   Teller—none0/10

   Teller's docs describe its own Payments resource (Zelle transfers) and Identity/Balances APIs, but there is no documented processor-token exchange or integration flow that hands verified account credentials to third-party payment processors/platforms (e.g., a Stripe/Dwolla-style processor token). Community threads even confirm Teller does not enable moving money to arbitrary third parties beyond its own Zelle feature.

   • [claimed-docs] “The payments resource allows you to send payments to yourself or a 3rd party on behalf of the end-user from their account. Currently the onl…”
   • [claimed-docs] “The payments resource allows you to send payments to yourself or a 3rd party on behalf of the end-user from their account.”
   • [community] “Founder response: 'FWIW it is not currently possible for users to move money with Teller... Our terms are comparable to the incumbent screen…”

   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
   Teller~partialprobed6/10

   Teller's docs describe a REST API with well-defined resources (balances, transactions, identity, payments) and some enrichment like transaction categorization, pagination, and idempotency, suggesting structured, documented data an app could parse programmatically. However, there is no evidence of a machine-readable schema (OpenAPI/swagger) or llms.txt for agent discovery—probes show all such endpoints 404—so an AI agent would have to rely on human-oriented docs rather than a formal schema. missing for 10: machine-readable OpenAPI/schema files, llms.txt or agent-specific docs, richer enrichment metadata (e.g., merchant/location tags) beyond basic categorization.

   • [claimed-docs] “The account balances API provides your application with live, real-time account balances.”
   • [claimed-docs] “The transactions API exposes the ledger transactions of a financial account.”
   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”
   • [claimed-docs] “the category that the transaction belongs to. Teller uses the following values for categorization”
   • [claimed-docs] “This endpoint supports idempotent requests.”
   • [claimed-docs] “the transactions list endpoint supports pagination controls.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://teller.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://teller.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://teller.io/openapi.json, https://teller.io/swagger.json, https://teller.io/api/openapi.json, …”

   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 to TrueLayer
   Teller~partialprobed4/10

   Teller's REST API supports the core primitives (balances, transactions, identity, connect/link sessions via Teller Connect, mTLS-scoped credentials) that an agent could call, but there is no evidence of an MCP server, agent-oriented SDK, or machine-readable API spec — probes for llms.txt, docs.md, and openapi.json all returned 404, indicating no first-class AI-agent integration surface. missing for 10: an MCP server or agent tool-calling interface, machine-readable OpenAPI/llms.txt discovery, and any documentation framing agent-driven scoped access.

   • [claimed-docs] “Teller lets users connect their accounts in seconds, and you verify account ownership, ACH details, balances, and transactions with ease.”
   • [claimed-docs] “The account balances API provides your application with live, real-time account balances.”
   • [claimed-docs] “The transactions API exposes the ledger transactions of a financial account.”
   • [claimed-docs] “The Teller API uses mTLS to authenticate the API caller. Teller issues client certificates that you use to connect to the Teller API.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://teller.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://teller.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://teller.io/openapi.json, https://teller.io/swagger.json, https://teller.io/api/openapi.json, …”

   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
   Teller—none0/10

   No evidence of an end-user consent dashboard or portal where users can view or revoke third-party app access to their bank data; docs cover enrollment, data APIs, webhooks, and auth but nothing about consent management/revocation UI. Missing for 10: a documented end-user consent portal, revocation flow/API, and any independent confirmation of such a surface.

   • [claimed-docs] “finish up by linking your first financial accounts to Teller.”
   • [claimed-docs] “**100 enrollment limit** — An enrollment represents one bank login, which may include multiple accounts”
   • [claimed-docs] “Learn about Teller Connect and how to integrate and customize it for you application.”

   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
   Teller—none0/10

   No evidence in the pack documents a deletion/disconnection flow, data purge process, or user/connection removal API — the docs focus on connecting, verifying, and retrieving financial data (balances, transactions, identity, payments) with no mention of offboarding or data deletion mechanics.

   ⚑ 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 TrueLayer
   Teller—none0/10

   The evidence describes separate API resources (balances, transactions, identity, payments) but there is no documentation of a consent flow where developers can request only specific scopes or where end-users see a product-scoped grant rather than an all-or-nothing authorization. No mention of a 'products' parameter, granular permission toggles, or data-minimization consent screen in Teller Connect.

   • [claimed-docs] “Teller lets users connect their accounts in seconds, and you verify account ownership, ACH details, balances, and transactions with ease.”
   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”
   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”
   • [claimed-docs] “Learn about Teller Connect and how to integrate and customize it for you application.”

   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 Teller
   Teller~partialclaimed4/10

   Teller's balances API is documented as returning "live, real-time account balances" (teller-docs-2, teller-docs-22), implying each API call effectively refreshes data on demand, and webhooks fire on data changes (teller-docs-7, teller-docs-17). However, there is no dedicated refresh/sync endpoint, no documented semantics for how or when transaction data is refreshed, and no explanation of caching or refresh triggers for the transactions API — missing for 10: a documented refresh endpoint/mechanism, explicit refresh semantics (latency, staleness window), and confirmation for transactions data (not just balances).

   • [claimed-docs] “The account balances API provides your application with live, real-time account balances.”
   • [claimed-docs] “Guaranteed live account balances. Used for underwriting or ensuring sufficient funds are available before submitting an ACH debit.”
   • [claimed-docs] “To register a new webhook, you need to have a URL in your app that Teller can call. You can configure a new webhook from the Teller Dashboar…”
   • [claimed-docs] “Teller sends webhook events when specific conditions or changes are detected in user enrollments or their financial data.”
   • [claimed-docs] “The transactions API exposes the ledger transactions of a financial account.”

   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 drawn
   Teller~partialclaimed5/10

   Teller docs confirm webhook events exist for enrollment/data changes (teller-docs-17) and describe how to register a webhook URL (teller-docs-7), covering the general 'push not poll' data-freshness goal. However, the evidence pack contains no mention of webhook payload signing/verification mechanism, nor independent confirmation that webhooks reliably fire for transactions, balances, and connection-state changes as described. Missing for 10: explicit signature/verification scheme for webhooks, documented list of event types (transaction created, balance updated, enrollment disconnected), and third-party/hands-on confirmation of webhook delivery reliability.

   • [claimed-docs] “To register a new webhook, you need to have a URL in your app that Teller can call. You can configure a new webhook from the Teller Dashboar…”
   • [claimed-docs] “Teller sends webhook events when specific conditions or changes are detected in user enrollments or their financial data.”

   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
   Teller~partialcommunity3/10

   Teller publishes a single aggregate figure ("more than 7,000 financial institutions") but no breakdown by geography, no searchable list of supported institutions, and no way for a founder to verify coverage against their specific user base. The old community thread references only a handful of UK banks, but this appears to be from an earlier version of the product and is not directly comparable to the current 7,000+ claim. missing for 10: geographic breakdown, institution-name list/coverage tool, independent verification of the 7,000 figure.

   • [claimed-docs] “Connect instantly with more than 7,000 financial institutions and fall back to same-day ACH microdeposit verification for everyone else.”
   • [community] “Teller is available today for Santander UK, Barclays, Natwest, Nationwide, RBS, Isle of Man Bank, and Ulster Bank.”

   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 drawn
   Teller—none0/10

   No evidence of a status page, per-institution outage/degradation signals, or documented error codes distinguishing bank-side failures from client-side errors. Webhooks are mentioned for enrollment/data change events, but nothing ties to institution health visibility or error taxonomy.

   ⚑ 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 drawn
   Teller✓fullclaimed7/10

   Teller's architecture centers on a single enrollment/access-token granted via one Connect flow, which then powers balances, transactions, identity, and account-details APIs (teller-docs-1, teller-docs-4/19 note identity covers 'all accounts the end-user granted access authorization', teller-docs-13 defines an enrollment as one bank login with multiple accounts). This implies a single link session unlocks multiple data products without repeated connect flows. missing for 10: an explicit statement confirming no re-authentication is needed per product, and independent/hands-on developer corroboration of this multi-product single-session behavior.

   • [claimed-docs] “Teller lets users connect their accounts in seconds, and you verify account ownership, ACH details, balances, and transactions with ease.”
   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”
   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”
   • [claimed-docs] “**100 enrollment limit** — An enrollment represents one bank login, which may include multiple accounts”
   • [claimed-docs] “The account balances API provides your application with live, real-time account balances.”
   • [claimed-docs] “The transactions API exposes the ledger transactions of a financial account.”

   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
   Teller~partialclaimed5/10

   Docs confirm a quickstart guide that ends with linking a first sandbox account, a dedicated sandbox environment with simulated data and OTP test flows, and at least one client library (React hook/component) for Teller Connect. However, authentication requires mTLS with client certificates rather than a simple self-serve API key (raising integration friction), and there's no evidence of client libraries beyond React or of a fast self-serve signup process for keys/certs. Missing for 10: explicit self-serve API-key/signup flow, additional-language client libraries (Node/Python/etc.), independent hands-on confirmation of speed from quickstart to first linked sandbox account.

   • [claimed-docs] “finish up by linking your first financial accounts to Teller.”
   • [claimed-docs] “The sandbox environment uses simulated data and never connects to real financial institutions.”
   • [claimed-docs] “`otp` () - Will follow an OTP MFA flow whereby the user will be asked to select a contact to send an OTP code. The correct code is `0000`”
   • [claimed-docs] “The Teller API uses mTLS to authenticate the API caller. Teller issues client certificates that you use to connect to the Teller API.”
   • [github] “React hook and component for integrating with Teller Connect”

   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 Teller
   Teller✓fullclaimed8/10

   Docs confirm a sandbox environment with simulated data that never touches real institutions, plus documented test credentials/flows (e.g., OTP MFA code '0000'), and full documented APIs for linking, balances, transactions, identity, and payments that can be exercised in sandbox. Missing for 10: independent/hands-on developer accounts specifically validating the sandbox test-credential workflow and documented error-state simulation beyond MFA.

   • [claimed-docs] “The sandbox environment uses simulated data and never connects to real financial institutions.”
   • [claimed-docs] “`otp` () - Will follow an OTP MFA flow whereby the user will be asked to select a contact to send an OTP code. The correct code is `0000`”
   • [claimed-docs] “The account balances API provides your application with live, real-time account balances.”
   • [claimed-docs] “The transactions API exposes the ledger transactions of a financial account.”
   • [claimed-docs] “**100 enrollment limit** — An enrollment represents one bank login, which may include multiple accounts”

   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
   Teller~partialclaimed5/10

   Teller exposes rich API endpoints for balances, transactions, identity, payments, and account details (teller-docs-2,3,4,5,6), suggesting most financial data operations are API-driven, but account linking is done through the Teller Connect UI widget and webhook registration is explicitly described as being configured 'from the Teller Dashboard' rather than via an API endpoint (teller-docs-7), indicating some UI-only actions lack documented API equivalents. Missing for 10: an API endpoint for webhook/enrollment management equivalent to Dashboard actions, explicit documentation confirming full API/UI parity, and independent confirmation of no UI-exclusive features.

   • [claimed-docs] “The account balances API provides your application with live, real-time account balances.”
   • [claimed-docs] “The transactions API exposes the ledger transactions of a financial account.”
   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”
   • [claimed-docs] “The payments resource allows you to send payments to yourself or a 3rd party on behalf of the end-user from their account. Currently the onl…”
   • [claimed-docs] “To access account details from these institutions, you can implement the 'Verify Account Details via Microdeposit' flow.”
   • [claimed-docs] “To register a new webhook, you need to have a URL in your app that Teller can call. You can configure a new webhook from the Teller Dashboar…”
   • [claimed-docs] “Learn about Teller Connect and how to integrate and customize it for you application.”

   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 to Teller
   Teller~partialcommunity3/10

   Teller exposes account balances/transactions/identity via JSON API (open format), and a community member built a third-party script exporting Teller data to CSV/QIF, showing data can be extracted. However there is no first-party 'export all my data and leave' feature, no bulk data-export or account-deletion tooling, and no documentation of full data portability for end users. Missing for 10: official bulk export/download-all-data feature, documented account closure/data portability process, and independent confirmation beyond one hobbyist script.

   • [community] “I built a little script to export my accounts to CSV/QIF. Super easy to use API! https://github.com/scottrobertson/teller-export”
   • [claimed-docs] “The account balances API provides your application with live, real-time account balances.”
   • [claimed-docs] “The transactions API exposes the ledger transactions of a financial account.”
   • [claimed-docs] “Identity provides you with all of the accounts the end-user granted your application access authorization along with beneficial owner identi…”

   proof ↗⚑ 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
   Teller—none0/10

   Teller is a closed, proprietary financial API/service; the only open-source artifact found is a client-side React SDK wrapper (teller-connect-react), not the product's core source. A community comment explicitly wishes Teller were open source, implying it is not, and no license or source-availability claims appear in vendor docs.

   • [github] “React hook and component for integrating with Teller Connect”
   • [community] “I'd much prefer that this were just open source so I don't have to share my bank credentials.”

   proof ↗⚑ 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
   Teller~partialclaimed5/10

   Teller docs confirm a payments API that lets a developer send a payment from a connected account to self or a third party, with idempotency support (teller-docs-5, teller-docs-18, teller-docs-20), and separately state broad institution coverage (7,000+ US institutions) for account connectivity (teller-docs-11). However, the payments API explicitly supports only the Zelle scheme currently, not general ACH/bank-transfer payment initiation, and there is no explicit geography statement scoped to the payments product itself (vs. the broader account-linking coverage claim). Missing for 10: multi-rail payment initiation beyond Zelle, an explicit payments-specific geography/eligibility statement, and independent/hands-on confirmation that payment initiation works live in production.

   • [claimed-docs] “The payments resource allows you to send payments to yourself or a 3rd party on behalf of the end-user from their account. Currently the onl…”
   • [claimed-docs] “The payments resource allows you to send payments to yourself or a 3rd party on behalf of the end-user from their account.”
   • [claimed-docs] “This endpoint supports idempotent requests.”
   • [claimed-docs] “Connect instantly with more than 7,000 financial institutions and fall back to same-day ACH microdeposit verification for everyone else.”
   • [claimed-docs] “**100 enrollment limit** — An enrollment represents one bank login, which may include multiple accounts”

   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
   Teller—none0/10

   Teller's payments resource only supports Zelle-based payments to self or third parties; there is no mention of variable recurring payments, standing consents, or documented recurring debit flows.

   • [claimed-docs] “The payments resource allows you to send payments to yourself or a 3rd party on behalf of the end-user from their account. Currently the onl…”
   • [claimed-docs] “The payments resource allows you to send payments to yourself or a 3rd party on behalf of the end-user from their account.”
   • [claimed-docs] “This endpoint supports idempotent requests.”

   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
   Teller—none0/10

   No evidence of any data residency/region selection controls in Teller's docs or community discussion; the pack covers account linking, payments, mTLS auth, and webhooks but nothing about data storage location choice.

   ⚑ 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
   Teller—none0/10

   No evidence anywhere in the pack addresses data retention policies, deletion controls, or data lifecycle management for end-user financial data; docs cover connectivity, API resources, auth, and webhooks but nothing on retention/deletion controls.

   ⚑ 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
   Teller—none0/10

   Teller's docs cover balances, transactions, categorization, and identity, but no evidence describes recurring-stream detection, payroll detection, or an income-verification product built on the transaction data — this is a fair axis for an account-aggregation platform but unaddressed in the evidence pack.

   ⚑ 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 to Teller
   Teller~partialclaimed4/10

   Docs confirm the transactions API includes categorization of transactions (teller-docs-16, teller-docs-3), but there is no documented evidence of merchant name cleaning/normalization or merchant logos as a platform capability. missing for 10: documented merchant-name cleaning, logo enrichment, independent corroboration of enrichment quality.

   • [claimed-docs] “the category that the transaction belongs to. Teller uses the following values for categorization”
   • [claimed-docs] “The transactions API exposes the ledger transactions of a financial account.”

   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 Teller
   Teller~partialcommunity6/10

   Docs confirm a transactions API with pagination support and category enrichment, plus webhooks that fire on data changes (a plausible 'fetch only what changed' mechanism), and a community report of successfully exporting transaction history via the API. However, there's no documented statement of how far back transaction history extends, and no explicit incremental-sync/cursor endpoint beyond generic webhook notifications. Missing for 10: documented history depth/lookback window, an explicit delta-sync or cursor-based endpoint (not just webhooks) for changed transactions.

   • [claimed-docs] “The transactions API exposes the ledger transactions of a financial account.”
   • [claimed-docs] “the transactions list endpoint supports pagination controls.”
   • [claimed-docs] “the category that the transaction belongs to. Teller uses the following values for categorization”
   • [claimed-docs] “Teller sends webhook events when specific conditions or changes are detected in user enrollments or their financial data.”
   • [claimed-docs] “To register a new webhook, you need to have a URL in your app that Teller can call. You can configure a new webhook from the Teller Dashboar…”
   • [community] “I built a little script to export my accounts to CSV/QIF. Super easy to use API! https://github.com/scottrobertson/teller-export”

   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