Minutes - 11 Sep 2019

Data Standards Advisory Committee, Meeting Minutes

Date: Wednesday 11 September 2019
Location: Westpac Banking Corporation, Level 12, 150 Collins Street, Melbourne
Time: 14:00 to 16:00
Meeting: Committee Meeting No: 14

Download meeting minutes (PDF 221KB)

 

Attendees

 

Chair Introduction

Mark Staples passed on apologies from the Chair for late arrival due to his delayed flight. Prior to the Chair’s arrival, at the request of the Chair and on his behalf, Mark Staples opened the meeting. The Chair had suggested a revised order of the meeting prior to his arrival.

Mark Staples thanked all committee members and observers for attending the meeting. Lauren Solomon (CPRC), Stuart Stoyan (MoneyPlace) & Andy White (Aust Payments) were apologies for this meeting.

Minutes

Minutes

Mark Staples thanked the Committee Members for their comments and feedback on the Minutes from the 14 August 2019 Advisory Committee Meeting.

One member noted in reference to the Chair’s introduction in the papers the outstanding issue of consent for multiple services. It was noted that the API Lead would speak to this later in the meeting.

The Minutes were taken as read and formally accepted.

Action Items

It was noted that the Action Items were either completed or would be covered off in discussion during this meeting or future meetings.

One member noted that in regard to the Action Item for Committee Members to provide ping data to the Chair, that because of cloud services and VPNs, the origin of pings was uncertain. Many Australian providers have cloud services hosted elsewhere, and pings will come from there. It was noted that the Chair was interested in this data mostly as an indicative sign.

Treasury Update

Daniel McAuliffe from Treasury provided an update on the Consumer Data Right Legislation as follows:

It was noted that since the last meeting Andrew Stevens was officially appointed as the Chair of the Data Standards Body (DSB) and likewise, Data61 was officially appointed as the DSB. It was noted that up to that point it has been an informal arrangement but now they hold those legal positions. It was noted that the Designation Instrument for the banking sector has also been executed and registered and this was signed on the 6^th September 2019. It was noted that the Consumer Data Right has been officially turned on for open banking.

It was noted that in terms of the Privacy Impact Assessment (PIA), there was a small delay in the independent review, to incorporate the latest version of the rules. The consultancy firm that is doing the PIA is Maddox Lawyers, and their analysis is expected to be public within the next week or so. After consulting on that analysis, the goal is to issue the final PIA in mid to late October 2019.

It was noted that for the public awareness campaign, it is progressing internally. Treasury is engaging consultants to develop the messaging and to design the advertising campaign. Treasury may reach out to the big 4 banks and FinTechs who are well progressed for February 2020, for their views about delivery and content for this campaign. It was noted that ACCC will talk about education.

It was noted that on the commitment that was undertaken by the Government to make amendments for deletion rights, that bill is scheduled to be introduced into parliament in the next week or following week. The bill may be introduced and passed in the sittings, and the amendments may come through by October 2019 or November 2019. It was noted that Treasury’s reading is that the ACCC rules might not change in substance, but that deletion rights currently present in the rules might just be amended to be based on the new provisions.

In was noted that in regard to Energy, the Government has released the Treasury consultation paper on data sets for the energy sector in parallel to the ACCC releasing their energy data sharing model paper. It was noted that the data set consultation paper seeks feedback on high-level questions about data sets and participants, and that consultation closes on the 26 September 2019. It was noted that there will be a subsequent consultation process on the actual Designation Instrument for Energy which will be more detailed. It was noted that the data sets for Energy will be simpler than for the Banking sector.

One member asked regarding deletion rights, whether significant changes were expected in the rules. ACCC indicated that they are not contemplating any rules changes on deletion as a consequence of the proposed legislative amendment.

Technical Working Group Update

A summary of progress since the last committee meeting on the Working Groups was provided in the Committee Papers and was taken as read.

