# 09-Asset-Transfer-Status-Management



09-Asset-Transfer-Status-Management [#09-asset-transfer-status-management]

1\. Data to Save [#1-data-to-save]

| Data                                   | Description                                             |
| :------------------------------------- | :------------------------------------------------------ |
| transferId                             | Unique ID assigned to asset transfer details            |
| status                                 | Status information of the asset transfer details        |
| Transaction asset information          | Asset transfer details, such as symbol, amount, etc.    |
| Sender/receiver information            | The name of the party to the asset transfer transaction |
| Sending/transmitting VASPs information | Information on asset transfer VASP                      |

2\. Status [#2-status]

The status values of the transferId must be managed in a more detailed way. This is not only to manage each transfer case properly, but also to **provide accurate responses when the counterparty (beneficiary) VASP requests a [Transaction Status Search](https://code-docs-en.readme.io/reference/request-transaction-status-search) inquiry.**

The content of this page is for guidance only, but it outlines the minimum required standards. We would appreciate it if you could refer to it and follow accordingly.

| Status         | Description                                                                                                                      |
| :------------- | :------------------------------------------------------------------------------------------------------------------------------- |
| wait           | The originating VASP has requested the beneficiary VASP for the asset transfer authorization and is waiting for its response.    |
| verified       | The asset transfer has been authorized by the beneficiary VASP, but the transaction has not yet been executed on the blockchain. |
| denied         | The asset transfer authorization has been denied by the beneficiary VASP.                                                        |
| pending        | The blockchain transaction has not been sent yet and is currently pending.                                                       |
| processing     | The transaction has been sent to the blockchain but is currently waiting to be mined.                                            |
| wait-confirmed | The blockchain transaction has been mined, but finality has not yet been secured.                                                |
| confirmed      | The asset transfer on the blockchain has been completed, and the TXID has been updated.                                          |
| canceled       | The asset transfer has been canceled, and the transaction was not executed on the blockchain.                                    |

3\. Beneficiary VASP View [#3-beneficiary-vasp-view]

<Mermaid
  chart="graph LR
    %% Main Transaction Track
    T1[&#x22;'transferId' received&#x22;] --> T2[&#x22;wait&#x22;]
    T2 --> C1[&#x22;canceled&#x22;]
    T2 --> T3[&#x22;confirmed<br/>(TXID received)&#x22;]

    %% Monitoring Track
    M1[&#x22;Transaction<br/>monitoring&#x22;] --> M2[&#x22;TXID detection&#x22;]
    M2 --> M3[&#x22;TXID mapping&#x22;]

    %% Rare Link
    T3 -.->|Extremely rare| M3

    %% Styling Definitions
    classDef changeable fill:#f5f5f5,stroke:#d3d3d3,stroke-width:1px,rx:20,ry:20
    classDef static fill:#f8d7da,stroke:#f5b7b1,stroke-width:1px,rx:20,ry:20

    %% Assign Classes
    class T1,T2,T3,M1,M2,M3 changeable
    class C1 static"
/>

> **Is it possible for a 'confirmed' status to change to 'canceled'?**
>
> * We recommend that VASPs change the status to 'confirmed' ('Report Transfer Result') only after finality has been secured.
> * However, each VASP has its own criteria for determining finality. For example, Exchange A may consider finality sufficient after three additional blocks are generated, whereas Exchange B may require six blocks for confirmation. Therefore, there is a probabilistic chance that the status may change from 'confirmed' to 'canceled'.

* Monitoring and mapping both Travel Rule information and blockchain networks is required.
* There is a statistical possibility that a 'confirmed' 'transferId' may still be 'canceled'.

4\. Originating VASP View [#4-originating-vasp-view]

<Mermaid
  chart="graph LR
%% Node Definitions
wait[&#x22;wait&#x22;]
denied([&#x22;denied&#x22;])
verified[&#x22;verified&#x22;]
pending[&#x22;pending&#x22;]
processing[&#x22;processing&#x22;]
wait-confirmed[&#x22;wait-confirmed&#x22;]
confirmed[&#x22;confirmed&#x22;]
canceled([&#x22;canceled&#x22;])

    %% Style Classes
    classDef changeable fill:#f2f2f2,stroke:#d9d9d9,stroke-width:1px,color:#000;
    classDef unchangeable fill:#ead1d1,stroke:#d1b0b0,stroke-width:1px,color:#000;

    %% Assigning Classes
    class wait,verified,pending,processing,wait-confirmed,confirmed changeable;
    class denied,canceled unchangeable;

    %% Primary Transitions
    wait --> denied
    wait --> verified
    verified --> pending
    pending --> processing
    processing --> wait-confirmed
    wait-confirmed --> confirmed

    %% Cancellation Transitions
    verified --> canceled
    pending --> canceled
    processing --> canceled
    
    %% Low Probability Transitions (Dashed lines)
    wait-confirmed -.-> canceled
    confirmed -.-> canceled

    %% Explanatory Legend (Internal Comments)
    %% - Solid arrows: Standard transitions.
    %% - Dashed arrows (-.->): Probability is low but possibility exists (rare case).
    %% - Grey Nodes: Status value can be changed (can be changed).
    %% - Red Nodes: Status value cannot be changed (canot be changed)."
/>

* verified / denied: Determined based on the response from the counterparty VASP to the 'Asset Transfer Authorization' request..
* Sending the 'Asset Transfer Result'(txid) is recommended only after blockchain finality has been secured.
* There is a probabilistic chance that a 'confirmed' transferId may also be canceled.