Skip to content

ACCC & DSB Data Holder Working Group Agenda & Meeting Notes 2020_04_30

Jump to bottom
CDR API Stream edited this page May 8, 2020 · 6 revisions

ACCC & DSB Data Holder Working Group Agenda & Meeting Notes (30th of April 2020)

When: Weekly every Thursday at 3pm-4.30pm AEST
Location: WebEx, quick dial +61262464433,785383900%23%23
Meeting Details:

Desktop or Mobile Devices https://csiro.webex.com/csiro/j.php?MTID=m7c39ee9db5e5892ab35cd0bd7bbf94ce
Once connected to your meeting remember to start your audio and video
Please mute when you are not speaking.

Video Conferencing (VC) Rooms
Use the remote control or touch panel and dial the number indicated below:
External VC Room: 785383900@csiro.webex.com

Phones - AUDIO ONLY

Agenda

  1. Introductions
  2. Outstanding actions
  3. CDR Stream updates
  4. Q&A
  5. Any other business

Meeting notes

Introductions

  • 5 min will be allowed for participants to join the call.

Actions

Outstanding questions

Type Topic Update
Question Please note - question to be verified against answer _Question posted here in Issue 162

The ACCC refers data holders to Schedule 3, rule 3.1 of the Competition and Consumer (Consumer Data Right) Rules 2020 which sets out the meaning of required product data and voluntary product data for the banking sector. Generally:

Required product data is:
> Data specifically about depositing money (except as part payment for goods or services), advances of money, purchased payment facilities and other financial activities which are publicly offered by the data holder;
> Data about the eligibility criteria, terms and conditions, price, availability or performance of such a good or service;
> Data which is held in a digital form; Where the data is about availability or performance of the good or service, the data is publicly available.

Voluntary product data is:
> Data specifically about depositing money (except as part payment for goods or services), advances of money, purchased payment facilities and other financial activities which are publicly offered by the data holder;
> May be about any other aspect of the good or service, is not required to be held in a digital form, and may not be publicly available.


Both classes of data are sometimes called ‘product data’, ‘product specific data’ or ‘product reference data’. In the banking sector, product data may include terms and conditions, interest rates, fees and charges, discounts and product features on products, such as transaction accounts, term deposits, credit card and debit card accounts.

When a data holder responds to a product data request, the data holder must include any required product data (that is the subject of the PRD request) that is otherwise contained in a Product Disclosure Statement or on their website. This is a qualitative metric to ensure the PRD that is being shared is commensurate with the information that is otherwise/already publicly available on those products.

The standards include some “optional” fields because those fields may not be applicable to every product that could be requested through that API. While the fields may be designated “optional”, it is required that the “optional” data will be provided by where this data is “required product data” and meets the qualitative metrics detailed above. In other words, some required product data may be “required” to be shared under an “optional” field.

Financial institutions cannot charge fees for required product data requests, but may charge fees for voluntary product data requests.

The ACCC expects that data holders will approach their PRD sharing obligations in good faith, having regard to the obligations outlined above about what information is required to be shared. In light of experience, the ACCC may determine that further refinement to the obligations in the Rules is needed to support PRD sharing that will facilitate meaningful comparison of products and promote switching.

The ACCC welcomes feedback from data holders about key issues they encounter in meeting their PRD obligations, in order to ensure the policy objectives of PRD sharing are met. The ACCC has not developed a tool for Data Holders to test conformance with the Standards for product reference data and at this stage, the DSB will continue to update the Payload Validation Tool on CDS. If you have any questions concerning the requirements under the Rules to share required product data, Data Holders can contact the ACCC by emailing accc-cdr@accc.gov.au .

Question I could not see any difference between the Get Products v2 and v3 api specifications, was that intentional or am I missing something? -

CDR Stream Updates

Provides a weekly update on the activities of each of the CDR streams and their workplaces

  • ACCC Rules
  • ACCC CDR Register (Technical)
  • DSB CX Standards
  • DSB Technical Standards - Energy & Banking