One member noted that apart from the OpenID Foundation email, they have received inbound contact from Financial Data and Technology Association (FDATA) and a few others who are interested in the variance between other standards and the CDR data standards. It was noted that this interest was in learning, and further conversations are needed.

One member noted that they previously requested that in the Product Reference Data (PRD) standards, that there could be more flexibility to show fees that were tiered. The member was concerned that following the data standards might create possible breaches of regulations for information disclosure about financial products. It was noted that an example of this is where a fee is a either a percentage or amount, whichever is greater or the less depending on the particular product, and the way the standards is set does not allow them to show that and they are therefore not fully describing that product. It was noted that they would like an optional way for them to flexibly show that. It was noted that there was a proposal on GitHub outlining the request but that there has been no movement on this since raising this concern.

Treasury noted that there has been some other feedback on the PRD standards on things like frequent flyer points and free form data. Treasury asked about the timeframe for a second version of PRD standards.

The API Lead noted that the DSB is versioning the whole collection of the standards and is working to release a major version of the standards for the ACCC lockdown rules. It was noted that the focus has not been on making major changes to PRD. It was noted that there is a lot of optionality in PRD and DSB had been discussing whether to lock that down to have easier interpretation across different product types and providers. It was noted that the proposal for PRD is planned for consideration in the maintenance process, after the end of the month, following the major data standards release responding to the rules, registry design choices, and some other issues on GitHub. It was noted that this maintenance phase will be a trial process, but urgent changes can be made outside that cadence. It was noted that to support changes to PRD in production, the standards are moving to end point versions and approaches for that are being developed.

The Chair noted that there would likely be a valid explanation for ASIC if they are complying with the data standards. It was noted that PRD is only one disclosure of terms that relate to that product and there are other disclosures that could be referenced. It was noted that a further discussion will be held out of session to understand the importance of this PRD issue.

ACTION: The API Lead to hold further discussions out of session on PRD for tiered fees.

One member asked about the timing of the resolution of concurrent consents. The API Lead noted that the issue relates to the rules. It was noted that the DSB is working on a proposal but needs to coordinate with the ACCC rules team and potentially Treasury prior to going public. It was noted that the DSB hopes to include a resolution for the end of month standards release.

One member stated that they are extraordinarily appreciative that feedback was heard and considered to adjust the ACCC registry from static to dynamic. The member noted that consent APIs work better with a dynamic registry, and that this might be a reason to consider that in the data standards. The API Lead noted that for dynamic registration, specific drivers for consent APIs have not yet been raised, but if teams could provide specific feedback that would be helpful.

It was noted that the thinking about fine-grained consent being informed by additional CX testing, and that better understanding the customer needs will help to solve appropriately and correctly. One member asked if there is a timeframe for this CX research in relation to fine-grained consent that might drive design choices around the consent API. It was noted that this is currently planned to be conducted in the December 2019 to January 2020 timeframe, that the CX team is currently sketching out scenarios for fine grained control. It was noted that this is more complicated than simply fine-grained control in the consent flow, because it also impacts re-authorisation, management and revocation. It was noted that a workshop is planned but not yet scheduled on fine grained control for input to provide a base to work from.

One member noted that CX guidelines say that consumer management dashboards should be in a consistent location and asked where dashboards might live for a data holder and a data recipient so that it is in a consistent location in the menu. It was noted that the CX guidelines aim not to be too prescriptive on this. It was noted that for dashboards and withdrawal of consent, the UX team will provide examples on how to put the rules into effect so people can align to them but allow people to structure interfaces to best suit their purposes.

It was noted that the July 2019 draft contained general guidance and design patterns for consent flow, to help implementors avoid designs that might cause problems with later introduction of fine-grained consent.  It was noted that these patterns concerned staged consent that is part of the consent flow. It was noted that another school of thought is that consent should be a resource, shareable, potentially mutable, and so be delivered from a resource server not an authorisation server. It was noted that this is still an open question.

ACCC Update

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

