Minutes - 11 Dec 2019

Data Standards Advisory Committee, Meeting Minutes

Date: Wednesday 11 December 2019
Location: AEMO, Level 22, 530 Collins Street, Melbourne
Time: 10:00 to 12:00
Meeting: Committee Meeting No: 2

Download meeting minutes (PDF 202KB)

 

Attendees

 

Chair Introduction

The Chair of the Data Standards (DSB) opened the meeting and thanked all committee members and observers for attending meeting no 2. The Chair thanked Joe Locandro from AEMO for hosting the December meeting.

The Chair introduced Barry Thomas, the Director of the Data Standards Body and invited him to provide a brief summary of what he has done in particularly in the standards area and culminating in his most recent role.

Barry Thomas noted that he was originally involved in co-founding a standards body for mortgage lending, called LIXI Limited and spent 8 years there as the Technical Director. It was noted that he was also very involved in the original scoping work for the national electronic conveyancing system and more recently spent 18 months with ABA as their Director of Open Banking Standards, working intimately with the DSB putting together the first iteration of the Consumer Data Right (CDR).

The Chair noted that Barry has succeeded Mark Staples who was our acting Director and before that Warren Bradey.

The Chair introduced Spiz Dimopoulos from Energy Australia who was not able to attend the initial meeting and asked him to provide a brief summary of his experience.

Spiz Dimopoulos noted that he started his career with 15 years in banking and then the following 15 years in energy. It was noted that his last role in banking was Head of Marketing for Credit Cards and in the last 15 years he has spent time at AGL and Energy Australia with roles in strategy and sales. He is currently the General Manger, Analytics and Insights at Energy Australia.

Fiona Walker from ACCC also introduced herself. It was noted that she will be working with Bruce Cooper in the Consumer Data Right Branch on future sectors and focussing on the energy sector.

The Chair noted that Gartner has a Data & Analytics Summit which is being held on the 17-18 February 2020 and that he has been asked to present on “Rethink Consumer Insights Strategy in the New Data Economy: How to Capitalise on Consumer Data Right”. It was noted that he has been asked to put together a panel of 3 or 4 people and has asked committee members that are interested in being on the panel to let him know.

ACTION: Committee Members to advise the Chair if they are interested in participating on the panel at the Data & Analytics Summit.

It was noted that Ed Shaw from AusGrid & Ying Chin from OAIC were apologies for this meeting.

Minutes

Minutes

The Chair thanked the Committee Members for their comments and feedback on the Minutes from the 13 November 2019 Advisory Committee meeting. The Minutes were taken as read and formally accepted.

Action Items

The Chair noted that the Action Items were either completed or would be covered off in scheduled discussions.

Data Standards Body Update

The Chair noted that the meeting will address the Working Groups and the CDR Energy Standards Development Framework (Framework) document, followed by an update from ACCC & Treasury.

The DSB noted that the Framework provides us with a starting point from which we can begin to identify and address the challenges that will arise as we move into a new sector. The Framework is the starting point for us to build our work program as we move forward.

It was noted that the standards are constrained and defined by the Rules and that it is a very clear relationship. It was noted that at the same time the work to create the standards can often inform the Rules. This necessitates work on developing standards and Rules progressing to some degree in parallel.

It was noted that the Framework has been proven in practice as it is the same process we went through in banking. It was noted that as the Framework is a starting point, it does not in itself attempt to make any decisions. It merely identifies decisions that need to be made and outlines the process we need to go through.

It was noted that there are four key components to the Framework document, with the first one being the high-level principles. This section proved to be particularly important for the banking work because it provided a context for making necessary trade-offs between conflicting architectural and standards approaches.

It was noted that those principles have worked well for us in the banking sector over the past 18 months and that they can be expected to work equally well in the energy sector as they are quite generic and qualitative. It was noted that the principles are noted in Appendix A of the noting paper.

It was noted that energy introduces a new complexity which is cross sector consistency. It was noted that the Framework document proposes an additional outcome-based principle reflecting the intent of the overall regime to be an economy-wide consistent data sharing mechanism. This is referenced in the Framework paper as “Principle 5: APIs are consistent across sectors”.

It was noted that we previously put the banking Framework document on GitHub for public comment and expect to do the same for the energy sector.

