Non-Functional Requirements Consultative Group meeting minutes – 22 February 2024

Overview of the Purpose

James Bligh from the DSB opened the meeting and noted the NFR Consultative Group has been established to provide advice to the Chair on the development of the standards.  This is the first advisory group, apart from the Data Standards Advisory Committee (DSAC) that has been set up under the legislation that establishes the Consumer Dat Right (CDR). 

The DSB noted that this Group has been set up on a trial basis and the DSB will act as Chair and Secretary for the meetings.  Meetings will be held once a month for approx. two hours for a period of 6 months with the intention that the current participants will act as the inaugural committee.  After the initial period, the DSB will report back to DSAC, and a determination will be made on future steps for this Group. 

The DSB noted the Chair of the Data Standards has provided guidance that membership is in a personal capacity and delegation to others in your organisation is not desirable. 

The DSB noted that minutes will be taken for each meeting but will not contain attribution to individuals.  The minutes will also be tabled with the DSAC.

Membership & Introductions

The DSB invited the participants to introduce themselves to the group.  Introductions were made by all attendees. 

One member noted that whilst there is representation by the big fours in this group, there was no representatives from smaller data holders.  Should they be included? 

The DSB noted the goal was to get representatives that represent the bulk of the usage in the ecosystem and whilst the smaller data holders are important participants and stakeholders, they don’t generate much traffic.  Membership is limited and biased towards people that are doing significant volume.

The DSB noted this is an advisory group, and we will not be making any decisions.  Any decisions to be made on changes to NFRs or standards will be developed into a Decision Proposal for comment and feedback by stakeholders. 

Logistics

The DSB asked the group for their preferred timing for regular meetings.  It was agreed the meetings would be held monthly on a Wednesday on interleaving weeks to the DSB’s Maintenance Iteration meetings. 

ACTION:  DSB to send out invites for future meetings

One member asked if the DSB could create a collaboration space (e.g., confluence) or just a group email address for members to communicate on topics outside of meetings.

The DSB noted that they will look at some tooling and come back to the group on this.  They noted that it would also be good to have some space where we can share data etc. 

ACTION:  DSB to create a collaboration space for the group

Code of conduct for management of shared data

The DSB noted they have received guidance that establishing a Non-Disclosure Agreement would be inappropriate for this group.  They suggest setting up a voluntary code of conduct that will include requirements for managing confidential performance data provided to the group, which we would make public with a Charter for the Group.  As part of membership, you would need to voluntarily abide by the code of conduct regarding any data shared within the group.

One member noted that as the sole energy data holder in the group, it would be very clear who the data is coming from which comes with some degree of sensitivity. 

The DSB emphasised they are not expecting the data provided to be limited to members of this group and they will be procuring data from all data holders and accredited data recipients (ADRs) who have an interest.

Another member had similar concerns. They are a proponent of making data driven decisions but as the biggest data holder it would be obvious where the data came from, and their organisation may regard that data as commercially sensitive. They suggest a tiered approach for some data sets, where people may feel comfortable sharing with the group but other data sets which are more commercially sensitive could be used to help the DSB or ACCC in their decision-making process.

The DSB agreed that this was a good suggestion.

One member asked if the Get Metric data which was available to ACCC could be used as well. 

The DSB noted they have been liaising with ACCC about accessing this data and a pathway has been established.  They are open to sharing the data with this group.  They could also implement the tiered approach and share insights only to the group to make decisions if required. 

The DSB noted the goal is not to just collect data, and a policy of deleting data once the objective is achieved would perhaps be useful.  It was agreed to include this in the code of conduct with the assumption that the code is an equivalent of the data minimisation principle – i.e., principle that data won’t be shared unless it’s for the purpose of discussing NFRs for the CDR and infrastructure planning etc.  

One member noted they’re gathering the equivalent to Get Metrics from all retailers, and they were looking at stripping out the retailers’ name.  As we will be potentially getting the Get Metrics data from ACCC they see no need to deidentify now.

The DSB noted as a general principle, data will not be attributable to individual participants wherever possible. As a group we don’t need to know the individual data holder.  

The DSB asked the group to let them know of any further inclusions for the Code of Conduct.  They will provide a draft to the group for feedback. 