It was noted that the Rules were published on 31 August 2019 and the next step is to send to the Treasurer for his approval for ACCC to formally make the CDR Rules. It was noted that ACCC will make only minor tidy-up amendments to the August version and envisage sending to the Treasurer by the end of September or early October.

It was noted that there are several changes to be aware of from the exposure Draft Rules. It was noted that a finding of the CX research was that separating consent for use and collection was not meaningful to consumers. As a result, the rules provide for a single consent to collect and use. It was noted that withdrawal of consent or authorisation will withdraw consent to both collect and use. Another change was the removal of the concept of the CDR contract. This was in response to feedback on the exposure draft. The rules have been updated to ensure an appropriate level of transparency for consumers about the consequences of revoking consent and there is increased reliance on common law in relation to ensuring that consumers are able to withdraw their consent without any detriment.

It was noted that rules for joint accounts are pretty much unchanged. It was noted that for joint accounts, data holders will be required to provide a joint account management service to enable consumers to set preferences in relation to CDR data sharing at the account level. This service must be ready for use by 1 July 2020. It was noted that for the first version of the rules, multiple party authorisation is an optional implementation for data holders. It was noted that data holders are expected to work towards the implementation of multi-party authorisation as this will become a requirement in the future.

It was also noted that consumers will be able to elect to have their redundant data deleted. They will be able to make this election at any time, and they will be prompted to make this election during the initial consent process.

One member asked whether the word “redundant” has any significance in that statement.  It was noted that “redundant data”, as set out in the rules, is data where the need to use that data has expired, depending upon the basis of the consent and other legal obligations. For example, if the purpose of the consent is to provide credit and other laws require that data be held for a particular time to satisfy broader obligations, that data won’t be redundant while those legal obligations remain.

It was noted that the ACCC have called for Expressions of Interest (EOI) for entities who want to apply for accreditation as Data Recipients and commit to assisting with testing with the big 4 banks in the lead up to February 2020. It was noted that as at cob Friday 6 Sep 2019 the ACCC had received 40 EOI’s and hopes to inform the successful participants by 20th September 2019. It was noted that the ACCC is on track to open the Accreditation Platform in October 2019 for applications for Data Recipients who want to be accredited but aren’t in the first tranche.

One member asked whether ACCC could give a sense of the type of the 40 companies that have applied. ACCC noted that some are Australian, some are international; some are ADIs some are not; some are aggregators some are not; some are big, and some are small.  There is a wide cross-section. One member asked when we will know who they are and when can we connect with them. ACCC noted that their aim is to announce around 20 September 2019.

It was noted that ACCC is continuing to draft guidance in relation to the requirements for insurance and information security and that this has been put to the ACCC CDR Committee for approval. One member noted that they have received a price on insurance as a Data Recipient for $12,500 for $5M cover. It was noted that there is insurance cover out there, but it is important to create a market to ensure that there is not a barrier to adoption. Another member noted that they received a similar quote for insurance. ACCC asked whether this would be a barrier to entry or is it a reasonable cost? One member noted that they would need to weigh up how many records they would consume and the likelihood of a breach. Another member noted that they do not think it will stop any activity but briefing the insurers would be useful.

It was noted that in regards to testing, the final version of the Assurance Strategy, covering assurance and testing of the end-to-end ecosystem in advance of launch, was published on 29th August 2019. It was noted that ACCC have commenced alignment sessions with the big 4 banks, including sessions to assist in ensuring a common view of what is covered in the scope for February 2020 and the timing for different phases of testing. It was noted that ACCC have also had ongoing collaboration with the ABA on this. It was noted that through Ernst Young (EY), the ACCC is continuing to develop detailed test plans and test scenarios in order to begin testing in October 2019.

