Skip to content

ACCC & DSB Data Holder Working Group Agenda & Meeting Notes (18th of June 2020)

Jump to bottom
CDR API Stream edited this page Jun 18, 2020 · 13 revisions

ACCC & DSB Data Holder Working Group Agenda & Meeting Notes (18th of June 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: [email protected]

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

Type Topic Update
Maintenance Banking Maintenance Iteration 03 Decision Proposal 108
Decision Proposal - Energy Decision Proposal 109 - NMI Standing Data Payloads Decision Proposal 109
Decision Proposal - Energy Decision Proposal 110 - Additional Account Holders Decision Proposal 109
Decision Proposal - All Decision Proposal 119 - Enhanced Error Handling Payload Conventions Decision Proposal 119
Decision Proposal - All Decision Proposal 120 - CDR Error Codes for Enhanced Error Handling Decision Proposal 120
Decision Proposal - All Decision Proposal 121 - Application of existing HTTP Error Response Codes to Enhanced Error Handling Decision Proposal 121
Decision Proposal - All Decision Proposal 122 - Extension of Supported HTTP Response Codes for Enhanced Error Handling Decision Proposal 122
Workshop Enhanced Error Handling - Error Structure Workshop Outcomes Outcomes in comments of Decision Proposal 119
Question Is CX research on amending consent focused more on the process of obtaining consent rather than consent management? This depends on how ‘consent management’ is defined. Rounds 4 and 5 of CX research explored how existing consents could be amended by adding/removing datasets, adding/removing uses, extending the duration of an existing consent, and the separation of collection and use. The trigger for these are expected to be an ADR requesting a consumer’s consent to amend, rather than the consumer amending an existing consent on a dashboard. On this basis the consumer is still managing an existing consent, but is probably better understood as being focused on ‘the process of obtaining consent’ for a subsequent consent.
Question What will be the registry access token lifetime (e.g. 10 mins)? Access token lifetimes are 5 minutes. This is relatively short lived as they are only used for Data Holder discovery and retrieving SSAs.
Question What is the limit on historical account/transaction data which a DH needs to share, i.e. what is the “oldest time” that an ADR can request for?
    Broadly speaking, historical data:
    • Cannot date back earlier than 1 Jan 2017, as per the designation instrument (the date exampled in the CX Guidelines)
    • Cannot date back more than 7 years for open accounts with respect to the above, meaning:
      • Historical data requested in 2020 cannot date back further than 2017
      • Historical data requested in 2030 cannot date back further than 2023 (i.e., not 2017)
    • Cannot date back more than 2 years for closed accounts
    • However, there are multiple limits on historical data in addition to the above as outlined in Rule 3.2(4) in Schedule 3
Question Seeking clarification on CBA’s position: during outage periods, failure to respond to API requests does not constitute a refuse to disclose. This is in relation to both planned outages, and incidents (unplanned outages). By nature these periods will have limited system capabilities and will not provide reliable instrumentation. Additionally, planned outages and incidents are measured through other data standards APIs. James clarified during the DH WG 14/5/2020 that Refuse to disclose applies when there is an intentional active condition that is refusing, which is why incidents and planned outages does not fit the definition of refuse to disclose. We agree with the view that planned and unplanned outages are not refusals to disclose and will not be in scope for record keeping and reporting. Please confirm in writing.

From a technical perspective the reporting of a refusal to disclose means that the request is received and is valud but the data holder (for one of a variety of reasons) refuses to provide the requested data.

During a period of system instability or outage the first part of this technical definition may not be met. The initial request may not be received or may not be able to be assessed for validity. In these situations a refusal to disclose should not be recorded. This would, however, be recorded as a period of unavailability under the NFRs if the outage was unplanned. If the outage was planned and communicated with enough advance notice according to the standards then the calls would not need to recorded either as a period of unavailability or as a refusal to disclose.

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

  • To be advised

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 Follow-up for:
Question regarding the term “publicly offered” (clause 1.4 of Schedule 3 to the CDR Rules) What is the ACCC’s view of the term “publicly offered?” Clarification is sought as to how this term is intended to be interpreted.		 -
#2 Follow-up for:
    Questions for ACCC around Product reference data timeline obligations -
    • 1) Could you please clarify if Non-major ADIs can commence sharing PRD data for phase 1 products "prior to 1 July 2020" if ready?
    • 2) And if yes, would this automatically trigger any changes to other swim lane obligations (for PRD phase 2 and/or Consumer data)?
    • 3) Also, are we required to advise/inform the ACCC of the exact go-live date?
-
#3 Would an ADR’s SSA issued for July go-live contain future dated scopes that are not currently supported (e.g.: Scheduled payments and direct debits)? Answered in Issue 243
#4
    If it would, what behavior is expected when in authorization flow an ADR requests a scope that is currently not supported?
    • Should the ADH accept the request; or
    • Should the ADH reject the request; or
    • Should the ADH allow the request if there are other valid scopes, but ignore scopes currently not supported?
Answered in Issue 243
#5 If it won’t, then do we expect ADRs to submit a new SSA when additional scopes are introduces? Answered in Issue 243
#6 Clarification In regard to accreditation of and ADI or possible and Intermediary. The Guidelines make reference to certifications or assurances by a third party of CDR requirements such as Information technology and Disputes. Can an ISO 27000/1 Internal or external auditor or a PCI QSA provide the assurances? If so do they or an entities internal or external auditors require to have completed some additional training or certifications for CDR to prior to providing these or their existing qualifications accepted? -
#7 Follow-up on the following question:

Question 4 Would you please confirm an Open Banking Solution Provider contracted by a ADR ADIs or Fintechs be set as their endpoint connection to a DH.

  1. A an AAS (As a service ) provider of an application developed that would be hosted and provide ADH and or ADR capability for and ADI , Intermediary or other entity. Do they need to be identified and included in the Consent sent to an ADH?.
  2. As an Intermediary who has developed and application itself with capability to provide ADR and or ADR capability for use by itself and deliver products/applications
    1. directly to consumers. In this case would only the Intermediary Id be included consent to and validated by an ADH.
    2. To act as the middleman between a single or multiple ADHs and an ADI or other entities. Is the only Intermediary required to be shown or verified to the CDR Register and not the end recipient ADR of the consumer data? So and ADR can be masked or sit behind and Intermediary away from an ADH?

The difference being the entity solution providers or Intermediaries may have one or many ADH/ADRs clients being different to an Outsourced solution provider who may be directly identified by separate records in the CDR for each of their client ADH or ADR.

-
#8 Could we confirm the process for getting some assistance with the PRD comparison tool? -
#9

There is appears to be some ambiguity in the interpretation of rules with respect to joint account elections, as described in Monday’s OB Implementation Advisory Meeting (see extract below, p3, Item 4 (3)). In short the ACCC response below suggests that, when the joint account election is removed, “the data holder must not disclose consumer data on that account in response to a consumer data request. However, all other authorisations remain in place”.

This is ambiguous and appears to contradict previous advice shown in the adjacent column below.

We believe that the wording should be “the data holder must not disclose consumer data on that account in response to a new consumer data request. However, all other existing authorisations remain in place”.

We would be grateful if the ACCC would confirm our understanding. NOTE - Required Image to be added.

-
#Template

Notes

  • TBA

Question and answers

# Question Answer/ Action
#T
#T

Other business

  • TBA

Appendices

  • TBA

Next Steps

  • TBA

Getting Started

Meetings

Maintenance Iterations

CDR Implementation Call

Clone this wiki locally