Key issues for feedback

53. The primary function of the draft law is to require designated data to be shared on request of the customer it is about, in standard formats, if the necessary checks and safeguards are met. This enhances the ability for customers to exercise authority and control over their data. It is why this type of legislation has been summarised as a ‘consumer data right’ here and overseas.

54. The draft law includes several safeguards, on which we are seeking feedback.

Consent settings: respecting and protecting customers’ authority over their data

55. Strong consent protections are central to the draft law. They are the key to respecting the authority of all customers – including businesses or other entities – over the data held about them by businesses.

56. The draft law provides that designated customer data can only be shared if that customer has provided consent that is express and informed. It also provides that data holders and receivers must enable consent to easily be withdrawn at any time.

57. Regulations made under the draft law will provide more detail on these safeguards. These will be developed later following further public engagement and consultation.

58. In this document, we are seeking views on the design of the high-level consent safeguards in the draft law itself. We are also seeking feedback on some of the detail that future regulations could contain for requirements about consent, to make sure the two will work well together.

How should ongoing consent be managed?

59. When consent to access data is given, an important element is the length of time for which it lasts. Consent is called an ‘authorisation’ in the draft law, and is addressed in clauses 30 to 35.

60. Customers will be able to specify how long an authorisation is for, when they sign up for a product or service which is enabled by access to their customer data.

61. Managing customer awareness and consent over time is important too. Some customers will be forgetful, or have low motivation to review their settings and check they are still aligned with their needs and interests. The risk in these circumstances is that data continues to be accessible after a customer is no longer interested in or using the product or service they signed up for.

62. The draft law provides that regulations can specify a maximum length of time (after which all consents must expire), or else stay silent on the matter. We are seeking feedback on the best approach to managing ongoing consent, and what safeguards are proportional to risk. We think the key considerations to balance here are ease of use for customers, maximising participation, and implementation cost for businesses.

63. Australia’s CDR has a 12-month expiry period.^[8] This means that even if customer wants to give consent for a period longer than 12 months (for example, ongoing access for a budgeting platform), the customer’s consent must still expire after 12 months.

64. The United Kingdom’s Open Banking system originally had a consent expiry date of 90 days. This created a strong sense of security for customers. However, it also led to a large proportion of customers losing data-enabled services that they still wanted to use, because of fatigue and frustration, or because they didn’t know they had to log back on, or because they forgot. In March 2022, the rules were changed to require only a yes/no confirmation of consent every 90 days.^[9]

65. We note that regulations will also be able to specify events which require authorisation to end. We propose that they should specify that when a customer closes an account with a data holder, or when an accredited requestor’s accreditation is suspended or cancelled, associated consents would end automatically.

Future regulations about obtaining, withdrawing, or modifying of consent

66. The draft law requires that customers must give consent to data exchange – and be able to view and withdraw consent at any time. Regulations will lay out obligations for obtaining express and informed consent, and withdrawing consent. Where practical, regulated entities may also be required to have capability for modifying consent.

67. We are conscious that these safeguards should not create an inconvenient or burdensome customer experience which will discourage customers. This is because the process enabled by the draft law will be safer and more efficient than many alternatives currently in use, so good uptake will be important.

68. Further, we expect that customers may not always be able to interact with a data holding business online, or may prefer to interact in other ways. Therefore, the draft law should account for these needs and preferences.

69. We propose that the following obligations be required of data holders and accredited requestors in regulations:

• All parts of the consent process must be outlined in a clear and accessible way.
• When customers are consenting in the first instance, accredited requestors must inform customers that their consent can be withdrawn at any time and explain how to do so.
• In addition to the methods required by the draft law for the customer to view and end their consent (eg a dashboard) accredited requestors and data holders must also enable customers to withdraw their consent via a simple alternative method of communication (eg by phone or email).
• Ending consent must not be harder than agreeing to consent.
• If a customer wishes to withdraw their consent, the consequences (if any) of doing so must be outlined by the accredited requestor or data holder.
• If an accredited requestor receives a withdrawal of consent, they must notify the data holder (and vice versa). The customer must be notified once their request for withdrawal is actioned.

