Deposits Assignments

Integration, Compliance and Bookings for Deposits, using the Trever Treasury Integration Service

Deposit Workflow

Worklfow

1 - Fetch Depsoits

Trever retrieves current transactions from integrated treasury venues every 10 seconds.

2 - List Deposits

The data provided is displayed in the Trever Treasury Screen.

Deposit History

3 - Deposit Matching

For all incoming deposits, Trever checks whether they can be automatically assigned to a customer account. For this purpose, all configured wallets are checked for Assigement Configurations.

How exactly assigment data can be configured is explained below.

If the assignment to an account is successful, a so-called Deposit Assignment is created. The amount deposited is booked to the customer’s Lock account. This means that the amount appears in his balances but is not yet available to him.

If no compliance is activated (Workspace Setting) the successful Deposit Assignment is immediately booked to the Head account of the customer. This means that the amount is also available for trading.

4 - Compliance

If compliance is activated, there are two possibilities for the client’s system to learn that there are new Deposit Assignments.

It can retrieve all current deposit assignments via a GET call from the Trever API.
It can provide an http POST endpoint itself and store the information about it in Trever. Trever Treasury will then send the current deposit assignments to this endpoint as soon as they are created.

At this point, the deposit assigment has the status PENDING. The client’s system can now perform the compliance checks for the assigned customer and then set the deposit assigments to REJECTED or SUCCESSFUL if necessary. Trever provides a PATCH endpoint for this purpose.

5 - Bookkeeping

If a Deposit Assigment is set to SUCCESSFUL, the amount is booked to the customer’s HEAD account and is available for trading. If a Deposit Assigment is set to REJECTED, the amount remains in the LOCK account of the assigned customer. A manual decision must now be made on how to proceed with this deposit. It can either be set from REJECTED to SUCCESSFUL at a later date or the assignment can be rectified. Either via the API or in the frontend.

Deposit Matching

Destination with reference

deposit.destination_address == wallet.deposit_config.destination_address
deposit.reference == wallet.deposit_config.destination_reference

This setup is used if the deposit address or destination address of a transaction is used multiple times (e.g. omnibus wallet). A reference can then be assigned to a customer wallet so that a decision can be made to whom this deposit is assigned.

Assignment Information for destination address and reference

Destination without reference

deposit.destination_address == wallet.deposit_config.destination_address

If the destianaion address of a transaction is unique and sufficient to assign it, this setup is used.

Assignment Information for destination address

Source with reference

deposit.source_address == wallet.deposit_config.source_address
deposit.reference == wallet.deposit_config.source_reference

As an alternative to Setup 1 - Destination with reference, an source address can also be specified to assign a transaction. For example, if an omnibus wallet is used to receive crypto deposits and the underlying protocol does not offer the option of a memo, note or reference text, an origin address can be stored to identify the depositing customer. If the source address is also an omnibus wallet, a reference text can optionally be used here as well.

Assignment Information for sourcw address and reference