One member noted that they need more visibility on a weekly basis of what is being tested and the progress on the testing.  ACCC agreed and noted that as we move towards February 2020, they are looking to set up something like an Implementation Advisory Committee which could meet fortnightly. It was noted that this would be at a higher level than some of the working meetings that are currently under way. The intention is that it would include the ACCC, the big 4 banks, probably ABA, and with observers from OAIC, DSB and Treasury. It was noted that ACCC would continue to have regular one on one meeting with data holders. It was noted that ACCC are conscious that there needs to be a way to bring in the data recipients without making the group too unwieldly. It was noted that if there were between 5 and 10 data recipients it would create a big meeting. No decision could be made until the identity of the initial data recipients is known.

In response to a member expressing the concern that this could be just another meeting, the Chair asked the member whether they were saying that the Implementation Advisory Committee is redundant? The member noted that they think that we are starting to have too many meetings. The Chair asked did we need it on top of more frequent testing meetings. It was noted that there is a need for a higher-level meeting to identify road blocks and how to overcome them. ACCC noted that the ABA suggested this type of forum and that it is something that ACCC has been contemplating for some time.

The Chair asked committee members for their feedback on the suggested meetings going forward, and the views from the big 4 banks and fintech’s on what would be helpful as we go through the testing phase so ACCC can input into the process.

One member asked out of the 40 EOI ACCC has received, how many were they considering accepting. ACCC stated that they are thinking to start with 8 or so, so that they can test in pairs.

One member noted that it feels like it should be one meeting but would also like a bi-weekly escalation capability meeting as a standing order agenda. It was also noted that they are very concerned about joint accounts and closed accounts and the amount of design work that needs to happen for the July 2020 timeframe.

It was noted that as part of testing, both the data holder and data recipient should designate a technical contact that can talk to each other.

ACCC noted that there is going to be a defect management tool which will give daily visibility to testing outcomes and an intention to continue weekly technical testing meetings. The ACCC is looking at a different escalation forum to consider blocks in the testing and also to consider “go”, “no-go” decisions and some of the design issues for Phase 2 and Phase 3. One member encouraged ACCC to ask that attendees have designated authority at the bi–weekly meeting so we don’t create an additional forum.

The Chair noted that with the testing and design work for July 2020, the work load will be high, and that we want to be sparing with meetings and to make them very targeted and short. The Chair asked ACCC to consider the meetings and timing.

One member noted a comparison to the New Payments Platform (NPP). It was noted that the NPP had 6 months to develop their testing and 4 months to test, and that there have already been 2 breaches. It was noted that CDR would end up with 5 to 8 weeks of testing before go-live, given the December 2019 freeze, if testing starts at the end of November 2019. It was noted that prioritising what we are testing is important, that security testing is nonnegotiable, and that what is being delivered is defined.

One member noted that the switch from a cloud hosted conformance suite to a downloaded suite will add 2 weeks of work which has not be built into the schedule. The member noted that they appreciate that there was a considered decision for that change, but that it impacts an already very compressed timeframe. It was noted these implications should be considered for subsequent changes. ACCC noted that the cloud hosted conformance suite was preferable but not possible in the time frame. It was noted there will be a move to a more automated conformance suite but not for February 2020. ACCC understands that this has an impact and notes that the detailed test plan will prioritise different elements of the testing. It was noted that the detailed test plan is on the way and that this should answer many of these questions.

One member noted that they don’t know whether we are going to meet the testing calendar. It was noted that it is possible that either 1 February 2020 will get deferred from a testing stand point or some other compromise may be required to go live for 1 February 2020. It was noted that the compromise should not compromise safety. The Chair noted that we had this conversation at the last meeting about exit criteria.

One member wanted to see the detailed test plan team at the Advisory Committee meetings. ACCC noted the need to consider whether this meeting is the forum for that.

One member requested an indication of when the conformance suite will be available as the tier 2 banks are making technology decisions for July 2020 now and are asking technology providers if they are compliant. It was noted that there is currently no way of testing compliance. The ACCC noted that procurement of a conformance suite is not a short-term thing and will not be concluded within 2 or 3 months. One member asked whether ACCC or Data61 had considered forking the UK conformance suite. ACCC confirmed that this had been considered, but this would have required 2 months’ work and would not be a permanent solution for CDR so could not be justified as a procurement exercise.

