Unilateral Demand Transfer Process

Table of Contents


Unilateral Demand Transfer Process Flow

Unilateral Demand Transfer Process

StepDescriptionPartyRecipient / ObserverMessage ReferenceAPI Contract
1

The Participant populates the Demand Transfer Request with the following:

  1. Mandatory ISO 20022 elements defined in the Message Usage Guidelines;
  2. Optional ISO 20022 elements defined in the Message Usage Guidelines where applicable to their transaction;
  3. Related ASX business values and rules applicable to their transaction.

The Participant sends the Demand Transfer Request to the CSP.  

Sender Participant

CSPDemand Transfer Request (hold_201)-
2The CSP validates the request against the schema and business validation rules.CSP---
On Success
3

If the Demand Transfer Request is schema and business valid the CSP will check that sufficient units are available in the Delivering Account (HIN) for the Security Code.

If sufficient units are available then the CSP will: 

  • Decrease the holding balance in the Delivering Account (HIN) by the Unit Quantity of the Demand Transfer Request.
  • Increase the holding balance in the Receiving Account (HIN) by the Unit Quantity of the Demand Transfer Request.

If insufficient units are available then refer to step 6; "On Fail".

CSP---
4

The CSP sends a Demand Transfer Confirmation to the  Delivering Participant (Transferor).

CSPSender Participant Demand Transfer Confirmation (hold_202)

Holding.Holding
(Holding)


Holding.Holding2Issuer (Holding) [on lock of delivering party units | Issuer (Registry) Only]

5If the request is a Demand Transfer within a Participant Group the CSP also sends a Demand Transfer Confirmation to the Receiving Participant (Transferee).CSPReceiving Participant Demand Transfer Confirmation (hold_202)Holding.Holding
(Holding)
6Where holding balance has been changed, the CSP will use the Change in Holding Balance process to determine if a notification will be sent to the Issuer.CSPIssuer--
On Fail
7

If the Demand Transfer Request fails schema or business validation, the CSP will send the Participant:

  • An Invalid Transaction Notification with the relevant error code for schema failure. 
  • A Rejected Transaction for business validation failure.
CSPSender Participant

Invalid Transaction Notification (comm_807)

Rejected Transaction (comm_808)

-

Business Values and Rules

Unilateral Demand Transfer Request

ASX Element Name

ISO Message ElementGuidelines
Sender ParticipantBAH/FromThe Participant submitting the request, who has appropriate permissions. Further details of Party Identifications are detailed here
Transaction IDTransaction Identification

The Transaction ID is a unique identifier for the Demand Transfer Request.

Further details of Transaction Identifications are detailed here. 

Supplementary Reference 

Common IdentificationThe Supplementary Reference field allows a Participant to optionally include a reference on the request which will be passed to the Counterparty (if member of Participant Group). No business validations are performed on this field.

Participant Reference

Trade Identification

The Participant Reference field allows a Participant to optionally include a reference on the request which remains private to the Sender Participant.  No business validations are performed on this field.

Underlying Reference

Trade IdentificationThe Underlying Reference field allows a Participant to optionally include an additional reference on the request which remains private to the Sender Participant.  No business validations are performed on this field.
Override Basis of MovementTrade Transaction Condition

The Override Basis of Movement field(s) allow a Participant to optionally Override the default Basis of Movement for the transaction where there are current corporate actions.

There can be up to 3 Override Basis of Movement present on the Demand Transfer Request, and the value must exist in the Basis of Movement table.

Security Code

Financial Instrument Identification

Identifies the security in which units are being transferred.  Either a Security Code, an ISIN or both elements may be populated.  Where both elements are present, the ISIN and Security Code must refer to the same security. Further details of Security Identification are detailed here.

Unit Quantity

Settlement Quantity

The Unit Quantity of the Security Code which is being transferred.  This must be a positive whole number greater than 0, with no decimal places.  

The Delivering Account (HIN) must have sufficient available units greater than or equal to the Unit Quantity for the specified security.

Delivering Account (HIN)

Quantity And Account Details/Safekeeping Account  

The Delivering Account (HIN) is the Account (HIN) from which units are being delivered.  Delivery of units is only permitted from Accounts which are active and have not been locked or cancelled.

The Delivering Account (HIN) must be different to the Receiving Account (HIN) and must be controlled by the Delivering Participant.

The allowable movements between Delivering Account (HIN) and Receiving Account (HIN) based on the Account Type are validated as per the table in Unilateral Demand Transfer Overview.

Transaction BasisSecurities Transaction Type

The Transaction Basis field characterises the movement of securities.  Must be one of the valid values in the Transaction Basis table.

Transaction Condition Settlement Transaction Condition / Proprietary / Identification

Defines the type of the Transaction. In this case, populated with either:

  • Unilateral Demand Transfer (UDTR); or
  • Unilateral Demand Transfer - Related Participants (UDRP).
