Bilateral Demand Transfer Process

Table of Contents


Bilateral Demand Transfer Process Flow

Note: shown from the perspective of the Sender Participant.

Bilateral Demand Transfer Process

StepDescriptionPartyRecipient  / ObserverMessage ReferenceAPI Contract
1

The Participant populates a 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 ParticipantCSPDemand Transfer Request (hold_201)-
2The CSP validates the request against the schema and business validation rules.CSP-
-
3

If the Demand Transfer Request is schema and business valid and the Sender Participant is the Delivering Participant, 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 lock the units such that they cannot be used for any other purpose.

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

CSP-
-
On Success
4

The CSP then runs the Matching process to determine if there is a Bilateral Demand Transfer Request in an "Unmatched" state which Matches the submission.

CSP-
-
If No Match Available
5If no Matching request is available, the Bilateral Demand Transfer Request is placed in an "Unmatched" state and made available for Matching against any future requests from the Counterparty.CSP

-
6The CSP notifies the Sender Participant with a Demand Transfer Status Advice to indicate the transaction is Unmatched.CSPSender ParticipantDemand Transfer Status Advice (hold_207)

Holding.Holding (Holding) [Holding balance locked | Delivering Participant Only]


DemandTransfers.BilateralDemandTransfer (BilateralDemandTransfer)

7The CSP sends a Demand Transfer Allegement Notification to the Counterparty.CSPCounterpartyDemand Transfer Allegement Notification (hold_208)SettlementInstructions.Allegement (Allegement)
8

The CSP re-runs the Matching process against any new submission to determine if a Match has become available.

CSP-
-
9Where no Match has become available the Sender Participant can cancel the request using Bilateral Demand Transfer Cancellation Process at any point prior to a Match taking place.Sender ParticipantCSP
-
10Where no Match has taken place by a specified time the "Unmatched" transaction will be cancelled by ASX Housekeeping.CSPSender Participant and Counterparty
-
Match Available
11

If the CSP Matches the transaction it records the transaction as "Matched" and immediately:

  • Decreases the holding balance in the Delivering Account (HIN) by the Unit Quantity of the Demand Transfer Request.
  • Increases the holding balance in the Receiving Account (HIN) by the Unit Quantity of the Demand Transfer Request.
CSP-
-
12The CSP sends a Demand Transfer Confirmation to both the Sender Participant and the Counterparty.CSPSender Participant and CounterpartyDemand Transfer Confirmation  (hold_202)

Holding.Holding (Holding) [Holding balance locked | Delivering Participant Only]


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


DemandTransfers.BilateralDemandTransfer (BilateralDemandTransfer) [Sender Participant Only] [Archived]


SettlementInstructions.Allegement (Allegement) [Counterparty Only] [Archived]

13Where 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
14

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

Bilateral Demand Transfer Request

ASX Element Name

ISO Message ElementGuidelines
Sender ParticipantBAH/FromThe Participant submitting the request, who has appropriate permissions.
Delivering ParticipantDelivering Settlement Parties/Party 1/Identification

The Delivering Participant identifies the Participant delivering units and must be either the Sender Participant or the Counterparty.

The Delivering Participant must be different to the Receiving Participant.

Receiving ParticipantReceiving Settlement Parties/Party 1/Identification

The Receiving Participant identifies the Participant receiving units and must be either the Sender Participant or the Counterparty.

The Receiving Participant must be different to the Delivering Participant.

Transaction IDTransaction Identification

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

Further details of Transaction Identifications are detailed here. 

Securities Movement TypeSecurities Movement Type

If the Sender Participant is the Delivering Participant then Securities Movement Type must be "Delivery" (DELI).

If the Sender Participant is the Receiving Participant then Securities Movement Type must be "Receive" (RECE).

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.

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.

Account (HIN)

Quantity And Account Details/Safekeeping Account


The Sender Participant must be in control of the Account (HIN).

Delivery of units is only allowed from accounts which are active and have not been locked or cancelled. 

Receipt of units is allowed into accounts which are active, or have been locked, but must not have been cancelled.

Bilateral Demand Transfer Requests are allowed from any Account (HIN) type to any Account (HIN) type.

Transaction BasisSecurities Transaction TypeThe Transaction Basis field characterises the movement of securities.  It must contain one of the valid values in the Transaction Basis table.
Transaction ConditionSettlement Transaction Condition / Code / Proprietary / IdentificationThe type of the Transaction. In this case, Bilateral Demand Transfer (BDTR).
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.

Guaranteed Foreign IndicatorInvestor Capacity

The Guaranteed Foreign Indicator allows Participants to agree that a transfer is made between Accounts (HINs) with a Foreign Residency Indicator.

Where the Guaranteed Foreign Indicator is supplied (ORFF) then the Account (HIN) must have a Residency Indicator of Foreign (FRGN).

Participant Reference

Trade IdentificationThe 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.

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. This field must be supplied where the Secondary Matching Flag (SMAT) has been set.

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.
Secondary Matching FlagSettlement Instruction Processing Additional DetailsThe Secondary Matching Flag (SMAT) indicates that the Sender Participant wishes to additionally match on the Supplementary Reference.
Settlement DateSettlement Date / Date / DateIdentifies the date the transfer is requested by the Sender Participant. 

Bilateral Demand Transfer Notifications

Demand Transfer Status Advice