One member noted that cross sector consistency is a great principle, but that it should ideally have been included in the banking framework as well, to ensure awareness that the APIs need to be consistent across sectors when designing for the first one. In response it was noted that we started with banking knowing it was cross economy and that the way that this principle has been framed is to say we need to be consistent across sectors. It does not say that future sectors are bound by decisions made for the first sector. It was noted that this principle cuts both ways and could lead to changes for the banking sector. It was noted that when we introduce a third sector the principles will cut across all three sectors and so on.

It was noted that the second section of the Framework outlines the drivers for cross sector consistency. It was noted that when we started the journey it was very much a case of having to identify why we would diverge from the UK standards. It was noted that for the energy sector, instead of aligning to other jurisdictions’ standards, our focus will be on aligning appropriately to the standards that we now have in place.

It was noted that there have been discussions on the divergence internally and across the different agencies and, taking into account the Chair’s guidance, it was noted that this area would be good for open discussion and particularly public consultation.

The Chair noted that we have also sought to use global standards where practical. One member noted the need to have consistency of standards given that there are various bodies (e.g. one in the Victorian Government and one in the Federal Government) now looking at API-related standards and there could be synergies achieved by aligning with these. It was noted that the Financial-Grade API Group (FAPI) has contacted us and said that they were aware of a number of departures from their standards to our standards. Some of those are listed on page three of the Framework paper and reasons are given for the cross-sector divergence. It was noted that some divergences occurred because the Rules required it, or we had different characteristics in the operational environment and/or also that we are building a cross sector regime.

It was noted that the primary reason driving divergence from existing standards is that we are bound by specific and prescriptive Rules. More broadly-based existing standards lacking such a frame of reference for standard development can be a little generic or high level for our purposes. It was noted that our particular challenge is to provide consistency in a regime that is designed for economy-wide application.

The Chair asked if we have a principle about using global standards where we can. It was noted that we do and it can be found in the Framework document as “Principle 2, APIs use open standards”. It was noted that when talking to standard setting groups they were often very keen to talk to us because we have a statutory requirement for compliance whilst most of the other standards organisations rely on voluntary compliance.

One member noted that for anyone that exports their applications globally it is really important to be consistent with global standards where possible.

The Chair noted that in the case of banking the organisations that have come to see us were all intermediaries, largely due to their uncertainty as to where they fit into the regime.

One member noted that one characteristic of global, open standards is that anyone can use the standard. The CDS are different in that they can only be used in the context of the CDR by parties approved and regulated by the ACCC.

The Chair reiterated that open standards are different to global standards. Open standards are standards that are open and able to be accessed by all where global standards are standards that apply across the world. It was noted that it is unlikely there will be global standards specific to our context as defined by the Rules.

It was noted that we are working in the context of government, and often if you take a closed standard there is a proprietary aspect to that with commercial attachments. It was noted that our bias to open standards means, in the same way as DTA being biased towards open source software, it is more viable to ask people to implement our standards as a regulatory and compliance requirement. It was noted that there are some sections where more closed standards have been proposed and the principle of use of open standards does not preclude us from using existing standards that are established and widely used and controlled by a commercial entity. It was again noted that our bias is towards open standards.

It was noted that an example of this is that we have been approached by Swift. They have engaged with us on the banking sector and were very keen for us to use their standards particularly for the transaction and payment section of our standards for banking. It was noted that in the end we utilised aspects of their standards but we did not align with their standards because it is a closed standard controlled by Swift, and it is a highly banking-oriented standard. It was noted that we did not feel that it would benefit us in a cross-sector scenario if we embraced their standards too much and it would have caused us to change the way we were doing standards across the board. It was noted that we utilised them from a data representation perspective with fields, field types, general structure etc., however we did not take their standards verbatim.

The Chair requested that the API & InfoSec Lead update the Framework document to provide more clarity.

ACTION: DSB to update the Framework document to provide more clarity on global standards.

One member noted that in regards to the language in “Principle 2: API’s use open standards” that it is perhaps in part in conflict with the language in the new “Principle 5: APIs are consistent across sectors”. It was noted that we are talking about “open standards that are robust and widely used in the industry will be used wherever possible” but in “Principle 5: APIs are consistent and across sectors”, thus it may be appropriate to consider a change in Principle 2 to remove “in the industry”.

ACTION:  DSB to update Principle 2 in the Framework document and to remove, “in the industry”.

