baanx

Baanx.com Ltd

• Name: Baanx.com Ltd
• URL: https://www.baanx.com/
• Category: stablecoin card-and-wallet operator / crypto-funded card-program company / onboarding-and-consent workflow boundary
• Tags: ethereum-ecosystem solana-ecosystem
• Summary: Baanx clears the bar for a company note because the sticky dependency is not only wallet-to-card middleware exists; it is that a named operator issues API credentials, whitelists redirect URIs, runs onboarding and Veriff KYC, maintains consent and audit-trail policy, configures custodial versus non-custodial wallet modes, and hosts the card, ledger, and webhook workflow partners actually integrate with. The product note still matters for delegated spend and wallet-priority logic; this note is for the legal and operating shell that decides who gets access and what compliance and settlement posture they inherit.
• What it does:
  • Operates the Baanx API multi-tenant gateway that packages OAuth, user onboarding, wallet setup, delegation, card issuance, transaction history, and webhook delivery for partners building crypto-funded card products
  • Supports both custodial internal-wallet programs and non-custodial delegation flows, while keeping the surrounding account, auth, and compliance workflow inside one company-run platform
  • Runs registration and verification steps including email and phone verification, address collection, personal-details capture, and Veriff identity-verification sessions
  • Maintains a consent-management system with policy-specific requirements, immutable audit trails, and explicit US-versus-global compliance branching
  • Exposes internal, credit, and reward wallet objects plus card-linked wallet-priority controls, meaning the company is not just relaying onchain approvals but also defining offchain balance and spend workflow semantics
  • Packages the stack for exchanges, neobanks, wallet apps, DeFi products, and white-label third-party applications rather than for a single first-party consumer brand
• Key claims:
  • The homepage legal notice identifies the operator as Baanx.com Ltd, UK company number 11155611, and says the company is registered with the FCA as a cryptoasset business under the Money Laundering Regulations with FCA registration number 927401, which is enough to justify a named legal-entity boundary
  • The docs introduction calls Baanx API a multi-tenant gateway bridging cryptocurrency wallets with traditional card payments and presents OAuth, dual wallet models, card issuance, blockchain delegation, and consent management as one bundled platform
  • The OAuth quickstart says API keys come from a technical account manager, redirect URIs must be whitelisted, custom schemes require approval, and user consent is mandatory, which makes partner admission and configuration an explicit company control surface rather than a neutral open protocol
  • The llms.txt index shows the company operating a broad first-party workflow surface across registration, phone/email verification, Veriff KYC, consents, cards, internal wallets, withdrawals, webhooks, and blockchain delegation
  • The consent-management docs describe region-specific policy types, immutable audit trails, and E-Sign Act handling for US flows, showing Baanx as a compliance workflow operator instead of a thin card wrapper
  • The credit-wallet docs say spending balances, withdrawal rights, and restrictions can depend on verification status, pending transactions, or platform policies, reinforcing that practical authority includes offchain ledger and eligibility state
• Whitepaper: No separate company whitepaper is the point here. The strongest current materials are the official site, docs corpus, and the source capture in ../whitepapers/baanx-company-primary-sources-2026-08-08.md.
• Sources:
  • https://www.baanx.com/
  • https://docs.baanx.com/guides/introduction
  • https://docs.baanx.com/guides/oauth/quickstart
  • https://docs.baanx.com/guides/consent/overview
  • https://docs.baanx.com/llms.txt
  • https://docs.baanx.com/api-reference/wallet/credit
  • ../whitepapers/baanx-company-primary-sources-2026-08-08.md

Internal linkages

• Product-layer note: baanx.
• Useful adjacent operator reads: rain, gnosis-pay, and redotpay.
• Useful product-layer contrast: gnosis-pay.

Protocol / company boundary

• Keep baanx focused on the product shell: custodial versus non-custodial wallet modes, wallet-to-card linking, delegated spend, internal wallet priority, and the user-visible card-management surface.
• Keep this company note focused on Baanx.com Ltd as the named operator that issues credentials, approves integrations, sets auth and redirect constraints, runs onboarding and identity checks, maintains consent policy, and packages the broader legal/compliance shell around those APIs.
• That split matters because how does Baanx route card spending across wallets? and which company controls access, compliance state, and production workflow defaults around that route? are related but not identical questions.

Control surface

• Practical leverage sits in client-key and secret issuance, redirect-URI allowlisting, hosted-versus-custom auth setup, onboarding configuration, Veriff and consent workflow, custodial-versus-non-custodial product packaging, spender-address and blockchain configuration publication, internal/credit/reward wallet semantics, card-program availability, and webhook/event delivery.

• The useful analytical point is not merely that Baanx touches cards; it is that partners and users inherit a company-run access, compliance, and balance-state shell before any card purchase ever reaches the wallet-priority or delegation logic.

• Read Baanx.com Ltd as the operating boundary around the product, not as a neutral payment primitive.

• Last reviewed: 2026-08-08 UTC