One member asked about testing and the principles for the “go” and “no go” decision. It was noted that ACCC is looking to provide that within the next month.

One member asked whether in the testing regime they and other test participants could be given permission for their teams to “red hack” the system to do penetration testing on the whole system not just their own system. It was acknowledged that ACCC had previously committed to conducting penetration testing on the registry and penetration testing of the ecosystem. ACCC noted the request and took it on notice.

ACCC noted that they have decided to move to a dynamic register. The ACCC thanked all those who participated in GitHub discussions and the recent workshop. One member thanked ACCC for taking on board this feedback. ACCC noted that consultation demonstrated that although the change would lead to a slightly longer initial build for data recipients, the trade-off for reduced ongoing maintenance would outweigh the initial additional cost. The ACCC also took into account the data holders’ arguments about reduced complexity and cost in build and maintenance. It was also noted that a dynamic register is consistent with UK Open Banking and with directions in New Zealand and Mexico. ACCC thanked everyone for their comments and input.

The API Lead noted that after discussions with the ACCC, the changes to the data standards required by moving to a dynamic register appear to be minimal. There will be some flow impacts, but changes to the standards are expected by the end of the month.

ACCC noted that one impact is two additional weeks for their build, so instead of having the register ready in the middle of September 2019 it is more likely October 2019.

ACCC noted that intermediaries are not in the current rules and are unlikely to be in place by February 2020. It was acknowledged how important intermediaries will be for the ecosystem and ACCC are working on a path for them. It was noted that some entities will have both a direct consumer relationship and be an intermediary and may have expressed an interest to be an initial data recipient, and ACCC is working through that issue.

One member asked ACCC when there might be an announcement on intermediaries. ACCC noted that it would aim to make a statement in early to mid-October 2019.

The Chair noted that he has been contacted by two overseas intermediary organisations who he thinks are trying to find out where intermediaries are provided for in the rules. It was noted that there is a fairly high level of interest from intermediaries and potential intermediaries because of the role intermediaries have played in the UK.

Operating Model Update

An update on the Operating Model was provided in the Committee Papers and was taken as read.

A further update was provided in two parts. First the API Lead discussed the trial for maintenance for the standards planned after the next version of the standards, and then the Head of Technical Delivery covered the broader operating model.

One member asked if the presentation could be shared with the committee. It was agreed to.

ACTION: To provide the Operation Model presentation to the committee and observers.

The API Lead noted that the process to date has been effective, but we now need to move to a maintenance mode as we get implementation feedback and use of the standards. A noting paper on this was raised in March / April 2019 and there has been a dialogue about it. It was noted that there has been general support, and that some tweaks and recommendations have been incorporated as much as possible.

One member noted that some specific recommendations were made on improvement of transparency with decision making and priority setting. The API Lead noted that prioritisations are set as articulated in the noting paper, whereby the community contributes their priorities, the Chair sets the priorities for the team, and any issues are escalated to the Chair. The member noted that the feedback was that they want more say in prioritisation which is the intent of community consultation, and that there be a product owner.  The API Lead noted that the obligation for standard setting is with the Chair.

The API Lead noted that the trial will commence in the 1^st week of October 2019 and will be limited in scope to the maintenance of the API Standards and Information Security profile, and not CX. It was noted that the trial will be undertaken on GitHub to leverage the existing community and that there will be two modes of operation. It was noted that the maintenance trial will look at smaller issues, and that larger issues will still go through the consultative decision proposal approach. It was noted for the Energy sector, the DSB will use decision proposals for the Energy standards.

One member asked what the division is between large and small issues. The API Lead noted that understanding this was part of the trial. It was also noted that sometimes things start out as a standards issues but may later be revealed to be policy or rules questions. It is noted that the intent is to start issues in the maintenance process, and then if and as appropriate to close and raise them as a decision proposal or to raise them for the ACCC.