70. The regulations may also prescribe that certain modifications of consent must be available to customers (eg changing the expiry date of the consent).

71. We consider that this level of prescription in obligations provides clear and sufficient guidance without being overly detailed. This could enable the industry to maintain a degree of flexibility in how they meet the obligations. We also consider these obligations to be interoperable with Australia’s CDR model.^[10]

72. As noted above, the relevant regulations will be developed in due course following further public engagement and consultation. They will also include specific functionality required for common situations. These include joint account holders or secondary users (eg staff acting on behalf of their employer).

Care during exchange: standards

73. Increased flows of data across the economy also increase the risks of breaches of privacy, or of unauthorised releases of commercially sensitive information. The creation of standardised safeguards, processes, and penalties around the electronic exchange of customer data are important to ensure all customers can have confidence in the level of protection provided for their information when it is exchanged.

74. Put simply, standards are a set of requirements for how something should be done. The purpose of standards under the draft law will be to set certain technology requirements and specifications for regulated entities, so that accredited requestors’ computer systems can ‘talk to’ those of data holders securely and effectively.

75. Standards will include technical standards for the interfaces between API’s. These cover security and access controls, the description and format of data fields, and the structure of requests and responses. To ensure accessibility, inclusion, and consistency, it may also be necessary to set standards for the functionality or design of customer consent dashboards, or the structure of a customer’s consent process. The draft law is designed to enable these types of standards too.

76. The standards themselves will be instruments of secondary legislation under the draft law.

How will standards be set?

77. Clauses 87 to 89 of the draft law provide that MBIE’s Chief Executive will set standards. This can be done as part of the designation process of a particular sector.

78. The intention is to build on the industry-led work already underway. For example, in the banking and payments sector, the Payments New Zealand API Centre has been developing technical standards for the exchange of payments and transaction information. These are already being implemented by the sector, at various speeds.

79. The draft law sets out considerations that must be taken into account prior to creating new standards or incorporating existing ones. These include whether the material is consistent with tikanga Māori in relation to data governance, and whether incorporating the material would create unnecessary obstacles to international trade and investment.

80. Further, the draft law requires that prior to making standards, MBIE must consult with the Privacy Commissioner, and people and groups that will be substantially affected by the issue of the proposed standard. This includes iwi, hapū and Māori organisations (see clause 88 of the draft law).

81. The proposed considerations and procedural requirements are based on those which currently apply either to the making of standards under the Standards and Accreditation Act 2015^[11] or under the DISTF Act.^[12] The intention is to ensure due process before a proposed standard is granted legally binding status. There may be occasions in which some considerations are in tension with others. In these cases, it will be appropriate for the various trade-offs to be expressly identified.

82. We note that we do not expect it to be necessary for standards to cover collection, use and storage of personal information. These matters are currently, and will continue to be, governed by the Privacy Act as outlined on pages 17 to 20.

83. The draft law provides that failing to adhere to certain requirements in relation to personal information will be treated as breaching Privacy Act requirements (see clauses 47 and 48).

84. Thinking ahead, it is also essential to ensure that standards about data in different sectors of the economy are as interoperable as possible.

85. We want to ensure the draft law is well-adapted for when data in second and subsequent sectors is designated under the draft law. We are interested in your views on which elements of the current API standards for banking are suitable for use in other sectors, and which would require significant modification.

86. We think that the security standards that have been developed for banking could be appropriate for many other types of sensitive data or transactions. Using bank-level security standards for exchanges under the draft law would effectively protect all data as if it had a high level of sensitivity.

Trust: Accreditation of requestors

87. The draft law will create an accreditation regime for those who want to make binding requests for designated customer data or actions (clauses 64 to 73 of the draft law). It will also make it an offence for requestors to falsely hold themselves out as accredited when they are not.

88. An accreditation regime ensures only trusted people with trusted systems can make data or action requests using the draft law. It is critical to creating an environment in which customers and data holders can efficiently share data with service providers of their choice.

What privileges will accreditation provide?

