Customer Frequently Asked Questions

We have established the CHESS Replacement mailbox and CSP Support mailbox as a means of addressing any project related or functional questions.  We have highlighted below the most recent questions of interest.

Functionality & Specifications

If the participant was to send an application request (mfnd_401) and investor details (acct_012) together we cannot guarantee in which order they will be processed by the CSP.  Should the investor details (acct_012) be processed before the application request (mfnd_401), then the investor details (acct_012) will be rejected by the system.

To guarantee that valid investor details (acct_012) related to an initial application are accepted by the  CSP, it is advisable to transmit the investor details (acct_012) message once the application request (mfnd_401) has been transmitted and the CSP has acknowledged the receipt of it.

mFund specifications are provided in ASX's documentation portal.

It's always the buyer (receiving broker) who would submit an Isolate Request for the number of units it wants to Isolate (it may not be for the full value of the Novated Rescheduled Instruction (NRI) because there may be more than one client buying but only one client is seeking to Isolate).

Once isolated, the participant on the other side failing to deliver is identified and a link is established. The original NRI is marked down by the value of the isolation and the will be available for further isolation. The resulting Isolated NRI is no longer available for further isolation. An NRI is available to be isolated until its completely isolated or delivered and if it keeps on failing it may be in the buyer's interest to isolate to discover who the sellers are that are failing to deliver. 

You can read more details here in ASX's documentation portal.

From a Rule perspective it is not mandatory for the Participant to lock a Deceased Joint account, if there is a surviving Holder. The Controlling Participant must, within 1 business day, establish a new Account (HIN) in the surviving Holder's name. The Participant transfers the relevant holdings to the new one surviving holder account (HIN). The Participant can then cancel the old, deceased Joint Holders account (HIN) once all Holdings have been transferred out.

You can read more details are provided here in ASX's documentation portal.

Participants can modify multiple attributes of a Holder Name and associated details within a single Account Modification Request. 

You can read more details here in ASX's documentation portal.

The scenario is correct.  The response received will show BOTH account status and holder status as 'Locked'. 

You can read more details here in ASX's documentation portal.

The functional process and specification for Account and Holder Locking and Unlocking are published in our Technical Documentation portal. 

Plus we have some additional information here - FAQs - Account Locking & Unlocking.

ISO 20022 message signing:

As part of our ISO 20022 Messaging technical specifications that have been published, ASX has provided a useful cross reference page to help users relate from EIS to the new standard. 

Please see the following page - ISO 20022 Messaging - TM - EIS to ISO 20022 Cross Reference Guide.

CHESS Users are represented as a DAML party in the system. A party is identified in the system by its unique DAML Party Identifier. To connect to the CSP via the Ledger API, CHESS Users undergo a formal on-boarding process which grants them one or more DAML Party Identifier(s) and permits them to access a master ingress contract.

For further details on Ledger API connectivity refer to the Connectivity section of our Documentation portal.

ISO message signing will be available from CDE 6 (from Tuesday 3 March 2020) and customers can 'opt in' to use it within CDE.  Release notes will be published to accompany CDE 6.  To opt-in to ISO Messaging signing in CDE, click here to send an email to the ASX CTS team.

Implementation & Transition

A software vendor only needs to accredit software once, so long as the same version of software is used by multiple clients.

Details on Technical Accreditation can be found in our Documentation portal.

This topic was also included in one of the Software Provider Readiness working groups. Details and slides of past sessions can be found here.

Yes, message content will be verified as a part of the messaging component of the Technical Accreditation activity.

Details on Messaging Accreditation can be found in our Documentation portal.

The first release of message test scenarios for technical accreditation was made available from April 2020.  Additional message test scenarios will be progressively released in tranches in line with the published plan.

Details on Messaging Accreditation can be found in our Documentation portal. Additional information about subsequent industry testing phases is provided under our Implementation Phases section of our Documentation portal.

Information about subsequent industry testing phases is provided under our Implementation Phases section of our Documentation portal, including the Industry Test Strategy.

Questions relating to the approach to transition, cutover and accreditation will be published in our Documentation portal under Frequently Asked Questions.  We will continue to highlight any common questions in our regular newsletter.

Connectivity

CHESS Users don't need to have access via the new CHESS UI; it is an optional connectivity channel that replaces CHESS PC software.

Product Issuer Settlement Participants (PISPs) are heavy users of CHESS PC and ASX anticipates this cohort to use the browser. Another potential cohort is an organisation that wants to use the browser as a supplementary connectivity channel for low volume corner cases.

ASX has published a CHESS UI user guide in our Documentation portal.

All access channels will be authenticated by ASX, for AMQP users this will be via ISO 20022 message signing and for Ledger API users via Token Authentication.  

ASX will provide details of the new Customer Service Account Management (CSAM) service to the Documentation portal by Q4 2021 in advance of ITE1 opening.

Ledger API questions:

CHESS Users are represented as a DAML party in the system. A party is identified in the system by its unique DAML Party Identifier. To connect to the CSP via the Ledger API, CHESS Users undergo a formal on-boarding process which grants them one or more DAML Party Identifier(s) and permits them to access a master ingress contract.

For further details on Ledger API connectivity refer to the Connectivity section of our Documentation portal.

The master ingress contract is a non-consuming DAML contract that allows CHESS Users to issue a command to the CSP to start the associated workflow.

Each DAML party in the system is permissioned to execute specific commands and business workflows as set out in the party’s master ingress contract. Each command, is a combination of choice with a parameter, which when exercised, sends an instruction to the CSP. A party can initiate a workflow by exercising a choice on the master ingress contract, which triggers a piece of code, representing a workflow, and results in one or more contracts being created or archived on the ledger.

For further information refer to Identify the Master Ingress Contract.

For further details on Ledger API connectivity refer to the Connectivity section of our Documentation portal.

When developing a Ledger API client application, events can be viewed using the getTransactionClient.getTransactionsTrees() method.

This will produce not just the committed event but the entire transaction in a tree structure. The Transaction Tree structure contains exercised choices, contracts created, and scenarios run among other events. For further information and a full description of all the attributes visible on a transaction tree, refer to the DAML SDK.

For further details on Ledger API connectivity refer to the Connectivity section of our Documentation portal.

 

Many other questions about CHESS Replacement can be found at the following links:

The following macros are not currently supported in the footer:
  • style