# Interpreting Eligibility Requirements

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.

### Eligibility Response Overview

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 = true` does not imply that an identity has already been created.


### When Requirements Are Empty

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.

## Requirements Dictionary

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 |


## How to Handle Requirements in Your Integration

Recommended approach:

1. Check eligibility once sufficient transaction context is available.
2. If no requirements are returned:
  - Ensure an identity exists
  - Continue to ramp creation.
3. 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.

## Progressive Compliance

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