89. Accreditation will grant a requestor the right to request data or actions from data holders, if other safeguards are also met. While any entity or person (accredited and non-accredited) can request data or actions on behalf of a consenting customer, the draft law requires data holders to comply with requests from accredited requestors. Non-accredited requestors can still make requests, but they will not have the benefits of the draft law, meaning data holders can choose whether or not they comply, and what format they send the data in.

How will accreditation be structured?

90. We intend to introduce different classes of accreditation according to risk level so accreditation processes and fees can be tailored to different kinds of use. This helps ensure costs and protections are proportionate to the use. With this in mind, we propose introducing two classes of accreditation in regulations, listed below.

Class One: Action initiation

91. Requestors with this accreditation would be able to access, hold, view, change and use data. For example, they could initiate a payment or change information on a customer’s online profile with the customer’s consent. This class of accreditation would have more stringent requirements. The more stringent requirements would reflect the increased risk profile inherent in action initiation.

Class Two: Read-only access

92. Requestors with this accreditation would be able to access, view and hold data. For example, they could retrieve a transaction history or fee data. This class of accreditation would have less stringent requirements.

We have not provided a special class of accreditation for intermediaries

93. The Australian CDR regime has a special class of accreditation for intermediaries (entities which collect designated customer data on behalf of other entities).^[14] This special class of accreditation was necessary because the Australian regime otherwise prevents accredited persons from sharing their data with others.^[15]

94. Under our draft law, accredited requestors can share data with another entity if the customer consents to it. Considering this, we do not see a need to include a special class of accreditation for intermediaries. Instead, businesses that help other businesses request designated customer data or actions from a data holder would be expected to become an accredited requestor themselves.

Intermediaries and outsourced providers are different concepts

95. This discussion document and the draft law make reference to ‘outsourced providers’ (clauses 23 and 24). While there are overlaps between the concept of outsourced providers and the Australian concept of intermediaries, they refer to different things.

96. An outsourced provider is defined in the draft law as an entity that helps a data holder or accredited requestor perform a duty or power it holds. For a data holder, an outsourced provider might be an entity which helps it connect its data systems to enable regulated data services to be provided. For an accredited requestor, an outsourced provider might be an entity that requests the data from the data holder on the accredited requestor’s behalf. In this latter situation, the outsourced provider would also need to be an accredited requestor themselves.

Reciprocal data sharing requirements are not proposed

97. In the Australian CDR Rules, accredited parties are treated as if they are data holders in some circumstances. This is called ‘reciprocity’ and means that accredited persons may be required to share specific CDR data as if they were designated data holders (including data they have generated themselves). These obligations are intended to bring more types of data into the CDR system more quickly, and to even the playing field between holders and others who provide data-enabled products and services. In recognition of the additional cost of reciprocal obligations, the Australian Rules provide for case-by-case applications to delay the onset of reciprocal obligations.^[16]

98. We have proposed a different approach. To encourage the transition to regulated data services from other methods such as screen-scraping, our intention is to maximise uptake and the participation of accredited requestors. Accordingly, our draft law does not provide for reciprocal data holder obligations on accredited requestors. If customer data created by accredited requestors (or their clients) is considered suitable for regulated data services, a designation process can be used to bring this data into the regime.

What should the requirements for becoming accredited be?

99. Regulations will set the criteria which must be met before an applicant is accredited.

100. We propose that the initial criteria set out in regulations include a fit and proper person test and a demonstration of adequate information protection and security measures. We are also considering whether they should include proof of appropriate business insurance. Each of the proposed criteria is set out below.

Fit and proper person

101. We propose that the directors and senior managers of the applying entity – or anyone in an equivalent position – must be ‘fit and proper persons’. The requirements for this criterion could be similar to other ‘fit and proper’ tests in existing legislation, such as the Credit Contracts and Consumer Finance Act 2003.^[17] If the applicant can show they have passed an equivalent test under another Act, we propose there should be a fast-track option available.

Demonstrated information protection and security measures

102. We propose that the applicant must have demonstrated appropriate information protection and security measures.

