FAQs - Functional Specification

• ASX advised participants and vendors in March 2019 that ASX was undertaking a review of the account opening process.
• ASX has re-designed the creation and maintenance processes for both accounts and holders including messages, sequencing and workflows.
• Details of these changes have been published in our latest release of Technical Documentation in May 2019.

This wiki-style technical documentation environment is dynamic and will be updated at regular publishing intervals.  With each major publication ASX will provide detailed 'Release Notes' outlining any new functionality, updated documentation or details of version changes.  For minor updates 'What's New' notes will be provided detailing the specific changes.  Any updates will include links to the relevant pages contained within this Technical Documentation environment.

A wiki-style online environment was chosen to replace static PDFs to provide a superior customer experience in the following ways:

1. A dynamic environment allows frequent updates and transparent evolution.
2. Search capability facilitates fast navigation.
3. Integrated links enable immediate location of applicable operational, messaging and connectivity requirements.

RGID stands for “Registration Id”. The RGID is a temporary static data object that resides on the CSP. The purpose of the RGID is to identify the correct Issuer Sponsored holding involved in the movement financial products between sub-registers. The RGID contains registration details of financial products that are not held on the CHESS sub-register but are being moved between the Issuer Sponsored Sub-register and the CHESS Sub-register in preparation of some type of dealing, e.g. sale transfer.

The RGID is also used in the SRN enquiry workflow for the same purpose, to identify financial products that are being held on the Issuer Sponsored Sub-register which are the subject of the enquiry.

Once created the RGID is only valid as long as there are pending transactions that reference it. The RGID is cancelled through the housekeeping process. This means that during its life the RGID can be utilised to perform any transfers with matching registration details from all Issuer Sponsored Sub-registers.

The RGID has been introduced for two primary reasons:

1. Under the ISO standard a message cannot be used for multiple purposes. For example, separate messages must be used for the transfer of a holding and the advice of registration details, these two elements cannot be combined onto one message;
2. The RGID is to facilitate the transfer of registration details between the CSP and Issuer Sponsored Sub-register where the “holding” is not maintained within the CSP; and
3. For an Issuer Sponsored to CHESS Transfer the post-transfer registration details check currently performed by the participant is being replaced with a pre-transfer check to be performed by the registry that will make use of the data supplied on the RGID. This new checking paradigm has been introduced to provide greater holder security and reduce the instances of incorrect transfers.

Please find the following detailed description for Settlement Locks:

On Request – Mandatory - is available for “Bilateral Demand Transfer” and the new “Bilateral Demand Settlement Instruction”.  The lock is mandatory and is applied immediately because ASX considers the nature of these movements is “demand” so units must be locked otherwise when the counterparty submits its message and the units are not in the delivering HIN the movement will fail.  This defeats the purpose of the movements being “demand”.

On Request – Optional - is available for “Unilateral Settlement Instructions” and “Bilateral Settlement Instruction”.  The lock is optional and will only be applied if the original message is submitted with the optional lock set to true.  ASX considers the nature of these movements to be “scheduled into the future” (not “demand”) so the delivering participant is allowed time to receive units in to cover the movement after the original message is submitted.  There is an exception to this workflow for a Unilateral Settlement Instruction where the delivering Account (HIN) in the Accumulation Entrepot of the participant and the receiving Account (HIN) is the Settlement Entrepot of the participant.  In this case the CSP will apply a lock on request and if insufficient units are unavailable in the delivering Account (HIN) the instruction will be rejected.

On Match - Is available for “Bilateral Settlement Instructions”.  The lock can be set to “on Match” on the original message so that if the participant does not have sufficient units in the delivering account at the time of the original message but believes that units will arrive prior to the counterparty submitting its matching instruction then on match the units will be locked.  The participant can rely on the lock for movements that match.

Settlement Lock - is available for “Unilateral Settlement Instructions” and “Bilateral Settlement Instructions”.  This particular feature allows the participant to apply a lock at any time for an instruction that had not already be set to Lock on Request or Lock on Match.  The lock can be set regardless of whether the instruction is matched on unmatched and at any time after the original message was sent and before the commencement of Batch Settlement.
Settlement Lock Descriptions.

For further information refer to Settlement Locks Overview in our Technical Documentation portal.

The Lock and Unlock can happen in the following scenarios:

1. Lock a holder in case of Notification of death (NODE) and Notification of bankruptcy (BKRP)

2. Unlock a holder which was locked following a notification of death.

Holder update reason: 

-  Grant of Probate or Letters of Administration (GPLA)

-  Small Estate Statement (SEST)

-  Transfer Indemnity Bond (TIBD)

-  No holdings (NHLD)

3. Unlock a holder which was locked following a notification of bankruptcy.

Holder update reason:

-  Legal Trustee Request (LTRQ)

-  Annulment (ANNT)

4. Unlock a holder which was locked in error

Holder update reason:

-  Error (ERRO)

5. Lock and Unlock an account for a non-specific reason

Account update reason:

