FAQs - Functional Specification

Table of Contents

What is happening with Account & Holder Creation and Modification?

 Answer
  • 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.

How will ASX manage versions of Technical Documentation?

 Answer

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.

Why has the Technical Documentation changed format?

 Answer

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.

What is a Registration Identifier (RGID)?

 Answer

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.

What is the Purpose of the Registration Identifier (RGID)?

 Answer

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.

Can you please provide further information around Settlement Locks?

 Answer

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.

Can you confirm the Account and Holder Locking and Unlocking process?

 Answer

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.

Is it possible to transfer (via the Change of Controlling Participant Process) an Account with an Account Type of Sponsored while the Holder Type is Unknown after the Cutover Weekend?

 Answer

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

When an ETO Clearing Participant rejects a collateral removal request received from a Controlling Participant, what rejection reason codes should be used?

 Answer

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.

Reason CodeUsage
ASX Clear Directive (ASXD)This reason code can only be used by ASX Clear when requesting the removal of collateral as a part of the Collateral Removal by ASX Clear Process.
Security approaching expiry date (EXPI)This reason code can only be provided in a Collateral Removal Notification (pldg_306) sent by the CSP as a part of the Collateral Removal Warning due to Expiry Process.
ETO Clearing Participant Authorisation Required (CPAR)

This reason code is provided to ASX Clear by the CSP following the acceptance of a Controlling Participant's Collateral Removal/Reduction request by the ETO Clearing Participant as a part of the Collateral Removal for ETO Sub-process.

This process is only applicable where the Controlling Participant is not the ETO Clearing Participant.

When a Payment Provider rejects a Payment Funds Obligation as a part of the Aggregate Funds Obligation Process, there is no attribute to provide the rejection amount. Will the rejection always be for full amount against a Payment Facility?

 Answer

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

Where a Participant has a single Payment Facility with a Payment Provider and a Payment Funds Obligation is rejected by the Payment Provider as a part of the Aggregate Funds Obligation Process, will all obligations for the Participant will be re-scheduled through the Default Management Back-out Algorithm Process?

 Answer

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.

Where a Participant has multiple Payment Facilities (e.g. Payment Facilities 'A', 'B' and 'C') associated with a Payment Provider, and a Payment Funds Obligation is rejected for a single Payment Facility (i.e Payment Facility 'A') as a part of the Aggregate Funds Obligation Process, will the Default Management Back-out Algorithm be applied to Payment Facilities 'B' and 'C' in order to re-calculate the funds for the remaining Payment Facilities?

 Answer

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

The Total Balance of a security holding on an Account (HIN) consists of the Available Balance, Holding Administration Lock balance, one or more collateral sub-positions, one or more Bid Election sub-positions and one or more Settlement Lock Balances. Are the Settlement Lock Balances being maintained separately for each Settlement Instruction? For example, if there are two matched Bilateral Demand Settlement Instructions (BSSIs) for the same security and Account (HIN), does the CSP will maintain two separate Settlement Lock balances?

 Answer

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.

What transactions can be completed when the CHESS Sub-register is either suspended, closed or archived?

 Answer
TransactionOpenSuspendedClosedArchivedNotes
Trade RegistrationTrades registered in during a suspended or closed states will not settle unless sub-register is re-opened.
Scheduling Settlement InstructionsSettlement instructions created during a suspended state will not settle unless sub-register re-opened.
Transfers between HINs (either via demand transfer or batch settlement)
Transfers and conversions between participant and issuer sponsored sub-registers✖ (conversions on suspended sub-registers may be initiated by ASXO)In-flight Issuer to Participant Transfers & Conversions may be completed in a Suspended or Closed state
Holding Adjustments
mFund OrdersIn-flight mFund orders may be completed in a Suspended or Closed state
Takeover processing
Collateral processing

Netting and Settlement Workflow Changes

For further details regarding the design of netting and settlement workflows, refer to the following documentation: 


Focus Group FAQs