103. To meet this criterion the regulations could require the applicant pass a system security test, complete a self-report on information protection and security measures, or demonstrate their ability to connect to and safely use the IT systems the draft law will rely on. These general regulations could be supplemented by sector-specific requirements. For example, businesses in high-risk sectors may be required to demonstrate more robust levels of information protection and security.

Evidence of appropriate insurance

104. Business insurance increases the ability of customers and other persons to obtain redress or compensation against a company which may have caused harm or loss. With business insurance, wronged customers are more likely to be compensated in the case of a breach of their legal obligations.

105. We are considering introducing a requirement in the regulations that businesses hold “appropriate” insurance. The regulations would not define what appropriate insurance must be – instead, whether insurance is appropriate would be assessed on a case-by-case basis by the accrediting agency when it assesses the application. However, as has been done overseas, we propose publishing guidance which would set out what insurance would be considered appropriate. This guidance could be easily updated by the accrediting agency as insurance practices change. We believe this approach would provide sufficient clarity to affected businesses whilst also being flexible enough to accommodate differing industries and practices so that it does not create barriers to entry.

Supporting the participation of Māori

106. To ensure that the regime works well for all, it must earn the trust of a wide variety of potential users. As noted earlier, there are strong interests on the part of iwi, hapū and Māori organisations in the care and guardianship of data. For this reason, we would like to understand their particular perspectives on the proposed criteria to become an accredited requestor. We would like to know if these criteria are sufficient to support trust from Māori customers, and whether the proposed criteria would affect the willingness or ability of Māori organisations to apply for accreditation.

Other ways to support trust

Transparency requirements

107. In addition to accreditation criteria, the draft law provides for regulations to add further safeguards (clause 84). This could include a requirement that both accredited requestors and data holders publish information in their data policies stating whether they, for example:

• use customer data for research or statistical purposes
• sell or rent customer data, or insights from the data, to other parties.

108. Both of these things are currently permitted under the Privacy Act if there is customer consent, or if individuals are not identifiable.^[18] This kind of transparency requirement would mean that people can make informed decisions as to whether to become a client of any given data holder or accredited requestor. See also paragraphs 172 to 173 below for more detail on data policies, and paragraphs 138 to 146 regarding options for guiding ethical data use.

Cultural capability of accredited requestors

109. Under the draft law, the ultimate ‘user’ is the customer themselves, but the accredited requestor or the ultimate data receiver will use access to the data to provide the good or service requested by the customer. They may hold the data for different lengths of time, subject to the Privacy Act (for personal information) or commercial agreements (in the case of non-personal information).

110. Not all accredited requestors or service providers will have the knowledge or capability to ensure that data is stored and used in a manner which is culturally appropriate for Māori customers, or for others with specific approaches or interests in relation to their data.

111. We have not proposed that accredited requestors be required to meet cultural capability thresholds as a criterion for accreditation. This is because other safeguards in the draft law and Privacy Act mean that customers will:

• choose which services they wish to opt-in to
• have to give express, informed consent prior to any data exchange.

112. Therefore, those providers who can demonstrate culturally appropriate approaches will be offering a point of difference in the market. We are interested in feedback on this point.

Note regarding interoperability

113. When developing the regulations, we will seek as much as possible to:

• align our accreditation criteria with similar criteria in international accreditation regimes
• introduce fast-tracks in the accreditation regime for businesses that will be required to complete a similar process for other domestic schemes, such as the DISTF Act. The rules for this are currently in development.

114. Interoperability will not however be an over-riding consideration. Cost-effectiveness, fit with our statute-book and constitution, equivalency of user experience with data exchange outside of the system, supporting accessibility and inclusion, and ensuring safeguards are proportional to risk will also be essential considerations.

Unlocking value for all

115. This section looks at future use cases to check that the settings in the draft law are suitable for all types of customers to benefit. Below we ask for feedback about opportunities for Māori, customers who are businesses, and about ways of ensuring accessibility and inclusion.

Māori, iwi and hapū

116. We seek your feedback on how the design of the draft law could best enable by-Māori for-Māori uses of data.

Māori approaches to data

117. All data has a whakapapa (genealogy).^[19] Data about an individual is considered an extension of that person and can have different levels of tapu (sensitivity) depending on its nature and context.^[20]