One member noted that the Framework document is very much about data standards and what has already been done in banking with data standards. They noted that they are interested in where we come from the other direction and look at what energy industry standards and regulations are already in place. For example, the obligation to share data with Australian Energy Market Operator (AEMO) and others. It was noted that this is from a data and API point of view and the less complicated we make it the easier it will be to implement.

The Chair noted that we are dealing with something which is covered by separate legislation and it has a defined scope according to the Designation Instrument and the Legislation and then the Rules. It was noted that there could be reasons for the divergence and for non-divergence.

It was noted that the Framework Principles are necessarily a statement of intention, and that standards development is always intentional. It was noted that some of the Principles do have the potential to conflict at times.

It was noted that we have a “Principle 7: APIs are simple”. It was noted that we are striving for simplicity, because complexity leads to implementation costs and ambiguity. One of the hardest issues the DSB have had in the last 18 months is scenarios where we have a wide range of opinions in the community. If we took into account everyone’s opinion the standards would have become hideously complex so the DSB try to find a solution that deals with all the issues in the simplest workable way. It was further noted that we are not creating an implementation in response to a series of standards, we are actually building a standard ourselves. The result of the work the DSB do is actually an industry open standard and we do not see what we are producing is lesser than the other standards out there. It was noted that our obligation is to take the best from the things that are out there and deal with our specific policy, legislative and rules requirements to come up with a simple solution that is good technically while meeting these principles.

The Chair noted that it would be good to capture these comments in the Framework document. Pointing out the tensions with “simplicity vs global standards” and “divergence vs alignment” and providing some examples which may flesh this out a bit.

One member noted, in regards to customer experience, that the feedback they provided through the open banking process will need to be replicated here somewhat. It was noted that when consumers make decisions, what preconditions need to be met to make them effective comparative decisions. It was noted that the sorts of things that we need to think about are i) accessibility - removing barriers for as many customers as possible, ii) is the information presented comprehensible (can they understand the information presented to them so that is maximises the consumer control and choice?), and iii) accountability (if the consumers are unhappy with a transaction that has occurred do they have a way to rectify and is that available readily?). It was noted that we are designing a system for the consumers who need to have a good customer experience and we would like that reflected in the standards as well.

One member asked if this was addressed in banking. The Chair noted that it was not initially, but we did get to the point of doing three rounds of Consumer Experience (CX) testing to guide the CX Guidelines and Standards. It was noted that we should build this in now as a Principle for energy.

One member noted that it might be preferable not to build the APIs standards until the CX and the system is developed. It was noted that one of key questions before the API’s are really defined and the entire flow determined is what are the CX options? It was noted that API’s sit in the context of system design and they must refer to that.

One member noted the significance of the non-consumer-facing data holders in energy, in the context of the Principles (Valid reasons for cross sector divergence), as opposed to in banking where transactions are pretty much held with the bank. With energy, there seems to be a lot of disparate sources, and not a lot are customer facing. When we get to consent it is going to get tricky because we are asking the consumers to go back to the original data holders for consent - or are we looking at another way to do that via the data recipient?

The Chair noted that as we have found out in the early work done by the CX team, the concept of consent is quite new and ground-breaking for 99.5% of consumers. It was noted that the learning rate we found from Round 1 to Round 2 was quite substantial. It was noted that after briefing them for ten minutes, the vertical uplift of their understanding that they actually have a choice was substantial.

DSB noted that the first encounter with data sharing in CDR is a leap for many people. It was noted that we are trying to understand some of the on-flowing responses by recruiting a consumer panel so we can reengage on some of these things. It is noted that we are doing this to try and overcome the initial barrier to see how much learnability is a factor.

One member noted that the APIs have to sit in a systems context, and a more nuanced examination of what consent looks like.  It was noted that we are reinforcing that CX is significant and needs to be done early rather than later.

One member noted that this partly covers the relatively low digital enablement conversation but is also partly to do with the use cases conversations. They noted that they agree with the principle that we need the CX right up front but would suggest that we don’t have to necessarily stop any work on API’s unless you have CX sorted out. It was noted that some of the payloads and transactions are going to be necessary regardless of CX findings.

