# Bankident Plus

This guide provides all the essential information about Solaris' Bankident Plus 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:<br/>User Registration &<br/>Mobile Verification") --> A2("Step 2:<br/>Trigger Bankident Plus<br/>(Create Identification)")
        A2 --> A3("Step 3:<br/>Redirect to IDnow<br/>(Selfie & QES)")
    end

    subgraph P2 ["Phase 2: Compliance & Account Opening"]
        B1("Step 4.1:<br/>Internal Compliance<br/>Checks (CDD)") --> B2{CDD Status<br/>Check}
        
        %% Green Path
        B2 -->|Green| B3("Step 4.2:<br/>Auto Account Opening<br/>(Debit Blocked)")
        
        %% Yellow Path (Manual Review Loop)
        B2 -->|Yellow| M[("Wait for<br/>Manual Review")]
        M -.->|Eventually Green| B3
        M -.->|Eventually Red| D
    end
    
    subgraph P3 ["Phase 3: Activation (First Top-Up)"]
        C1("Step 5:<br/>Display IBAN to<br/>Customer") --> C2("Step 6:<br/>Incoming Reference<br/>Transfer (SEPA)")
        C2 --> C3{Transfer<br/>Validation}
        C3 -->|Valid| C4("Step 7:<br/>Account Unblocked<br/>(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). Note the list of accepted documents by IDnow [here](https://go.idnow.de/autoIdentDocuments).
  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 Bankident Plus 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, in case Bankident Plus fails.


If there is a need to cancel a Bankident Plus 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 &<br/>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 tap their ID instead of relying on the capture of hologram images. If you would like to enable this, please reach out to your Partner 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.


```text Request URL
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 Bankident Plus 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 the [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_account/get#/api-reference/identity/identifications/person-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1identifications~1%7Bid%7D~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 (e.g., 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. | `canceled` |
| `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 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`) |