Presentation

No presentation is scheduled for this week.

Q&A

Questions will be received by the community via WebEx chat before the questions are opened to the floor. Participants can pre-submit questions to the DSB mailing box.

Currently received pre-submitted questions:

# Question Answer
#1 During the DSB/ACCC Data Holder Working Group held on 16/04/2020, a participant asked a question about the on-sharing of data (question 1 of Question and Answers). When will a response be provided by the ACCC? -
#2 Issue 198 -
#3 Account Status Rules and standards refer to Open and Closed accounts, but in reality there are also Pre-Open or Pre-Active accounts. There is no guidance that we have found on at what point an account moves into an Open Status and we believe it would preferable to have a uniform approach across the regime. Three examples:
A Home Loan goes through stages until it is approved and then drawn down. We would currently view drawn down as the first status that corresponds to Open
A Term Deposit is opened but the term does not begin until the funds are deposited. We would view the depositing of funds as the first status that corresponds to Open.
A savings account is created and at a later point a deposit is made. We would view the creation as the first status that corresponds to Open		 -
#4

Transaction Status

We are mapping transactions to transaction types in the standards. Should a reversal be treated as the same transaction type as the original transaction. Eg is a reversal of a Transfer Outgoing a Transfer Incoming or is it still a Transfer Outgoing but the ‘sign’ of the amount indicates a reversal?

No definitions are provided in the standards for transaction types and we do not know what is expected for many common transactions. It is not clear if a transfer connotes funds to another account within the same organisation that the consumer also operates or whether it may mean any payment to any account anywhere. As an example - It is not clear what an ATM withdrawal should be mapped to. Or a Pay Anyone via online channel. Again, it would clearly benefit the entire regime if there is consistency in the application of these type. </p?

 -

Notes

  • Rules
    • Draft rules have been published
    • Target to be in place before 1st of July 2020
    • Comments by 8th of May 2020
  • Register
    • Number of actions progressing with policy and operation
    • No material changes since last week’s update
  • CX
    • Amending consent work underway; primarily research but looking to start Phase 04 to commence very shortly
    • Phase 03 report has been completed
    • Ended consumer policy research to assist with consumer advocate research, to start audit of some guidelines and then move to consultation
    • CX Update for April to be published in the next day or two
  • Technical
    • Banking
      • Feedback and minor issues for 1.3.0 captured and rolled into 1.3.1 release
      • A third of the way through Maintenance Iteration 03, check point meeting is due in a few weeks
      • Primary focus now is enhanced error handling; first is error payload and structure
      • Great feedback on the error scenarios under Decision Proposal 119, 120, 121 and 122
    • Energy
      • Workshop on the 29th of April 2020, great success and awesome feedback
      • Additional Decision Proposals are now up on GitHub - majority are placeholders as we prepare the next round of consultation

Question and answers

# Question Answer/ Action
#1 Question: given the non-majors regulatory date being moved from 1 july to 1 october for product data, are participants able to voluntary deploy their product apis earlier? particularly version 2? Answer pending review
#2 With regards to voluntary sharing of PRD prior to 1 Oct, if a Data holder chooses to share PRD data earlier, how would this impact timeline obligations for the other swim lanes or is this completely independent of other swim lanes? If a Data Holder chooses to share PRD data earlier, this does not impact timeline obligations for other swim lanes.
#3 Does the data holder need to apply for voluntary participation?

Previous responses provided for questions similar to this included:

As a Data Holder, you are not required to register on the CDR Register until you are required to share CDR consumer data with accredited data recipients in accordance with the timetable set out in under Schedule 3 of the CDR Rules. You are not required to register to share product reference data nor report on product reference data via the Admin APIs.

Further clarification was provided:

As a Data Holder, you are not required to register on the CDR Register until you are required to share CDR consumer data with accredited data recipients in accordance with the timetable set out in Schedule 3 of the Rules. You are not required to register to share product reference data (PRD). Reporting via the GetMetrics API is also delayed until Data Holders are required to share CDR consumer data, however, reporting under Rule 9.4(1) commences when Data Holders commence sharing PRD. We anticipate the approved form for reporting will be made available in the near future.

