## Identity Creation & KYC Models 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. ### 1. Basic Identity Creation (KYC-Free / Low-Tier) 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. ### 2. KYC Provider Token Sharing 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. ### 3. Identity Reliance (Partner-Managed KYC) 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. ### 4. KYC Submission to Banxa 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. ## How These Models Work Together 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. ## Which Model Should I Choose? 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 ## How Eligibility Fits In Eligibility is the control plane for identity verification. Partners should: 1. Create or reference an identity using a persistent `identityReference` 2. Check eligibility for the intended transaction 3. Collect and submit additional information only if eligibility requires it 4. Re-check eligibility before proceeding with the transaction This ensures users are only asked for additional information when it is actually required.