Baanx company primary sources — 2026-08-08

Project status in this pass

• Existing projects/baanx note was strong on the product shell but still flattened too much of the operator boundary into one project note.
• This pass pulled the company-specific control surface back out into ../companies/baanx.md.

Primary-source snapshots

1) Main site / legal footer

• URL: https://www.baanx.com/
• Key excerpt:
  • The homepage markets Digital Banking & Crypto Solutions and says Baanx technology enables self-custody transactions so users can buy, spend, and borrow against digital assets.
  • The visible legal notice says Baanx.com Ltd is registered with the Financial Conduct Authority as a cryptoasset business under the UK Money Laundering Regulations, lists FCA registration number 927401, and gives company number 11155611.
• Why it matters:
  • This gives a named legal-entity boundary for the operator stack rather than leaving the note at generic brand level.

2) Docs introduction

• URL: https://docs.baanx.com/guides/introduction
• Key excerpt:
  • The introduction calls Baanx API a multi-tenant gateway bridging cryptocurrency wallets with traditional card payments.
  • It presents OAuth 2.0 with PKCE, dual wallet models, card issuance, blockchain delegation, and consent management as one integrated platform.
  • It explicitly targets neobanks, exchanges, DeFi platforms, wallet apps, and white-label applications.
• Why it matters:
  • This is strong evidence that the real dependency is a broad partner platform operated by one company, not just an isolated card product.

3) OAuth quickstart

• URL: https://docs.baanx.com/guides/oauth/quickstart
• Key excerpt:
  • The quickstart says API keys come from a technical account manager, redirect URIs must be whitelisted, custom schemes require approval, and users must explicitly consent to what partner apps can access and do.
  • It distinguishes Hosted UI versus API Mode and frames Baanx as the auth and authorization boundary.
• Why it matters:
  • This makes partner admission, key issuance, redirect policy, and consent handling part of the company control surface.

4) Consent management overview

• URL: https://docs.baanx.com/guides/consent/overview
• Key excerpt:
  • The Consent Management API describes immutable audit trails, US-versus-global policy types, E-Sign Act handling for US flows, and staged linking from onboarding IDs to permanent user IDs.
  • Audit records include timestamps, IP addresses, and user-agent tracking.
• Why it matters:
  • This is not just a UI nicety; it shows Baanx operating a compliance-state machine that downstream partners inherit.

5) llms.txt docs index

• URL: https://docs.baanx.com/llms.txt
• Key excerpt:
  • The index exposes registration, phone/email verification, Veriff KYC sessions, card APIs, consent APIs, delegation flows, internal/credit/reward wallet objects, whitelist operations, and webhook configuration.
• Why it matters:
  • The breadth of the operator surface is the argument for the company note.

6) Credit wallet API

• URL: https://docs.baanx.com/api-reference/wallet/credit
• Key excerpt:
  • Credit wallets hold funds available for spending through the platform and expose balance, currency, and isWithdrawable status.
  • The docs warn withdrawal restrictions may depend on verification status, pending transactions, or platform policies.
• Why it matters:
  • This shows Baanx is defining offchain ledger semantics and eligibility policy, not merely passing through onchain approvals.

Working conclusion

Baanx is more usefully split into product and company layers. The project note should keep delegated-spend mechanics, card-linking, and wallet-priority routing visible. The company note should capture the named operator boundary around API credentialing, onboarding and Veriff, consent policy, wallet-mode packaging, ledger restrictions, and the FCA-registered legal shell partners actually inherit.