The Banxa Native API supports multiple identity and KYC integration models, allowing partners to choose how customer information is created, shared, and verified.
All models use a persistent identityReference to represent a single end user across transactions.
Partners may use one model exclusively or combine models over time as users progress.
Partners can create a lightweight identity record without submitting verification documents.
This model is suitable for:
- Low-risk or low-value transactions
- Jurisdictions where KYC-free thresholds are permitted
- Fast onboarding flows for first-time users
In this model:
- The identity exists with minimal information
- Eligibility determines whether additional verification is required
- Some transactions may proceed without any KYC
If eligibility later requires verification, the same identity can be upgraded without restarting onboarding.
If a user has already completed verification with a supported KYC provider, partners can share that verification with Banxa.
Currently, Banxa supports token sharing with Sumsub.
This model allows partners to:
- Reuse existing KYC outcomes
- Avoid duplicate document collection
- Keep onboarding entirely within their own UX
Typical use cases include:
- Wallets with embedded KYC
- Platforms with established onboarding flows
- Returning users who have already been verified elsewhere
If you use a different KYC provider, please contact Banxa to discuss supported options.
Eligibility determines whether the shared verification is sufficient for the current transaction context.
In some cases, Banxa can rely on a partner’s own customer identification and verification program.
This model is typically used by:
- Regulated platforms
- Financial institutions
- Partners operating their own AML / KYC frameworks.
When identity reliance is approved:
- Banxa may treat applicable identity verification requirements as satisfied for the agreed scope and transaction context
- Eligibility still governs whether additional information is needed
This model requires prior agreement and configuration.
Where Banxa performs verification directly, partners can submit identity information and documentation via API.
This model is suitable for:
- Partners that do not run their own KYC flows
- Transaction contexts where document-based verification is sufficient
Note that some verification capabilities (such as selfie or liveness capture) may require additional coordination.
If your use case depends on these capabilities, please contact Banxa to discuss available options.
Submitted information is associated with the existing identity and reused for future transactions where permitted.
These models are not mutually exclusive.
A single identity may:
- Start as KYC-free
- Later reuse shared KYC
- Be escalated with additional information submitted to Banxa
Eligibility determines:
- Whether the current identity state is sufficient
- What additional information is required, if any
Partners should rely on eligibility responses to decide when and how to collect or submit identity information.
The right model depends on how much control you want over onboarding and whether you already perform KYC.
Choose Basic Identity Creation if:
- You want the fastest possible onboarding
- You support low-value or low-risk transactions
- You are comfortable escalating verification only when required
Choose KYC Provider Token Sharing if:
- You already verify users using Sumsub
- You want to avoid collecting documents twice
- You want full control over the user experience
Choose Identity Reliance if:
- You are a regulated entity with your own compliance program
- You already meet Customer Identification requirements
- You want Banxa to rely on your existing verification
Choose KYC Submission to Banxa if:
- You do not operate your own KYC flows
- Your use cases can be satisfied with document-based verification
- You want Banxa to manage verification where possible
Eligibility is the control plane for identity verification.
Partners should:
- Create or reference an identity using a persistent
identityReference - Check eligibility for the intended transaction
- Collect and submit additional information only if eligibility requires it
- Re-check eligibility before proceeding with the transaction
This ensures users are only asked for additional information when it is actually required.