118. There will be relationships between the articles of Te Tiriti/the Treaty, tikanga relating to data governance and use, and elements of the draft law. We are interested in feedback on these potential relationships.

Opportunities created by the draft law

119. In New Zealand, iwi, hapū and Māori organisations have significant responsibilities, but can face challenges in accessing timely, relevant and accurate data in order to carry out their functions and meet their aspirations.

120. By enabling data portability at the customer’s consent, the draft law creates opportunities for access to data not only for the customer’s direct benefit, but also potentially for collective benefit. Opportunities may include the following:

• Family trusts or businesses will be able to share account information easily with specialist advisers.
• Individuals could request that specific data about them be shared with collectives, such as hapū or iwi for governance purposes, or with initiatives such as Te Whata.²¹
• Accredited requestors or other data receivers could develop services enabling customer self-identification of Māori data (eg adding the hapū/iwi they belong to, before on-sharing with a party of their choice).
• Action initiation could assist with maintaining up to date contact details across tribal registers.
• Māori organisations could consider becoming accredited data requestors – to offer specialist data capability and functionality for iwi/Māori groups.

121. We want to ensure that the design of the draft law best:

• removes barriers to Māori accessing and using their own data
• enables use cases which align with iwi and Māori aspirations.

122. While not directly connected to the design of the draft law, we are also interested to hear from iwi/hapū/Māori organisations about their aspirations for capability to receive, use and protect customer data and product data.

Business customers

123. The draft law holds significant potential for businesses. Unlocking business’ transaction and account records for access by accountants or other specialist advisers saves time and effort, and can generate new insights. The potential for efficiency and innovation will increase further as other sectors are designated, and banking data can, for example, be layered with energy use data or connected with non-bank finance products.

124. Small businesses in particular have been clear that they want to see an environment in which the cost and process of lending is reduced. The draft law will enable these efficiencies. A variety of use cases have emerged in the United Kingdom based on banking data and payment functionality. These include a range of business to business payments products, working capital lending products, and business operations products and services.

125. We are interested to understand any other use cases of particular interest to businesses, including small businesses, to ensure we don’t inadvertently create barriers for them in our design.

126. We note that when the draft law is introduced and regulations design is underway, business input will be essential to ensuring that requirements for ‘secondary user’ functionality meet business operational and administrative needs.

Ensuring inclusion and accessibility

127. The intention is for accreditation to be open to all entities who meet the requirements, and for participation of customers to be driven primarily by the use cases on offer in the market. This is consistent with the purpose of the draft law as enabling infrastructure.

128. However, relying only on market-driven expansion could widen existing gaps in consumer access to some products or pricing. It may also mean the benefits of data-enabled products and services are focused on commercial customers and businesses, and not extended to collective and social purposes or the voluntary sector.

129. In other jurisdictions, ‘data for good’ initiatives have been proposed as a potential solution, to stimulate development of products and services specifically for broader social benefit, or else for customers who are not perceived as ‘high value’ or who might otherwise be underserved by the market. Any inclusion initiatives here would need to consider Te Mahere mō te Whakaurunga Matihiko – The Digital Inclusion Blueprint, Action Plan and its Outcomes Framework.^[22] The blueprint defines four ‘elements’ key to inclusion: Motivation, Access, Skill, Trust. This is something which will be considered in due course.

130. At this stage, we are interested to understand the types of use cases which may be of interest to ensure we don’t inadvertently create barriers for them in the design.

131. Further, we want to hear about ways that the implementation of systems and user interfaces under the draft law could actively support inclusion and accessibility. Guidance for data holders and accredited requestors will likely be of assistance here. We are considering whether a resource library could play a role. This could involve developing and/or sharing ‘good practice’ templates, user journeys or other ‘patterns’ which meet technical and accessibility standards as well as supporting participation from diverse customers. The availability of such templates or other guidance which could be adapted and re-used on a ‘creative commons’ basis could reduce compliance costs for designated sectors as well as make it easier for those who want to become accredited requestors to deliver services which are accessible and culturally inclusive. We seek your feedback on this idea.

Ethical use of data and action initiation