The Chair asked what the raising process is and who can raise issues. The API Lead noted that all community members are free to raise issues in GitHub. It was noted that this is what GitHub is designed for.  It was noted that this has been trialled in the Infosec and engineering stream.

The Chair asked whether using GitHub will cause any issues for the 4 big banks because of their social media policies. One member noted that potentially it could be an issue, but their teams had received permission to use GitHub. It was noted that one fall back is to send responses via the ABA which is cumbersome. The Chair noted that we need to check that the GitHub input of issues will not raise undue friction.

ACTION: The API Lead to check that the GitHub input point will not cause undue friction.

The API Lead noted that anyone involved within the community can participate, whether via an anonymous account, or an account belonging to a bank or a known vendor; it is the content of the issue that is important not the person raising it. One member noted that they support broader engagement in the community and that the wider it goes, the easier it is to raise issues there and provide more thoughtful input. Concerns were noted about noise and scope creep. It was noted that in these situations it is easy for all voices to feel they are equally weighted, but there are many individuals and then the big 4 banks.

The API Lead noted that feedback on the operating model included that we should do an agile cadence of 2 weeks. It was noted that changes to the standards have an implication for investment and change. It was noted that there may ultimately be hundreds of recipients and changes to the standards will require them to implement changes as we will not keep every version of every API, we will obsolete some versions over time. It was noted that the current planned cadence is 6 changes a year for that reason. It was noted that this is not the cadence or operating model for February 2020. It was noted that the trial cadence is to inform maintenance over the longer term.

One member asked whether there will be a long-term support level? The API Lead noted that a good example to consider is PRD. If proposed changes to PRD would break production systems, this would be version 2 of those end points. This is part of the versioning strategy which has been public for a while, and the rules accommodate this. For changes, there will be consultation on a). when that change becomes binding, and b): when we obsolete an old version. It was noted that part of the decision on a new version of an end point will be when everyone must have it in production and when the old version be turned off for data recipients and data holders. One member recommended that except for security, that should be the approach.

It was noted that part of this trial is to start listing the issues and that we can learn from existing models out there. It was noted that for version changes, we want to grow into them, not impose them and to learn what the right cadence is. It was noted that according to the legislation and rules, the decision rights on when it will become binding sits with the Chair.

One member noted that they get their funding a year in advance to make changes, unless there is a security breach, and so they would need to have a 12-month period to address all the changes that are needed with the required amount of funding to make those changes. The Chair asked if members could put all those suggestions in GitHub as to what kind of visibility they want. It was noted that at the moment, the phasing timetable from the ACCC gives some guidance on that with the known changes.

It was noted that all the decisions will go to the Chair, and the intention is that proposed changes are bundled into a single decision proposal and that the advisory committee can comment and then the Chair makes the final decision. It was noted that the standards repository continues to be an audit trial.

It was noted that if there is a security change, we will not wait 8 weeks. It was noted that if there is something that is affecting everybody then we will make that change and note that this will also apply to things potentially coming out of the testing regime over the next three months.

It was noted that we also intend to do a retrospective later by holding a workshop to find out what worked and what didn’t. The Chair has asked the API Lead to provide a summary update on what we have already found out in the trial at the next committee meeting.

ACTION: API Lead to provide a summary of the trial to date at the next committee meeting.

The Head of Technical Delivery noted that the DSB has been socialising ideas about a wider cross-agency, cross-sector Operating Model and noted this is provided as a Strawman, with the aim of stimulating wider discussion about what the CDR eco-system will need in the longer term. The Chair noted that the strategic issues are likely to come from the multiple sectors’ applications and interoperability and that potentially the multi sector drivers that drives the strategic change.

