KYC & compliance

What UR verifies during KYC, the data we collect, and the methods we use.

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. For implementation details, including endpoints, status enums, and webhooks, see the Developer Resources 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 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.

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 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	The inbound penny remittance is EUR (primary) or CHF. (A USD virtual IBAN is not required beforehand: for eligible partners the USD vIBAN is provisioned for Tourist users before KYC completes, so a USD IBAN is not gated on finishing KYC.)
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.

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.

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 [e-mail] 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 Swiss IBAN 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.

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.

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.

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
URID minted, before KYC	Tourist	Receive partner off-ramp and inbound P2P (up to 250 USD/EUR); cannot move funds externally
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.

The KYC step machine depends on the path. Partner-managed (FMA) partners who push data or hand over a share token see the coarse sequence PartnerDataIngestion -> IdentityVerification -> SignFormA -> Register, while FMA partners on the Sumsub SDK see the fine-grained Sumsub steps ending IdOrPassportOrOtherIdInformationScan -> IdAndLiveness -> SignFormA -> Register. The UR-hosted flow runs the same fine-grained steps. See the state tables in Managed Custody SDK KYC and Managed Custody Mode.

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.

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.

How you integrate additional KYC depends on which KYC model your partnerId uses. The two models do not share endpoints or webhooks, so read only the one that applies to you.

Partners on the UR-hosted KYC flow

This covers External Wallet Access Mode and other integrations where the user completes KYC through UR's own flow. The task is discovered by polling, and the outcome arrives on kyc_status.

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.	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
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
3. Receive the decision	UR sends the compliance decision (Pass / Rejected) to your webhook. You can also query status again to confirm the latest result.	kyc_status webhook; 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 for the full mapping.

The retry parameters above apply to /api/v1/sumsub/create-access-token. The by-network variant, Create Sumsub access token by network, takes only tokenId and network and always issues a token at the flow's start level, so it cannot drive a specific retry level. If your users are on an external (non-Mantle) network, confirm the path for additional KYC through your dedicated integration channel.

If the user misses the deadline for an open task on this model, the user moves to SoftBlocked and money features stay locked until the task is completed.

Partner-managed (FMA) partners

Partners who own the KYC user experience do not poll for these tasks. UR operations issue a retry directive, and your platform is notified over webhook. There is no polling step and no kyc_status event.

Step	What you do	Where it's documented
1. Receive the directive	Handle the fma.additional_kyc.required webhook. Its taskType says what the user must redo, and dataChannel says which of your integration paths applies. Neither your platform nor the user can start a retry.	Retry KYC; payload contract in Webhooks
2. Claim a session and collect the data	Call POST /api/fma/v1/kyc/session/create to claim the session UR created, then run only the steps taskType names, through the same endpoint your channel uses for onboarding. Re-sign Form A, and call /kyc/submit only when fiat24Mode is auto_register.	Retry KYC, including a per-channel walkthrough and lifecycle diagram
3. Record completion	UR sends fma.additional_kyc.completed when the session reaches its last step. No further call is required.	Retry KYC

On this model the directive's deadlineAt is informational: UR does not expire the directive or the session when it passes, and no event fires at the deadline. Compliance applies the consequences off-platform.