-
Notifications
You must be signed in to change notification settings - Fork 56
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (15th of October 2020)
CDR API Stream edited this page Oct 15, 2020
·
7 revisions
When: Weekly every Thursday at 3pm-4.30pm AEDT
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
- 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
- Actions
- CDR Stream updates
- Q&A
- Any other business
Meeting notes
- 5 min will be allowed for participants to join the call.
We acknowledge the Traditional Custodians of the various lands on which we work today and the Aboriginal and Torres Strait Islander people participating in this call.
We pay our respects to Elders past, present and emerging, and recognise and celebrate the diversity of Aboriginal peoples and their ongoing cultures and connections to the lands and waters of Australia.
| Type | Topic | Update |
|---|---|---|
| Standards 1.5.1 | Published | Link to change log here |
| Maintenance | 5th Maintenance Iteration underway | List of scope and agenda(s) can be found here |
| Maintenance | Next week's 5th Maintenance call will be moved to 2pm AEDT Thursday 15th of October 2020,originaly scheduled for 2pm AEDT Wednesday 14th of October 2020 | Community to take note, update to invite to be sent shortly |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| ACCC Newsletter | To subscribe to ACCC Newsletter | Link here |
| Banking Product Comparator | For who wish to publish their endpoints on the Banking Product Comparator Tool we have put together some tips and simple instructions to get you going | Check out the guide here at the CDR Support Portal |
| Guide | New Guide published on Collection Arrangement | CDR Support Portal Guide |
| Request for clarification | These are to be moved to the CDR Support Portal from Consumer Data Standards Maintenance GitHub | Current requests will be answered and closed out, for new requests - we ask you raise these via the form here or via email to [email protected] |
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 - Banking
- DSB Technical Standards - Energy & Engineering
CDR On-boarding Guidance
Overview of the recently published draft CDR On-boarding Guide and feedback approach
Presented by David Franzmann (ACCC)
Slides can be found here
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.
Current received pre-submitted questions:
| Ticket # | Question | Answer |
|---|---|---|
| 173 | Appreciate if we could get some answers to these github issues. Expectations when a consumer closes their account/relationship with an ADR Issue 313 |
Taken on notice |
| 177 | Hi – Just looking for an update on the required approach for use of ADR/brand/software product names and logos as requested through these issues. As the non-majors progress their builds it is becoming increasingly important to have direction on this to ensure consistency across the ecosystem. https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/222 https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/296 |
Taken on notice |
| 189 | I have been unable to find guidance on when a CDR Policy must be made available by Data Holders. A literal reading of the regulation would suggest that it should be made available as soon as any data sharing occurred (i.e 1 October for most data holders). However, the vast majority of a typical CDR Policy is only relevant for customer data sharing. Can you confirm that a Data Holder does not need to provide a CDR Policy until they begin customer data sharing? | Taken on notice |
| 190 | I am seeking guidance on how "wholesale" products are handled in the CDR. In this context I'm talking about products that are sold via alternative channels, but branded by the Data Holder. Examples would be term deposits sold through marketplaces such as Australian Money Market or Cashworkz, or loans sold through brokers. In these cases, the terms and conditions may differ from directly sold retail products. As the channels are generally not ADIs and therefore not Data Holders, I would assume any obligations would fall back on the product originating ADI. It's unclear if these products are "publicly available" under the CDR definitions as they are not sold directly by the ADIs concerned. Additionally, the terms and conditions can vary across the re-sellers and so if required, how should they be exposed in the PRD APIs? A separate entry for each re-seller, or a generic entry with, for example, no rates given? Any additional guidance around "wholesale" products sold through alternate channels would be appreciated. Thanks. | Taken on notice |
| 192 | We, are looking for clarity on requirements that are compulsory for account & transaction data on Phase 1 & 2 products, specifically for joint accounts. We understand that ACCC provided the Joint Account Guidance where scenarios are outlined. The question we have is on the status of Joint Account Guidance document – are the requirements derived from this document compulsory to implement, or only suggested but not compulsory? Specifically the next two requirements – are they compulsory to implement for account & transaction data on Phase 1 & 2 products release: 1. ‘Pause’ via JAMS (Scenario 4a & b) If one of Joint Account Holders removes an election via JAMS for an account that is already in an active sharing arrangement with 3rd party, authorisation should not be withdrawn, but the data sharing for that account should be stopped. Removal of election via JAMS for joint account does not cause removal of this account from authorisation. It only caused the data sharing to stop for this account. 2. Resume via JAMS (Scenario 4c & 7) After the requirement above, if both Joint Account Holders elect though JAMS for this same joint account that is ‘paused’ in an active sharing arrangement to be shared back (meaning this account is marked back as ‘available for data sharing’), the data sharing should continue as this account was never removed from authorisation in the first place. |
Taken on notice |
| 195 | Could you please provide clarity about what “a product that is publicly offered” (under the ACCC CDR Rules) and “products that are currently openly offered to the market” (under the CDR Standards for Banking APIs) means when it comes to sharing required PRD. Specifically, if a phase 1 product is currently only offered by direct invitation to existing customers (i.e. not through online application channels), is PRD required to be shared? | Taken on notice |
| 196 |
https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/329 https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/330 |
Taken on notice |
| 202 | Seeking clarification on withdrawal of authorization at the Data Holder end. Is the Data Holder mandated to provide an alternative for authorization withdrawal beyond the Consumer dashboard? The rules (shown below at the end of this email) states two options using the "or" keyword implying that one or the other is adequate. I would be well within the guidelines by providing this capability only in the Consumer dashboard. However, I was wondering what if the Consumer Dashboard channel (say Internet Banking has an outage (not a common occurrence these days, however, we have seen these issues in the past). Also, Internet Banking can have scheduled maintenance say for 5-6 hours (e.g once a year scheduled maintenance), and if the consumer wants to withdraw authorization during this period they would be inconvenienced. Would love to hear comments and thoughts from the experts at Data61 and ACCC. The rules state the following: 4.25 Withdrawal of authorisation to disclose CDR data and notification (1) The CDR consumer who gave, to a data holder, an authorisation to disclose particular CDR data to an accredited person may withdraw the authorisation at any time: (a) by using the data holder’s consumer dashboard; or (b) by using a simple alternative method of communication to be made available by the data holder for that purpose |
Taken on notice |
| 204 | Clarification on Data holder providing link to CDR policy: This question relates to Part 7 – Rules relating to privacy safeguards, section 7.2.1. According to this rule, a Data Holder (DH) will need to include details of the complaints process on the Consumer Data Right (CDR) policy.. The question is at which stage (wireframe) is the CDR policy expected to be shown on Data holder side. As per the CX guidelines, the CDR policy is only visible on the Data recipient Consumer dashboard as attached. |
Taken on notice |
| 205 | Within the Consumer Experience Guidelines (v1.4.0) it is stated that Data holders SHOULD prioritize information that is important to consumers. This MAY include using tabs (e.g. active, pending, archived). Can we please have clarification on the "Pending" status significance for Data Holder with regards to consent - what would be the real-time scenario when the authorization is in this special state? |
- |
| 206 | In the Get Accounts API response, "maskedNumber" is the masked version of the account. Whether BSB/Account Number, Credit Card PAN or another number. Masking of the data is to be done by hashing out all but the last four digits of the account. Is there any additional requirement around the sensitive data masking to achieve compliance with standards such as PCI especially for Credit Card? | - |
| 207 | We intend to measure availability of the (/Authorisation Endpoint) by using an un-registered ADR client , and if the system responds with an error thereby blocking the request to proceed, we will consider that API is functional. This saves us from constructing an ecosystem of test entities (required if we want to proceed to successful issue of token) and it does not add spurious calls to our metrics. We believe it is compliant with the definition of availability on the standards. We would welcome any comment/advice on our intended approach. | - |
| 208 | Seeking further clarification with regards to the CDS rule - Part 5, Division 5.2 (Rule 5.10) which states that 5.10 Other conditions on accreditation (1) The Data Recipient Accreditor may, in writing: (a) impose any other condition on an accreditation: (i) at the time of accreditation under subsection 56CA(1) of the Act; or (ii) at any time after accreditation; and (b) vary or remove any conditions imposed under this rule. and that ... (5) The Accreditor: (a) may, but need not, give public notice of a condition or variation imposed or removed under this rule; and (b) may do so in any way that the Accreditor thinks fit. Example: The Accreditor could give public notice of a description of the effect of the conditions, rather than of the conditions themselves. Background: Given that these conditions could be varied and nebulous there is the potential of impact on data holders when engaging or providing CDR Data to an Accredited Data Recipient (ADR) As example - What if the condition is: 1. the ADR is only allowed access to a subset of CDR Data; or 2. only able to receive a particular period of CDR data; or 3. only able to hold authorisation for a particular period. Question: Due to the above are Data holders required to identify and comply with these conditions; and if there is a breach of a condition due to CDR data passed from a Data Holder to an ADR, where does liability sit? Adding some more clarification on the context related to the question, 1. Will these conditions placed on the ADR , be within the metadata update endpoint i.e. DH be informed of these new imposed conditions via metadata update? 2. Regardless of whether it’s in the metadata end point or not, who will be liable to ensure the correct information has been shared between the DR and the DH? a. Will it be on the DR – that they are only requesting the information they have been accredited for? b. If a DH has packaged information, and there is a data set in that package – is it up to the DR to only consume the information they are conditioned to or is it up the DH to remove the set of information DR is not allowed to access ? |
- |
| 209 | Where there is a joint account with a Power Of Attorney, what are the rules around sharing data, when both parties are required to authorise the sharing of data? The Power of Attorney question also relates to individual accounts. Where a request has been made, however it has been made from the Power of Attorney, what rules apply to sharing the data? If we have deemed the transaction not be be causing financial or physical harm, is there an issue with sharing the data? |
- |
| 210 | We have noticed the answer provided on ZenDesk in relation to the minimum product grandfather period (https://cdr-support.zendesk.com/hc/en-us/articles/900002707406-Minimum-Product-Grandfather-Period), which asked if there were criteria required for products which have been grandfathered. Based on the response that said “No. If the product is open or was closed for less than 12 months it should be included." We note that products can either be on-sale or not-for-sale (grandfathered). We therefore seek clarification on whether the intention of the previous response with respect to required consumer data is as in the attached table. |
- |
| 211 | I had raised an issue here on github https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/321 Hoping that the enumeration is a complete list and that the description has a typo error in specifying "base" as a rate type which is not available in the enumeration list. https://consumerdatastandardsaustralia.github.io/standards/#tocSbankingproductdepositrate Reference: The type of rate (base, bonus, etc). See the next section for an overview of valid values and their meaning |
- |
| 212 | Please explain what return code should be specified in the case of an incorrect 'page' parameter. i.e. Given an DH has 25 records that match a certain request, in that request the ADR specifies - page-size of 10 AND page=5 Then clearly some form of error should be returned, as page 5 does not exist in this case. Questions; - Should the DH return a 200 with no data, page 1 by default, or some 400-range error, and if so which one. - Additionally, where is this specified in the data standards? |
- |
| 213 | NAB is running FAPI-RW certification conformance tests against our CDR banking APIs. The test suite is sending the requests to our authenticated banking APIs which include x-fapi-customer-ip-address as one of the headers but NOT the x-cds-client-headers. Our APIs are rejecting the request as it doesn't have the x-cds-client-headers header. - The CDR standards define the x-fapi-customer-ip-address header as "The presence of this header indicates that the API is being called in a customer present context." - The CDR standards also define the x-cds-client-headers header as "Mandatory for customer present calls." Could you confirm NAB's interpretation that if the header x-fapi-customer-ip-address is present in the request, then the x-cds-client-headers must be present as well for the request to be valid? |
- |
| 214 | Wanting to confirm the following in the phasing table: 1. Part 4 for 1 Feb 2021: is this a MUST timeframe or can FI's fall back to the 1 July 2021 as the MUST date? 2. Part 3 for 1 July 2021: has it been finalised that CDR Consumers (customers/members of the bank) can request their information directly from the FI? |
- |
| 215 | Hi, We are interested to understand how the Big4 banks approached testing their Data Holder solutions? When we look at our testing needs, we see that we will have to potentially create a mock of the ACCC registry as well as a mock ADR in order to perform the necessary testing of our Data Holder solution. We welcome any advice or guidance on how to effectively do this and are also interested in how other banks have handled this. Thank you. | - |
| 216 | From the wireframes it does not look like a customer/member can request another OTP if they did no receive the initial one or they input the initial one incorrectly. Can you please confirm that this is the case? And if so, if the incorrect OTP is input, that the customer/member will need to go back to the User Identifier screen and start the process again? | - |
| 217 | What is the expected behaviour on the CX for closed accounts? In the CX wireframes closed accounts are displayed in the "Accounts unavailable for sharing", however under the previous question "Expected API Behaviour for Closed Accounts" it states: "All APIs are in scope for closed accounts. However scheduled payments and direct debits APIs should return a 200 OK with an empty response. It would still be valid to allow ADRs to get the details on an account and any past transactions on the account even if it is closed. You're correct that the ADRs would use the BankingAccount::openStatus to deduce if the account is closed or not". The API responses indicates closed accounts should be displayed in the "Accounts available to share" section of the CX. Which path is a DH to follow? |
| Ticket # | Question | Answer |
|---|---|---|
| 168 | Definition of 'status' and how health check status can be determined? | CDR Support Portal Article |
| 169 | Definition of 'status' and how health check status can be determined? | CDR Support Portal Article |
| 179 | InfoSec Endpoints and reporting for GET Metrics API | CDR Support Portal Article |
| 188 | ID Permanence for Scheduled Payments Schema Fields | CDR Support Portal Article |
| 197 | CommonOrganisation - lastUpdateTime field clarification | CDR Support Portal Article |
| 198 | Get Product Detail v2 & v3 - feeType impact | CDR Support Portal Article |
| 203 | The response addresses the continued support for V2, which currently has no published end-date. End-date for Version 2 aside, we still have a scenario where we need to go live with Phase 2 PRD on Feb 1st, and then enable V3 by Feb 28th. This may be more of a question for the ACCC, as it would simplify things if the Feb 1st ACCC date for Phase 2 PRD, was shifted by 28 days, to align to the DSB V3 date of Feb 28th. Then the “other adi” sector could go live with Phase 2 PRD at the same time as we go live with V3, and do a single release instead of two releases. We understand that we would also need to support V2, but we’re trying to avoid multiple releases where possible, and would like to see alignment between the ACCC & DSB obligation dates. Is this something that can be considered and discussed with the ACCC please? |
The reason for retaining version 2 of the standards is that some clients have already implemented to this standard. Any ADR that is specifically relying on the fee structure to the degree that this issue is relevant will be motivated to upgrade to v3 as soon as possible but not all users of the APIs are using all of the data. There are a variety of use cases. For this reason the DSB prefers to maintain support for older API versions for a period of time. |
- TBA
| # | Question | Answer/ Action |
|---|---|---|
Other business
- TBA
- TBA
- TBA