# Video identification via IDnow

This guide describes how to implement video identification via [IDnow](https://www.idnow.io) for completing the Know Your Customer (KYC) process in your solution. You can implement this feature either as a standalone solution or in combination with Solaris CRR products.

## Introduction

### User journey

Below are the steps involved in performing customer KYC using video identification via IDnow:

1. In your frontend, during the sign-up flow, the customer provides the required data points and their consent to Solaris' Terms and Conditions and data processing terms.
2. Inform the customer that they will be redirected to IDnow to complete the identification process. List the documents that they will be required to provide.
3. Your solution forwards the customer and their data to IDnow using the [IDnow SDK](#idnow-integration).
4. IDnow will prompt the customer to begin a video identification session with an IDnow agent (either in English or in German). The customer must provide the following:
  - A government-issued identification document (e.g., passport or national ID card).
  - A document that proves their address (only if their identification document does not include an address).
  - A valid mobile number.
5. During the video session, the following steps will occur:
  - The IDnow agent will verify the data provided by the customer during your sign-up flow against the data in their identification document.
  - The IDnow agent will collect any missing information.
  - IDnow will verify the customer's mobile number using an SMS one-time password.
6. Once the process completes, the customer will be redirected to your frontend to complete the sign-up flow.


### Eligibility

Video identification via IDnow is the primary identification method for customers residing in **Germany**.

For customers residing in other EU countries (excluding Germany), [Fourthline](/guides/kyc/fourthline) is the recommended identification method.

Regardless of residence, your customer must possess one of the documents listed on [IDnow's supported documents page](https://go.idnow.de/bafin2017/documents).

Note
IDnow offers video identification via mobile (SDK) or webview. For the sake of fraud prevention, Solaris strongly recommends integrating IDnow's **mobile SDK** instead of the webview APIs.

If your customer does not have an identification document from the supported list, then you must complete KYC using a [different method](/guides/kyc/).

For more information about which KYC method fits which use case, see the [KYC section of the onboarding requirements guide](/guides/get-started/onboarding-requirements/5-kyc/#digital-banking--cards).

## System prerequisites

Before integrating this feature, you must implement the following requirements in your solution:

**1. Technical setup**

Set up your environment and get your authentication keys. For instructions, see the [Technical setup guide](/guides/get-started/technical-setup).

**2. Legal and compliance screens**

Build the necessary legal and compliance screens in your sign-up flow to collect your customers' consent to the necessary legal and compliance requirements. The [Legal and compliance screens guide](/guides/get-started/onboarding-requirements/1-legal-compliance-screens) explains how to create these screens and lists their mandatory contents.

Record the customer's consent on each screen as a UTC timestamp (e.g., `2019-01-01T00:00:00Z`). Pass each timestamp in its respective field to Solaris.

* Collect the customer's consent to Solaris' Terms and Conditions and store the timestamp in the `terms_conditions_signed_at` field.
* Collect the customer's consent to data processing and store the timestamp in the `data_terms_signed_at` field.


These fields belong to the `person` resource, which stores all customer data points.

### IDnow integration

In addition to the Solaris technical prerequisites, you must also integrate IDnow into your solution. You can achieve this either using IDnow's **mobile SDKs** (available for iOS and Android) or using their **webview APIs** (for desktop).

For instructions on how to set up IDnow in your solution, see the following IDnow documentation links:

- **Mobile:**
  - [iOS SDK](https://github.com/idnow/de.idnow.ios)
  - [Android SDK](https://github.com/idnow/de.idnow.android)
- **Desktop (Webview):**
  - [API documentation](https://docs-videoident.idnow.io/#9fc992bc-3ceb-4cbf-a7e8-bbdc03dbd50e)


Please read the security considerations below before completing this section.

#### Security considerations

Video identification methods can be manipulated by identity fraudsters who collect personal data from individuals under false pretenses (e.g., app testing). Therefore, it's crucial that your solution integrates the data collection and the video identification processes. This minimizes the threat of fraudsters hijacking the customer identification session.

For security reasons, Solaris **strongly recommends** using the **mobile SDKs** for video identification instead of the webview APIs.

warning
Each IDnow identification session has a reference ID. Do not share this ID with the customer under any circumstances.

### Webhooks

You must subscribe to the following webhook events to ensure that your system receives notifications for crucial events in the identification process. For detailed instructions on implementing Solaris webhooks, see the [webhooks documentation](/api-reference/webhooks/).

- [IDENTIFICATION](/api-reference/onboarding/webhooks/webhook-events/paths/identification/post)
- [PERSON_CHANGED](/api-reference/onboarding/webhooks/webhook-events/paths/person_changed/post)
- [PERSON_DELETED](/api-reference/onboarding/webhooks/webhook-events/paths/person_deleted/post)
- [PERSON_MOBILE_NUMBER_CREATED](/api-reference/onboarding/webhooks/webhook-events/paths/person_mobile_number_created/post)
- [PERSON_MOBILE_NUMBER_DELETED](/api-reference/onboarding/webhooks/webhook-events/paths/person_mobile_number_deleted/post)


## Step 1: Collect customer data and create person resource

You must begin by collecting the mandatory data points from the customer in your sign-up flow, including timestamps from when the customer consented to each of the [legal and compliance screens](#system-prerequisites). Afterward, pass all the data points to Solaris by calling the API to create a person resource.

**API reference**

For a complete list of endpoints, properties, and examples related to the `person` resource, visit the following links:

- [Person resource API reference](/api-reference/onboarding/persons/#tag/Persons)
  - [POST Create person](/api-reference/onboarding/persons/#tag/Persons/paths/~1v1~1persons/post)
  - [GET Retrieve a person](/api-reference/onboarding/persons/#tag/Persons/paths/~1v1~1persons~1%7Bid%7D/get)
  - [PATCH Update person](/api-reference/onboarding/persons/#tag/Persons/paths/~1v1~1persons~1%7Bid%7D/patch)


**Related webhook events**

- [`PERSON_CHANGED`](/api-reference/onboarding/webhooks/webhook-events/paths/person_changed/post)
- [`PERSON_DELETED`](/api-reference/onboarding/webhooks/webhook-events/paths/person_deleted/post)


Important points about data collection
- Review the special requirements in the [Onboarding requirements guide](/guides/get-started/onboarding-requirements/2-data-collection/#important-considerations-for-data-collection).
- Submit information exactly as it appears in official documents.
- **Sandbox Testing:** Ensure that each person you create has unique values for `first_name`, `last_name`, `birth_city`, and `birth_date`. If you create over 1000 identical person resources, the API will return a `400` error.
- **Privacy:** Do not use real personal data when testing in Sandbox.


#### POST Create person

This endpoint creates a person resource for your customer. You must collect the mandatory data points from your customer in the sign-up flow and pass them to Solaris in the request body of this endpoint.

- `salutation`
- `first_name` (including all middle names as printed on the ID document)
- `last_name` (including all name parts as printed on the ID document)
- `birth_date`
- `nationality` (Use [ISO 3166-1 alpha-2 codes](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2))
- `mobile_number`
- `address` (Street, Number, City, Post Code, Country, State)
- `data_terms_signed_at` (UTC timestamp)
- `terms_conditions_signed_at` (UTC timestamp)


**Request URL**


```shell
POST /v1/persons
```

**Request example**


```json
{
  "salutation": "Mr",
  "first_name": "Marc",
  "last_name": "O'Polo",
  "birth_date": "1999-01-01",
  "nationality": "DE",
  "mobile_number": "+4917612345678",
  "address": {
    "line_1": "Solaris street",
    "line_2": "1",
    "postal_code": "10119",
    "city": "Berlin",
    "country": "DE"
  },
  "tax_information": {
    "tax_assessment_country": "DE"
  },
  "terms_conditions_signed_at": "2021-01-01T00:00:00Z",
  "data_terms_signed_at": "2021-01-01T00:00:00Z"
}
```

**Response**

The API returns a person object with a unique ID for the person (i.e., the `id`). You will need this `id` to append the person resource with additional information in the remaining steps of this guide.


```json
{
  "id": "dc1a6812a14f6cc338cd084208535bcdcper",
  "salutation": "Mr",
  "first_name": "Marc",
  "last_name": "O'Polo",
  "birth_date": "1999-01-01",
  "nationality": "DE",
  "mobile_number": "+4917612345678",
  ...
}
```

[Click here to view the full API reference](/api-reference/onboarding/persons/#tag/Persons/paths/~1v1~1persons/post)

#### PATCH Update person

This endpoint updates one or more properties on a `person` resource. You can only update the following properties using this endpoint:

- `title`
- `salutation`
- `address` (`line_1`, `line_2`, `postal_code`, `city`,  `state`, `country`)
- `contact_address` (`line_1`, `line_2`, `postal_code`, `city`,  `state`, `country`)
- `employment_status`
- `job_title`
- `email`
- `tax_information` (`tax_assessment`, `marital_status`)
- `fatca_relevant`
- `fatca_crs_confirmed_at`
- `business_purpose`
- `industry`
- `industry_key`
- `own_economic_interest_signed_at`
- `aml_confirmed_on` (only with today or tomorrow's date)
- `expected_monthly_revenue_cents`
- `vat_number`
- `website_social_media`
- `business_trading_name`
- `nace_code`
- `business_address_line_1`
- `business_address_line_2`
- `business_postal_code`
- `business_city`
- `business_country`
- `annual_income_range`
- `data_terms_signed_at`
- `branch`
- `birth_province`
- `birth_post_code`
- `socioprofessional_category`
- `purpose_of_account_opening`
- `main_income_source`
- `work_country`
- `work_province`
- `self_declared_as_pep`
- `international_operativity_expectation`
- `registration_number`


Important
**Restricted Updates:**

* Fields not mentioned in this list can only be updated via Customer Support.


**Freelancer & Self-Employed Requirements (B2C):**

* If a customer changes their `employment_status` to `FREELANCER` or `SELF_EMPLOYED`, you must include **one** of the following in the request to avoid an error:
  1. The customer's `nace_code` (Recommended for data quality).
  2. Set `industry` and `industry_key` to `null`.


**Request URL**


```shell
PATCH /v1/persons/{id}
```

**Request example**

* [API Reference: Update person](/api-reference/onboarding/persons/#tag/Persons/paths/~1v1~1persons~1%7Bid%7D/patch)


## Step 2: Create the identification resource for the customer

Once you have collected the customer's data, you may initiate the KYC process. First, you must create an **identification resource** for the customer. This resource sets various parameters for the identification process and stores the results returned by IDnow.

**API reference**

- [Customer identification (KYC) API reference](/api-reference/identity/identifications)


Prerequisites
- This guide focuses on video identification with **IDnow**.
- Ensure you have completed the [IDnow technical prerequisites](/guides/kyc/videoident/#idnow-integration) (e.g., mobile SDKs or web redirects).


**Related webhook events**

- [`IDENTIFICATION`](/api-reference/onboarding/webhooks/webhook-events/paths/identification/post)


### Create identification

Call this endpoint to initialize the identification process. You must specify the method (`idnow`) and the customer's preferred language.

**Required fields:**

- `method`: Set to `idnow`.
- `language`: `EN` or `DE`.
- `proof_of_address_type`: Required if the ID document does not show the address (e.g., Passport).
- `proof_of_address_issued_at`: Required if providing a proof of address (must be < 6 months old).


Creating the resource does **not** start the video call. You must trigger it in the next step.

**Request example**


```json
// POST /v1/persons/{person_id}/identifications
{
  "method": "idnow",
  "language": "DE",
  "proof_of_address_type": "GAS_BILL",
  "proof_of_address_issued_at": "2022-09-21"
}
```

**Response example**

Returns an identification object with status `created`.


```json
{
    "id": "6dc54352d6793a892e0702850d07b831cidt",
    "status": "created",
    "method": "idnow",
    ...
}
```

[Click here to view the full API reference](/api-reference/identity/identifications/#tag/Person-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1identifications/post).

Custom Flows
The method `idnow_custom` allows for a customized IDnow flow. If you are interested in offering this to your customers, contact your Partner Manager.

### Check supported documents

Before redirecting the customer, check which documents are supported for their country. This avoids user frustration if they attempt to use an unsupported ID.

**Request URL**


```shell
GET /v1/persons/{person_id}/identifications/{id}/supported_documents
```

[Click here to view the full API reference](/api-reference/identity/identifications/#tag/Person-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1identifications~1%7Bid%7D~1supported_documents/get)

### Trigger identification request

Call this endpoint to generate the required tokens and URLs for the IDnow session.

**Request URL**


```shell
PATCH /v1/persons/{person_id}/identifications/{id}/request
```

**Response example**

The status changes to `pending`. The response contains two critical fields depending on your integration type:

- `url`: Use this for **Web** integrations (redirect the user here). **Valid for 14 days.**
- `reference`: Use this token for **Mobile SDK** (iOS/Android) integrations.



```json
{
    "id": "6dc54352d6793a892e0702850d07b831cidt",
    "reference": "TST-KCCEY",
    "url": "[https://go.test.idnow.de/solarisbankvideoidentsandbox/identifications/](https://go.test.idnow.de/solarisbankvideoidentsandbox/identifications/)...",
    "status": "pending",
    ...
}
```

[Click here to view the full API reference](/api-reference/identity/identifications/#tag/Person-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1identifications~1%7Bid%7D~1request/patch).

### The IDnow session


```mermaid
flowchart LR
    A[Start] --> B{Integration Type?}
    B -- Web --> C[Redirect User to 'url']
    B -- Mobile SDK --> D[Init SDK with 'reference']
    C --> E[IDnow Session]
    D --> E
    E --> F{Outcome}
    F -- Success --> G[Webhook: IDENTIFICATION]
    F -- Failure --> H[Retry / Abort]
```

Once you redirect the customer (Web) or initialize the SDK (Mobile), the IDnow session begins.

1. **Consent & Setup:** The customer lands on an IDnow-branded page. They must consent to Terms & Conditions and confirm they have a valid ID document ready.
2. **Mobile Verification:** The customer provides a mobile number. The IDnow agent sends an SMS OTP to this number during the call to verify possession.
3. **Video Call:** The agent connects via video to verify the customer's face and ID document live.
4. **Data Update:** If the agent detects missing or incorrect data (e.g., name spelling), they will update the record directly. These changes are automatically reflected in the `person` resource.


### Retrieve identification status

Once the webhook `IDENTIFICATION` signals success, retrieve the final data.

Use the `?include_documents=true` query parameter to download the images of the ID document and the user's face.

**Request URL**


```shell
GET /v1/persons/{person_id}/identifications/{id}
```

[Click here to view the full API reference](/api-reference/identity/identifications/#tag/Person-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1identifications~1%7Bid%7D/get).

### Other utility endpoints

- [List IDnow attempts](/api-reference/identity/identifications/#tag/Person-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1identifications~1%7Bid%7D~1idnow_attempts/get) (Audit log of failed/aborted calls)
- [Upload additional documents](/api-reference/onboarding/persons/#tag/Person-documents/paths/~1v1~1persons~1%7Bperson_id%7D~1identifications~1%7Bid%7D~1document_upload/post)


After the customer successfully complete the video identification process, you can download the documents submitted during the identification session using our document-related endpoints [here](/api-reference/onboarding/persons/#tag/Person-documents).

## Testing

IDnow offers test scenarios to simulate different outcomes for the identification process. To trigger a test scenario, you can create a `person` resource and set the `first_name` or `last_name` to one of the following prefixes and the name of the relevant test case. The format is as follows:


```text
{{Test scenario}}-{{Test case}}
```

Example:


```text
X-MANUALTEST-HAPPYPATH
```

### Test scenarios

| Prefix | Description |
|  --- | --- |
| `X-MANUALTEST` | Performs a test where you can use the web or app, but the agent is automated. |
| `X-AUTOTEST` | Both the user and the agent are automated. No user interaction required. |


The available test scenarios are as follows:

| Test Case | Description |
|  --- | --- |
| `HAPPYPATH` | Performs a happy path test. The identification is finished successfully and no changes are made. |
| `CHANGEALL` | Performs a successful identification, but changes all fields to new values. In addition, all allowed UTF-8 characters supported by IDnow are returned. |
| `CHANGEALLREVIEW` | Performs a successful identification, but changes all fields during review (and not during the identification like `CHANGEALL`). |
| `ABORTIDENT` | The agent aborts during the identification (e.g. the video quality is not good enough). |
| `FRAUDOK` | The agent reports fraud suspicion during the identification, but during the review the identification is marked as legit. |
| `CANCELED` | The agent performs a successful identification, but during the review it is detected that the ident was not performed correctly (e.g. the picture quality is not good enough). |
| `LONGREVIEW` | Normally, the review of the test scenarios is performed right away (~1-2 Minutes delay). Using the `LONGREVIEW` scenario, the review is performed 24 hours later. |
| `HOLDCERTIFICATE` | The agent performs a successful identification, but the system sends out the signed documents and the results after 10 minutes. **This test is only performable with an eSigning identification.** |
| `FRAUDIDENT` | The agent reports fraud suspicion during the identification and the fraud is confirmed in the review.**This test case is not supported for eSigning.** |


### Happy path test tutorial

Complete the following steps to simulate a successful identification workflow with IDnow on Sandbox.

#### 1. Create a person

Create a `person` [resource](/api-reference/onboarding/persons/#tag/Persons/paths/~1v1~1persons/post) using the following endpoint and set the value of the `first_name` field to `X-MANUALTEST-HAPPYPATH`to trigger the `HAPPYPATH` scenario and any value for the `last_name` in the request body.

**Request**


```json
// POST /v1/persons
{
   "first_name": "X-MANUALTEST-HAPPYPATH",
   "last_name": "{{random_name}}"
}
```

#### 2. Create an identification resource

Create an identification [resource](/api-reference/identity/identifications/#tag/Person-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1identifications/post) and specify the identification `method` as `idnow` in the request body of the following endpoint. Add the `person_id` returned from the previous API call to the request URL.

**Request example**


```json
// POST /v1/persons/{person_id}/identifications
{
   "method": "idnow"
}
```

#### 3. Trigger the identification

To trigger the identification flow, call the following endpoint, using the `person_id` and the identification `id` returned from the previous API call in the request URL.

**Request example**


```shell
PATCH /v1/persons/{person_id}/identifications/{id}/request
```

**Response example**

The API call will return the details of a test video identification session, including `url` (for web browser) and `reference` (for mobile app).


```json
{
    "id": "b80ea8c7f76909749763e77f3efc2c87cidt",
    "reference": "TST-CHMUV",
    "url": "https://go.test.idnow.de/solarisbankvideoidentsandbox/identifications/b80ea8c7f76909749763e77f3efc2c87cidt",
    "status": "pending",
    "completed_at": null,
    "method": "idnow",
    "proof_of_address_type": null,
    "proof_of_address_issued_at": null,
    "language": null,
    "iban": null,
    "terms_and_conditions_signed_at": null,
    "authorization_expires_at": null,
    "confirmation_expires_at": null,
    "estimated_waiting_time": 60
}
```

#### 4. Complete the identification flow

Depending on whether you want to test the identification on the web browser or IDnow mobile application, you can click on the URL to go to the web browser session or enter the reference in the mobile app.

Afterwards, you'll be directed to the video identification flow where you have to:

1. Enter any mobile number that starts with `0` or you can use the static value: `+15550101`, check all boxes and click on **Start identification**.
![Test video identification flow 1](/assets/idnow-happypath1.e4c930d927165d898fd7e40a8f33df8cb39992afff160ee1f574cadf531d5ef9.86e4b84a.png)
2. The flow will start and you'll start seeing different pop-ups with instructions, simulating what would happen in a real video identification session.
3. The flow goes to the successful stage and you have to confirm the identification by entering the following static Ident code: **123456**.
![Test video identification flow 2](/assets/idnow-happypath2.32e1ff19e997b6d4935898ea0af3fea9058ee3839fc4e6ac36512e9078b3ca40.86e4b84a.png)
4. The successful identification screen will appear.
![Test video identification flow 3](/assets/idnow-happypath3.ab6c7587ef834d7f2f225930f7441c04c820e9eaf8fb58d2bc976e067e0cbe55.86e4b84a.png)
5. Afterward, you can call the following endpoint, which will show the identification `status` as `successful`. Additionally, the webhook event `IDENTIFICATION` will be triggered as well after a successful identification.


**Request URL:**


```shell
GET /v1/persons/{person_id}/identifications
```

## What's next?

Congratulations! You have successfully completed the customer KYC process using IDnow video identification.

Check the following appendices for more information on enum values and testing data.

For an overview of other KYC methods, check the identity products [overview page](/guides/kyc/).

### Useful resources

Check the following links for additional related guides and API reference documentation:

- [Customer identification (KYC) API reference](/api-reference/onboarding/persons/#tag/Persons)
- [Person Documents API reference](/api-reference/onboarding/persons/#tag/Person-documents)


## Appendix I: Enums

### Document types

The following table includes the possible values for the field `document_type` and their descriptions.

| Enum | Description |
|  --- | --- |
| `ANNUAL_FINANCIAL_STATEMENT` | A business or company's annual financial statement. |
| `KYC_REPORT` | The KYC report generated after successful customer identification. |
| `ID_DOCUMENT` | A person's identification document, such as a passport or ID card. |
| `SIGNATURE` | A signature sample. |
| `PICTURE` | A picture or scanned document of any other type. |
| `QES_DOCUMENT` | A document related to a Qualified Electronic Signature (QES). |
| `SIGNED_CONTRACT` | A signed contract of any kind. |
| `SIGNED_QES_DOCUMENT` | A document signed by a Qualified Electronic Signature (QES). |
| `REGISTER_APPLICATION` | A document proving the application for registration (Gründungsurkunde), used for companies "in formation". |
| `REGISTER_CHECK` | A register check. |
| `REGISTER_EXTRACT` | A commercial register excerpt or similar document. |
| `FOUNDATION_DOCUMENT` | The foundation document of a company or business. |
| `SCHUFA_COMPACT_REPORT` | A compact SCHUFA report. |
| `SCHUFA_GWG_REPORT` | A GWG (Money Laundering Act) SCHUFA report. |
| `SCHUFA_FULL_REPORT` | A full SCHUFA report about a person. |
| `SCHUFA_SHORT_REPORT` | A short SCHUFA report about a person. |
| `CREDIT_AGENCY_REPORT` | A report issued by a credit agency. |
| `SHARE_HOLDERS_AGREEMENT` | A shareholder agreement. |
| `SHAREHOLDERS_LIST` | A list of shareholders. |
| `TRADING_LICENSE` | A trading license. |
| `TRANSPARENCY_REGISTER_EXTRACT` | An extract from the transparency register. |
| `INVOICE` | An invoice of any kind. |
| `OTHER` | Any other type of document. |
| `VIDEO` | A video of any kind. |
| `VAT_CERTIFICATE` | VAT registration certificate. |


### IDnow status values

The following table includes the possible values for the field `status` for the video identification process carried out by IDnow and the related description of each status.

| Status | Description |
|  --- | --- |
| `created` | The identification resource has been created for the customer. |
| `pending` | The identification process has been triggered, and the video identification URL and reference have been generated. Redirect the customer to the URL to complete the identification. |
| `pending_failed` | The identification is currently under review by the provider. You **cannot** offer banking services to the customer at this stage. |
| `successful` | The video identification was successful. The customer can be onboarded. Note that the customer's data might have been updated during the identification session. |
| `aborted` | The customer aborted the identification process. They can retry using the same URL. |
| `canceled` | The provider canceled the video identification. The customer should retry using the same URL. |
| `failed` | The identification was unsuccessful. You **cannot** onboard the customer or offer any banking services to them. |
| `expired` | The identification link has expired (validity period passed). You must create a new identification request. |


IDnow provides a reason whenever the identification has a `canceled` or `aborted` status. No reason is disclosed for the final `failed` status.

### IDnow failure codes

The following table describes the possible failure or cancellation reasons for IDnow video identification.

| Failure reason | Description | Permanent? | Caused by User? |
|  --- | --- | --- | --- |
| `AUDIO_OTHER` | Any other audio issues not covered by other reasons. | No | Yes |
| `BAD_AUDIO` | Audio is not of enough quality to continue with the call. | No | Yes |
| `BAD_AUDIO_ENVIRONMENT` | Audio disturbance in the call. | No | Yes |
| `BAD_PHOTO_QUALITY` | ID and/or User photo is not of good quality to successfully conclude the identification. | No | Yes |
| `BAD_VIDEO` | Video call established, but is not of enough quality to continue. | No | Yes |
| `CALL_QUALITY_FAIL` | During network pre-check; the network bandwidth is found to be lower than expected to conduct a successful video call. | No | Yes |
| `CONNECTION_BAD` | Connection is not good quality to continue. | No | Yes |
| `CONNECTION_LOST` | Call connection lost. | No | Yes |
| `CONNECTION_OTHER` | Any Other issues with connection not covered by other reasons. | No | Yes |
| `DATA_APPLICATION_ADDRESS` | Address from application does not match address from ID document and cannot be corrected. | Yes | Yes |
| `DATA_APPLICATION_DATA` | Data from application and data from the ID document do not match and cannot be corrected. | Yes | Yes |
| `DATA_ID_EXPIRED` | The validity date of the ID document has expired. User must use a different document. | No | Yes |
| `DISAGREE_WITH_VIDEO_RECORDING` | User disagrees with Video Recording of the call. | No | Yes |
| `ENROLLED_TO_WAITING_LIST` | User has been put on the waiting-list. Depending on the configuration, this can be voluntary or mandatory, or a mix of both. Users cannot remove themselves from the waiting-list, restarting the Ident will lead to a warning message. | Yes | Yes |
| `ID_NOT_SUPPORTED` | User is using an ID document that is not supported for the online identification process. | No | Yes |
| `ID_DAMAGED` | User is using an ID document that is damaged and not fit for the online identification process. | No | Yes |
| `ID_OTHER` | Any other ID related issue not covered by other reasons. | No | Yes |
| `IDENT_CODE_NOT_RECEIVED` | Ident code SMS/email not received by the user. | No | No |
| `IDENT_CODE_REPEATEDLY_INCORRECT` | User entered wrong Ident Id multiple times. | No | Yes |
| `INCORRECT_ID_NUMBER` | ID number is wrongly entered during identification | No | No |
| `INCORRECT_NAME_IN_QES` | Only for eSigning. Name mismatch found after QES generation. | No | No |
| `INDECENT_BEHAVIOUR` | User exhibited behavior towards agent that is indecent. | Yes | Yes |
| `NO_AUDIO` | No audio established between Agent and User. | No | Yes |
| `NO_CONNECTION` | Connection between Agent and User not established due to network issues. | No | Yes |
| `NO_ESIGN_FRAUD` | For eSign transactions, agents must cancel a call if they believe it is fraudulent before it comes to the signing step. It will then be submitted for review with the status FRAUD_SUSPICION_PENDING | No | Yes |
| `NO_SECURITY_QUESTION_ASKED` | If enough security questions are not asked during an ident, reviewer/supervisor may cancel the ident with this reason. | No | - |
| `NO_VIDEO` | Video call could not established. User and Agent do not see each other. | No | Yes |
| `OTHER_ABUSE` | Abuse of the procedure. Inappropriate behavior. | No | Yes |
| `OTHER_ERROR` | Any other error, not further defined. | No | Yes |
| `OTHER_MISCELLANEOUS_PERMANENT` | Other error, which is not covered by specific error. Cannot be solved. | Yes | - |
| `OTHER_MISCELLANEOUS_TEMPORARY` | Other error, which is not covered by specific error. Can be solved by a retry. | No | - |
| `OTHER_TEST` | Identification was a test call. | No | Yes |
| `PHOTO_OTHER` | Other problems related to the photo. | No | Yes |
| `SECURITY_QUESTION` | If a supervisor is not satisfied with the answers to security question, they may cancel the ident with this reason. | No | - |
| `SECURITY_QUESTION_NOT_CORRECT_ANSWERED` | If reviewer/supervisor is not satisfied with the answers to security question, they may cancel the ident with this reason. | No | - |
| `STALLED_TIMEOUT` | When an identification process is running for too long, then the identification request will be cancelled with this reason. | No | - |
| `TECH_AUDIO` | Poor audio quality. Audio quality is poor or user/agent inaudible. | No | Yes |
| `TECH_DISCONNECTED_VIDEO` | The video stream has disconnected during the identification. | No | Yes |
| `TECH_DISCONNECTED_WEBSOCKET` | The websocket connection is disconnected during the identification. Normally caused by loss of internet connection by the user. | No | Yes |
| `TECH_HOLOGRAM` | Security features not visible or broken. No suspicion of fraud. | No | Yes |
| `TECH_ID_TYPE` | ID document is not allowed or is not supported. | No | Yes |
| `TECH_IDENT_CODE_DELIVERY` | User was unable to receive the ident code SMS. | No | Yes |
| `TECH_INTERNAL_SERVER_ERROR` | An error occurred on server. | No | No |
| `TECH_INTERNET_CONNECTION` | Internet connection of the user is not fast enough. | No | Yes |
| `TECH_LIGHTING` | Poor lighting. Person or ID document not sufficiently visible. | No | Yes |
| `TECH_PHOTO` | Poor photo quality. Person or ID document not sufficiently sharp and recognizable. | No | Yes |
| `TECH_TIMEOUT` | The identification request was open too long. Identification requests get aborted after 30 minutes. | No | Yes |
| `TECH_VIDEO` | Poor video quality or camera not good enough. Person or ID document not sufficiently sharp and recognizable. | No | Yes |
| `USER_ABORT_WHILE_WAITING` | User has aborted the identification while he was waiting for an available agent. | No | Yes |
| `USER_CANCELLATION` | User has aborted the identification. | No | Yes |
| `USER_ID_NUMBER` | User repeatedly reads the wrong ID document number. | No | Yes |
| `USER_IDENT_CODE` | Ident code repeatedly entered incorrectly. | No | Yes |
| `USER_LANGUAGE` | User speaks unsupported language. | Yes | Yes |
| `USER_NO_ID` | User has currently no ID card available. | No | Yes |
| `USER_STARTED_NEW_REQUEST` | User has started another ident attempt from different channel (web/app). | No | Yes |
| `USER_WRONG_PERSON` | The person of application and identification do not match. For example, husband has opened bank account, but wife is in the identification call. No suspicion of fraud. | No | Yes |
| `VIDEO_ENVIRONMENT` | User is not in ideal conditions to perform the video call. | No | Yes |
| `VIDEO_OTHER` | Any other problem with video not covered by other reasons. | No | Yes |
| `WRONG_PHONE_NUMBER` | Only for eSigning. User entered wrong phone number. | No | Yes |


### Identification documents

1. List of accepted passports for video identification via IDnow: [here](https://go.idnow.de/bafin2017/documents)
2. List of accepted passports for postIdent: [here](//assets.ctfassets.net/8zxfdz0ps59a/3MjoXQpeatxH4C2rfiDUc3/f89f426b11539d21d4f680f20d37c607/dp-postident-ausweisliste-filiale.pdf)
3. Search for an identification document: [here](https://www.consilium.europa.eu/prado/en/search-by-document-country.html)


#### List of passports with address

The following table lists all ID types that include the bearer's address, which you can use to perform identification without having to provide a proof of address document.

| Document | Issuer Country | Type (ID/PP) |
|  --- | --- | --- |
| BGR-AO-01005 | Bulgaria | Passport |
| CHN-AO-04003 | China | Passport |
| HRV-BO-02001 | Croatia | ID |
| HRV-AO-02001 | Croatia | Passport |
| CZE-BO-04001 | Czech Republic | ID |
| CZE-BO-04002 | Czech Republic | ID |
| FRA-BO-02002 | France | ID |
| FRA-AO-03001-03003 | France | Passport |
| DEU-BO-01003 | Germany | ID |
| DEU-BO-02001 | Germany | ID |
| IND-AO-01001 | India | Passport |
| ITA-BO-04003 | Italy | ID |
| ITA-BO-03004 | Italy | ID |
| ITA-BO-03002 | Italy | ID |
| ITA-BO-03001 | Italy | ID |
| ITA-BO-03003 | Italy | ID |
| MLT-BO-02001 | Malta | ID |
| MLT-BO-03001 | Malta | ID |
| MAR-AO-02001 | Morocco | Passport |
| POL-BO-02001-02003 | Poland | ID |
| SGP-BO-01001-A | Singapore | ID |
| SGP-BO-01001 | Singapore | ID |
| SVK-BO-02001 | Slovakia | ID |
| SVK-BO-05001 | Slovakia | ID |
| SVK-BO-04001 | Slovakia | ID |
| SVN-AO-02001-02003 | Slovenia | Passport |
| SVN-AO-02004 | Slovenia | Passport |
| SVN-BO-02001 | Slovenia | ID |
| SVN-AO-01004 | Slovenia | Passport |
| ESP-BO-03001 | Spain | ID |
| ESP-BO-05001 | Spain | ID |


## Appendix II: IDnow status transitions

Only the following transitions can occur during an IDnow identification session:

**Case 1:** Happy path

`created` → `pending` → `successful`

**Case 2:** Suspicion of fraudulent behavior by IDnow that was not confirmed. Identification was marked as successful after review.

`created` → `pending` → `canceled` → `successful`

**Case 3:** Fraudulent behavior was detected during a review of an identification that was previously marked as successful.

`created` → `pending` → `successful` → `canceled`