The eligibility check evaluates whether a specific transaction can proceed for a given identity and transaction context.
When additional information is required, the response includes a list of requirements. These requirements indicate what your platform needs to collect next in order to satisfy compliance and continue the transaction.
Each requirement represents a category of information, not always a single field.
The eligibility response indicates whether a transaction can proceed and whether additional information is required.
It includes two key signals:
- paymentReady – whether the transaction can proceed immediately
- requirements – which categories of information are required, if any
A common and valid outcome is:
- paymentReady = true
- requirements = empty
This means the transaction can proceed without collecting additional information.
Note:
An identity must still exist before a ramp can be created.paymentReady = truedoes not imply that an identity has already been created.
An empty requirements list is expected in the following cases.
KYC-free or low-risk transactions
For some transaction contexts, no identity verification is required.
Eligibility will return paymentReady = true with no requirements.
If the user does not yet have an identity, the partner must still create or establish one before proceeding with ramp creation.
Returning users with existing verification
If a returning user has already completed the necessary verification for the current transaction context, eligibility will also return paymentReady = true with no requirements.
Previously submitted identity information is reused and no further user action is required.
If the transaction context changes (for example, a higher transaction amount, a different payment method, or a new jurisdiction), eligibility may return additional requirements and paymentReady may become false until those requirements are satisfied.
The table below explains what each eligibility requirement means and what your platform is expected to collect.
| Requirement | What this means | What you need to collect |
|---|---|---|
| PERSONAL_DETAILS | Basic identity information is required | Name, date of birth, email, mobile number, residential address |
| DOCUMENT | Identity documents are required | Passport or government ID details, document metadata |
| SELFIE | A selfie or liveness check is required | Live selfie capture or selfie image Note: Selfie and liveness are currently supported via Sumsub token sharing, or through Banxa-hosted flows where applicable. |
| OCCUPATION | Occupation information is required | Occupation industry and occupation (job title) from a predefined list |
| SOURCE_FUNDS | Source of funds or wealth must be declared | Select from a predefined list, e.g. Salary |
| PURPOSE_OF_TX | Transaction purpose is required | Reason for transaction (e.g. investment, remittance) |
| US_TAX_ID / TIN | A tax identifier is required | SSN, ITIN, or other jurisdictional tax identifier |
| POA | Proof of address is required | Utility bill, bank statement, address evidence |
Recommended approach:
- Check eligibility once sufficient transaction context is available.
- If no requirements are returned:
- Ensure an identity exists
- Continue to ramp creation.
- If requirements are returned:
- Collect the required information in your UX.
- Submit the information using the appropriate identity mechanisms.
- Re-check eligibility before proceeding.
Multiple requirements may be returned at the same time. Where possible, collect them together to minimise user friction.
Eligibility requirements are evaluated dynamically.
As transaction parameters change — such as transaction size, payment method, or jurisdiction — additional requirements may be returned.
This enables progressive onboarding:
- Low-risk transactions proceed with minimal information
- Returning users benefit from previously completed verification
- Higher-risk transactions trigger additional checks only when required