# KYC & Compliance

UR is a regulated financial product. Every end user must complete a **Know Your Customer (KYC)** process before they can access core banking features (external transfers, IBAN, debit card, FX). This page describes **what** UR verifies and **how** — not the specific question texts, which are owned by UR's compliance team and presented to the user at runtime via the Sumsub SDK.

For the user-journey view of when each step happens, see [The User Lifecycle](/concepts/overview-the-user-lifecycle.md). For implementation details (endpoints, status enums, webhooks) see the [Developer Resources](/developer-resources/api-reference-external-wallet-access-mode.md) section.

## What UR Verifies

UR verifies four things: **identity**, **domicile**, **account purpose & source of funds**, and **sanctions exposure**. Each is collected through a dedicated method below.

### 1. Identity Verification

**Method: NFC chip scan of a biometric passport or national ID + liveness check.**

The user scans the electronic chip on their biometric passport or national ID via the Sumsub mobile SDK. UR validates the chip data against the document's certificate chain and reads the user's identity details directly from the chip (document number, issuing country, name, date of birth, gender, expiry, MRZ, photo).

The user then completes a **liveness check** — a short selfie capture via the SDK that confirms the person is physically present and live. The live photo is matched against the photo retrieved from the NFC chip; the verification only passes when both the liveness signal and the photo match succeed.

NFC scanning requires an NFC-capable mobile device. Web-only platforms cannot complete this step via the Sumsub web SDK — see the note in [The User Lifecycle](/concepts/overview-the-user-lifecycle.md).

### 2. Domicile Verification (Proof of Address)

**Primary method: GPS check.** The user confirms they are at their declared home address. The device captures GPS coordinates, which UR reverse-geocodes and compares against the address provided in the questionnaire. The check passes when the device location is within the expected proximity of the declared address.

**Alternative method: Document upload.** When GPS is not viable, the user uploads a document proving residential address.

| Constraint    | Accepted                                                                   |
| ------------- | -------------------------------------------------------------------------- |
| Document type | Government-issued documents, utility bills, bank or credit card statements |
| Document age  | Issued within the last 3 months                                            |
| Languages     | English, German, French, or Italian                                        |

### 3. Account Questionnaire

The questionnaire collects the information UR needs to operate a regulated bank account. The categories are listed below; the canonical question set is configured in Sumsub and presented to the user at runtime.

* **Eligibility** — age (18+), citizenship in non-restricted jurisdictions, US Person status, PEP (politically exposed person) declaration, acceptance of UR's Terms of Use and Privacy Policy.
* **Personal information** — legal name, date of birth, gender, nationality, residential address, verified email.
* **Employment** — employment status, job category, business sector.
* **Account purpose** — the user's intended use of the UR account (e.g. crypto off-ramp, savings, investment).
* **Source of funds** — annual income range, total assets range, source-of-funds category.
* **Declarations** — beneficial-ownership declaration, address-accuracy declaration, deposit-protection acknowledgment, and other regulator-required attestations.

A separate **Beneficial Ownership Declaration (Form A)** is generated from this data and signed by the user at the end of the flow. See [Component 4 in The User Lifecycle](/concepts/overview-the-user-lifecycle.md).

### 4. AML & Sanctions Screening

UR runs automated AML (Anti-Money Laundering) screening throughout the user's lifecycle:

* **At onboarding** — the user is screened against international sanctions lists, PEP lists, and adverse media.
* **Continuously** — users are re-screened periodically to catch list changes after onboarding.
* **On transactions** — specific transactions may trigger additional risk-based checks. For example, a step-up liveness check before high-value off-ramps; see `needLivenessCheck` in the [API reference](/developer-resources/api-reference-delegated-contract-mode.md).

A user who fails sanctions screening cannot use UR services and is moved to `Blocked` status.

## When KYC Happens

UR runs a two-stage **progressive KYC** flow at onboarding, plus ongoing verification triggered by risk or regulatory events.

| Stage                    | Status    | What's collected                                                                                                                                                    |
| ------------------------ | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Stage 1 — Sign-up        | `Tourist` | Eligibility checks + basic personal/contact details (questionnaire subset). Sufficient to mint a Tourist URID and issue a restricted IBAN.                          |
| Stage 2 — Full KYC       | `Live`    | Full questionnaire + domicile verification + identity verification (NFC + liveness) + Form A signature. Required before the user can move funds externally.         |
| Ongoing — Additional KYC | varies    | UR may trigger re-verification at any time (refresh proof of address, re-scan passport, re-sign Form A, CRS self-certification). Partners are notified via webhook. |

## Verification Outcomes

KYC results map directly to the user's URID status:

| Outcome                                 | URID status   | What the user can do                                           |
| --------------------------------------- | ------------- | -------------------------------------------------------------- |
| Stage 1 passed                          | `Tourist`     | Receive funds (up to 250 USD/EUR), receive partner off-ramp    |
| Full KYC approved                       | `Live`        | All banking features: external transfers, IBAN, debit card, FX |
| Compliance review failed                | `Blocked`     | No UR services                                                 |
| Pending Additional KYC, deadline missed | `SoftBlocked` | Money features locked until the open task is completed         |

For the on-chain status mapping (`Tourist=2`, `Live=5`, etc.) see [Smart Contracts](/developer-resources/smart-contracts.md). For the KYC step machine (`FormA → IDScan → SignFormA → Review`) see the [API reference](/developer-resources/api-reference-external-wallet-access-mode.md).

## Vendors

* **Sumsub** — primary KYC provider for the questionnaire, document scanning, NFC chip read, liveness check, and document upload.
* **ReadID** — secondary NFC scanning provider used in specific retry flows.

The final compliance decision (Pass / Rejected) is relayed to partners via the [`kyc_status` webhook](/developer-resources/webhook.md).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.ur.app/concepts/kyc-and-compliance.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.