DSB noted that we established the principles using our decision proposals process for consultation, resulting in a much broader set of feedback coming in and much more to consider. It was noted that the process for making decisions is a process that meets our obligations under the Rules and the legislation and meets the Chair’s requirements, as the person who makes and decides the standards. It was noted that our process creates an environment where we tackle small issues incrementally and invites as much consultation as possible into the conversation with the wider community. The name “decision proposal process” is just a description of what it is. The process is articulated in the Framework document under “Decision Making Operating Model”.

One member noted that the “Decision Making Operating Model” had a logical flow going through the working groups and the only comment he had to make was in section 6. This was, “If the Chair is comfortable with the decision, then the decision document is sent to the EDSAC for a final review for a period of two business days”. It was asked is two days enough for review and sign off?

The Chair noted that the decision proposals were only sent to him after extensive consultation via GitHub with the wider community. It was noted that by the time anything reaches the decision proposal stage it is not a surprise to anyone after the consultation period, and that is why we have used two business days for the final check in the banking sector and are suggesting the same for the energy.

DSB noted that in over 50 consultations done to date, which have all gone to the Advisory Committee with a two day turn around, there has only been one where we have had feedback from an Advisory Committee member in Banking. In that instance we held up the final decision until we were able to consult further.

One member suggested that we extend the review period from two business days to five business days to allow additional time for the review and sign off in organisations.

One member noted that, from their perspective, engaging via GitHub has been a challenge as they don’t have time and they have resource constraints as they cut across many sectors. It was noted that if there were any major decisions that required committee feedback that it would be useful to receive this via email as well as on GitHub. It was noted that they have also found the two day turn around challenging.

DSB noted that the process this time around will be a little different. It was noted that GitHub is a place of record for us and a publicly accessible place but that it can be a somewhat difficult for non-technical people, however it is definitive. It was noted that the ongoing process will be to hold more public meetings, teleconferences and face-to-face meetings. It was noted that GitHub can be a way for people to lodge comments and keep up to date but we will also have other parallel processes available for non-technical people.

The Chair noted that we will update point 2 in the “Decision Making Operating Model” section of the Framework paper to include “provide the details via email to committee members”. It will be updated to, “The decision to be made is defined by the relevant stream lead (API and InfoSec Lead or Consumer Experience Lead) and a decision proposal document, with context and options, is published and we will provide the details via email to Advisory Committee members.”

ACTION: DSB to update point 2 in the “Decision Making Operating Model to include the step of emailing members.

DSB noted that in regards to the “Foundational Decisions” section in the Framework document, this is not a set of decisions. It was noted that what we have tried to do is identify a series of questions, without any proposed answers at this stage, that the DSB feels need to be progressed before we can get into the details. It was noted that in the banking sector we also had early foundation questions. It was noted that we can parallelise some things, but some decisions will invalidate other work unless we know up front. It was noted that we have tried to break these decisions into two sections, one which is for decisions that have policy or legal impact and decisions that are technical in nature.

It was noted from a standards perspective the questions are definitely in the rules, policy and legal area first. It was noted the standards follow the Rules. The standards do not go outside the Rules or add to the Rules, they work within the constraints of the Rules. It was noted that we are trying to highlight that we have a number of decisions but some of those decisions are actually the accountability of the Treasury or the Australian Competition and Consumer Commission (ACCC), presumably with our input and collaboration as this has been a feature of the regime all the way through, but they are not for the DSB or the Chair to determine. It was noted that they are decisions that need to be made and then the DSB can work within the constraints.

The Chair noted that the discussion of gateways in the paper is not an attempt to reopen the data access model that has been promulgated by the ACCC but was an indication that the impact of these decisions will have on standards development. For instance, the number and complexity of API standards to be developed will be different in a scenario where a retailer can be accessed exclusively via the gateway or optional via a direct connection. It was also noted that the use of an exclusive gateway could introduce additional types of standards to allow for the gateway to obtain data from retailers that is not currently held.  In addition, while it was understood that a clear decision has been made regarding the use of a gateway to access authenticated data the gateway model for obtaining product reference data is not yet confirmed.

The DSB noted for the question on, “If a public gateway is adopted, will it be optional for retailers to use it?”, which is in the “Foundational Decisions” section (page 6) of the Framework paper. It was noted that this refers to the second choice for product reference data - will a gateway be designated and will it be used? - as distinct to the gateway decision for sharing authenticated data. It was noted that the use of a gateway for product reference data is a less firm choice at the moment than the use of AEMO for the authenticated gateway. If the tariff information and the product reference data information is also to be designated through a gateway, is that an optional gateway or a single gateway? It was noted that that is why that question has been put in there but we need firm decisions.

