to clarify that 'in digital form' should be interpreted to have its ordinary meaning.
For the CDR to be effective, it is critical that CDR data is of good quality. This includes product reference data (PRD) as well as consumer data.
This means that data disclosed through CDR must be accurate, up-to-date, complete, and in the format specified by the Consumer Data Standards (the standards). This includes populating relevant fields in the circumstances outlined in the standards with all data that is digitally held by the data holder, and relevant to the data request.
Data quality obligations are imposed by the CDR Rules, the CDR Privacy Safeguards, and the standards. It is incumbent on data holders to understand their obligations and implement solutions that comply with those obligations.
During consultation with stakeholders on Data Quality in the CDR, the ACCC identified specific instances in which key data holder obligations have been misinterpreted.
This article is not intended to provide comprehensive guidance regarding a data holder’s obligations in relation to data quality. It is intended to provide additional guidance on the specific data holder obligations that have been misinterpreted. The additional guidance provided in this article is on:
- The meaning of required data under the CDR Rules
- The meaning of Mandatory, Optional and Conditional in the standards.
Our additional guidance on these topics can be found under the relevant headings below.
This article supplements existing guidance, including the DSB’s Data Formats – Schema Guidance, the OAIC’s Privacy Safeguard Guidelines, and the ACCC Compliance Guidance for data holders.
This article may be updated from time to time to highlight relevant pieces of specific guidance as they are created, such as specific field guidance that is being published by the DSB.
Background: Reporting Data Quality Issues
At the outset, it is important to note that as the success of CDR relies on data being of good quality, there are avenues to report issues relating to data quality.
Where a user of product reference data wishes to report a particular example of poor quality data, they may contact the data holder directly, or make a report to the ACCC via accc-cdr@accc.gov.au.
If an entity involved in CDR considers that the schema outlined in the standards could be improved, they can make a standards change request to the DSB via GitHub. This might be the case where a piece of data is unavailable, or not in the form that is useful for a given use case. Change requests are subject to a consideration and consultation process before any changes are made to the standards.
If a consumer wishes to complain about the quality of data about them which has been disclosed through the CDR, they should complain to the business that disclosed the data in the first instance. If the business doesn’t respond to the complaint within a reasonable amount of time, or the consumer is not satisfied with the response, they can lodge a complaint with the OAIC by submitting a complaint via the Complaint Function on the CDR website. Consumers can also choose to complain to the relevant external dispute resolution scheme.
Entities involved in CDR are required to provide information about dispute resolution in their CDR policies for consumers. Where an entity involved in CDR experiences a potential data quality issue with a particular data holder, we encourage them to raise a ticket via the process outlined in the Service Management Portal User Guide.
Data holders may self-report compliance gaps via the Rectification Schedule submission process outlined in the Service Management Portal User Guide.
Where an entity involved in CDR has other concerns about their own compliance, or the compliance of others, with these requirements, we encourage them to contact the ACCC CDR Compliance Team via accc-cdr@accc.gov.au, or use the report and enquiry functions on the CDR Website. The ACCC and OAIC consider all reports of non-compliance in line with the ACCC/OAIC Joint Compliance and Enforcement Policy for the CDR.
Background: High Level Data Quality Obligations
Product Reference Data Quality Obligations
Rule 1.12 requires data holders to provide an online service that
Rule 2.4(3)(b) requires data holders to, when making a disclosure in response to a product data request, include any required product data that is contained:
Rule 3.1 of Schedule 3 provides that the meaning of ‘required product data’ in the banking sector means information
The standards set out the detailed requirements for the product data disclosure service operated by data holders. For the banking sector, these are the Get Products and Get Product Details standards. The standards further provide that data holders must take reasonable steps to ensure the quality of disclosed PRD. In the banking sector, product reference data holders are authorised deposit-taking institutions, and in the Energy Sector, they are the Australian Energy Regulator and the designated Victorian Government entity. |
Consumer Data Quality Obligations
Rule 1.13(b) requires data holders to provide an online service that
Data holders must also provide equivalent services for nominated representatives and secondary users. Rule 4.6 requires data holders, in response to valid consumer data requests, to disclose requested required consumer data through their accredited person request service, and provide that data in accordance with the data standards. The standards set out the detailed requirements for accredited person request services. These are the various Banking and Energy APIs. Privacy Safeguard 11 requires:
to:
See Chapter 11 of the OAIC’s Privacy Safeguard Guidelines for detailed information on the Privacy Safeguard 11 obligations, including how data holders and accredited data recipients should ensure consumer data they are disclosing through the CDR system is correct, when and how to advise a consumer if CDR data that was disclosed was incorrect, and when corrected CDR data should be disclosed. Privacy Safeguard 13 deals with correction of CDR data, and the steps that must be taken in response to a consumer’s correction request. See Chapter 13 of the OAIC’s Privacy Safeguard Guidelines for further information on how to acknowledge, action and respond to consumer correction requests. |
Additional guidance: The meaning of required data under the CDR Rules
Product Data
In response to a valid product data request, data holders must disclose all required product data they hold in digital form. We consider this includes the information that is on their website, or in a product disclosure document.
This requirement is not limited to information that is held by a data holder in specific business systems, such as the core banking system. In practice, almost all information that is on a website or in a product disclosure document will be held in a digital form. Obligations to disclose data apply to all relevant information that appears on a data holder’s website, or in a product disclosure document. Therefore, the absence of information from a given catalogue or source system is not a justification for not disclosing it.
It is incumbent on data holders to understand their obligations and implement solutions that comply with those obligations.
Consumer Data
In response to a valid consumer data request, data holders must disclose all required consumer data that they hold in a digital form. Required consumer data includes information that is customer data in relation to a CDR consumer, account data, transaction data, or product specific data.
For the avoidance of doubt, relevant digitally held data must be disclosed, even where data is not shown to consumers via an existing digital channel. As with product reference data, the internal structure of a data holder’s storage systems does not affect its obligation to disclose required consumer data in response to valid requests.
For example, if a data holder discloses the type of repayments (e.g. owner/occupier or investment) of a home loan product on its website and holds the information about repayment frequency in relation to that product but does not display this information to individual customers via online banking, it must still disclose the relevant information as product specific data in relation to that consumer, if requested in response to a valid consumer data request.
Additional guidance: The meaning of Mandatory/Optional/Conditional in the standards
The CDR Rules provide that all required data must be disclosed in response to a valid consumer or product data request in a manner that conforms with the standards. The standards provide fields through which data holders can disclose data, and specify three states for these fields – mandatory, optional, or conditional. These states have specific definitions in the CDR standards.
These specific states do not alter the obligation under the CDR Rules to disclose required data (which remains mandatory), but rather facilitate data holders not including information in particular data fields where it does not exist.
All three forms of data must be disclosed if given criteria are met.
- Mandatory fields must always be included in the disclosure. This includes attributes like product names, product IDs, and other information that is fundamental to the request.
- Conditional fields are required if other values in the disclosure meet the criteria outlined in the standards.
Example
The BankingProductFeatureV2 standard provides that additionalValue fields must be populated if the FeatureType is set to a particular value. |
- Optional fields are required where external factors, which cannot be determined by analysing the disclosure, are met. Optional fields are not optionally implementable by the data holder. Optional fields must always be present where the field is relevant to a particular request, and the data holder holds the relevant information.
Example
Lendingrate is an optional field because some products, like a transaction account, may not have an applicable lending rate. If the data holder holds data relevant to the field in respect of a particular product, it must disclose it. This is required regardless of whether the information could be inferred from another field (such as the product name, or additional information). This also applies regardless of whether the relevant data is held in a different system than other data included in the disclosure. |
If data holders consider that required data cannot be accommodated by the existing schema, we encourage data holders to raise a change request on Github so that the standards may be altered to accommodate the relevant data.
Other articles on the CDR Support Portal that are relevant to Data Quality
Specific Field Guidance
Other Data Quality Guidance
Conventions
Align CDR channel experiences to existing digital channel experience
General Requirements
Correspondence between transactions listed by API and by Internet banking applications
Clarification on transaction times
Currency scope for min-amount and max-amount in Get Transactions For Account API
Transaction Fields: Description and Reference clarification
Mandatory/optional fields
BankingAccountDetail schema and rate inclusions
Contact
ACCC Communication with Participants
Compliance and Enforcement Policy
Privacy Safeguards
Correcting data for data recipients
Comments
0 comments
Please sign in to leave a comment.