Delivering ParticipantDelivering Settlement Parties/Party 1/IdentificationThe Delivering Participant identifies the Participant delivering units and must always be the same as the Sender Participant.
Receiving Participant Receiving Settlement Parties/Party 1/Identification

The Receiving Participant identifies the Participant receiving units. This can be the same as the Delivering Participant.  Alternatively, it can be a different Participant if it is associated with the Delivering Participant in a Participant Group.

Receiving Account (HIN)Receiving Settlement Parties/Party 1/Safekeeping Account 

The Receiving Account (HIN) is the Account (HIN) for which units are being received. Receipt of units is allowed into Accounts which are active, or have been locked, but must not have been cancelled.

The Receiving Account (HIN) must be different to the Delivering Account (HIN) and must be controlled by the Receiving Participant.

The allowable movements between Delivering Account (HIN) and Receiving Account (HIN) based on the Account Type are validated as per the table in Unilateral Demand Transfer Overview.

Settlement DateSettlement Date / Date / DateIdentifies the date the transfer is requested by the Sender Participant.
Guaranteed Foreign IndicatorInvestor Capacity

Identifies whether the transaction is to be processed as a foreign to foreign transaction for securities subject to ASX foreign ownership restrictions. In this case, populated with Foreign To Foreign (ORFF).

Where the Delivering Account (HIN) or Receiving Account (HIN) is Domestic or Mixed and the Guaranteed Foreign Indicator is Foreign To Foreign (ORFF), the Unilateral Demand Transfer Request (hold_201) will be rejected.

Demand Transfer Notifications

Unilateral Demand Transfer Confirmation

A Demand Transfer Confirmation (hold_202) is always sent to the Delivering Participant to confirm that the transfer has settled. If the Receiving Participant is different to the Delivering Participant and a Participant Group association exists between the two Participants, then a Demand Transfer Confirmation (hold_202) is also sent to the Receiving Participant.

ASX Element Name

 ISO Message Element

Guidelines
Transaction IDAccount Owner Transaction IdentificationThe Transaction ID per the Demand Transfer Request.
Supplementary ReferenceCommon Identification

The Supplementary Reference per the Demand Transfer Request.  

This will be present on responses to the Receiving Participant where it differs to the Delivering Participant.

Participant ReferenceTrade Identification

The Participant Reference per the Demand Transfer Request. 

This will not be present on responses to the Receiving Participant, where it differs to the Delivering Participant.

Underlying ReferenceTrade Identification

The Underlying Reference per the Demand Transfer Request. 

This will not be present on responses to the Receiving Participant, where it differs to the Delivering Participant.

Effective Settlement DateEffective Settlement DateThe date on which the transfer of units was affected between the Delivering Account (HIN) and Receiving Account (HIN).
Basis of MovementTrade Transaction ConditionThe Basis of Movement which was applied to the transaction taking into account the Override Basis of Movement, where submitted.
Security CodeFinancial Instrument Identification

The security of which units were transferred per the Demand Transfer Request. 

Both Security Code and ISIN will always be present on the response.

Unit QuantitySettled QuantityThe number of units transferred per the Demand Transfer Request
Delivering Account (HIN)Quantity And Account Details/Safekeeping Account The Delivering Account (HIN) per the Demand Transfer Request.
Transaction BasisSecurities Transaction TypeThe Transaction Basis per the Demand Transfer Request.
Transaction ConditionSettlement Transaction Condition / Proprietary / Identification

The type of the Transaction. In this case, populated with either:

  • Unilateral Demand Transfer (UDTR); or
  • Unilateral Demand Transfer - Related Participants (UDRP).
Delivering Participant Delivering Settlement Parties/Party 1/IdentificationThe Delivering Participant per the Demand Transfer Request.
Receiving Participant 

Receiving Settlement Parties/Party 1/Identification

The Receiving Participant per the Demand Transfer Request.
Receiving Account (HIN)Receiving Settlement Parties/Party 1/Safekeeping Account The Receiving Account (HIN) per the Demand Transfer Request.
Delivering Holding BalanceDelivering Holding Balance

The balance of the holding for the Delivering Account (HIN) after the units were settled.

This will be present only on responses to the Delivering Participant.

Receiving Holding BalanceReceiving Holding Balance

The balance of the holding for the Receiving Account (HIN) after the units were settled.

This will be present only on responses to the Receiving Participant and where the Delivering Participant and Receiving Participant are the same.



Related Pages:

There are no related labels.

Browse Popular Pages:

No labels match these criteria.



This document provides general information only. ASX Limited (ABN 98 008 624 691) and its related bodies corporate (“ASX”) makes no representation or warranty with respect to the accuracy, reliability or completeness of the information. To the extent permitted by law, ASX and its employees, officers and contractors shall not be liable for any loss or damage arising in any way (including by way of negligence) from or in connection with any information provided or omitted or from anyone acting or refraining to act in reliance on this information.

© 2022 ASX Limited ABN 98 008 624 691