132. Accredited requestors will transmit or hold a lot of designated customer data, including potentially sensitive information. Where authorised by a customer, some will also be able to issue instructions to data holders on behalf of customers. This could include instructions to, for example, move money, update contact details, or open and close accounts.

133. A primary purpose of the draft law is to unlock data to generate value, including valuable insights, from data. Another is to encourage investment in more secure and efficient alternatives to data sharing methods currently in use. During previous consultations, several submitters highlighted the importance of also considering safeguards on the ethical use of customer data and action initiation. Ethical use of data sets is a key concept in Māori approaches to governance of data sets and would be in line with the purpose of the draft law regarding customer and social benefit.

What is ‘ethical use’?

134. Ethics are beliefs about what is morally right and wrong. A variety of guidance and principles already exist with ethical data use in mind, such as the Stats NZ Ngā Tikanga Paihere data ethics principles,^[23] the recently published Māori Data Governance Model^[24] as well as the Ministry of Social Development’s NZ Privacy, Human Rights and Ethics Framework^[25] (PHRaE). None of these are binding on the broader economy.

135. Overseas, the Australian CDR amendment Bill currently before Parliament contains a duty that accredited persons act ‘efficiently, honestly, and fairly’ when initiating CDR actions.^[26]

Existing legal protections on data use

136. The Privacy Act limits the use of personal information to the purpose for which it was collected, or where there is consent for a different use. However, there are exceptions, so personal information can be used for other purposes without an individuals’ consent, including if:

• it is used in a form that does not identify individuals, or
• it is used for statistical or research purposes and won’t be published in a form which would reasonably identify the individual(s).

137. In addition, the Privacy Act only covers personal information, so the protections for use do not extend to all designated customer data under the draft law. This means that insights from customer data can potentially be used for any purpose, including ones at odds with customer wellbeing or business interests.

Considering safeguards for use of customer data

138. As noted at paragraph 107 to 108 above, the draft law enables transparency requirements to be set for data holders and data requestors, in relation to customer data, product data and action performance.

139. If it is considered necessary to include additional safeguards for ethical use of customer data, there are two proposed options for safeguards which we would like feedback on. We note these are preliminary options and that we are open to other approaches.

140. In line with feedback to date, the intention is that these additional requirements would apply to participants in regulated data services, rather than travel with the data (eg when it is on-shared in compliance with the Privacy Act).

Option one: Ethical requirements as a condition of accreditation

141. This could involve an additional requirement that requestors’ systems and policies ensure data and action initiation are used ethically, responsibly and appropriately, and would be necessary for accreditation (as mentioned in paragraphs 99 to 112).

142. Requirements could be tailored for different sectors, as appropriate. For example, for accredited requestors of designated banking data this could potentially look like the fair conduct principle in the Financial Markets (Conduct of Institutions) Amendment Act 2022.^[27] Other data designated in future may need a different standard (eg health data).

Option two: Requirement to get express consent from customers for de-identification of designated customer data

143. This could involve requiring accredited requesters and data holders to request and receive consent from customers before their data is de-identified^[28] or used for research or statistical purposes. This option could relate specifically to ‘read access’ to data (rather than action initiation).

144. This requirement would give customers additional awareness and control over their customer data being used for purposes other than the direct good or service they obtain from the accredited requestor or other data receiver (ie they can choose to consent to de-identification or not).

145. When considering options for safeguards on use, a key consideration will be the purpose of the draft law. As well as unlocking data for the benefit of people and their organisations, another purpose is to encourage investment in more secure and efficient alternatives to existing data sharing methods already in everyday use. If accreditation or other participation requirements on holders and requestors are too high or costly, the draft law will not be able to achieve either purpose.

146. If an appropriate balance cannot be struck in the draft law, it may be necessary to consider economy-wide safeguards in other legislation.

Footnotes

[8] Australia originally had 90 days but changed to 12 months in response to user submissions https://www.accc.gov.au/system/files/CDR-Rules-Outline-corrected-version-Jan-2019.pdf [PDF, 1.3MB](external link), para. 7.25.

