Block8 recently provided a submission to the Australian Senate’s Select Committee on Financial Technology and Regulatory Technology. We focused our discussion on the use of distributed ledger technology (DLT) and its relevance to the Committee’s two public consultation papers that were released during 2020, as well as the Committee’s terms of reference in general.
The perspective we provided was one not just as technologists, or as blockchain specialists, but as a holistic product development company. Block8 not only provides professional services, but also co-ventures with subject matter experts to design, build and commercialise full-stack and production-grade software solutions. We understand the importance of discussing these topics with a practical lens. In isolation, DLT presents several novel characteristics when designing a new software application, but we must look to integrate a number of related technologies and considerations in order to realise its full potential. This includes things like scalability techniques, rules as code, privacy-preserving technologies such as zero-knowledge proofs and secure hardware, and digital identity.
This blog series mirrors our submission to the Committee, covering the following points of discussion:
If you’re in any way curious about the future of digital technology, particularly as it applies to Fintech, Regtech, or the future of the Australian digital economy, we hope you will find some value from this series.
As before, new blogs will be published each week, but if you want to read the full submission early, you can do so below.
Earlier in 2020, Block8 also supplied a Response to Treasury’s inquiry into the Future Directions for the Consumer Data Right. In it we outlined the benefits of employing a distributed-ledger based solution over the API-based messaging approach currently being implemented. While the 2018 Review into Open Banking in Australia appropriately recommended that Australia follow the UK approach to implement APIs as a first step, there doesn’t appear to be sufficient flexibility in the amendment to the Treasury Law (the law that brought the CDR into effect), and accordingly in any of the regulatory or data standards apparatus to support a distributed-ledger based solution for consumers to access their data.
While we acknowledge that it was largely drawn from the UK model, the Treasury Laws Amendment (Consumer Data Right) Bill 2018 influences its technical implementation in a way that is not technologically neutral. The Amendment defines Data Holders and Data Recipients as distinct functions and distinct entities, which, unfortunately for distributed software, clearly reflects the normative paradigm of centralised information management, i.e. copying data from a source database to a destination database via an API.
While this particular example is illustrative, the core issue is the overwhelming misapprehension that there is only a singular way to manage the sharing of data. It seems obvious why this is the case; all digital systems that have been developed in recent memory follow the same paradigm of centralised information management. But this is not the only way that software can manage information.
In fact, there need not be any distinction at all to be made between Data Holders and Data Recipients if the CDR data is provisioned using a distributed system; once a Data Recipient has made a network connection with a Data Holder, both entities would effectively become Data Holders. Such a connection would be real-time, always-on (persistent), and mathematically guaranteed to be correctly synchronised, all with the same information security requirements and guarantees of the current regime. While the original (current) issuer of the financial product would be clearly defined at all times, in such a distributed scenario, switching to the newly connected third party would be technically trivial. The new “issuer” could then assume control of the existing financial product, tune the parameters of the financial product to the newly agreed settings instantly (such as setting a lower interest rate), and automatically satisfy regulatory obligations, all with zero consumer impact beyond the original provision of consent. An interoperability environment such as this would fundamentally maximise competition and the potential for overlay fintech innovation.
The originating system however (being the system of record for the financial product) must be compatible with a distributed ledger based architecture, or indeed be based on distributed ledger technology to begin with. This requires either replacing the originating product system, or retro-fitting it with a transparency layer. But of course consumers do not care about the incumberences of legacy technology; this is the disruption (resp. opportunity) scenario that could be available to new entrants if the regulatory environment so supported it.
While there does not appear to be any explicit roadblock contained in the relevant CDR rules, and recognising Recommendation 1.1 from the Review into Open Banking, there persists a lack of regulatory clarity for the use of smart contracts to satisfy the requirements and principles of the CDR:
“Open Banking should not be mandated as the only way that banking data may be shared. Allowing competing approaches will provide an important test on the design quality of Open Banking and the Consumer Data Right.”
Further information on the use of DLT in the CDR can be found in our submission available on our website or via Treasury.
Following the above in relation to the use of DLT for achieving CDR-based outcomes, we note that this currently falls outside of the remit for the ASIC FinTech Sandbox. In fact, there are currently no regulatory testing environments for the application of smart contracts to fintech or regtech use cases. While there is a degree of ministerial interest in investigating these kinds of innovative approaches, and beyond the constraints of the language used in both law and regulation, regulators themselves have no venue (or indeed no practical mandate) to satisfy themselves that different ways of solving the problem can be supported.
Whatever the eventual regulatory home for the CDR, consideration should be given to establishing an appropriate regulatory sandbox environment to provide a proving ground for smart-contract-based or otherwise alternative solutions that may not fit the current legal and regulatory articulation. This will be ever more important as Open Banking matures and the CDR expands to other sectors.
In their submission to the Inquiry into the Future Directions for the Consumer Data Right, the NPPA advised that enabling write access would be delivered via their existing access regime; the Mandated Payments System (MPS) for third party initiation of account to account payments is due for rollout completion in 2021 and builds upon the existing infrastructure and capabilities (fraud, security etc.) that are in place today. While the MPS is not covered by the CDR, the NPPA’s position is that the current design will materially deliver the capability that the fintech community is seeking in terms of third-party payment initiation, albeit via satisfying technical, commercial and regulatory connectivity requirements. NPPA also established their intention to harmonise their third-party write access interface with the CDR data standards where possible.
At this stage, Block8 supports the NPPA’s position to exclude write access to the MPS under the CDR. However, critically, while Direct Debit is captured under the CDR Data Standards, we note that read access for customer mandates is not. This appears to originate from the Consumer Data Right Rules wherein direct debit is stipulated for inclusion under CDR account data. It is unclear whether the exclusion of NPP mandates was intentional and potentially done under the assumption of capture in a future CDR extension. Regardless, third party access to customer NPP mandate information will be at least as important as access to Direct Debit information given that API-based write access is made possible via the NPP access framework.
We note that any distributed information infrastructure under the CDR would still be required to comply with the existing rules for Data Holders. Information security, licencing, data coverage and reciprocity requirements remain the same between both approaches, however a Data Holder source system based on smart contracts would avoid the need to implement a separate API; the data is already shared (distributed) to nodes that have permission to connect.
The CDR Data Standards Body has endorsed an OpenID Connect-based authentication scheme, which sets Data Holders as Identity Providers and Data Recipients as the relying party. An end-to-end orchestration of CDR data involves both (i) authentication flows of consent between the end-customer and the Data Recipient, as well as (ii) authentication flows between the Data Recipient, Data Holder, and CDR Register (a centralised service operated by the ACCC).
The CDR rules appear to have been written with a specific end-state in mind; the ways in which data sharing and authentication flows are described closely reflects how a set of established institutions would augment their existing systems to send and receive CDR data. However, new fintech and regtech entrants may be able to offer alternative solutions that do not strictly conform with the current standards, for example:
By decoupling these kinds of common fintech and regtech functions, we maximise interoperability and the potential for competitive and novel approaches to come to market. Such decoupling does not prevent existing businesses from implementing their desired architecture, but it does provide an easy option for decoupling in the future.
This is a critical consideration in deciding regulatory and technical rules for implementation of schemes such as the CDR; the nature of the technical interoperability rules directly influences what fintech and regtech services can be offered in the market. If a fully modular approach to interoperability is not adopted, then we necessarily inherit decisions relating to market competition, regardless of whether the impacts of those decisions have been fully considered.
Block8 would be happy to further discuss our thinking on any of the topics covered above, including specific detail on solution architectures and demonstrations of currently working distributed ledger systems developed to address the challenges and opportunities outlined in the Issues Paper and our Response.
Our experts are also available to assist with research mapping the value chains for centralised and decentralised approaches, the identification of the highest-value areas for a consumer-centric data infrastructure, or working with the Government and other members of industry in the development of pilot or production programs.
 A principle of ‘reciprocity’ exists in the CDR ecosystem which requires Data Recipients to subsequently inherit Data Holder obligations, however even with full reciprocity the benefits of a distributed data sharing scheme would not be obtained.
 The current operational control and consent arrangements established by the NPPA have been through a thorough design process, and while the inclusion of mandates under the CDR would undoubtedly turbocharge fintech innovation, write-access to cash payments should be considered at a later time as and when financial institution interoperability matures.
 ACCC: Competition and Consumer (Consumer Data Right) Rules 2020
About the Author:
Samuel G Brooks is Block8's Chief Technology Officer.
He is an expert in developing decentralised software products and has designed numerous solutions for startups, enterprise, government and OpenTech since 2014.
Samuel regularly speaks at technology conferences, meetups and podcasts, and holds several advisory positions on technical industry boards and committees. He is a also a heavy contributor to blockchain and fintech-related public inquiry and writes about the nature and benefits of distributed ledger technology on our blog.
Samuel holds a degree in Electrical Engineering from UNSW, and has stayed close to both the code and the latest research ever since encountering Bitcoin in 2011.