It was noted that the activity in GitHub has been confined to standards and engineering, with CX and other agencies in other places. It was noted that issues that are raised may potentially permeate and perhaps escalate beyond standards, to the rules etc. It was noted that responsibility is not with the DSB alone.

It was noted that some of the questions are in regard to principles, on scaling, simplicity, and consistency across sectors. It was noted that the communities and stakeholders involved can be vastly different. One member noted that a missing principle was security.

One member noted that before we define principles, we need to think about the philosophy. The Chair stated that we will need to get together with the ACCC and Treasury to discuss these questions at a philosophical level before we can finalise the principles.

ACTION: Chair to meet with the ACCC and Treasury to discuss the cross-sector questions on a philosophical level.

One member noted that the principles you need to refer to go back to the Productivity Commission. The Chair noted that this needs to go back to the level above legislation, to the design concept of the entire regime. It was noted that from the interactions on the access models there are different interpretations of what cross-sector means for the CDR.

It was noted, is there is a logical grouping of the data standards and that banking has different standards to energy, and is there a need to take out common elements? It was noted from a management level, we have choices.

It was noted that as CDR spreads across sectors, decision making in one sector might impact others. It was noted that this was less likely for sector-specific data payloads, but maybe for security.

The Chair asked about the process for resolving this. It was noted that a change management system that could address this could be active on GitHub.  It was noted that everyone will be impacted when there are changes to artefacts related to legislation, rules, standards, engineering, CX, implementations in the regime like the register, and implementations that everyone is building to the API standards. It was noted that there are also some internal artefacts influenced by changes. It was noted that we need to have a system, managing the different stakeholders sets and expertise.

It was noted that the processes should adjust in formality based on the significance of the change and or the state or critically of the component. It was noted that each component should be managed by a Configuration Control Board (CCB) comprising of representatives with a domain and experts such as the Design Authority. It was noted that related CCBs will need to escalate change impacts that go beyond individual components and potentially impact eco-system operations. It was noted that the approved changes would be passed to the specialists in the Artefact Teams for implementation.

The Chair noted that in the rules, they say that in banking that a consumer and the relevant data is an open account held by a consumer, which the consumer accesses digitally. It was noted that if the same rule is applied in energy, that will mean 80% of the energy customers will not be accessing CDR via this regime as they don’t access their data digitally. The Chair noted back to the philosophy point, what is the philosophy of the CDR? The Chair noted again that he needs to meet with ACCC and Treasury to help to decide those things from the data that we have already gathered.

One member noted that they spent the last two years testing data access. It was noted that with other sectors rolling over a ten-year period, this might change the decision and discussion about the critical elements that need to be nonnegotiable shared across the entire regime vs things that are sector-specific. It was noted that in the banking sector, no single group could easily dictate changes on some of the items that they have worked through in detail.

One member noted that there will be some things that can be shared like identity.

The Chair noted that we need some philosophical consideration before we get into the operating model.

One member noted that it is a whole of economy orchestration kind of thinking. It was noted that an operating model for an economy needs to be federated and orchestrated and needs more thinking.

The Chair noted he would like ACCC’s input on this (out of session) to get this right and achieve the potential of the regime.

Other Business

The Chair noted in regards to the energy sector, there is increasing interest in the CDR from stakeholders, some of which is positive and genuine and forward looking. It was noted that we are preparing to release, as we did for this Banking, an Expression of Interest (EOI) on an Advisory Committee for Energy.

It was noted that after Warren Brady’s departure, Mark Staples will be directing the activity for the time being. It was noted that we are in the process of developing a role description for the Director Position at Data61 and DSB and look to you to help with identifying suitable candidates for the role.

The Chair thanked Jamie Twiss from Westpac Banking Corporate (WBC) for hosting the September Advisory Committee Meeting.

Meeting Schedule

The Chair advised that the next meeting will be held on Wednesday 9 October 2019 from 2pm to 4pm at the Data61’s offices in Eveleigh.

Closing and Next Steps

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

Meeting closed at 16:03