> For the complete documentation index, see [llms.txt](https://docs.ur.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ur.app/concepts/kyc-and-compliance.md). # KYC & compliance UR is a regulated financial product. Every end user must complete **Know Your Customer (KYC)** checks before they can access core banking features such as external transfers, IBANs, debit cards, and FX. This page explains **what** UR verifies, the data UR collects, and **how** each check works. It lists the data fields and the options behind each check, but not the exact user-facing question wording, which UR's compliance team configures and shows to users at runtime through 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, including endpoints, status enums, and webhooks, see the [Developer Resources](/developer-resources/api-reference-external-wallet-access-mode.md) section. ## What UR verifies UR verifies five core areas: **identity**, **domicile**, **account purpose and source of funds**, **beneficial ownership**, and **sanctions exposure**. Each area is collected through a dedicated check described below. ### Data conventions UR applies the following conventions to all KYC data: * **Eligibility basis:** UR determines eligibility by the user's country of residence (domicile). A small set of restricted nationalities (US persons, North Korea, Iran, Russia) is excluded regardless of residence. See [Supported regions](/getting-started/supported-regions.md) for the unsupported-residence list and the restricted nationalities. * **Language:** all data shared with compliance must be in English. For users from non-English-speaking countries, personal-data fields such as name and address are collected in both native script and Latin transliteration. * **Country codes:** ISO 3166-1 alpha-3 (for example, `POL`, `CHN`, `DEU`, `CHE`). * **Dates:** `YYYY-MM-DD`. ### Identity verification UR offers three identity-verification methods. NFC is the primary path. Penny transfer and video verification support users who cannot complete an NFC scan. | Method | Role | User device | | ---------------------- | -------------------------- | --------------------------- | | **NFC + liveness** | Primary | NFC-capable mobile device | | **Penny transfer** | Fallback for EU/FATF users | Any (bank account required) | | **Video verification** | Reserved fallback | Any (camera required) | #### NFC scan + liveness check *(primary)* The user scans the electronic chip in their biometric passport or national ID through the Sumsub mobile SDK. UR validates the chip data against the document's certificate chain and reads the identity details directly from the chip, including document number, issuing country, name, date of birth, gender, expiry date, MRZ, and photo. The document must be valid for at least 3 months from the date of submission; UR blocks a document that expires sooner or has already expired. The extracted name, date of birth, and nationality must match the questionnaire responses. The user then completes a **liveness check**, a short selfie capture in the SDK that confirms the person is physically present. The live photo is matched against the photo retrieved from the NFC chip. Verification only passes when both the liveness check and the photo match succeed. NFC scanning requires an NFC-capable mobile device. Web-only platforms cannot complete this step through the Sumsub web SDK. See the note in [The User Lifecycle](/concepts/overview-the-user-lifecycle.md). In the **UR-hosted webview** integration path, the NFC chip scan, document scan, and selfie are completed in **ReadID** (the ReadID app on Android, or an [App Clip](https://developer.apple.com/app-clips/) on iOS), which UR orchestrates for you. The questionnaire and the domicile (device location) check run in the webview itself. An NFC-capable mobile device is still required for the ReadID step; the webview path removes the partner's need to build the NFC handoff, not the NFC scan itself. #### Penny transfer *(fallback for FATF-jurisdiction users)* For users who cannot complete an NFC scan, UR supports a **penny transfer**. The user sends a small bank transfer from their personal bank account to their UR IBAN. UR validates the inbound transfer details and uses them as proof of identity, together with the standard liveness check. **Constraints** | Constraint | Detail | | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Same name | Sender name must match the UR account holder. Family-member or business accounts are not accepted. | | FATF country | The sender's bank must be in one of the 37 active FATF member jurisdictions, determined from the BIC/SWIFT country code. | | Currency | EUR (primary) or CHF. USD is not supported because KYC must be completed before a USD IBAN can be issued. | | Amount | Approximately 50 CHF or EUR is recommended; amounts up to 500 CHF or EUR are accepted. There is no enforced minimum; any received amount can be used for validation. Larger transfers may be subject to post-activation account limits. | | Processing time | Typically 1 to 2 business days. | {% hint style="info" %} **Eligibility.** Penny transfer is only available to users whose bank is in a FATF jurisdiction. Users outside that scope are routed to the NFC flow. {% endhint %} #### Video verification *(reserved fallback)* For users who cannot complete either NFC or penny transfer, for example because they have no NFC-capable device and no FATF-jurisdiction bank account, UR offers a video-verification path coordinated case by case with the support team. Contact when a user reaches this state. ### Domicile verification (proof of address) | Method | Role | How it works | | ------------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **GPS check** | Primary | The user confirms that they are at their declared home address. The device captures GPS coordinates, which UR reverse-geocodes and compares with the address provided in the questionnaire. | | **Document upload** | Alternative | When GPS is not viable, the user uploads a document proving residential address. | The GPS check passes when the device location is within the expected proximity of the declared address. | Constraint | Accepted | | ------------- | ------------------------------------------ | | Document type | Government-issued documents, utility bills | | Document age | Issued within the last 3 months | | Languages | English, German, French, or Italian | ### 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, and acceptance of UR's Terms of Use, Privacy Policy, and Card Terms. * **Personal information:** legal name, date of birth, gender, nationality, residential address, and verified email. * **Employment:** employment status (employed, self-employed or freelancer, retired, student or trainee, unemployed); job category when employed (employee, manager, C-level or executive, director or board member); and business sector. * **Account purpose:** the user's intended use of the UR account, such as crypto off-ramp, savings, or investment. * **Source of funds:** gross annual income range (under 50,000; 50,000 to 100,000; 100,000 to 500,000; 500,000 to 1,000,000; over 1,000,000 USD), approximate total assets range (under 100,000; 100,000 to 500,000; 500,000 to 1,000,000; over 1,000,000 USD), and source-of-funds category (business income or salary, savings and pension, investments, inheritance, or other). * **Declarations:** address-accuracy declaration, the FINMA-required acknowledgment that deposits are not covered by any depositor-protection scheme, and other regulator-required attestations. The user must confirm UR-specific declarations explicitly; they cannot be auto-filled. ### Beneficial ownership declaration (Form A) A **Beneficial Ownership Declaration (Form A)** identifies the natural person or persons who ultimately own or benefit from the assets held in the UR account. UR generates the declaration from the user's KYC responses, and the user signs it as part of the KYC flow. For most individual users, Form A confirms that the user is the beneficial owner of the assets. If another person is the beneficial owner, UR may need to collect that person's required identifying information. Depending on the partner UX, Form A can be handled inside the Sumsub process or integrated as a separate signing step. See [Component 4 in The User Lifecycle](/concepts/overview-the-user-lifecycle.md). The declaration consolidates the user's confirmations into a single signed statement. It covers that the user is over 18, is not a national of North Korea, Iran, or Russia, and is not a US person; that the residential address and sole country of tax residence are accurate; that the user is the sole beneficial owner of the account assets; the declared source of funds; acceptance of the Terms of Use, Privacy Policy, and Card Terms; acceptance of the business risks of using UR; and the FINMA acknowledgment that deposits are not protected by any depositor-protection scheme. The statement also notes that deliberately providing false information is a criminal offense under article 251 of the Swiss Criminal Code. UR renders the exact text from the user's collected data and returns it for the user to read and sign; display it verbatim. For the fetch, sign, and submit endpoints, see the [Developer Resources](/developer-resources/api-reference-managed-custody-mode.md). ### Tax self-certification (CRS) Under the Common Reporting Standard (CRS), UR collects a tax-residency self-certification, either at onboarding or as an ongoing-KYC task. The user declares each country of tax residence as an ISO 3166-1 alpha-3 code, together with a Taxpayer Identification Number (TIN) whose format matches that country. A user with more than one tax residence provides one entry per residence. If a CRS task is due and the user misses its deadline, the account moves to `SoftBlocked` until the task is completed. ### 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 capture list changes after onboarding. * **On transactions:** specific transactions may trigger additional risk-based checks, such as a step-up liveness check before high-value off-ramps. See `needLivenessCheck` in the [API reference](/developer-resources/api-reference-managed-custody-mode.md). A user who fails sanctions screening, is from an unsupported country, or has an unsupported nationality is rejected during compliance review. The user remains in `Tourist` status and cannot access core banking features. ## When KYC happens UR runs KYC when a user opens a UR account and continues compliance monitoring throughout the user's lifecycle. After the initial KYC verification, UR may request additional information through ongoing KYC, client enhanced due diligence, or transaction enhanced due diligence depending on the user's profile, activity, and regulatory requirements. | Review type | When it happens | What UR may collect | | ---------------------------------- | ---------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Initial KYC verification | During account opening, before the user can access core banking features | Questionnaire, domicile verification, identity verification (NFC, penny transfer, or video), signed Beneficial Ownership Declaration (Form A), and AML/sanctions screening. | | Ongoing KYC | Periodically, or when regulatory refresh rules require updated user information | Refreshed proof of address, updated questionnaire responses, refreshed identity documents, CRS self-certification, or a re-signed Form A. | | Client enhanced due diligence | When the user's profile, country, occupation, source of funds, or other risk signals require deeper review | Additional information about account purpose, source of funds, source of wealth, expected activity, supporting documents, or compliance attestations. | | Transaction enhanced due diligence | When a specific transaction or activity pattern triggers additional risk-based review | Transaction rationale, supporting documents, additional liveness checks, or other information needed to assess the transaction. | ## Verification outcomes KYC results map directly to the user's URID status: | Outcome | URID status | What the user can do | | -------------------------------------------------------------- | ------------- | -------------------------------------------------------------- | | Initial eligibility completed | `Tourist` | Receive funds (up to 250 USD/EUR), receive partner off-ramp | | KYC approved | `Live` | All banking features: external transfers, IBAN, debit card, FX | | Compliance review failed or user rejected | `Tourist` | Core banking features unavailable | | Pending ongoing KYC or enhanced due diligence, 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:** KYC provider for the questionnaire, the domicile (device location) check, document upload, and AML/sanctions screening. When you integrate the Sumsub SDK directly (External Wallet Access Mode), the document scan, NFC chip read, and liveness check also run in the Sumsub mobile SDK. * **ReadID:** in the UR-hosted webview path, performs the passport/national-ID NFC chip read, document scan, and selfie/liveness capture. The user opens ReadID as a mobile app or via the iOS App Clip. UR sends the final compliance decision (`Pass` / `Rejected`) to you via the [`kyc_status` webhook](/developer-resources/webhook.md). ## Additional KYC After a User Goes Live KYC does not end at onboarding. After a user becomes `Live`, UR may request additional verification when regulatory refresh rules, risk signals, or compliance reviews require updated information. Examples include a proof-of-address refresh, passport re-scan, re-signed Form A, full re-verification, or CRS self-certification. These requests map to the ongoing KYC and enhanced due diligence reviews described in [When KYC Happens](#when-kyc-happens). If the user misses the deadline for an open additional KYC task, the user moves to `SoftBlocked` and money features remain locked until the task is completed. For partners, additional KYC follows three integration steps: | Step | What you do | Where it's documented | | ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **1. Detect the required task** | Poll the account/status endpoints and read `kycRetryVerificationLevel`, `kycCurrentStep`, and `crsInfo` (`needCrs`, `restrictDate`, `url`) to see what the user must complete and by when. Partners can also receive the compliance result proactively via webhook. | [Fetch UR Account Information](/developer-resources/openapis.md#fetch-ur-account-information), including the **KycRetryVerificationLevel** and **kycCurrentStep** enum tables; per-mode account status with `kycFlow` and `crsInfo` in the [External Wallet Access Mode API reference](/developer-resources/api-reference-external-wallet-access-mode.md) | | **2. Collect and submit the update** | Re-initiate the Sumsub flow for the required retry level using `isRetryVerification=true` and the matching `retryLevel`, with optional `stepType` when needed. The user then completes the requested step in the Sumsub SDK. For CRS, direct the user to the `crsInfo.url` link returned by the status endpoint. | Get Sumsub SDK Token (`/api/v1/sumsub/create-access-token`) in the [External Wallet Access Mode API reference](/developer-resources/api-reference-external-wallet-access-mode.md); for external (non-Mantle) networks, [Create Sumsub Access Token By Network](/developer-resources/openapis.md#create-sumsub-access-token-by-network) | | **3. Receive the decision** | UR sends the compliance decision (`Pass` / `Rejected`) to your webhook. Partners can also query status again to confirm the latest result. | [`kyc_status` webhook](/developer-resources/webhook.md); [Query Sumsub Status By Network](/developer-resources/openapis.md#query-sumsub-status-by-network) | The retry level in `kycRetryVerificationLevel`, such as `ResetAll`, `ResetSign`, `ResetGPS`, or `RetryVerificationPassport`, tells you which data points the user must provide again. See the enum tables in [OpenAPIs](/developer-resources/openapis.md#fetch-ur-account-information) for the full mapping. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.ur.app/concepts/kyc-and-compliance.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.