Appendix 1: Assessment tool for evaluating DLT-based services
This appendix should be read with Information Sheet 219Evaluating distributed ledger technology (INFO 219).
We have set out six categories of questions for you to consider in your assessment of using distributed ledger technology (DLT) for your business. These questions are designed to help you and ASIC to assess whether the service meets appropriate technology and risk management standards. If you think about these questions before you approach ASIC for guidance or an application, our response to the issues you raise will be quicker and more efficient.
Some questions may be more applicable to some business models or services than others. For example, if your service has the potential to have an impact on the wider financial system or if your participants are important in terms of their size or interconnectedness, we may give greater consideration to questions about scalability, network effects and financial stability.
Is there an existing service provider which performs these functions already?
Understanding the functions and history of any existing services will help to quickly identify the breadth of the regulatory and risk landscape in which the DLT is to function and will provide a benchmark for assessing the use of the DLT-based service.
Who will the participants/users of the service be and what permissions will they have?
We would like to know whether the DLT will be permissioned or permissionless.  If the DLT is permissioned, we will be interested in the assessment criteria for participation and permissions available. If the DLT is permissionless, we will want to understand your assessment of the associated risks (such as compliance with Know Your Customer laws) and how they are effectively managed. See also Table 4.
What information will be held on the ledger of the DLT?
The information held on the DLT ledger may be, for example, a time stamp, tokens of ownership, identification data, a 'hash' of transactions, or it may be something more extensive. See also Table 3.
Does the service require immutability?
Immutability means that the information stored on the ledger cannot be modified after it is created. There may be a stronger case for using DLT for the service if the information required by the service needs to be or should be immutable.
Does the design include any smart contracts?
We are interested in any technology which is used to develop and run smart contracts, as well as how they integrate with the rest of the service.
Table 2: What DLT platform is being used?
What is the DLT platform used?
There are many different platforms that can be used (such as Bitcoin, Ethereum, Ripple, Hyperledger and Corda). It is important to understand the functionality of the chosen platform and whether it effectively supports the proposed business model.
What information standards apply or are relevant to your service?
For example, the financial services industry relies heavily on a number of standards based on particular organisations, such as the International Organization for Standardization (ISO), International Swaps and Derivatives Association (ISDA) and FIX Protocol (FPL).
Is the platform reliable and stable?
It would be useful to understand any tests on the platform because evidence of identifications for failure and their remediation is useful in understanding the risks of a platform.
Can the platform provide interoperability?
Will the service be working alongside existing systems and other systems, such as payment systems or digital currencies?
Is the platform secure?
It is important that the encryption used in the DLT is robust and that threats to the safety of the DLT-based service are recognised, understood and planned for.
Table 3: How is the DLT using data?
What data is the DLT-based service running on?
What is the source of the data that is being recorded on the ledger, how reliable is it and how appropriate is it to make this information available to others?
Who is allowed to access data on the DLT-based service?
DLT can be used to put in place a range of access arrangements, from information being visible to the public at large, to being visible only to participants only to the extent of the records or transactions that have involved that participant. The extent of this visibility can raise considerations of confidentiality, market abuse and privacy.
What are the data security mechanisms?
How will the data submitted to the DLT-based service and the information on the ledger be protected from security issues such as unauthorised access and operational failure?
How can regulators view the data?
Depending on the nature of the data and information consumed and recorded on the DLT, it may be more efficient for you and ASIC if we had real-time access to the ledger. If so, we would like to understand the permissions that regulators may be given and what part of the ledger they will be able to access.
Will records of changes to the data be kept?
If changes in the record can be made, it will be important that records of the changes are kept as they may not be evident from the ledger once changed.
Table 4: How is the DLT run?
Who operates, owns or oversees the DLT-based service?
The owner, operator or overseer of the DLT-based service can influence its operations or governance. If the DLT operates in a decentralised manner, how are the associated risks in operating, running and overseeing the service being appropriately and effectively managed?
What are the protocols and standards of the DLT-based service?
There are different sets of protocols and standards which are relevant. There are those related to the operation of the DLT and then there are those related to the financial service provided by the facility. For example, where the DLT is to be used with a facility relating to derivative contracts, the financial protocol being used could be one based on the ISDA and Financial products Markup Language (FpML) frameworks.
What consensus mechanisms, if any, are used?
As the consensus mechanism is effectively the arbitrator between participants in relation to the information on the ledger, different mechanisms can produce different real-world outcomes. The technological operation of the mechanism and its real-world consequences would need to be understood.
What are the participation conditions, if any?
If the DLT is permissioned, the conditions of participation will determine who has access to the facility. Would such conditions provide non-discriminatory access or a different outcome?
Where are the rules or procedures of the service located?
If there are rules or procedures governing the operation of the DLT, how are these rules made available (e.g. through code, smart contracts, constitution, operating rules), are the rules transparent, are the mechanisms for creating and changing rules consistent and understood?
Are the operation and rules of the DLT-based service fair?
Does the DLT support the fairness of the service? This could depend on whether the DLT sets non-discriminatory arrangements for access or whether there is transparency in its rules.
Table 5: How does the DLT work under the law?
Which legal systems apply to the DLT-based service?
Where a DLT-based service operates across borders, cross-jurisdictional legal questions may arise. Factors that may affect the jurisdictional issues include the location of participants, staff, the legal entity and infrastructure, and the location in which contracts are created and governed.
Is the DLT sufficiently flexible for the purpose it was created?
There are many cases where the legal system does not permit the enforcement of a contract solely on its terms, for example insolvency laws (clawback of transactions). The DLT may need to have the flexibility to reflect the legal system in full, and not just selected parts. Also, flexibility to correct identified breaches needs to be considered.
Does the DLT-based service create property rights?
The complexity of legal issues can increase considerably if the DLT used by a service creates rights in property as well as contractual rights between the participants.
Will the DLT comply with regulation?
The DLT must be able to comply with applicable regulation, including for financial services and use of information. It should also facilitate compliance by participants and other systems which connect with it.
How will it affect existing arrangements, if any, between participants?
Can the use of DLT cause changes to existing arrangements between participants (including participants of the service or intermediaries)? This would include circumstances where existing arrangements cease or are no longer able to be performed in their current manner.
Are the workings of the DLT-based service legal?
Does the use of DLT by the service cause the creation, variation, performance and termination of rights and obligations, and how will the use of DLT be consistent with the law?
Table 6: How does the DLT affect others?
Can the DLT-based service connect with other systems?
A service's ability to link with other systems will allow ASIC to assess its potential influence on the wider financial system.
What is the timing of finality in the DLT-based service?
If transactions recorded on a DLT are recorded only at particular intervals of time then the finality which they may be able to offer participants cannot be of a shorter time. Does this give rise to any risks?
Is the DLT platform scalable?
Is the DLT platform scalable and what limits have been identified? Where a DLT platform is considered highly scalable, what risk trade-offs (if any) have been identified to enable this?
What are the network effects?
As the use of the DLT increases, it can attract a greater number of participants at an increasing scale. If the DLT and the service which uses it are scalable and become widely used, then considerations about competition, open access and concentration may arise.
How is the DLT-based service affected by participant failure or default?
Certain types of financial market infrastructures or services can depend on the ongoing viability of their participants for their own viability. We are interested in the effect which the failure of its participants could have on the service itself and on other participants.
Are there plans for managing service failures?
Management of these failures should be planned in advance. This is because if failures in this service are not contemplated and planned for, there is an increased likelihood that any such failures will have a much more significant impact on the viability of the service and its participants.
Does the DLT-based service have broader financial stability impacts or implications?
A service using DLT with linkages to the broader financial services ecosystem could cause instability if it fails. Services which use DLT may need to understand the impact their activities may have on broader financial stability, particularly where their participants are important in terms of size and/or interconnectedness.
 In a permissioned ledger, participants are known and identifiable. Only those with authorised access can write to the ledger.[back to text]
 In a permissionless or unpermissioned ledger, anyone can have access and can write to the ledger.[back to text]