ASX hosted three focus groups in March 2021 to discuss the changes to netting & settlement workflows with impacted stakeholders including software providers, clearing & settlement participants and settlement participants. Frequently asked questions on the changes, including questions asked before, during and after the March 2021 focus group sessions are also available here.


Cancellation of settlement batch, and timing of Settlement Instruction Generation Notification (sett_130)

It appears that the Sufficient Unit Check Process reschedules one or more settlement instructions or NNDPs with SSP adjustments applied and Settlement Instruction Generation Notifications (sett_130) sent, and if batch settlement is cancelled at a subsequent stage, there will be no means of settling the SSP adjustments already notified. Can you confirm this cannot happen, and also clarify how settlement batch cancellation will work if some instructions/positions have already been rescheduled because of unit failure, and exactly when these messages get sent under different circumstances?

 Answer

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.

Clarification on new acronyms

Besides Movement Type on the Settlement Movement Confirmation (sett_136), where else will we see the new NGMT and NNGM acronyms?

 Answer

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

Will the Settlement Transaction Condition still be GMTD for both novated and non-novated trades?

 Answer

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

Will the Settlement Instruction Type on the Settlement Instruction API contract continue to be GMTD for all Market Trades, or will it change to NGMT/NNGM?

 Answer

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.

Reflection of settlement in API contracts

At what point will settlement be reflected in the relevant API contracts, in particular the Settlement Instruction API Contract?

 Answer

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.

Timing of Settlement Instruction Generation Notification (sett_130)

During the settlement batch, will a Settlement Instruction Generation Notification (sett_130) (and related Adjusted Settlement Instruction (sett_139) where applicable) be sent before or after the related Settlement Movement Confirmation (sett_136) or is there no particular order?

 Answer

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. 

Non-novated gross market trades

Which trades/securities will be ineligible for novation?

 Answer

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

Change to NNDP on Settlement Date

Do the events listed on the Netting and Settlement Workflow Changes page only impact novated gross market trades (NNDP) or are other types of settlement instruction similarly impacted by some or all of these events?

 Answer

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 TradeCorporate Actions, Settlement Instruction Management and the specific sections on USSI and BSSI within Holding Transfers.

Clarifications on the communication of an ASX Operations initiated transfer to manage a default or by the request of a regulator or enforcement agency

Functionality / Event

Communicated to Participants

ASX Operations initiated transfer to manage a default or by the request of a regulator or enforcement agency.

Each transfer will be communicated to Participants using:

  • For Novated Rescheduled Instructions and Market Trades (Novated and Non-Novated), Settlement Instruction Cancellation Advice (sett_122) to the original Settlement Participant

  • For BSSIs, Settlement Instruction Status Advice (sett_109) to the original Settlement Participant
  • Settlement Transaction Generation Notification (sett_130) to the new Settlement Participant

  • Adjusted Settlement Instruction (sett_139) to the counterparty of the transferred settlement instruction

Will the Settlement Transaction Generation Notification (sett_130) to the new settlement participant identify this as a GMTD?

 Answer

All gross market trades (novated and non-novated) will be denoted with the Settlement Transaction Condition of ‘GMTD’

Will there be any way for the new settlement participant to recover attributes of the trade that would have been contained on the Trade Confirmation Notification (sett_101) to the original settlement participant but are not accommodated on Settlement Transaction Generation Notification (sett_130)?

 Answer

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.

What will be contained on the Adjusted Settlement Instruction (sett_139) to the counterparty? If this is for a novated trade, what will have changed from the counterparty’s point of view?

 Answer

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.

Does the event generating the Settlement Transaction Generation Notification (sett_130) only apply to novated gross market trades, or can it also apply to other settlement instruction types. Is that why the counterparty might receive an Adjusted Settlement Instruction (sett_139)?

 Answer

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.

Novated rescheduled instructions

When a NRI fails settlement and no units are settled, what is the settlement amount of the rescheduled component and is it adjusted for the SSP that has been paid or received in the batch settlement cycle in which the NRI fully failed?

 Answer

Settlement Failure Notifications

How are failed settlements notified? 

 Answer

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. 

How do these notifications link to the failed obligation? 

 Answer

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. 




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