-  Non-specific (NOSC)

6. Lock and Unlock an account following a court order.

Account update reason:

-  Subject to Court Order (SNCO)

7. Unlock an account which was locked in error.

Account update reason:

-  Error (ERRO)

For further information refer to Account and Holder Locking and Unlocking Overview in our Technical Documentation portal.

Yes, it will be possible to transfer an Account when the Holder Type is 'Unknown' after the Cutover Weekend.

The list of valid rejection reason codes for an ETO Clearing Participant is documented in the Collateral Removal for ETO Sub-process within the Intra Position Movement Instruction Status Advice - Accepted and Rejection Business Values and Rules table.

The reason codes outlined in the table below cannot be used by the ETO Clearing Participant to reject a Collateral Removal Request.

 Yes, the full Payment Funds Obligation amount would be rejected in this scenario.

Yes, the Back-out Algorithm Process removes a Net Payment Obligation from a Participant by rescheduling the Settlement Instructions for the purchase of securities to the next settlement day. For example in the case of a default, the Back-out Algorithm Process would recalculate and put the defaulting Participant obligation to zero or in credit.

The  will only be used in the scenario where a Payment Funds Obligation has been rejected, and would only affect rejected Payment Funds Obligations (e.g. in the case of default where the Payment Funds Obligation cannot be met).

Each instruction will have a separate sub-position created with reference to the Obligation Id where there is a Settlement Lock. In the scenario where there are two matched BSSIs for the same security and Account (HIN), there would be two settlement lock sub-positions created for each instruction.

It can be confirmed that materialisation of rescheduled instructions onto the ledger and corresponding notifications (due to unit failure or default management) will not occur until batch settlement is in an irrevocable state (i.e. when funds have successfully moved in RITS). In the event batch settlement is cancelled, instructions that would have otherwise fully or partially failed or fully settled will be rescheduled to the next batch settlement cycle with the unit quantity and settlement amount scheduled for the current batch settlement cycle.

Note that Settlement Instructions ineligible to settle due to the security state will remain rescheduled or suspended as have been notified.

Note also that in the event the batch settlement cycle is cancelled novated gross market trades will be rescheduled using the NSF/NRI paradigm.

No SSP adjustment is applied or settled for NNDP’s or NRI’s that are rescheduled when batch settlement is cancelled.

These codes will exist on the Reporting Request (rptg_601) when requesting the Obligation Status Report and on the Obligation Status Report (rptg_608).

GMTD will continue to generically represent all types Gross Market Trades (both novated and non-novated).

The Settlement Instruction Type “MarketTrade” will be used to define both novated and non-novated gross market trades on the Settlement Instruction API contract. The Market Trade API contract will include a novation indicator to indicate that the gross market trade is either novated or non-novated.

An Event Notification (sett_170) will notify participants that batch settlement has been completed or cancelled. Additionally, a Settlement Status API will also exist to indicate batch settlement has been completed or cancelled for the current business date. The Event Notification (sett_170) will be sent and Settlement Status API will be updated after all settlement related notifications are sent and any applicable rescheduling of settlement instructions has occurred. All settlement instructions (that are not suspended) should be deemed settled where they exist with a settlement date on or prior to the Event Notification (sett_170) being sent or prior to the settlement date on the Settlement Status API.

During scheduled batch settlement, the Settlement Transaction Generation Notification (sett_130) and Adjusted Settlement Instruction (sett_139) will be sent by the system prior to the Settlement Movement Confirmation (sett_136). 

Once Settlement Movement Confirmations (sett_136) have been sent, the system will send an Event Notification (sett_170), advising that batch settlement has been completed. 

Where notifications are in pairs, the pairs will be generated and sent by the system at the same time. However, the order in which the pairs are received cannot be guaranteed. Examples of pairs of notifications include: 

• Settlement Transaction Generation Notifications (sett_130) are generated for both the NSF and the NRI where there is a NNDP failure; and
• A Settlement Transaction Generation (sett_130) is generated for the Part Settled/SSP Settled Component and an Adjusted Settlement Instruction (sett_139) is generated for the Rescheduled Component, in the case of a fully failed NRI. 

CHESS Replacement will notify whether a trade is novated or non-novated in the Trade Confirmation Notification (sett_101). The Trade Confirmation Notification advising that a new trade has been registered will contain a novation indicator: 

• "True" indicates the trade has been novated; and 
• "False" indicates the trade is non-novated. 

There is capability for trading participants to report a trade via an AMO that may be ineligible for novation in the clearing and settlement facility. This capability supported by the existing CHESS application will be carried forward into CHESS Replacement.

All trades on the lit market are novated.

Examples of Market Trades ineligible for novation are those that occur as the result of a booking purpose trade report. These are trades with a condition code of ‘BP’. The majority of these are crossings and as such don’t result in any scheduled settlement when they are registered in CHESS.

AMO’s allow for trade reports to be entered between two different brokers, in this flow a scheduled settlement is created in CHESS (between the different buyer and seller) – the trade is non-novated and not cleared.

