Incorrect data has been observed in Product Reference Data APIs provided by the Major Banks, including incorrect lastUpdated dates, incorrect application of bundled discounts, misleading characterisation of fees, missing fees, and non-standard API response pagination.

The 4 Major Banks differ significantly in the way they have applied the data standards for product reference information. This is most pronounced in Residential Mortgage products, where products include a range of different price variations (eg owners vs investors, P&I vs Interest Only repayments, packaged vs non-packaged, fixed vs variable and different fixed loan terms). In every one of those types of price variation, there are at least 2 different approaches among the 4 banks and in some cases there are 4 different approaches. This will lead to significant difficulties for data users wishing to make accurate and complete product comparisons, and in some cases it will lead to an inability to compare or to users unwittingly making incorrect or misleading comparisons.

Non-ADI lenders are a significant segment in the home loan and personal loan markets. Currently the standards do not require product reference data to be published by non-ADI lenders. Given that one of the stated aims of CDR was an ability to provide consumers with better product comparison, this seems to be a major oversight.

The response provided by the ACCC is from a Non-ADI perspective. Could we please request that the ACCC provide a response from an ADI perspective (i.e. where the ADR is an ADI).

Will it be required that the ADR who has as a result of accumulating the multiple ADHs data respond to requests or be obligated to provide this accumulated or consolidated data to all of the respective any or all the original ADHs? In effect if you took a traditional PFM use case would where a consumer can “see all their accounts in one place”, that a consolidated view of transaction data forms the minimum data set that is eligible for reciprocity????

For information concerning ADI reciprocity

This question has two elements to address:

Once the ADI is a data holder in respect of the data, the ADI is required to share that data in response to a valid request (whether under the direct to consumer mechanism or with an ADR).

The timeline for direct to consumer functionality is still under consideration, and there is currently no requirement for DHs to provide functionality that facilitates consumer data requests made by CDR consumers.

During the course of the meeting, a follow up question was asked about correction obligations where 3rd case reciprocity has occurred. For example, if DH1 has become a data holder under third case reciprocity with respect to data originally received from DH2, what are their obligations for corrections (e.g., how can they correct data they weren’t responsible for creating)?

It is necessary to consider if Privacy Safeguard 13 (correction at the request of a consumer) applies. If Privacy Safeguard 13 applies, it is necessary to consider rule 7.15 of the CDR Rules, which outlines the steps to be taken when responding to correction requests.

If Privacy Safeguard 13 does apply because DH1 has previously disclosed that data previously received from DH2, then in response to a request to correct from a consumer, DH1 must either:

By consent grant process do you mean the consent flow? For R4 research we looked into extending duration (toward expiry of the data sharing arrangement), and amending consent where disclosure/collection expires, but use continues.

For R5- we are looking at adding/removing data sets through the trigger of extending duration (toward expiry of data sharing arrangement). I think in response to your question, we're looking at it more from a consent grant process, and less than from a consent management (ie- amending consent via the dashboard).

We have a question in regards to the following CX Guidelines (Account Selection Page): Data holders are not permitted to show unavailable joint accounts as joint accounts need to be elected via a joint account management service before they are permitted to appear in the authorisation flow (See CDR Rules: Schedule 3, 4.1(1); 4.2; 4.3(3); and CDR Rule 4.24)

1. Has consideration been given to customers whom only have joint accounts, under the above guidance such customers would not see any of their accounts listed under the ‘accounts unavailable for sharing’ section?
2. Would it not be better to show such these accounts in the ‘accounts unavailable for sharing’ section, along with information about the joint account management service explaining the customers how to enable them?