-
Notifications
You must be signed in to change notification settings - Fork 56
ACCC & DSB Data Holder Working Group Agenda & Meeting Notes (30th of July 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
- Primary Australia: +61 2 6246 4433
- Quick Dial: +61262464433,785383900%23%23
- Other Global Numbers: https://conferencing.csiro.au/Call-in.php
- Meeting Number/Access Code: 785 383 900
- Introductions
- Outstanding actions
- CDR Stream updates
- Q&A
- Any other business
Meeting notes
- 5 min will be allowed for participants to join the call.
| Type | Topic | Update |
|---|---|---|
| Questions and Answers | Please submit all new pre-submited questions to support@cdr-support.zendesk.com | New process to triage, assign, track and respond to questions raised by the Community. Questions and Answers can be now be found here: CDR Support |
| Maintenance | Banking Maintenance Iteration 04 |
Key Phase Dates Phase 1: Retrospective and Backlog Grooming - 9th July 2020 commencement. 2 weeks duration Phase 2: Consultation - 22nd July 2020 commencement. 4 weeks duration Phase 3: Approvals and Documentation - 19th August 2020 commencement. 2 week duration Please contact contact@consumerdatastandards.gov.au for an invite to the series |
| Maintenance | Banking Maintenance Iteration 04 |
Link to Summary Link to Board of changes |
| Decision Proposal - All | Decision Proposal 120 - CDR Error Codes for Enhanced Error Handling | Decision Proposal 120 |
| Standards | Version 1.4.0 Proposed Changes | Board of changes is located here |
| Action | Meeting Minutes and Agenda Clean-up | We've rolled up the months of February, March, April and May into a landing page for each month. Reduces the number of entries in the side bar - nothing has been removed. |
| Event - Workshop |
Data Quality Workshop - Overview and Objectives When: 4th of August 2020 @ 2:00PM - 4:00PM AEST Where: Online Workshop (Zoom) Register: Eventbrite |
Link to register can be found here |
| Event - Workshop |
Energy Rules Framework workshop 2–4pm Full details with be shared with registered participants closer to the date. |
Link to register can be found here |
| Website | New Data Standards Body Events Page now Live! | You can access this under "Communications" and select "Events" - link to page here |
| Question & Answer | Is pushed authorization a mandatory requirement for all data holders? Standard says "From November 2020, Data Holders MUST support Pushed Authorisation Requests via the pushed authorisation end point".It also says "If a Data Holder does not support Pushed Authorisation Requests (PAR), it MUST NOT support Request Object references". | Answer posted here |
| Question & Answer | thanks for link to comparator tool - we notice that one of the banks isn't returning data, is that something that is been taken up with them or a potential issue with the tool? | Answer posted here |
| Question & Answer | Generally speaking, w.r.t. Decision Proposals - how can we raise feedback/concerns and ensure our voices are heard? Github vs email? | Answer posted here |
| Question & Answer | In terms of Data Latency, the following statement is available - "the requirement for data latency is that data presented via API end points should be commensurate to data presented via other primary digital channels" How could we interpret 'commensurate'? - at the same time as, or within seconds/minutes of other channels? https://consumerdatastandardsaustralia.github.io/standards/#data-latency | Answer posted here |
| Question & Answer | as an ADR if we get consent for data scope A & B : and then do a data request for A & C, we are ok that gets rejected in full as it is not a validate request... a validate request in our view is for A, B or A+B | Answer posted here |
| Question & Answer | For the Payments API – specifically for Direct Debits endpoints, what are examples of these Direct Debits that banks are expected to expose to Data Recipients. We interpret this as any scheduled direct debit for Home Loans, Personal Loans, Credit card. Is this correct? | Answer posted here |
| Question & Answer | 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? | An ISO 27001 certification does not meet the information security requirement for the unrestricted level of accreditation. The required assurance report must be prepared in accordance with the Australian Standard on Assurance Engagements (ASAE) 3150 Assurance Engagement on Controls standard, or an accepted comparable standard, and must address all aspects of the information security obligation and control requirements specified at Schedule 2 of the Consumer Data Right Rules. ASAE 3150 is an Australian method of auditing and reporting. The following are accepted comparable standards for assurance reports:
When applying for accreditation, an applicant may seek to use an existing assurance report prepared in accordance with ASAE 3150, or one of the accepted comparable standards. However, the existing report must be no more than 6 months old at the time of submission of the accreditation application, and if it contains only partial coverage over the required controls in Schedule 2 while require certain treatment for acceptance. See our Supplementary Accreditation Guidelines on Information Security for further information on what is required. |
| Ticket #43 |
I am reaching out in regard to question raised during today CDR call on sharing CDR Register production URL for the following endpoints : GetDataRecipentsStatusGetSoftwareProductStaus GetDataRecipents |
Documentation to be updated with Base URI of the CDR Register here |
| Question & Answer | will it be possible for an Accredited ADR Intermediary or OSP to use the token of an Accredited ADI Principal when seeking data from a DH, further I mean in place of needing their own unique token if acting behalf an ADI | Technical details for CAP Arrangements needs to be documented: CDR Issue 130 |
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
- No presentation this week
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:
| Ticket # | Question | Answer |
|---|---|---|
| Ticket #49 | I am having a look at the standards regarding DomesticPayeeCard and wondering if you can explain its expected use? Is it intended for payments to be made directly to a card number? If so, via what channel? Postoffice, app etc? Bpay Payments? Used to retrieve a card number? If we do not currently offer functionality to pay directly to a card, this API would not be relevant, but is marked mandatory - how should we proceed? |
- |
| Ticket #50 |
We have a question in regards to the re-authorisation process. In the latest version of CDS and CX guidelines we couldn’t really find anything related to it (https://consumerdatastandards.gov.au/standards/latestversion/) However we found a Data61 prototype (both re-authorise via data recipient and data holder) below that was created a while ago:
Do I understand correctly when I say that this is considered as a consent update? |
- |
| Ticket #51 |
We are seeking clarification on the definition of a ‘pre-registered payee’ that should be returned from the Get Payees and Get Payee Detail API endpoints. Is it correct to assume this is limited to payees/billers stored within a customer’s address book? That is, excluding any payees not saved in the address book, including payees where a customer may have made an ad hoc or recurring payment? |
- |
| Ticket #52 |
ANZ is looking for some clarity around log retention requirements. Based on the rules section 9.3 (1)(e) and 9.3 (3) highlighted below a data holder would be required to keep logs of instances where CDR data has not been disclosed in reliance of an exemption from the obligation to disclose for 6 years. As we understand it this exemption would include where we protect our system from malicious behaviour or high volumes (aligned to the NFRs) which would risk our platforms. Given these controls are generally performed at the first entry point to a data holder like a web application firewall (WAF) the data within these logs would be subject to the security controls of the regime. We are wondering if keeping the full log detail of these requests holds any value to the regime, we say this because at the point of capture the detail in this log cannot be tied back to a particular customer as the only thing that is present is a short lived access token which won’t have relevance to the customer until exchanged in the DH’s IDP. We understand these records are valuable in assisting construct counts for the reports and metrics endpoints but is the whole record mandatory or could we just keep a collection of the aggregated count information? There is also some concern from security teams over the nature of the data in these logs which may indicate attack information or potential threat vectors and this information should only be kept for a period of time (12-18 months) and then purged from the records. Please note: regardless of the WAF records decision, all refusals subsequent to WAF (within the ANZ domain) will be recorded. Given the concerns around the security and the real value of these logs we feel this requirement may need to be reviewed/revisited or simply clarified if we have understood this incorrectly. CDR Rule 9.3 - Records to be kept and maintained Records to be kept and maintained – Data holder (1)A data holder must keep and maintain records that record and explain the following: (d) disclosures of CDR data made in response to consumer data requests; (e) instances where CDR data has not been disclosed in reliance on an exemption from the obligation to disclose CDR data; Specificity of records (3) Each record referred to in this rule must include the date and time when the record was made and, if applicable, the date and time when the event described by the record occurred. Period for retention of records (5) Each record referred to in this rule must be kept for a period of 6years beginning on the day the record was created. Regulatory reporting requirements defined in the data holder reporting form:
A reference to 'requests you received' includes all requests you received, regardless of whether the request was successful or not.
A reference to a 'refusal' to disclose CDR data is intended to cover all refusals to disclose CDR data. For the avoidance of doubt, circumstances where the data holder must report on the number of refusals to disclose CDR data include for technical reasons, refusals where it is considered necessary to prevent physical or financial harm or abuse, and refusals where the data holder has reasonable grounds to believe disclosure of some or all of the requested CDR data would adversely impact the security, integrity or stability to the Register of Accredited Persons or the data holder's ICT systems, and any other reason the data holder has not disclosed CDR data in response to a request. |
- |
- TBA
| # | Question | Answer/ Action |
|---|---|---|
| #1 |
Back in March 2020, ACCC released some guidance for participants to gain an exemption under s56GD. We noticed there hadn't been any additions to the register for some time. Is this an indication no further exemptions have been granted or that there is a backlog of exemptions to be published? As an example, have any Data Holders been given exemptions related to their Product Reference Data API? |
- |
| #2 | regarding the discussions on concurrent consent would you like some user cases from an ADR perspective, in advance of that meeting? | Yes, that would be fantastic! Please send these through to contact@consumerdatastandards.gov.au |
| #3 | For Mark, what was an example of a digital id that could not be used as a user identifier? | - |
| #4 | Can we get a practical scenario where an access/refresh token is revoked but the consent corresponding to that token is still active? because when ADR calls revocation API of DH, only the tokens are revoked but the consent is not impacted? | - |
| #5 | regarding ticket#50: why would we accommodate re-authorisation initiated from DH side? We don't allow consent authorisation from DH side today. So don't see how re-authorisation can be initiated from DH side. | - |
| #6 | If an ADI wishes to go live with Prodcut Reference Data functionlaity prior to 1 Oct 2020 are they required to provide notification to the ACCC (or any other entity) or attain certification in anyway? | - |
| #7 | Can I please check with Direct Debit information under bank:regular_payments:read. Is the Data Holder meant to provide details of direct debit arrangements they have with the consumer OR direct debit transactions that have been processed on the consumer's account | - |
| #8 | Can you please clarify what reporting is required if we go live with our PRD prior to Oct 2020. My understanding is that the Admin API (where reporting is handled) is not yet required to be stood up. | - |
| #9 | is it possible for an update to github issue #267 for a future meeting Issue 267 | - |
| #10 | To report on 'refusals to disclose' for ACCC reporting - are technical reasons covered by response codes 429 Too Many Requests and 403 Forbidden? Are there any others defined or better suited for business reasons? | - |
| #11 | Which is the preferred channel for CDS technical questions - github, zendesk or this call? | - |
| #12 | For the Excel reports listed in the link above, when is the end of the 6 month reporting period? | - |
| #13 | On the CDR Arrangement Management End Point it talks about Client Authentication is Required (for verifying Data Recipients) and also it mentions that for Data Holders, Data Recipients must be authenticated when they call this end point using a valid Access Token as specified in section 10.3 of [OAUTH2]. Are we talking about the Access token using token endpoint or client Authentication using private_key_jwt | - |
Other business
- TBA
- TBA
- TBA