The Chair noted that if Committee Members have any additional foundational questions that would be relevant, we would be happy to add them to the Framework document.

One member asked how do we envisage these foundation questions being resolved, as some of the questions look like they may need to be resolved by the ACCC or Treasury. It was noted that one of reasons we are using the gateway model is because AEMO has a process to define those standards.

The DSB noted that the questions in the “Foundational Policy” category are not being driven by the DSB, they need to be driven by either the Designation Instrument or the Rules.

The ACCC noted that in regards to the questions in the “technical in nature” category, they are working through some of these things and propose to publish a document that they will call the Rules Framework which is a similar process to that adopted in the banking sector. It was noted that the ACCC needs to see a draft Designation Instrument before it can consult on the Rules Framework.

The Chair noted that the ACCC’s publication of the Rules Framework informs the standards development process. It was noted that the provision of the Rules Framework was a major step forward in the banking context.

Treasury noted that in terms of what the data sets are, and of who they are going to designate to provide that data, they are looking to provide more certainty early. It was noted that they are still considering their decision on data sets, data holders and gateways and they are looking to get an “in principle decision” from the Government so we can get indicators as a tentative position with enough certainty to kick on and start in February. It was noted that the experience from open banking was that once you get data payloads for the standards, many issues come up. It was noted that there were some problems with accessing some of that data in the banking sector, and there may be similar issues getting the energy FinTechs more engaged than maybe at the higher-level consultation level.

Treasury noted that the goal is to get an “in principle decision” and they are open to the fact that as we work through the detail there will be a little bit of change and then they will produce the draft Designation Instrument next year, with the goal to have this consulted on in May and prior to 30 June 2020.

Treasury noted that in relation to the NMI standing, the distributed energy resources register and metering data, they are thinking about AEMO being the data holder. It was noted that in terms of generic product reference, they are thinking about specifying the Australian Energy Regulator and Victorian Energy Compare as data holders, who retailers are already lodging their generic tariff data with. In respect of retailers, they are thinking of designating them as data holders for consumer and billing data. It was noted that any product reference data that is tailored for the individual is the sort of information which isn’t provided to the Australian Energy Regulator (AER) or the DSB. Retailers would also therefore be designated as data holders for this data.

Treasury explained that they are considering designating retailers as the holders of billing data, which is information on payment refunds, invoices raised and information relating to discounts and concessions. It was noted that in the consultations, billing data was the most contentious and there was some push back. While it was noted that there would be a burden on the retailers to extract billing data out of systems and feed ultimately through the AEMO gateway, billing data was important to support the basic use case of product comparison. For this use case, you need to be able to compare the plans on offer with the one that a consumer is actually on. For this, you need either the actual amounts billed to the consumer under their current plan or access to the details of the actual plan the person is on (including any personal tailoring to the individual consumer).

The Chair noted that it sounds like the day one scenario will be price comparison only, and therefore the use case might be constraining. Treasury noted that that was not the case and what they expect is that we will want to be able to do a whole range of uses that we can and can’t contemplate at this stage. They are not selecting the data sets only for the main base use cases, but that said what they are making sure is that what is selected is adequate for those base use cases. It was noted that we want to make sure it works for high quality price comparison switching and that it supports decisions about investment in generation and storage by the consumer. Treasury confirmed that they have taken cross-sectoral use cases into account.

Treasury noted that a number of submissions to their CDR Energy datasets consultation paper, which they will publish in due course, raised a whole range of interesting ideas with cross sectoral use which they have taken into account in determining what will be included.

One member noted that the timing of what is required and what can be delivered needs to be aligned as well, as there is enormous regulatory change underway in the energy sector. It was noted that we need to be realistic in terms of what can be done.

The Chair noted that the implementation date will be an issue that Treasury will consult on with the ACCC.

Treasury noted that in regards to the timing of when we launch, the questions of who is designated and what data sets are included are relevant. It was noted that for example, we may assume that we will be commencing at a point where AEMO will be holding more comprehensive metering data sets for example. They are not thinking of designating in a way that has some sort of transition – e.g. requiring participants to build for access prior to introduction of 5-minute reporting and then adjust their builds afterwards. It was noted that they will be looking realistically at what the timeframes are so some of these reforms will be bedded down in place before we actually launch.