At this stage, the ACCC anticipates Data Holders will be able to register via the CDR Participant Portal just prior to the CDR consumer data sharing obligation commencing. A Data Holder’s PRD URI can also then be captured on the CDR Register. The ACCC recommends making your PRD URI available on your website between now and when you are Registered as a Data Holder.

We also note that on Friday last week, the ACCC made an announcement with respect to delaying the commencement date of product reference data sharing obligations in light of COVID – the media release is available here and newsletter here.
#4 And what is the process of conformance/assurance testing for those who want to share PRD data early? There is no process of conformance testing for PRD data.
#5 You're asking Holders if they think it's ok that Recipient complaints aren't covered by the rules framework? Presumably this would be a resounding "Yes" from Holders... it doesn't cover what recourse Recipients have if Holders fail to deliver reliable and accurate CDR services.

The Rules require data holders to have internal dispute resolution processes that comply with provisions of Regulatory Guide 165 that deal with certain matters, as if references in Regulatory Guide 165 to complaints or disputes were references to CDR consumer complaints.

CDR consumer complaints means any expression of dissatisfaction made by a CDR consumer to or about a CDR participant that relates to, inter alia, the CDR participant’s obligations under or compliance with Part IVD of the Competition and Consumer Act 2010, the Competition and Consumer (Consumer Data Right) Rules 2020 or the binding data standards.

The ACCC may consider expanding the scope of internal dispute resolution and complaints processes for Product Reference Data if required in light of experience, including complaints we receive directly.

#6 As per MTLS HoK, when client certificate is attached to long lived accesstoken, what would happen if client certificate expires and ADR brings new client certificate as part of MTLS with an existing access token which contains the old certificate Answer pending review
#7

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????

Under the Rules, reciprocal data holder obligations are turned on for accredited persons that are not ADIs only in respect of CDR data that is:

> Generated and held by the accredited person; and
> Generated and held in respect of a product that is publicly offered by the accredited person and generally known as one of the types in phase 1, phase 2, or phase 3 (see Clause 1.4 of Schedule 3).

That is, an accredited non-ADI will not be a data holder of CDR data that was disclosed to it under the CDR Rules. For example, a non-bank lender who has also been accredited to operate as an ADR could be a DH for CDR data that it generates and holds, but not for CDR data that it holds because it was disclosed to it via the CDR regime.

#8 Question for ACCC rules team: I believe with the recent changes to the wording within Rule 4.25 (Withdrawal of authorisation to disclose CDR data and notification), is it correct to assume that Data holders are not mandatorily required to accept authorisation withdrawal requests in writing now, and they can chose to have that feature if they’d like?

That is correct – the proposed amendment will mean that a Data Holder can allow a CDR consumer to withdraw authorisation to disclose CDR data to an accredited person by using an alternative method of communication made available by the Data Holder. The proposed amendment is intended to better reflect existing methods of communication made available by Data Holders to its consumers.

DHs must always have two forms of mechanisms available to consumers to withdraw authorisations. One mechanism must be through the consumer dashboard, and the other may be of the DH’s choosing, but an alternate method must be in place.

#9 Are the admin API's required for the launch of Product data for phase 1 No, they are not required for Product Reference Data Phase 01
#10 Question for ACCC rules team: Section 2.1(2)(a) provides reference to ‘individual who is 18 years of age’ (Meaning of eligible section). What does the word ‘individual’ mean here in the context of Business products which are tailored for businesses/organisatons (business savings ac, business TD, business CC)?

The proposed amendment to clause 2.1 to clarify that a CDR consumer is eligible is an individual who has an account with the data holder and is the account holder. This amendment is to clarify that the accounts in scope are those where the account holder is a natural person (not a legal person, e.g. a corporate entity). A business account will be in scope if the account is held in the name of one or two natural persons (e.g. a sole trader business).

