ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (22nd of October 2020) - ConsumerDataStandardsAustralia/standards GitHub Wiki

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (22nd of October 2020)

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

Agenda

  1. Introductions
  2. 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.

Recording

The Consumer Data Right Implementation Calls are recorded for note taking purposes. All recordings are kept securely, as are the transcripts which may be made from them. No identifying material shall be provided without the participant's consent. Participants may [email protected] should they have any further questions or wish to have any material redacted from the record.

Acknowledgement of Country

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.

Actions

Type Topic Update
Standards 1.5.1 Published Link to change log here
Decision Proposal - Energy Decision Proposal 116 - Billing Data Payloads View the Decision Proposal 116 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
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]

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 - Banking
  • DSB Technical Standards - Energy & Engineering

Presentation

The ACCC’s rules team will give an overview of the proposed CDR rules expansion amendments. This will include an opportunity for Q&A about any aspect of the proposed rules and the consultation, which closes on 29 October 2020

Link to the slides

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.

Current received pre-submitted questions:

Answer provided

Ticket # Question Answer
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? It is true that closed accounts should be in the 'available' list if they are eligible. The CX Guidelines demonstrate how DHs could tend to the issue of accounts being eligible but unavailable for some reason; they do not suggest that closed accounts should be considered unavailable or ineligible by default. The use of a closed account in the CX Guidelines is purely illustrative. The classic example considered for the unavailable account design pattern is a joint account that has not been made available for sharing, but there are other possible scenarios where a data holder could implement this design pattern to communicate that accounts are not displaying for other reasons. The unavailable account item is an optional aspect of the CX Standards for the account selection step. The model was produced to be flexible enough to apply to a range of situations if required. How/if a DH implements this pattern is at the DH's discretion.
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? This detail was not included in the CX Guidelines but we would recommend allowing the consumer to request another OTP at this authentication step.The standards don't preclude multiple retries and are intentionally silent on how many retries to allow. It would be considered good practice to limit the number of failed retries before cancelling the request. Unlimited retries will create an unnecessary security vulnerability. How data holders deal with incorrect authentication details is at their discretion, which is expected to have regard for any identified phishing risks and be in line with the data holder's existing security posture. An example for requesting another OTP will be included in an upcoming release of the CX Guidelines.
215 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. As you may be aware the ACCC has developed a Conformance Test Suite that includes a CTS Register and a CTS Accredited Data Recipient, as illustrated on slide 2 of the Conformance Test Suite Update presentation. The CTS is made available to ADIs during the on-boarding process. The ACCC is requesting ADIs interested in commencing the on-boarding process to get in touch with us by emailing [email protected]. To commence the on-boarding process your organisation, or Legal Entity, must have requested access to the CDR Participant Portal. This process is described in the On-boarding Guide which has been released in Draft; we encourage and welcome feedback on this document by 23 October 2020. The ACCC understands open source options for mock participants exist, although we’re are unable to provide details, which may assist with conducting a range of tests outside of the CTS. The process for non-Major ADIs joining the ecosystem will be different to that of the Major ADIs. The ACCC is not aware of the approach other non-Major ADIs are taking however we believe there is significant benefit in community lead discussion on this. We encourage use of the Community option available in the Consumer Data Right Support Portal to generate interest. Additionally you may be aware the ACCC recently published November Test scenarios, available here (§%09https:/www.accc.gov.au/focus-areas/consumer-data-right-cdr-0/cdr-phase-2-test-strategy-november-2020), written against CDS v1.5.0 and CDR Register v1.2.2. July 2020 test scenarios, written against CDS v1.3.0 and CDR Register v1.1.0, are also being considered for publication. We hope this helps and welcome any feedback you may have.
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? The pending example does not refer specifically to a consent or authorisation. The ‘pending’ design was devised to apply broadly to any situation where an action or activity relating to an authorisation is pending. It may be where disclosure itself is paused or interrupted because an ADR has been suspended, or the DH pauses disclosure due to suspicious activity. It may also refer to an action required by the user, such as a joint account election needing to be approved. Or it could be that an ‘empty authorisation’ exists where a consent is active, but no data is being shared because no accounts are associated with that consent. The use of ‘pending’ does not necessarily mean that the consent or authorisation itself is technically ‘pending’. The term ‘pending’ is only an example and should not be seen as prescriptive. How and if the 'pending' state examples are implemented are at the discretion of the DH.
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 We have published a response to issue 222 (which reflects issue 296) that includes a recommendation for this issue. It also suggests a possible future state based on an amendment in the v2 rules that may be warranted as CDR evolves. Your comments on that issue would be welcome to help move it towards a resolution.
105 I can’t find a response. Having difficulty navigate. Can you please confirm where response for #296. In particular clarity around source whether it be Brand, ADR or Software product as source for CX. We have published a response to issue 222 (which reflects issue 296) that includes a recommendation for this issue. It also suggests a possible future state based on an amendment in the v2 rules that may be warranted as CDR evolves. Your comments on that issue would be welcome to help move it towards a resolution.
68 #296 CX Stream: Use of ADR name and logo in CX Where the CX designs refer to an ADR name and logo should this be ADR name/logo or where provided - Brand or Software product? The CX should be consistent from consent through to authorisation establishment and management#297 Rules Account Owners added after authorisation.For accounts (typically businesses) an account owner can be added after an account has been opened. If a data sharing consent has been established when only one owner was on the account and subsequently an additional owner was added does the data holder need to stop sharing the data on that account (Phase 1 only single account holder) or pause sharing until the second holder has provided authorisation (Phase 2) If a third owner is added should disclosure of that account then be stopped and the account become ineligible to share. Additionally – Im sure this has been raised before but I could find the status?? The privacy safeguards require Dataholders to provide customers the ability to have their data resent / qualified following a data correction. Is there a mechanism being developed in the standards to support this requirement? We have published a response to issue 222 (which reflects issue 296) that includes a recommendation for this issue. It also suggests a possible future state based on an amendment in the v2 rules that may be warranted as CDR evolves. Your comments on that issue would be welcome to help move it towards a resolution.
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? Yes, your interpretation is correct. The FAPI conformance suite wouldn't be aware of the x-cds-client-headers header as it is a CDR specific addition.
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. The approach you have indicated in your question would be considered compliant by the DSB.
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? All masking requirements are explicitly stated in the standards. WIth specific regard to PCI compliance and Credit Cards, the CDR standards have taken the position that we do not want to introduce PCI issues into the CDR implementations so all Credit Card numbers should be masked. This applies to the unmasked version of the account number field in the account details end point.
224 In relation to the time-based data provided through the Get Metrics API for the various fields – currentDay, previousDays, currentMonth, previousMonths – https://consumerdatastandardsaustralia.github.io/standards/#get-metrics Should the values be based on the time of the call translated to the currentDay/Month as at ‘permanent AEST’ or aligned to the ‘current day’ of the ‘requestTime’ as at UTC which could be the raw value the data is stored at? (where the specified ‘day’ may be 10 hours behind the time of a call made at AEST, but would actually be a full day of data.) Hope that makes sense. Guidance from the ACCC for the (six monthly) data in the Reporting forms for Rule 9.4 was that UTC-based aggregation for each period (including number of requests, rejections etc.) was acceptable as long as that basis was noted in the submitted report.Some related discussion in these issues for reference –On ‘Permanent AEST’ for traffic periods –https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/47#issuecomment-560096824On ‘Offset with reference to UTC’ for date formatted values –https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/98#issuecomment-576224178 Currently the data standards are silent which means it is at the discretion of the Data Holder what timezone they respond in. This is useful where architecture constrains easily returning under a mandatory timezone. Given the metrics are relative in nature, this is not seen as an issue.The DSB does see value in creating a convention to deal with this. The DSB would recommend using AEST as the timezone of the metrics data unless the Data Holder has a good reason not to do so.Current day is representative of the time elapsed in the last calendar day based on the timezone of the Data Holder. This may vary between Data Holders and the collection time may also vary based on the ACCC requirements. Hence, current day represents a request to provide a point in time view of metrics for the current day. Noting that the DH may have some latency in log ingestion and processing, the response may not reflect an accurate count of metrics up to the exact time of the request. It probably pays to be a little more accurate with the wording on "current day"Current day is representative of the time elapsed since the end of the previous day, based on the timezone determined by the Data Holder for CDR reporting purposes. Time elapsed since the end of the previous day is analogous to the commencement of the current calendar day.In other words, it's the not the timezone the Data Holder operates business in, it is the timezone the Data Holder has chosen for reporting metrics data.
226 In the Get Metrics API response schema many of the Properties are marked as conditional, but there are no conditions specified. https://consumerdatastandardsaustralia.github.io/standards/#tocSresponsemetricslistv2 Could you please provide some details or reasons for this? For higher order objects this is a mistake.For lower level properties some are intentionally conditional based on the request query. If the response is filtered by "period" the response would return the appropriate time period conditional to what the client requested. Filtering by current day vs previous days is an example. Some properties should not be treated as conditional such as "customerCount" and "recipientCount" because they are not filtered on time period. Raising a change request to deal with these issues would be a great way to go. Raised here

Response pending

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
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
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
208 Seeking further clarification with regards to the CDS rule - Part 5, Division 5.2 (Rule 5.10) which states that5.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/#tocSbankingproductdepositrateReference: 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? -

Notes

  • TBA

Question and answers

# Question Answer/ Action

Other business

  • TBA

Appendices

  • TBA

Next Steps

  • TBA