ACTION:  DSB to draft up a Code of Conduct and circulate to group for feedback

Prioritisation of backlog issues

The DSB noted they would like to work through the first batch of problems for the group to discuss.  One item they would like to table with a high priority is the problem around future planning and forecasting which was one of the outcomes from the NFR workshops held in August and September 2023. 

It was noted it would be extremely valuable for the community to have some sort of future cast of what the load is likely to be in various contexts. For example, the number of consents in banking and energy or the number of API calls etc. 

One member noted they are a data aggregator for open banking data, and they currently serve the vast majority of clients via screen scraping. They are trying to push everyone to move over to open banking however the numbers they are seeing on their platform for CDR like services give them a bit of a headache. 

The member noted they are currently onboarding a partner who has significant volumes, and they plan to reach out to members of the group to discuss this as they get closer to going live.  They don’t have the concern about the multiple accounts, but they are keen to turn on open banking data.

A member noted there are a couple of large players in the market that are still relying on their own data feeds, it will create spikes making the load we currently have look tiny if they make the decision to move over.  They noted that this would affect the loads across the board.

Another member suggested we invite a representative from one of these players to attend an upcoming meeting to provide an overview.  They have a contact whose details they would be happy to share.  It was agreed that this would be a good idea.

ACTION:  DSB to reach out to the Member for contact details and invite representative to a future meeting

The DSB noted that one thing to consider in forecasting in the short term is providing a “what if statement”. For example, “if screen scraping isn’t banned and a big player doesn’t come in estimate the organic growth” and “if a major accounting platform comes in, estimate the likely growth by way of comparison” etc.  We could potentially put some scenario analysis in place rather than just a forecast. This would be beneficial for the policy people at Treasury and the Minister for understanding the implications of some of the choices they’re making. 

One member asked why we’re doing this and why is it so important.  If we have that context, it will lead to how much data we need to solve this. 

The DSB noted, from a forecasting perspective, there are a number of reasons for forecasting:

1. Individual participants can look at the forecast to plan accordingly;
2. The need for long lead times for infrastructure investment planning; and
3. To achieve a certain scenario the current NFRs may be inadequate.

The DSB noted that the treatment to future traffic is not always more kit and with the potential of larger accounting platforms transitioning, we need to start thinking about a batch process being part of the CDR. For example, introducing a batch mode as an alternative data transfer under consent. This could be something we could propose as a decision proposal specifically for certain scenarios in the future.

Members suggested other issues for consideration:

1. The issue around the concept of large-scale multi-site customers (i.e., C&I customers). From a consent perspective, when one customer with accounts that run into the 100s and 1000s and the use case not being considered from start to finish
2. The DSB noted that will unlikely be solved through NFRs but alternate paths like feeding advice into the consent and uplift conversations could resolve that.  There are a number of Maintenance Iteration issues raised on this topic and they need to be summarised for the group to consider.
3. ACTION: DSB to aggregate the Maintenance Iterations issues raised on C&I and summarise for the group’s consideration
4. How do we handle low velocity data sets?  They, at best, change data every night and recently had a particular NMI had 13k hits for data that doesn’t change.
5. Re-examining the current TPS thresholds to ensure they are appropriate; and
6. NFRs for data minimisation principles / ADR and NFRs.
7. The DSB noted when discussing NFR problems, if there were issues that mean we are better off changing the standards, they are open to that.  They would need to raise a Decision Proposal to allow feedback from the wider community.
8. Consumer Support
9. One member noted the issue around the support channels for consumers to get help troubleshooting issues that involve three parties (e.g., consumer, ADR & data holder).  There is no mechanism to currently support that.
10. The DSB noted that this issue might be best raised at DSAC as it doesn’t fit into the scope of this group.  They suggested this be raised by the member at DSAC.

ACTION: DSB to escalate the issue of consumer support channel to DSAC.

11. The concept of peak and off peak

The DSB agreed to go through these items and propose a set to address at the next meeting. 

ACTION: DSB to propose a set of issue to address at the next meeting

Any other Business

No other business was raised.

Closing and Next Steps

The DSB thanked the participants for attending the meeting.