Upvest's offers Outgoing Transfers to enable clients to initiate the request following a transfer request made by the end users.
There is a legal obligation to facilitate outgoing securities transfers to any other German investment services company within three (3) weeks of receiving notification from the end user. This API solution allows a smooth process where information is passed to Upvest to handle after the client has completed the basic validations.
Benefits of this API solution include:
- Reduce time and required interaction spent for a transfer out request, and to ensure the process is completed as timely as possible. This also has a significant reduction in the operational time and cost for the parties involved.
- Get updates on the status of the transfers from Upvest via webhook notifications and the ability to update end users as well.
- Ensures clients can meet regulatory requirements by fulfilling the transfer within the three (3) weeks timeframe and being able to recongize if there are any delays.
Prior to submitting the request via API for an outgoing transfer, the end user initiates the process on our client's UI. Once everything is validated and our client has sufficient information, the securities transfer process can be triggered and the API request is sent to Upvest.
There’s also a scenario where end users initiate the process on the receiving provider’s end by requesting an incoming transfer (outgoing for our clients). In this case, our clients would receive a request via post, mail, or fax. It’s still advisable to use the API to submit the request to Upvest to receive all the benefits mentioned above.
For outgoing transfers, end users must include accurate details of the account number they hold at the receiving provider. This is to avoid back and forth communication among the parties involved which may cause delays.
The assumption is that the client performs checks on their side prior to submitting the transfer request via API, including whether the requested amount is valid. For example, in the case that the end user wants to transfer 10 shares of an ISIN, but only 5 are available, Upvest will cancel the request.
As we cannot transfer fractions, only whole units, users are asked to sell their fractions.
The process of securities transfers requested via API within Upvest is similar for both incoming and outgoing, where each transfer goes through the following statuses. Any difference is specified in the following sections for each direction.
| Status | Description |
|---|---|
NEW | The transfer request has been submitted and will be validated. |
PROCESSING | The transfer has been instructed and is being processed. |
SETTLED | The transfer was executed at the custodian level. The units will be debited from the users account. Note: Partial settlement for a single ISIN (e.g., from different custodians, different timing) is not reflected in status. |
CANCELLED | The transfer was cancelled by the client, by Upvest or is rejected at the custodian level. Final state. To start the same transfer again a new one has to be created. |
Please be aware that this list of statuses may be extended in the future to accommodate additional use cases and functionalities.
{
"direction": "OUTGOING",
"instrument_id": "US0378331005",
"instrument_id_type": "ISIN",
"quantity": "10",
"transfer_type": "NO_OWNER_CHANGE",
"user_id": "7e9a0529-d289-4f4a-ae01-c2cd013d582e",
"account_id": "d396b7c3-aa67-488a-8e39-4a1a7cbeb9f4",
"settlement_reference": "b82dc5985558fdr2",
"counterparty": {
"bic": "DUMBZZ33XXX",
"account_number": "1234567891",
"name": "Max Mustermann"
}
}In the outgoing transfers request, you must populate the fields marked as Required. Other fields remain optional.
| Field | Required/Optional | Description |
|---|---|---|
user_id | Required | User unique identifier. |
account_id | Required | Account unique identifier. |
transfer_type | Required | Type of the securities transfer. Currently, only NO_OWNER_CHANGE (no change of ownership) is supported. |
direction | Required | The following values are supported: INCOMING: Securities transfer is incoming to the user OUTGOING: Securities transfer is outgoing from the user |
settlement_reference | Required | Unique identifier of the account transfer. Useful for API consumers to build special logic on their side. |
instrument_id | Required | ISIN (International Securities Identification Number) or other identity (depends on instrument_id_type) of the security to be transferred. |
instrument_id_type | Required | Type of the instrument_id. Currently, only ISIN (International Securities Identification Number) is supported. |
quantity | Required | The quantity of the instrument to move in or out. The value supported is maximum 15 digits including decimal place. Note: For INCOMING the end user ensures that they don't sell their instruments on the counter-broker to enable smooth transfer of their instruments on Upvest platform. |
counterparty.bic | Required | Business Identifier Code (also known as SWIFT-BIC, BIC, SWIFT ID or SWIFT code) ISO 9362. |
counterparty.name | Optional | The end user’s name at the counterparty's broker. The name is going to be split into 4 lines of 35 characters, the split is space based. This means that even if the name is exactly 140 of length, we may drop out the last parts if they don't fit into 4x35. |
counterparty.account_number | Optional | The account number is composed of a valid Swift charset with a max length of 28 if provided. The account number helps other brokers identify the owner of the assets. |
place_of_settlement | Optional | BIC code of the location where the securities are actually transferred and settled. Clearstream Frankfurt DAKVDEFFXXX or Clearstream Luxembourg CEDELULLXXX for Clearstream-internal transfers, else the BIC of the corresponding CSD. It depends on the instrument and/or counterparty. |
trade_date | Optional | The forecast date when the trade takes place. The value will change to ensure market match. If provided, usually T+1 is sufficient. Depending on the market, this means valid working days. |
settlement_date | Optional | The forecast date when the settlement takes place. The value will change to ensure market match. However, the effective settlement date might be the same date or future one. If provided, usually T+2 is sufficient or trade_date + 1. Depending on the market, this means valid working days. |
Only additional fields not present in the request are listed below.
| Field | Required | Description |
|---|---|---|
id | Required | Securities transfer request unique identifier. |
created_at | Required | Date and time when the resource was created. RFC 3339-5, ISO8601 UTC |
updated_at | Required | Date and time when the resource was updated. RFC 3339-5, ISO8601 UTC |
status | Required | Status of the securities transfer: NEW - Securities transfer is created but not started processing. PROCESSING - Securities transfer is in processing. SETTLED - Securities transfer was successfully settled. CANCELLED - Securities transfer was cancelled. |
quantity_settled | Optional | The quantity of instruments settled. This field is relevant for the future to support more complex scenarios such as partial settlements. |
actual_settlement_date | Optional | The date when the transfer settled, only known in SETTLED status. Date in YYYY-MM-DD format. |
You can retrieve a list of all securities transfers (both outgoing and incoming) using:
The example below shows the request and response for outgoing transfers.
{
"id": "9637e68f-7065-4131-a072-6d57044ebd8c",
"created_at": "2024-01-22T14:10:00.00Z",
"updated_at": "2024-01-22T14:12:34.56Z",
"direction": "OUTGOING",
"status": "SETTLED",
"transfer_type": "NO_OWNER_CHANGE",
"instrument_id": "US0378331005",
"instrument_id_type": "ISIN",
"quantity": "10",
"quantity_settled": "10",
"user_id": "7e9a0529-d289-4f4a-ae01-c2cd013d582e",
"account_id": "d396b7c3-aa67-488a-8e39-4a1a7cbeb9f4",
"settlement_reference": "b82dc5985558fdr2",
"counterparty": {
"bic": "ABCDDEFFXXX",
"account_number": "1234567891",
"name": "Max Mustermann"
},
"place_of_settlement": "DAKVDEFFXXX",
"trade_date": "2024-01-22",
"settlement_date": "2024-01-23",
"actual_settlement_date": "2024-01-24"
}