The Sender Participant receives a Demand Transfer Status Advice (hold_207) where the Bilateral Demand Transfer is recorded in an "Unmatched" state.

ASX Element Field
ISO Message Element
Guidelines
Transaction IDAccount Owner Transaction IdentificationThe Transaction ID per the Demand Transfer Request.
StatusMatching Status

A status of "Unmatched" (CMIS) indicates that the Demand Transfer Request has been recorded in the system as Unmatched.

Demand Transfer Allegement Notification

The Counterparty receives a Demand Transfer Allegement Notification (hold_208) to indicate that a Bilateral Demand Transfer Request has been alleged against them and has been recorded in the system in an "Unmatched" state.

ASX Element Field
ISO Message Element
Guidelines
Counterparty Transaction IDTransaction Identification

The Transaction ID as provided by the Sender Participant.

Securities Movement TypeSecurities Movement Type

The Securities Movement Type as alleged by the Sender Participant. This will indicate "Delivering" (DELI) where the Sender Participant is proposing to deliver units, and "Receiving" (RECE) where the Sender Participant is proposing to receive units.

Supplementary Reference Common IdentificationThe Supplementary Reference as alleged by the Sender Participant.
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 Override Basis of Movement table.

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 allegement.

Unit QuantitySettlement QuantityThe number of units to be transferred as alleged by the Sender Participant.
Transaction BasisSecurities Transaction TypeThe Transaction Basis as alleged by the Sender Participant and that exists in the Transaction Basis table
Transaction ConditionSettlement Transaction Condition / Code / Proprietary / IdentificationThe type of the Transaction. In this case, Bilateral Demand Transfer (BDTR).
Delivering ParticipantDelivering Settlement Parties/Party 1/Identification

The Delivering Participant as alleged by the Sender Participant.

Receiving ParticipantReceiving Settlement Parties/Party 1/IdentificationThe Receiving Participant as alleged by the Sender Participant.
Secondary Matching FlagSettlement Instruction Processing Additional DetailsThe Secondary Matching Flag (SMAT) as alleged by the Sender Participant. When present this indicates that the Sender Participant requires a match on the Supplementary Reference value.
Guaranteed Foreign IndicatorInvestor Capacity

The Guaranteed Foreign Indicator (ORFF) as alleged by the Sender Participant. When present this indicates that the Sender Participant requires both Accounts (HINs) to have a Residency Indicator of Foreign (FRGN).

Demand Transfer Confirmation

The Sender Participant and the Counterparty receive a Demand Transfer Confirmation (hold_202) to indicate their Demand Transfer Requests have matched, resulting in units being transferred between Accounts (HINs).

ASX Element Name

 ISO Message Element

Guidelines
Transaction IDAccount Owner Transaction Identification

The Transaction ID of the Participant's Demand Transfer Request.

Counterparty Transaction ID

Account Servicer Transaction Identification

The Transaction ID of the Counterparty's Demand Transfer Request.

Securities Movement Type


Securities Movement Type

The Securities Movement Type as alleged by the Sender Participant. This will indicate "Delivering" (DELI) where the Sender Participant is proposing to deliver units, and "Receiving" (RECE) where the Sender Participant is proposing to receive units.

Supplementary ReferenceCommon Identification

The Supplementary Reference field allows a Participant to optionally include a reference on the request which will be passed to the Counterparty. This field must be supplied where the Secondary Matching Flag (SMAT) has been set.

Participant ReferenceTrade Identification (instance 1)

The Participant Reference per the Demand Transfer Request submitted by the receiver of the Demand Transfer Confirmation.

Underlying ReferenceTrade Identification (instance 2)The Underlying Reference per the Demand Transfer Request submitted by the receiver of the Demand Transfer Confirmation.
Basis of MovementTrade Transaction ConditionThe Basis of Movement which was applied to the transaction taking into account the Override Basis of Movement, where submitted.
Guaranteed Foreign IndicatorInvestor Capacity

The Guaranteed Foreign Indicator (ORFF) of the matched Bilateral Demand Transfer. Indicates that the transfer was agreed to take place between two Accounts (HINs) with a Residency Indicator of "Foreign" (FRGN).

Secondary Matching FlagSettlement Instruction Processing Additional Details

The Secondary Matching Flag (SMAT) that indicates the transaction additionally matched on the value present in the Supplementary Reference.

Security CodeFinancial Instrument Identification

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

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

Unit QuantitySettled QuantityThe number of units transferred per the matched Bilateral Demand Transfer.

Account (HIN)

Safekeeping Account  The Account (HIN) that is controlled by the receiver of the Demand Transfer Confirmation. This will be the Delivering Account (HIN) for the Delivering Participant and the Receiving Account (HIN) for the Receiving Participant.
Transaction BasisSecurities Transaction TypeThe Transaction Basis of the matched Bilateral Demand Transfer and that exists in the Transaction Basis table.
Transaction ConditionSettlement Transaction Condition / Code / Proprietary / IdentificationThe type of the Transaction. In this case, Bilateral Demand Transfer (BDTR).

Delivering Participant 


Delivering Settlement Parties/Party 1/IdentificationThe Delivering Participant of the matched Bilateral Demand Transfer.

Receiving Participant

Receiving Settlement Parties/Party 1/IdentificationThe Receiving Participant of the matched Bilateral Demand Transfer.
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 response 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 response to the Receiving Participant.




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