[9] See article ‘UK changes from 90 days for consumers’ https://www.fca.org.uk/publication/policy/ps21-19.pdf [PDF, 4.1MB](external link) para. 1.30, page 7.

[10] Subdivision 4.3.2A and B of Australia’s Competition and Consumer Data (Consumer Data Right) Rules 2020 prescribe similar requirements https://www.legislation.gov.au/Details/F2021C00076(external link)

[11] See considerations for Board in section 13(4) https://www.legislation.govt.nz/act/public/2015/0091/latest/DLM6203017.html(external link)

[12] Section 21, DISTF Act provides for similar consultation requirements and exceptions https://www.legislation.govt.nz/act/public/2023/0013/latest/LMS459644.html(external link)

[13] New Zealand API standards to initiate payments and access bank account information. They are based on the UK’s Open Banking Implementation Entity standards but tailored for the New Zealand market. Market demand has driven development and led to the creation of bespoke functionality for New Zealand.

[14] See https://www.accc.gov.au/by-industry/banking-and-finance/the-consumer-data-right/consumer-data-right-cdr/accc-makes-accredited-intermediary-rules(external link)

[15] Subdivision 7.2.3 of the Competition and Consumer (Consumer Data Right) Rules 2020.

[16] Pages 10 to 11 https://www.cdr.gov.au/sites/default/files/2022-12/CDR-Accreditation-fact-sheet-version-2-December-2022.pdf [PDF, 198KB](external link)

[17] For more information, see https://comcom.govt.nz/business/credit-providers/fit-and-proper-person-certification(external link)

[18] More specifically: IPP 10 provides that “an agency that holds personal information that was obtained in connection with one purpose may not use the information for any other purpose unless the agency believes, on reasonable grounds, that the information: (i) is to be used in a form in which the individual concerned is not identified; or (ii) is to be used for statistical or research purposes and will not be published in a form that could reasonably be expected to identify the individual concerned”.

[19] Te Mana Raraunga, Principles of Data Sovereignty (2018) https://cdn.auckland.ac.nz/assets/psych/about/our-research/documents/TMR%2BM%C4%81ori%2BData%2BSovereignty%2BPrinciples%2BOct%2B2018.pdf [PDF, 97KB](external link)

[20] See Hudson et al (2017), footnote 5, and Kukutai, Campbell-Kamariera, Mead, Mikaere, Moses, Whitehead, Cormack (2023).

[21] Te Whata is a data platform designed specifically by iwi, for iwi. See https://tewhata.io/(external link) for more information.

[22] See https://www.digital.govt.nz/dmsdocument/113-digital-inclusion-blueprint-te-mahere-mo-te-whakaurunga-matihiko/html(external link) for more information

[23] See https://www.data.govt.nz/toolkit/data-ethics/nga-tikanga-paihere/(external link) for more information

[24] See https://www.kahuiraraunga.io/tawhitinuku(external link) for more information

[25] Ministry of Social Development’s Privacy, Human Rights and Ethics Framework (PHRaE) https://www.msd.govt.nz/documents/about-msd-and-our-work/work-programmes/initiatives/phrae/phrae-on-a-page.pdf [PDF, 258KB](external link)

[26] See section 56BZA in the Treasury Laws Amendment (Measure for Consultation) Bill 2022: Consumer Data Right – Implementing Action Initiation, https://parlinfo.aph.gov.au/parlInfo/download/legislation/bills/r6950_first-reps/toc_pdf/22126b01.pdf [PDF, 568KB](external link)

[27] Section 446C, Financial Markets (Conduct of Institutions) Amendment Act 2022.

[28] De-identification refers to a range of methods for reducing the amount of information in a data set such that individuals are not identifiable or are less easily identifiable. Some examples of de-identification methods and their effectiveness are provided here by Digital.govt.nz: https://www.digital.govt.nz/standards-and-guidance/privacy-security-and-risk/privacy/manage-a-privacy-programme/sharing-personal-information/making-personal-information-safe-for-reuse/(external link)

< Chapter 1: Overview and key issues for the proposed customer and product data framework | Chapter 2: The Customer and Product Data Bill - technical matters and system settings >