One member noted that from an industry perspective, we will have an enormous amount of regulatory change in regards to settlements, whether with AEMO or for other players in the industry, and we would like clarity around implementation and timeframes.

The Chair noted that this will not be a consideration for the DSB but we will certainly be aware of it. It was noted that getting started from the data up, in terms of the standards, helps to set not only the Rules Framework and therefore the Rules, but also brings the complexity of the standards to the foreground. The Chair assured the committee that once the timing is confirmed it will be tighter than anyone will like.

One member noted that AEMO will have the data for metering the moment global settlement starts which is February 2022. It was suggested this almost guarantees the earliest implementation date is now February 2022 and if we can do all our work by next year, industry has time to implement.

It was noted that the details of the timing of implementation not being settled now should not prevent us starting work on the data standards.

The Chair noted that we are not doing consultation on the timetable and “go live”. It was noted that what you need to do is get your organisation to respond on what you need by when and what is possible. The earlier we can get that into the standards in the context of what is likely to be designated the sooner this will bring the issues to the forefront.

The DSB noted that to deliver and give certainty earlier, the experience in the banking sector is the more people engage and provide early feedback the better.

One member noted that they see nothing in the Framework document that calls for a feedback loop from the outcome of the banking phase. The Chair noted that it is not there, partly because there are a lot of the same people involved and past work is consistently being built on. It was noted that our standards are regulated, legislated and we are committed to implement them. It was noted that there is no feedback loop for the implementors on this, and this seems to be an omission and it would be useful so we can feed it back into our process.

The Chair noted that it would be useful to include feedback from the implementors and that we will work out how to do this.

The DSB noted that we are kicking off CX research in January as we have lots of directions that we are looking to explore. It was noted that we have questions about identifiers for authentication and other questions around consent more broadly which are beyond our scope but are useful to consider. It was noted that we are open and welcome everyone to contribute. It was noted that we will publish things on the CDS website including artefacts for feedback.

One member noted that they will send DSB an email on a piece of research that covers off a literature review about how consumers make energy decisions that will be a useful data before they start the CX research.

ACCC Update

Bruce Cooper from the ACCC provided an update on the Rules and the register as follows:

ACCC noted that the Rules Framework document and the timing thereof is dependent upon the Designation Instrument. It was noted that until there is more clarity no further update can be provided.

Treasury Update

Daniel McAuliffe from Treasury provided an update as follows:

It was noted that Treasury has been talking to the State Energy Ombudsmen in regards to the CDR dispute resolution scheme. It was noted that at the moment, they are looking at piggybacking off the existing Ombudsman scheme which retailers are already members of. It was noted that they are working through this with the Ombudsmen but at some point, they will come out with another public consultation regarding the proposed approach.

One member noted that they will obviously need some changes to their scheme as only the retailers can be members of the scheme. Treasury noted that they have been speaking to the Ombudsmen schemes on who can access and the operation of the schemes. They noted that some schemes can be changed administratively to apply to CDR but some will need to get their legislation changed to broaden their scope. It was noted that there is therefore a bit of lead time and they will need to make a decision early next year.

One member noted that this goes into their funding models which is a substantial piece of work in terms of set up.

One member noted that in terms of the Ombudsman schemes and jurisdiction differences, every state has a different scheme. It was noted that calling out the difference across the jurisdictions would be useful. It was noted that the CDR is a Commonwealth wide regime which is however proposing to use different state-based schemes for EDR.

Treasury noted that while EDR schemes will all be resolving dispute on a common set of rules, there is the issue that the processes adopted to do so might be very different in different states. It was noted that they are talking to the Ombudsman to have a common set of procedures and information sheets that they share with each other and improve the experience.

The Chair noted that if a Fintech accesses data in a cross-sector way, what dispute resolution do they use, is it the Australian Financial Complaints Authority (AFCA) or is it dictated by the sort of data? Treasury noted that this is a complex issue that they are working this through with the Ombudsmen.

Meeting Schedule

The Chair advised that the next meeting will be held on Wednesday 12 February 2020 from 10 am to 12pm at Data61’s office in Sydney.

Other Business

There was no other business raised.

Closing and Next Steps

The Chair thanked the Committee Members and Observers for attending the meeting.

Meeting closed at 11:40