These trades will be managed and maintained similar to a BSSI:

• Do not contribute to the NNDP reported in the netted obligation report and are not assessed as part of a NNDP within batch settlement;
• Full Fails will result in the rescheduling of the market trade and notified by a Settlement Transaction Generation Notification (sett_130);
• Part Fails will result in the settled component notified by a Settlement Transaction Generation Notification (sett_130) and the rescheduled component notified by a Adjusted Settlement Instruction (sett_139); and
• Are included in the Overall Net Movement (as well as the funds component and count of obligations) in the Settlement Movement Confirmation (sett_136). A breakdown specifically for the non-novated gross market trade contributing to the overall net movement will be included on the Settlement Movement Confirmation (sett_136) identified by Movement Type ‘NNGM’.

The Obligation Status Report can be requested specifically for Non-novated gross market trades (i.e. Movement Type ‘NNGM’). Non-novated gross market trades can be identified on the Obligation Status Report by Movement Type ‘NNGM’.

Since the system will no longer be creating a materialised Net Broker Obligation, the purpose of the events listed within the page Netting and Settlement Workflow Changes - Change to NNDP on Settlement Date is to highlight those events that could alter the Novated Net Delivery Position (NNDP) scheduled for settlement on the current business date that was communicated in the last Netted Obligation Report (rptg_609).

The events will also be relevant to non-novated gross market trades, NRIN, BSSI, USSI. There has been no change in the functionality to these types of settlement instructions. Please refer to Market Trade, Corporate Actions, Settlement Instruction Management and the specific sections on USSI and BSSI within Holding Transfers.

No, the intent is to move the obligation to the new participant, not to simulate the trade notification. The Settlement Transaction Generation Notification (sett_130) will contain the details of the obligation to the new participant.

Where the counterpart to a settlement obligation has changed, a settlement participant will be notified of the change of counterparty by an Adjusted Settlement Instruction (sett_139).

Noting this is not applicable to NGMT, NRI, and USSI.

The new settlement participant will receive a Settlement Transaction Generation Notification (sett_130) for any type of obligation they will settle.

Where the counterpart to a settlement obligation has changed, a settlement participant will be notified of the change of counterparty by an Adjusted Settlement Instruction (sett_139). Noting this is not applicable to NGMT, NRI, and USSI.

Fully failed USSIs, BSSIs and NNGMs will be notified via a Settlement Transaction Generation Notification (sett_130). 

NNDPs that fully, or partially, fail will be rescheduled using the NSF and NRI construct and will be notified via a Settlement Transaction Generation Notification (sett_130). 

Partially failed USSIs, BSSIs and NNGM are notified via the following messages: 

• a Settlement Transaction Generation Notification (sett_130) for the portion that is settled; and
• an Adjusted Settlement Instruction (sett_139) for the failed portion that is rescheduled. 

Fully failed NRIs are notified via the following messages: 

• a Settlement Transaction Generation Notification (sett_130) for the Standard Settlement Price (SSP) Amount that is settled; and 
• an Adjusted Settlement Instruction (sett_139) to reschedule the Unit Quantity and notify of the change in the Settlement Amount as a result of the SSP adjustment. 

Partially failed NRIs are notified via the following messages: 

• a Settlement Transaction Generation Notification (sett_130) for the portion that is settled which includes the SSP Amount; and 
• an Adjusted Settlement Instruction (sett_139) to reschedule the remaining Unit Quantity and notify of the change in the Settlement Amount as a result of the SSP adjustment. 

Where the Settlement Transaction Generation Notification (sett_130) and Adjusted Settlement Instruction (sett_139) are sent: 

• The Adjusted Settlement Instruction (sett_139) will maintain the same Transaction Id and Obligation Id of the Settlement Instruction at the time it was generated by the system. Where the Settlement Instruction is a USSI or BBSI and not an accrual, the Transaction Id will be sent in the Settlement Instruction Request (sett_105).
• The Settlement Transaction Generation Notification (sett_130) will contain a new, unique Transaction Id and Obligation Id, as well as references to the Transaction Id and Obligation Id of the Settlement Instruction that has not been fully settled (as notified in the Adjusted Settlement Instruction). The reason stated on Settlement Transaction Generation Notification will be 'PART'. 

Where a single Settlement Transaction Generation Notification (sett_130) is sent:

• Fully failed USSIs, BSSIs and NNGMs will be notified via a Settlement Transaction Generation Notification (sett_130), maintaining the same Transaction Id and Obligation Id of the Settlement Instruction at the time it was generated by the system. Where the Settlement Instruction is a USSI or BBSI and not an accrual, the Transaction Id will be sent in the Settlement Instruction Request (sett_105).
• NNDP failures will result in the generation of a NSF and a NRI per Settlement HIN, Security and BOM combination, with new unique Transaction Ids and Obligation Ids within the Settlement Transaction Generation Notification (sett_130). A related Transaction Id will link the NRI to the NSF.