# Overview This guide provides all the essential information about Solaris' BankIdentPlus product, including key concepts, integration details, and available testing options. ## Introduction BankIdent Plus is a secure and easy way for customers to verify their identity when opening a new account. It combines a digital signature, known as a Qualified Electronic Signature (QES), with a bank transfer to confirm the customer's identity. The process includes taking a selfie, uploading an image of an ID card, approving a digital signature (QES), and making an initial top-up to the newly opened account. The process is divided into three steps: **1. Identity Check** The customer takes a selfie, scans their ID card, and provides a digital signature (QES). This confirms their identity. **2. Account Opening** Solaris automatically checks the customer’s details and performs the Customer Due Diligence (CDD) process. When no associated risk is identified (Green status), an account is opened for the customer. **3. First Top-Up** Show the IBAN to the customer, who then makes a small deposit to the new account. This transfer verifies ownership of the external bank account used for the top-up. ## User Journey The following flowchart illustrates the complete lifecycle of a BankIdent Plus onboarding, from registration to final account activation. ```mermaid flowchart TD %% --- Chart Structure --- subgraph P1 ["Phase 1: Registration & Pre-Identification"] A1("Step 1:
User Registration &
Mobile Verification") --> A2("Step 2:
Trigger BankIdent Plus
(Create Identification)") A2 --> A3("Step 3:
Redirect to IDnow
(Selfie & QES)") end subgraph P2 ["Phase 2: Compliance & Account Opening"] B1("Step 4.1:
Internal Compliance
Checks (CDD)") --> B2{CDD Status
Check} %% Green Path B2 -->|Green| B3("Step 4.2:
Auto Account Opening
(Debit Blocked)") %% Yellow Path (Manual Review Loop) B2 -->|Yellow| M[("Wait for
Manual Review")] M -.->|Eventually Green| B3 M -.->|Eventually Red| D end subgraph P3 ["Phase 3: Activation (First Top-Up)"] C1("Step 5:
Display IBAN to
Customer") --> C2("Step 6:
Incoming Reference
Transfer (SEPA)") C2 --> C3{Transfer
Validation} C3 -->|Valid| C4("Step 7:
Account Unblocked
(Active)") end D[Terminate Process] %% --- Connections between Phases --- A3 --> B1 B2 -->|Red| D B3 --> C1 C3 -->|Invalid / Expired| D %% --- Inline Style Definitions --- style A1 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px style A2 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px style A3 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px style B1 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px style B3 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px style C1 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px style C2 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px style C4 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px style B2 fill:#dedbd3,color:#1b2230,stroke:#5e6a7a,stroke-width:2px style C3 fill:#dedbd3,color:#1b2230,stroke:#5e6a7a,stroke-width:2px style D fill:#ffc2ad,color:#1b2230,stroke:#5d5746,stroke-width:2px %% Style for Manual Review Node style M fill:#fffacd,stroke:#d4a017,stroke-width:2px,stroke-dasharray: 5 5 %% --- Clickable Links (Anchors) --- click A1 "#step-1-user-registration" click A3 "#step-2-pre-identification-via-idnow" click B1 "#step-3-account-opening" click B3 "#step-3-account-opening" click C1 "#step-3-account-opening" click C2 "#step-4-reference-transfer-requirements" ``` Integrate Solaris' Bankident plus by completing the following steps: ### Step 1. User registration 1. Collect the mandatory customer data and consent to the legal and regulatory requirements in your sign-up flow, and create a person resource for your customer. 2. Create and verify the customer's mobile number. 3. The customer consents to the terms and conditions and agrees to open an account. ### Step 2. Pre-identification (Via IDNow) 1. Inform the customer that they will be redirected to IDnow to complete the pre-identification process. 2. During the IDnow process, the customer will be asked to: 1. Confirm their full name 2. Agree to IDnow’s terms and conditions 3. Scan their ID card (front, back, and security features) 4. Take a short video selfie 5. Electronically sign their information ### Step 3. Account Opening After the customer completes the previous steps, they must wait while Solaris completes the following: 1. **Compliance Checks:** Solaris performs internal compliance checks. See more information on the Customer Due Diligence (CDD) process [here](/guides/kyc/cdd). To proceed with account opening, the CDD status must be Green status listed [here](/guides/kyc/cdd/#list-of-greenyellowred-statuses). Any other status results in the termination of the identification process. The account opens ONLY after CDD is successfully completed. 2. **Account Opening:** If all compliance checks pass, Solaris triggers the account opening process automatically. Before moving to the next steps, your system must wait for the [`IDENTIFICATION` webhook](/api-reference/onboarding/webhooks/webhook-events/paths/identification/post) with status `pending_ref_transfer` to receive updates on the progress. Unlike the standard account opening process where the partner calls the API endpoint after a successful CDD, BankIdent Plus automates this step. Solaris triggers the account opening internally. You do not need to call the [standard account opening request](/api-reference/onboarding/account-creation#tag/Account-opening). 3. **IBAN Display and Account Restrictions** Once the account opens successfully with status `debit_block`, show the new IBAN to the customer in your interface. At this stage: - The account only accepts the expected reference transfer. - It is blocked from any outgoing transaction (debit block). - Any funds sent that don’t match the reference transfer requirements return immediately. ### Step 4: Reference Transfer Requirements 1. The customer must transfer funds to their new account using the displayed IBAN. 2. This transfer must be a SEPA transfer (Regular or Instant SCT) from an existing bank account in the customer's own name. 3. If the transfer fails: 1. For example, if the money is sent from an account the customer does not own, the transfer is rejected. 2. Your frontend can optionally: - Show that the attempt failed. - Inform the customer how many attempts remain. 4. Important Rules: 1. The customer has a maximum of 3 attempts within 30 days to complete the reference transfer. 2. If all attempts fail or no valid transfer is received within 30 days, the identification process terminates. 3. Solaris automatically triggers an [Ordinary Account closure request](/guides/compliance/account-closure#ordinary-closures) towards the IBAN. 4. Any future incoming transactions are rejected. 5. Data retention takes place as per the agreed Customer Data Retention Policies. Important If BankIdentPlus identification fails, the customer can be allowed to try again using a different identification method. - If the account has already been opened, they have 60 days from the failure date to retry. - After 60 days, the entire onboarding process must start over. This includes: - Creating a new user profile - Verifying the mobile number again - Setting up a new device connection - Any of the alternative identification methods provided by the partner can be offered to the customer, incase Bankident Plus fails. If there is a need to cancel a BankIdentPlus identification after the account has been opened, you can choose to fail the identification in order to accelerate the account closure process. Use the [Mark an identification as failed](/api-reference/identity/identifications/person-identifications/paths/~1v1~1persons~1%7bperson_id%7d~1identifications~1%7bid%7d~1mark_as_failed/patch) endpoint to terminate the identification process. ```mermaid sequenceDiagram autonumber actor Customer box "Partner Integration" #FFFFFF participant FE as Partner Frontend participant BE as Partner Backend end box "Solaris Ecosystem" #F9F9F9 participant Sol as Solaris Backend participant IDN as IDnow end %% PHASE 1 rect rgb(242, 242, 242) note right of Customer: Step 1: Sign Up Customer->>FE: Provide mandatory datapoints FE->>BE: Submit Registration Data note right of BE: Person Resource Creation BE->>Sol: POST /v1/persons Sol-->>BE: 201 Created (person_id) note right of BE: Mobile verification &
Device Binding complete FE->>BE: Provide mobile number BE->>Sol: POST /v1/persons/{person_id}/mobile_number Sol-->>BE: 201 Created Mobile number resource BE->>Sol: POST /v1/persons/{person_id}/mobile_number/authorize Sol->>Customer: Send Otp for confirmation BE->>Sol: POST /v1/persons/{person_id}/mobile_number/confirm Sol-->>BE: Verified mobile number end %% PHASE 2 rect rgb(240, 248, 255) note right of Customer: Step 2: Pre-Identification BE->>Sol: POST /identifications (method: bank_plus) Sol-->>BE: 201 Created (identification_id) BE->>Sol: PATCH /identifications/{id}/request Sol->>IDN: Create AutoIdent+QES IDN-->>Sol: Created (idnow_reference) Sol-->>BE: 200 OK (redirect_url) BE->>FE: Pass Redirect URL FE->>IDN: Initialize IDnow SDK Customer->>IDN: Complete Video/Selfie/QES IDN-->>Sol: Success Webhook note over Sol: Status: pre_successful Sol-)BE: Webhook: IDENTIFICATION end %% PHASE 3 rect rgb(255, 250, 240) note right of Customer: Step 3: Account Opening note over Sol: Internal CDD Checks opt CDD Status Change Sol-)BE: Webhook: IDENTIFICATION (pending_account_creation) end Sol->>Sol: Open Account (Debit Blocked) note over Sol: Status: pending_ref_transfer Sol-)BE: Webhook: IDENTIFICATION BE->>Sol: GET /identification_account Sol-->>BE: 200 OK (IBAN, BIC, Currency) end %% PHASE 4 rect rgb(240, 255, 240) note right of Customer: Step 4: Reference Transfer BE->>FE: Return IBAN FE->>Customer: Display IBAN & Instructions Customer->>Sol: Send SEPA Credit Transfer Sol->>Sol: Validate Sender Name & IBAN alt Transfer Failed (Name Mismatch/Fraud) Sol-)BE: Webhook: IDENTIFICATION_REFERENCE_TRANSFER_ATTEMPT BE->>FE: Display "Attempt Failed" (X left) else Transfer Successful note over Sol: Status: successful Sol-)BE: Webhook: IDENTIFICATION (account_id) BE->>Sol: GET /identification_account Sol-->>BE: 200 OK (Full Account Details) note over Sol: Account Unblocked end end ``` ## Integration Pre-requisites Before integrating this feature, you must implement the following requirements in your solution: **1. Product Setup** Identification and Account opening configurations need to be assigned to you by your partner manager. **2. Technical setup** Set up your environment and get your authentication keys. For step-by-step instructions, check the [Technical setup guide.](/guides/get-started/technical-setup) **3. 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](/guides/get-started/onboarding-requirements/1-legal-compliance-screens) screens guide contains step-by-step instructions on how to create these screens and what they must contain. Record the customer's consent on each screen as a UTC timestamp (e.g., 2019-01-01T00:00:00Z). Afterward, you must 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. **4. Devices** Before an identification can be created you have to: - Create a mobile number for the user - Create a device binding for the customer. More information on how to do that can be found in the [Device Binding guide.](/guides/authentication/device-binding/) ## Webhooks You must subscribe to the following webhook events to ensure that your system receives notifications for crucial events in the identification process. Webhooks help you monitor various status changes during the identification process. The following diagram illustrates the complete lifecycle of the identification status and the transitions you will receive via the `IDENTIFICATION` webhook: ```mermaid stateDiagram-v2 direction TB %% Initial State [*] --> pending: Identification Created %% Phase 1: IDnow state "Phase 1: Pre-Identification" as Phase1 { direction TB %% Happy Path pending --> pre_successful: User completes Video/QES %% Non-Terminal States (Retry Allowed) pending --> aborted: User quits pending --> canceled: IDnow cancels %% Retry Logic (Direct Jumps) aborted --> pre_successful: Retry & Succeed canceled --> pre_successful: Retry & Succeed %% Retry Failures aborted --> failed: Retry & Fraud/Mismatch canceled --> failed: Retry & Fraud/Mismatch %% Immediate Failures pending --> failed: Fraud/Mismatch } %% Phase 2: CDD & Account state "Phase 2: Compliance & Account" as Phase2 { direction TB pre_successful --> pending_account_creation: Internal trigger pending_account_creation --> pending_ref_transfer: Account Opened note right of pending_ref_transfer IBAN Available. Wait for funds. end note pre_successful --> failed: CDD Rejected } %% Phase 3: Transfer state "Phase 3: Activation" as Phase3 { direction TB pending_ref_transfer --> successful: Valid Transfer pending_ref_transfer --> pending_ref_transfer: Invalid (< 3 Attempts) pending_ref_transfer --> failed: Invalid (3rd Attempt) or Expired } %% Final States successful --> [*] failed --> [*] %% Styles classDef success fill:#e1f5fe,stroke:#01579b,stroke-width:2px; classDef error fill:#ffebee,stroke:#c62828,stroke-width:2px; classDef active fill:#fff3e0,stroke:#ef6c00,stroke-width:2px; classDef retry fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,stroke-dasharray: 5 5; class successful success class failed error class pending_ref_transfer active class aborted,canceled retry ``` ### Key Status Transitions to Monitor | Status | Description | | --- | --- | | **`aborted` / `canceled`** | **Non-Terminal.** The identification session was interrupted. The user can retry using the same link. The status remains here until a new outcome overwrites it. | | **`pre_successful`** | The Pre-Identification has been finished successfully. Solaris will now proceed with compliance checks (CDD). | | **`pending_account_creation`** | Compliance screening (CDD) has finished successfully. Solaris will now proceed with the account opening flow. | | **`pending_ref_transfer`** | **Critical Signal.** It confirms the account is open and the IBAN is ready. You must trigger your UI to display the IBAN to the customer at this stage. | | **`successful`** | The final terminal state. The reference transfer has been received, and the account debit block is removed. | | **`failed`** | This terminal state can occur at two stages: either due to a failed compliance check (Phase 2) or after 3 failed reference transfer attempts (Phase 3). | - [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) - [IDENTIFICATION_REFERENCE_TRANSFER_ATTEMPT](/api-reference/onboarding/webhooks/webhook-events/paths/identification_reference_transfer_attempt/post) Updates from the `IDENTIFICATION_REFERENCE_TRANSFER_ATTEMPT` webhook will notify the partner about the remaining number of reference transfer attempts left. ## IDnow Integration In addition to the Solaris technical prerequisites, you must also integrate IDnow into your solution. You can achieve this by using IDnow's mobile SDKs (available for iOS and Android) . For instructions on how to set up IDnow in your solution, see the following IDnow documentation links: - [Android SDK](https://github.com/idnow/de.idnow.android.sdk) - [iOS SDK](https://github.com/idnow/de.idnow.ios.sdk) To create a smoother process, it is possible to integrate another SDK which includes ID card reading via the NFC chip. To verify the ID card the customer simply has to tab their ID instead of relying on the capture of hologram images. If you would like to enable this, please reach out to your account manager. ## API Integration ### User onboarding/ Data collection **Creating a person** This endpoint creates a person resource for your customer. You must collect the [mandatory data points](/guides/get-started/onboarding-requirements/2-data-collection#important-considerations-for-data-collection) from your customer in the sign-up flow and pass them to Solaris in the request body of this endpoint. Request URL ```json POST /v1/persons ``` Response The API returns a person object with a unique ID for the person (i.e., the person_id). You will need this id to append the person resource with additional information in the remaining steps of this guide. [Click here to view the full API reference](/api-reference/onboarding/persons/#tag/Persons/paths/~1v1~1persons/post) **Device Binding** Before the BankPlus Identification can be created, the [device binding](/guides/authentication/device-binding/) flow needs to be followed. See Device Binding for reference. **Pre-Identification** #### Create Identification This endpoint creates an identification resource for the person specified in the request URL. You must add the following properties in the request body: - method : The identification method, use bank_plus . - language : language for the idnow flow Attributes needed for account opening: - product_name - account_type - account_bic - account_currency - Optional: account_purpose For more information see [account opening guide](/guides/digital-banking/account-opening/#fields-mapping) It is only possible to use account types that you have an existing configuration for. If you are unsure what configurations are present or need additional account types enabled, please reach out to your partner manager. [Click here to view full API reference.](/api-reference/identity/identifications/person-identifications/paths/~1v1~1persons~1%7bperson_id%7d~1identifications/post) **Request identification** This endpoint requests Solaris to begin the process for the person identification specified in the URL. The identification status will change to `pending` after calling this endpoint. [Click here to view the full API reference.](/api-reference/identity/identifications/person-identifications/paths/~1v1~1persons~1%7bperson_id%7d~1identifications~1%7bid%7d~1request/patch) You must redirect your customer to the URL returned in the previous call to start the AutoIdent + QES or initiate via IDnow SDK. You can track the various status of this process by subscribing to the [IDENTIFICATION](/api-reference/onboarding/webhooks/webhook-events/paths/identification/post) webhook. To retrieve the complete details of the identification, please use the [GET Retrieve a person Identification](/api-reference/identity/identifications/person-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1identifications~1%7Bid%7D/get) API endpoint **Account Opening** #### Get Identification Account Once an account has been created the IBAN can be accessed when required by requesting the identification account resource. [Click here to view the full API reference](/api-reference/identity/identifications/person-identifications/paths/~1v1~1persons~1%7bperson_id%7d~1identifications~1%7bid%7d~1identification~1identification_account/get) These details are also available by subscribing to the [IDENTIFICATION](/api-reference/onboarding/webhooks/webhook-events/paths/identification/post) webhook. ## Handling Failures & Account Reactivation If the BankIdent Plus identification process fails (for example, due to a failed reference transfer), you can recover the customer journey using a fallback identification method. If the customer successfully completes a supported fallback identification within **60 days** of the failure, you can reactivate their existing account instead of restarting the account creation process. ### Supported fallback methods * IDnow VideoIdent * PostIdent * Manual Identification ### Prerequisites for reactivation To reactivate an account, the following conditions must be met: 1. **Timeline:** The reactivation request must occur within **60 days** of the BankIdent Plus failure. 2. **Compliance:** The person’s Customer Due Diligence (CDD) status must be `green`. 3. **Identity:** A successful fallback identification resource must exist for the person. ### Reactivate identification account Call this endpoint to reactivate the account associated with the failed BankIdent Plus process. This returns the account details (IBAN, BIC) required for the customer to start using their account. ```text Request URL PATCH /v1/persons/{person_id}/identification_account/reactivate ``` ```json Response Body { "iban": "DE05011010100000000043", "account_currency": "EUR", "account_bic": "SOBKDEB2XXX", "product_name": "CURRENT_ACCOUNT_CONSUMER_GERMANY", "account_type": "CHECKING_PERSONAL", "account_purpose": "primary", "account_id": "5526853938474f3e92b22a03ea57a544cacc" } ``` Potential Errors 412 Precondition Failed: The account cannot be reactivated. This occurs if the 60-day limit has passed or no successful fallback identification exists. [Click here to view the full API reference](/api-reference/identity/identifications/person-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1identification_account~1reactivate/patch) **Additional API references** #### Mark an identification as failed You can mark an identification as failed if a user does not wish to proceed with the reference transfer. Failing the identification manually initiates the ordinary account closure faster. [Click here to view the full API reference](/api-reference/identity/identifications#operation/markIdentificationFailed) ### Testing We support simulating different outcomes of the separate identification steps to support your automated or manual testing. In order to enable testing that does not require wait times or specific data requirements, we support simulating all major asynchronous events in the flow. The endpoint is as follows: ```text Request URL PATCH /v1/persons/{person_id}/identifications/{id}/simulate_outcome ``` ```json Request Body { "scenario": "SUCCESSFUL_PRE_IDENT" } ``` ```json Response Body { 204 No content } ``` Click [here](/api-reference/identity/identifications/person-identifications/paths/~1v1~1persons~1%7bperson_id%7d~1identifications~1%7bid%7d~1simulate_outcome/patch) to view the full API reference. Please keep in mind that not every simulation event will immediately update the identification status. Some updates will take up to a few seconds. | Event | Description | Outcome | | --- | --- | --- | | `SUCCESSFUL_PRE_IDENT` | Simulates the user successfully finishing the Pre-Identification with the external provider (Eg: Idnow). Results in identification status pre_successful and will trigger Customer Due Diligence next. | pre_successful | | `CANCELED_PRE_IDENT` | Simulates the Pre-Identification being cancelled by the external provider before it can be finished. Results in identification status canceled. Since this status is not terminal, SUCCESSFUL_PRE_IDENT or FAILED_PRE_IDENT can be simulated next. | cancelled | | `ABORTED_PRE_IDENT` | Simulates the Pre-Identification being aborted by the user before it was finished. Results in identification status aborted. Since this status is not terminal, SUCCESSFUL_PRE_IDENT or FAILED_PRE_IDENT can be simulated next. | aborted | | `FAILED_PRE_IDENT` | Simulates a failure of the the Pre-Identification reported by the external provider (e.g. fraud suspicion). Results in identification status failed . | failed | | `SUCCESSFUL_ACCOUNT_OPENING` | Simulates the successful opening of an account (skipping the need for CDD results). Results in identification status pending_ref_transfer and will make the new IBAN available in the GET identification_account endpoint. | pending_account_opening (will become pending_ref_transfer after a wait time) | | `FAILED_ACCOUNT_OPENING` | Simulates a failure when opening an account (dummy reason will be set). Results in identification status failed. | failed | | `SUCCESSFUL_REFERENCE_TRANSFER` | Simulates the customer successfully transferring funds into the account. Results in identification status successful. | pending_ref_transfer (will become successful after a wait time i.e, final terminal status) | | `FAILED_REFERENCE_TRANSFER_NAME_CHECK ` | Simulates a failed attempt by the customer to successfully transfer funds into the account. Result depends on the count of attempts. After 3 failed attempts the identification will be failed. | pending_ref_transfer (if simulated for the 3rd time: failed) |