Further rules will be made to bring in accounts where the account holder is a corporate entity.

#11 Is it required to display the CDR data requests made by data recipients in the data holder's consumer dashboard or is it just the Authorization details to be shown in the dashboard? The details in rules 1.15 and 7.9 must be displayed in the data holder’s consumer dashboard. These details generally relate to authorisations and disclosures of CDR data.
#12 Question for API standards team: Is the static payload test tool available to download for API conformance testing for PRD? If available to all participants, could you provide a link to that? Link to the Conformance Test Suite is here
#13 Will there be rules for this dispute resolution process?

The Rules require data holders to have internal dispute resolution processes that comply with provisions of Regulatory Guide 165 that deal with certain matters, as if references in Regulatory Guide 165 to complaints or disputes were references to CDR consumer complaints.

CDR consumer complaints means any expression of dissatisfaction made by a CDR consumer to or about a CDR participant that relates to, inter alia, the CDR participant’s obligations under or compliance with Part IVD of the Competition and Consumer Act 2010, the Competition and Consumer (Consumer Data Right) Rules 2020 or the binding data standards.

The ACCC may consider expanding the scope of internal dispute resolution and complaints processes for Product Reference Data if required in light of experience, including complaints we receive directly. </p
#14 Hello there, Stage 4 dates for non-majors are still Feb-2021 or will it be considered to be extended ? The ACCC is conscious of the impacts of COVID-19 but no other changes have been made to the timeframes for the CDR as yet. Any future changes to the timetable will be communicated via the ACCC’s CDR newsletter.
#15 Asking recipients to use "commercial channels" with billion dollar banks is pointless. It seems like ACCC needs to be ensuring that Holders aren't "mistreating" Recipients

The Rules require data holders to have internal dispute resolution processes that comply with provisions of Regulatory Guide 165 that deal with certain matters, as if references in Regulatory Guide 165 to complaints or disputes were references to CDR consumer complaints.

CDR consumer complaints means any expression of dissatisfaction made by a CDR consumer to or about a CDR participant that relates to, inter alia, the CDR participant’s obligations under or compliance with Part IVD of the Competition and Consumer Act 2010, the Competition and Consumer (Consumer Data Right) Rules 2020 or the binding data standards.

The ACCC may consider expanding the scope of internal dispute resolution and complaints processes for Product Reference Data if required in light of experience, including complaints we receive directly.

#16 With version 1.3 looking to remove some fields from the PRD data structure - is removal of data considered a breaking change? Is there some guidance around versioning and breaking changes. Versioning approach for the Consumer Data Standards is covered here
#17 Is there an update on Reporting forms and PRD reporting guidance. The last udpate was: "We are expecting to release the approved reporting forms by the end of the month. We expect to release further guidance on our reporting expectations for phase 1 PRD obligations alongside the reporting forms." We anticipate an announcement to be made about the approved reporting forms and associated guidance via the CDR newsletter this Friday 8th of May 2020
#18 Get Status and Get Outages (which falls under the Common API section on the CDS page, even though they are I think referred to as Admin APIs) - Are they required for Product Data Launch? MV responded prvisouly.

These API endpoints are only required when an ADI is obligated to share consumer data (once onboarded to the CDR Register as a registered data holder).

An ADI may publish these endpoints earlier but it is not required.

#19 Is the CDS Conformance Suite repository publically available to build and run? As I noticed, the github link given in the documentation is not accessible. Question taken on notice
#20 Is there any timeframe for when the Data Recpients Working groups to commence? At this time no date has been set for the Data Recipients Working Group Call to commence, however this call is open to both Data Holders and Recipients and we welcome participation from both parties here.

Other business

  • TBA

Next Steps

  • Action 01 - Question to be verified against Answer - In Progress
  • Notes to be updated and distributed

Getting Started

Meetings

Maintenance Iterations

CDR Implementation Call

Clone this wiki locally